Equifax Issues Continue - Technical Debt at the Core

The challenges in the wake of the Equifax security breach are likely to have a devastating impact on the once-powerful credit monitoring agency. The exposure from the breach caused the personal information from 143 million people (mostly in the United States) to be vulnerable to unauthorized use.

A wide array of concerns have stemmed from the outbreak. Some are noted below:

• The rumor of insider-trading activity by senior executives - opting to sell their stock before the breach was made public.

• The subsequent website attack, which caused end-users to download malware onto their machines (while believing they were downloading a Flash player update).

• The lack of qualifications and experience around former Chief Security Officer (CSO), Susan Mauldin.

• How the credit monitoring industry does not have to adhere to the same guidelines as financial corporations, when they actually maintain just as much (if not more) personal information for the customers they serve.

While each of these concerns could stand alone as an individual article, none are going to be the focus of this article. Instead, I am going to focus on how unmanaged technical debt is at the core of the Equifax security breach.

Unpatched Struts - Really?!

It turns out, Equifax was using the Apache Struts framework on the application that was compromised. I was surprised to read that the Struts framework was still being used since I have contemplated removing that "skill" from my LinkedIn profile for the last two years. I had to go back to 2015 (over 2.5 years ago) to find results for top Java frameworks in use to gain an understanding of Struts usage. Based upon the January 6, 2015, article "Top 4 Java Web Frameworks Revealed: Real Life Usage Data of Spring MVC, Vaadin, GWT and JSF," Apache Struts 1 and 2 maintained 4.5% and 6% of those surveyed. Struts combined was used in roughly 10% of the market back in 2015.

From what I can tell, an article by zdnet the vulnerability impacted all versions of the Struts framework since 2008 and a hacker only needs a web-browser to initiate an attack against the exposed RESTful plug-in. The Remote Code Execution (RCE) issue is one of five RCE vulnerabilities identified on the Apache Struts announcement page since March 2017.

Articles surfaced shortly after the attack indicated the fix is not quick and easy to put into place. Without an understanding of the Equifax implementation of Struts, I am not sure of the effort involved for the Equifax support team to patch the framework. However, I am certain the very same team would take alternative actions if they were able to go back in time and relive this scenario.

It's All About Technical Debt

At the core of this issue, is really a lack of keeping technical debt under control. The impact of such an exposure to Fortune x00 companies can be astronomical. If the production support teams fail to keep their shared libraries updated - especially with regard to publically facing systems - they are at risk for vulnerabilities and exposure by outside attackers. That is why I always recommend dedicating 20% of a given development iteration towards technical debt activities.

The open-source software (OSS) concept is wonderful. Developers and pioneers use their skills and expertise to make things better for the community as a whole, most of the time at no cost to those who include the code in their project. The hope is that users will become contributors in a manner that best suits their skills.

However, using OSS code should never be viewed as bug-free - regardless of the skills or corporation backing the effort. As a result, it is vital that development or support teams have a clear understanding of the frameworks and shared solutions in place for their applications. Teams should also consider employment of static code analysis tools, which can assist in identifying known vulnerabilities in both open-source code and custom-written programming logic.

As these vulnerabilities are discovered, a plan should be put into place to remedy those situations that can impact a corporation’s data or services.

Conclusion

Recently, I worked on a new development project that was built using the Angular open-source framework. Internally, the decision was made to develop the application using version 1.5 of Angular. This, at a time when both Angular 2 and Angular 4 have already gained momentum in the marketplace.

I worry about the proliferation of client-based frameworks across the enterprise - because they are so quick and easy to get up and running. My worry is related to supporting applications, which could not only be running different versions of a given framework - but different frameworks and libraries altogether. Not only does it become difficult to maintain and support the frameworks, but it can be even more difficult to make certain all applications are adequately patched and maintained.

I noted above that public-facing applications should always be a priority, but that does not mean internal applications can be ignored. While the Rogue developer rarely exists (as noted in my "Does the Rogue Developer Really Exist?" article), corporations should always make sure their internal data is equally protected. In my personal view, internal applications should be validated and monitored in the same manner as public facing applications. After all, it only takes one missed patch to lead to a catastrophic event.

Have a really great day!