Lessons from Equifax: Get a Software Risk Scorecard


The biggest lesson learned from the Equifax breach is that executives and application owners need a software risk scorecard that clearly outlines KPIs around software structural quality and security.

Since the focus of the hack was around open source components, it raises the critical issue of security across the software supply chain. Most large industrial apps are now built with a substantial amount of open source software, like Struts. In some cases, third party software incorporated in an app may contain components of unidentified origin. All externally acquired software must be tested and vetted with the same rigor you would hope is being applied to internally developed software, but often this is not the case, as we see with Equifax.


What are the business consequences of such breaches?

We can expect to see lawsuits from individuals (class action), in addition to lawsuits from banks and credit card companies who are going to have to exchange a huge number of credit cards and will want to pass that cost on to Equifax. The credit ratings agencies are already not liked by the banks, with blockchain alternatives coming online. One could see long-term business implications that include a complete restructuring of the industry. Some think this security breach is the beginning of the end for the big three – Equifax, Experian and TransUnion.

How likely are other firms to suffer similar fates?

In a word – very. Most organizations are unaware even of known vulnerabilities and weaknesses in custom software. When our team spoke to a CISO about this last week, he told us that so far in his experience, there’s been no penetration testing situation where the red team hasn’t prevailed. (Red teams are the ethical hackers that lead penetration exercises.) CAST’s Chief Scientist, Bill Curtis, advises CIOs and CISOs to assume they’ve already been breached. The question they should be asking themselves is “How can I now protect my company’s data and keep it from being taken or exploited?”.

What, if anything, could CAST have done to avoid this breach?

It is of course difficult to guarantee security 100% in all circumstances, and hindsight is a wonderful thing. However, there are some actions which will absolutely minimize the risk of similar breaches:

CAST Highlight can be used to conduct a rapid portfolio-level analysis to immediately discover common open source frameworks in your application.

Our Application Intelligence Platform (AIP) can automatically identify which applications have Struts, which may very well be in use in the IT department without the knowledge of anyone on the executive team. It will expose known vulnerabilities in mission-critical applications currently in use by large companies. It will do the same for the 130 other open source frameworks which are in frequent use in enterprise applications. AIP can then show how Struts, and most of these other frameworks, are misconfigured and how to fix them.

CAST would have detected this Struts vulnerability even before it was publicly announced, helping protect security-sensitive applications from zero-day attacks. The minute a vulnerability and its remediating patch are announced as a numbered CVE (Common Vulnerability Enumeration), an IT organization has an obligation to its customers and shareholders to get the patch installed on all affected applications as a first priority since hackers are now on the prowl.

So, if an open source vulnerability is made known, what should your team do?

  1. Conduct a portfolio-level scan to see if you are vulnerable to these open source flaws (week one). If you are already a CAST customer, that scan is simply a look in the CAST portal. Or, you can have CAST proactively send you a list of affected applications.
  2. Conduct a system-level analysis for applications that tested positive for the vulnerability and identify how it affects other components in your system.
  3. Carry through a remediation action plan for apps that need fixing, with an upfront estimate of time to fix.
  4. Rest assured your applications are no longer vulnerable – priceless.

What is the bottom line?

If you’re not getting regular information about the structural quality around construction and composition of your software, you should do a quick scan of your application portfolio. But, the best approach would be to proactively scan the portfolio at least once a month to identify any significant new dangers introduced by your development teams and vendors.

Lev Lesokhin
Lev Lesokhin EVP, Strategy and Analytics at CAST
Lev spends his time investigating and communicating ways that software analysis and measurement can improve the lives of apps dev professionals. He is always ready to listen to customer feedback and to hear from IT practitioners about their software development and management challenges. Lev helps set market & product strategy for CAST and occasionally writes about his perspective on business technology in this blog and other media.
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item