Last updated at Tue, 14 May 2019 19:34:02 GMT
Much ink has been spilled on the Equifax breach, along with plenty of (well-deserved) public excoriation of all responsible parties, starting from the top.
However, quantity is no substitute for quality, and certainly not when it comes to tech journalism. Oftentimes, the content of such articles is dictated by the need for attention: clickbait first, substance never. As a result, there’s a missed opportunity to turn a disaster into a teachable moment.
What’s worse is that many people will end by learning the wrong lessons altogether. In the interest of contributing positively to the Equifax conversation, I’ll list some misconceptions people have glommed onto due to the steady avalanche of news coverage on Equifax’s security fails.
Wrong Lesson #1: Mommas, don’t let your music majors grow up to be CISOs
Marketwatch blared with an opinion piece entitled: “Equifax hired a music major as chief security officer and she has just retired.” I got messages from friends in non-technology industries expressing shock that Equifax was so incompetent as to have not checked references. (http://www.marketwatch.com/story/equifax-ceo-hired-a-music-major-as-the-companys-chief-security-officer-2017-09-15)
Twitter had some fun with this as well, in a job posting with this unlikely requirement: “Undergraduate degree or equivalent; music composition degree preferred.” (https://careers.twitter.com/en/work-for-twitter/201709/application-security-engineer0.html)
The missing context is that many people in the information technology field come from non-technical backgrounds. At the very least, they studied something non-STEM in college (if they went to college), and later learned the requisite skills either on the job, through self-study, or with later professional training. Articles such as the Washington Post had decent rebuttals: https://www.washingtonpost.com/news/the-switch/wp/2017/09/19/equifaxs-top-security-exec-made-some-big-mistakes-studying-music-wasnt-one-of-them/. And there were a barrage of tweets with hashtag #unqualifiedfortech used ironically, along the lines of #deplorables and #nastywoman.
The takeaway is that what matters is not one’s major, but the quality of one’s work. Mauldin’s work was embarrassingly bad. But don’t blame her choice of major. There were probably dozens of computer science majors out of 200+ security professionals at Equifax. The failure was systematic.
Wrong Lesson #2: “No law can fix stupid”
Thus proclaimed Greg Walden, a Republican representative from Oregon. That plays well with the sentiment that laws don’t matter, and it’s all about individual responsibility. However, compelling as that perspective may be, the fact remains that laws actually can “fix stupid.”
Take, for example, seat belt laws. A study back in 2003 showed that seat belt laws saved 1400 lives annually, which is a remarkable figure, considering that not all states have seatbelt laws.
Is there a reason Equifax and other credit agencies oppose regulation? You betcha. Think they would act differently if they were bound by law to comply with certain standards–if individuals within the company could face criminal prosecution, and if the corporation itself would face crippling fines? (Hint: the question is rhetorical.)
People are motivated by both carrots and sticks. Sometimes, when it comes to the responsible handling of sensitive data, legal accountability can be a powerful motivator to do what’s right.
Wrong Lesson #3: Freeze Your Credit
The honorable Brian Krebs recommends freezing your credit. I find that this advice is actually well supported. However, it’s easy to think that this is a bulletproof way to secure your credit. In fact, there are several documented pitfalls to this strategy.
For those who don’t know: When freezing your credit, you’re given a PIN (don’t say “PIN number,” please). While the credit is frozen, no one can get credit reports, nor open new lines of credit in your name. In order to unfreeze, you have to call in and provide your PIN.
However, Equifax, which obviously had a culture of promoting security anti-patterns (everything you should not do for the sake of security, it seems Equifax decided to do, because… YOLO) issued PINs that were entirely guessable, since the PIN for each user was based on the date of freeze. For anyone who’s taken even a single online security course, this is a triple head slapper. In fact, one doesn’t need a security course at all. PINs are numerical passwords, and most people’s security knowledge extends to the idea that passwords shouldn’t be guessable.
While everyone is hating on Equifax, the fact is that other credit bureaus are no better. Experian, stunningly, would provide your PIN to anyone answering rudimentary questions. A person’s “name, address, date of birth and Social Security number” are all you need to unfreeze their credit. FU Experian!
If you obtained a PIN before the above problems were widely reported and remediated, now’s a good time to reset that PIN.
Word of warning: the credit bureaus have been promoting a “credit lock,” which can be confusing at first glance. Nerdwallet has a nice breakdown here: https://www.nerdwallet.com/blog/finance/credit-lock-and-credit-freeze/. I’ll summarize their findings as follows: if you want to pay for convenience, reduced accountability on the part of the credit agency, and weaker security overall, then go for the credit lock. It’s what the agencies want you to do, and you can judge for yourself how much that means. If you want something backed by law enforcement, go with the lock, as Krebs says.
(Note: you can also do a fraud alert, which is the mildest of the three options. More information can be found here: https://www.consumer.ftc.gov/articles/0497-credit-freeze-faqs#difference).
Wrong Lesson #4: Don’t Use Apache Struts
On March 6th, Apache issued a patch for the same security vulnerability that would later be exploited to attack Equifax.
A simplistic analysis of the problem would place the blame on using open source software. In actuality, all software has bugs–commercial software no less so than open source. Apache, to its credit, has been quite prompt in responding to security issues and issuing timely patches. In this case, Apache issued a patch on March 6th, and months went by before Equifax adopted it.
But the exploit was incorporated into Metasploit within 24 hours. Attackers immediately began scanning the web for vulnerable sites. On March 10th, they discovered that Equifax was vulnerable and that anyone who chose to could successfully exploit the flaw.
Once the system was breached via the exploit, the attackers were able to establish a remote shell, allowing them to seize and maintain control. In fact, they established 30. At that point, it didn’t matter if the software was patched or not. (https://www.bloomberg.com/news/features/2017-09-29/the-equifax-hack-has-all-the-hallmarks-of-state-sponsored-pros)
Essentially, no one vulnerability should invite such a catastrophic breach. The speed with which attackers can respond once a vulnerability becomes known makes defending web apps extremely challenging. One cannot always apply a patch without doing other work on the application, and without going through other change management steps, like reviews and tests. As a result, many companies have a backlog of software component updates. It isn’t that unreasonable that Equifax failed to update Apache Struts within 4 days of the fix becoming available. What is important is that there’s a “plan B” if such actions fail to take place for whatever reason.
tCell, because it is “in app,” can identify out-of-date and vulnerable packages that are running in production in real-time. But, even more importantly, since it isn’t always possible to upgrade immediately, tCell can stop attacks like this by preventing the remote shells from being established from within the application itself.
In any case, the breach went undetected for weeks and would have been caught had Equifax monitored anomalous and suspicious activity on the application.
It is a stunning illustration of why the OWASP Top Ten of 2017 should not have been gutted of “A7” (Insufficient Attack Protection). A7 was added earlier this year, only to be rejected in the summer; its refactoring was announced on September 1 via LinkedIn article. Ironically, Equifax’s lack of monitoring and attack protection was announced less than a week later. One hopes that the biggest compromise in history will change minds as to what constitutes risk.
Wrong Lesson #5 – Mistakes were made
“The human error was that the individual who’s responsible for communicating in the organization to apply the patch, did not” — Richard Smith
At the end of the day, what happened at Equifax was systemic. It was systemic security failure.
If one person is responsible for patching, and none of Equifax’s 250 security professionals are available to prevent that single error, then what we have here is a systemic failure.
Let’s look at Kreb’s blog alone on Equifax’s mistakes:
● https://krebsonsecurity.com/2017/10/equifax-breach-fallout-your-salary-history/ – “…detailed salary and employment history on a large portion of Americans using little more than someone’s Social Security number and date of birth…”
● https://krebsonsecurity.com/2017/09/equifax-or-equiphish/ – “…the company appears to be training recipients to fall for phishing scams.”
● https://krebsonsecurity.com/2017/09/ayuda-help-equifax-has-my-data/ – “…researchers found they could view the names of more than 100 Equifax employees in Argentina, as well as their employee ID and email address. The ‘list of users’ page also featured a clickable button that anyone authenticated with the ‘admin/admin’ username and password could use to add, modify or delete user accounts on the system.”
● https://krebsonsecurity.com/2017/05/fraudsters-exploited-lax-security-at-equifaxs-talx-payroll-division/ – “Equifax says crooks were able to reset the 4-digit PIN given to customer employees as a password and then steal W-2 tax data after successfully answering personal questions about those employees.”
And that’s just THIS YEAR! And that doesn’t include the most recent report on people being infected with malware by visiting the Equifax site, as reported here: https://arstechnica.com/information-technology/2017/10/equifax-website-hacked-again-this-time-to-redirect-to-fake-flash-update/
On September 14th, the blog spuz.me published an interview with the attackers, detailing exactly how Equifax was compromised: http://spuz.me/blog/zine/3Qu1F4x.html. The tl;rl version is that:
● Equifax had critical web applications secured with admin accounts using the password “admin”
● These critical apps were internal systems, yet were accessible from the internet
● These apps displayed critical information, such as keys that enabled decrypting of all the valuable personal data that was carefully encrypted for security
Further, Bloomberg reported a large exodus of security professionals and a recently tumultuous relationship with their primary vendor Mandiant. All things point to systemic organizational failure.
The inspiration for tCell is that AppSec is way behind where it needs to be and that the critical piece missing from the puzzle is strong runtime monitoring and protection. WAFs and their legacy are insufficient: few use them, and those few are “satisfied” at best. More often, WAF-users are scornful, or–even worse–indifferent.
Often these issues are oversimplified, or outright wrong. And it’s important to delve deeper into the root causes of systematic failure, rather than falling for the temptation of the easy answer: “It’s one engineer’s fault. It’s the music major’s fault.”
OWASP missed an opportunity to be thought-leaders, ahead of the curve in advocating for tech that can directly address attacks like what hit Equifax. (One thing you can be sure of: this won’t be the last such breach.) One can certainly hope that in the future, the OWASP Top 10 will correct such mistakes; but in the meantime, it’s up to security professionals, and non-security professionals, to educate themselves about the latest breakthroughs in defensive technology–breakthroughs that can stop the next Equifax-level breach.