EQUIFAX BREACH
Recently there’s been a buzz over the Equifax breach — rightly so. It’s a transformative event and its effects will reverberate for years if not decades.
WHAT’LL HAPPEN NEXT
Nobody knows for sure, but we can guess. First, the leadership at Equifax will be replaced, and we’re seeing that happen now. Next, there’ll likely be new standards governing security in the workplace, specifically around punitive damages when service providers commit gross negligence, as was the case here. Finally, the usage of the Social Security Number itself as a credential in account origination will fall out of practice. Why? Because there’s no expectation that data is private now that 143 million records have leaked.
HOW TO PREVENT THIS FROM HAPPENING
There’s no foolproof way to secure computing systems. But there are ways to mitigate the risk of exposure once the inevitable breach occurs.
PRACTICE THE PRINCIPLE OF LEAST PRIVILEGE
If Equifax had run their software inside a sandbox, like SELinux or the Java Security Manager, it would not have been possible for a remote code exploit to invoke system commands, a precursor to leaking the data. The following code sample shows how to run Java code inside of a security sandbox that enforces mandatory access controls:
Nothing can be done before first being added to the policy file. Follow the instructions inside the README to understand how the Java Security Manager works and how it can be used to prevent untrusted code from executing system commands.
MORE READING
THE EXPLOIT CVE-2017-5638
http://www.zdnet.com/article/equifax-confirms-apache-struts-flaw-it-failed-to-patch-was-to-blame-for-data-breach/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638
https://www.rapid7.com/db/vulnerabilities/struts-cve-2017-5638
HOW DOES IT WORK
Input data deserialized into an executable object with privilege.
http://blog.diniscruz.com/2013/12/xstream-remote-code-execution-exploit.html