Comparing the 2018 report to 2017, we saw an increase in the length of time to identify and contain a breach
On September 7th, 2017, Equifax publicly announced a massive data breach, affecting approximately 143 million U.S. consumers. It later updated that number to 148 million affected consumers.
By exposing sensitive personal information, including social security numbers and birth dates, and for some people, credit card numbers and driver’s license numbers, Equifax put consumers at risk of several types of identity theft and fraud.
Today marks the anniversary of the Equifax breach, but what, if anything, has changed one year on?
Tim Mackey, technical evangelist at Synopsys, says: "While I’d love to say that Equifax was a turning point in application security, the 2018 OSSRA report showed that of the analysed code bases containing Apache Struts, a third of them still contained a version vulnerable to the same bug which impacted Equifax following its disclosure.
"Putting this observation against the backdrop of corporate security strategies, it’s fair to conclude that a lack of awareness of precisely what’s in a given software application and its “stack” is part of the problem. Put another way – you can’t patch what you don’t know you’re running.
"The question then becomes one of gaining awareness into the full stack of dependencies and the risks present. For example, containerising applications using Docker and deploying them on any number of platforms powered by Kubernetes is an increasingly popular development paradigm.
"That application container will be formed of content created by a “base-image” author, a development framework like Struts and the actual custom application code. While testing of the custom application for security and functional issues is common place, testing of the development framework and base-image are assumed to be done by others.
"In traditional application development, libraries of code are often used in creating the application. Those libraries are implicitly trusted by the developers. When those libraries contain security issues, the resultant application will also have issues. This paradigm is mitigated to an extent when the libraries are from commercial software vendors, but those commercial vendors have a relationship with their customers and can push updates to them.
"When the libraries are from open source projects and frameworks, unless the consumer of the project or library actively engages with the authors of their open source libraries, there is no way for those authors to push patches and updates to them. It is this engagement which is key to removing security risks when using any open source components.
"Importantly, even commercial libraries are increasingly dependent upon open source components so many larger organisations have embarked upon an analysis of those libraries for unpatched components. This analysis is all part of their open source governance policies designed to identify and mitigate risks in their software supply chain.
"Looking back at the Docker container scenario, we now have a series of applications and frameworks powering the deployment stack for the application. Each of the elements in the stack has its own set of potential security risks and patch procedures..
"Organisations seeking to avoid becoming the next Equifax, or for that matter to not run afoul of regulations like GDPR, recognise that modern applications are a mixture of open source components, proprietary code, third party APIs and application configuration. Each of these elements requires a different approach to security for the entire application to be properly secured.
"In July, IBM, with the Ponemon Institute, released their annual Cost of Data Breach report. Comparing the 2018 report to 2017, we saw an increase in the length of time to identify and contain a breach. With the number of CVE disclosures to date in 2018 at record levels, it’s clear that the vulnerability risks posed to organisations are increasing. It is only through awareness of all application dependencies that protecting against this rise in CVE disclosures."