What We Can Learn from the Accellion Breach

News about the recent Jones Day / Accellion vendor data breach highlights just how difficult third-party risk management (TPRM) is in practice. With this particular breach, Accellion’s “legacy” large file transfer product, FTA, was identified as the affected target. In this article, I’m going to cover a few interesting observations from some of the communications used to describe the event and mention five ways you can fortify your TPRM program to enhance your due diligence when evaluating vendors.

THE PRESS RELEASE

The official FTA Security incident press release, from Accellion was where I started. By examining some of the language they used, I hoped to better understand what really happened. Surprisingly, one of the first things that stood out was the terminology used to describe the affected product:

• legacy

• 20-year-old

• end-of-life

Contrast this with the terminology used to describe their newer and preferred solution, the “kiteworks” platform:

• entirely different codebase

• state-of-the-art security architecture

• segregated, secure development process

As a result, Frank Balonis, Accellion’s CISO recommended “all FTA customers to migrate to kiteworks...We remain committed to assisting our FTA customers, but strongly urge them to migrate to kiteworks as soon as possible.”

To Accellion’s credit, they are working with at least one managed bug bounty provider to assess their products and it’s hard, if not downright unfair, to criticize them for trying to migrate customers to a newer and conceivably more secure product offering. In any case, there’s no benefit in playing the blame game after the fact. The question then becomes, what could Jones Day have done to avoid falling victim to the consequences of relying on a vendor with legacy, 20-year-old, end-of-life software? And how can other organizations learn from this story to better protect themselves?

BUG BOUNTY TO THE RESCUE?

As mentioned earlier, Accellion does participate in a managed bug bounty program, but this breach is related more to third-party risk management. What’s the difference, and what does it have to do with bug bounties?

This led me to think a bit more about how this breach relates to the bug bounty delivery model. As mentioned in one of my previous posts about crowdsourced security, I believe that bug bounties have their place in the security management ecosystem and provide their customers with an opportunity to remedy a vulnerability, ideally, before it’s exploited.

However, third-party risk management is a complicated use case that doesn’t really fit well with the traditional bug bounty delivery model. One of the biggest hurdles is that most contractual agreements with third-party vendors are unlikely to allow unfettered, continuous testing – for a bug bounty – against their environments on behalf of their customers.

Not only do they not typically allow access, but even if they did, a single point-in-time test hardly provides the ongoing vigilance an organization would need to consider a third-party vendor secure. So, while Accellion took steps to manage risk by enrolling in a bug bounty program, there’s more work to be done to provide the appropriate assurances to their customers that their products are indeed secure.

DROPPING THE S-BoM

At its most basic form, a software bill of materials (SBoM) includes all proprietary, open-source, third-party libraries, and associated software licenses that comprise a company’s “product,” which could be purely software or embedded code within a device. The process is similar to how we think about the dynamic nature of the attack surface – software composition works in much the same way.

While automated tools are available to help generate a software bill of materials inventory, they can also turn into an exceptionally challenging endeavor if the company develops or manufactures hundreds or thousands of products with an equally diverse number of versions and combinations of components. This now becomes a due diligence effort to ensure the SBoM remains up-to-date, relevant, and available to inform and assess risk.

Having an SBoM at the ready is a great start, but, as the old saying “garbage in, garbage out” goes, the quality, accuracy, and completeness of this dataset is a key step toward a successful risk mitigation strategy. An updated SBoM allows you to cross-reference any potential issues against vulnerability databases or threat intelligence feeds that may indicate your business is at risk. The benefit of this is that you can discover some actionable insights to actually help you secure against those risks by analyzing feeds in a single stream.

Due to the terms mentioned earlier in Accellion’s security advisory, SBoM is a relevant topic for this breach – not only for Accellion itself, but also for Jones Day and third-party risk management in general. While there’s no way to know definitively if SBoM is used as selection criteria for their vendors, it most certainly should be moving forward for Jones Day. It’s apparent Accellion was preparing to decommission the affected FTA product, which also stands to reason that the contents of FTA’s SBoM would have reflected a legacy, 20-year-old product that would have indicated its reaching end-of-life status. All key terms that should raise a red flag to your security team when choosing a solution from a vendor that may interface with sensitive customer data.

CONCLUSION

This article is not intended to pass judgement on Jones Day, Accellion, the affected product, or the breach itself. Instead, this news is just the latest example we can use to learn from and improve our approach for mitigating third-party risk – a challenging topic itself. So, what steps can your organization take to manage third-party risk? Here are five takeaways that will help you evaluate how serious your vendor is about security:

1. Take the time to research and review past security disclosures from your vendors. Do they appear genuine, transparent, and embrace the reality that breaches happen? If so, then it’s a good sign that they’ve likely got a plan in place to effectively respond to, and limit the damage caused by, a breach. However, stay vigilant and trust but verify as appearances can be deceiving.

2. The existence of a bug bounty program is good, but it’s not enough. While your vendor may be enrolled in a managed bug bounty program, it’s not a one-to-one replacement for security assurance, and certainly presents challenges in a third-party risk management use case.

3. Ask whether your vendor maintains a Software Bill of Materials (SBoM). As with a bug bounty, the mere existence of an SBoM isn’t enough. Inquire about how your vendor keeps their SBoM current (preferably through automation) and what benefits they receive from doing so. If the answer is “for compliance” and not associated with proactively managing risk, then that could be a red herring.

4. Don’t forget about the Secure Software Development Lifecycle (S-SDLC). Inquire about how your vendor implements secure software development principles when building products. If possible, ask to speak directly to engineering leadership and look for a mature, documented, and repeatable process.

5. Remember, breaches happen. While the statement from Jones Day indicates that the sensitivity of the data involved in the Accellion breach is “mundane,” it behooves an organization to take note of the sensitivity of data that a vendor will have access to and inquire about the controls used to protect it. Breaches happen, but security assurance isn’t about perfection; it’s about staying vigilant and maintaining an acceptable level of risk across your organization.