The problem is that Equifax put within webserver's reach information that had no business being there. Apache Strut's vulnerability is unfortunate, but it shouldn't have been the keys to the kingdom, where the kingdom is the personal information of nearly the entire US adult population with a credit history. If I knew a service relied only on the security of a web server to protect deeply personal information such as my name and SSN I'd never sign up. We didn't have that choice with Equifax.<p>Having said that, definitely keep up on the vulnerabilities of software you use. It's hard though, especially when you're relying on a great deal of dependencies. A company the size of Equifax should have had a team dedicated to this. A team. It doesn't seem like they had anyone who knew anything about basic security at all.
<i>Our general advice to businesses and individuals utilizing Apache Struts as well as any other open or closed source supporting library in their software products and services is as follows:<p>1. Understand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements affecting this products and versions.<p>2. Establish a process to quickly roll out a security fix release of your software product once supporting frameworks or libraries needs to be updated for security reasons. Best is to think in terms of hours or a few days, not weeks or months. Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years.<p>3. Any complex software contains flaws. Don't build your security policy on the assumption that supporting software products are flawless, especially in terms of security vulnerabilities.<p>4. Establish security layers. It is good software engineering practice to have individually secured layers behind a public-facing presentation layer such as the Apache Struts framework. A breach into the presentation layer should never empower access to significant or even all back-end information resources.<p>5. Establish monitoring for unusual access patterns to your public Web resources. Nowadays there are a lot of open source and commercial products available to detect such patterns and give alerts. We recommend such monitoring as good operations practice for business critical Web-based services.</i>
This is not Struts' "fault"... An entity like Equifax cannot hold such private info and power over our finances, then not have multiple layers of protection to prevent this. You expect bugs in user faceing software, so you protect against breaches so that you don't expose 140 MILLION damn records..
As a Java developer, this gives me the lesson not to use smart meta programming facilities, like reflection, where possible. You reduce amount of code, but at the cost of making your protocols injectable to arbitrary code often in unobvious ways.
Not The Onion: Equifax's "chief security officer" majored in Music Composition: <a href="https://www.linkedin.com/in/susan-m-93069a/" rel="nofollow">https://www.linkedin.com/in/susan-m-93069a/</a>. How did she even get this job?
Interesting to also note that the "workaround" listed in the first announcement by the Apache Struts team was wrong. I followed the directions and my web application was still vulnerable. They have since updated it, but without an announcement.
I think this highlights the general problem of Java EE style architecture. There are many moving pieces and many permutations of how they interact together. It's practically impossible to understand it in its entirety, and thus impossible to guarantee that it's secure. You're basically plugging holes as you find them, but you're never sure that there aren't more holes you don't know about.