Case Study: How We Patched Data Breach into Law

In the constantly evolving landscapes of cyber-attacks, it is sometimes taken for granted how we respond to intrusions. When a company like, Target, Microsoft, Uber, are compromised, the users whose data is now splattered all over the dark web are given a warning and usually a complimentary two months of identity protection services (I guess they think hackers have short attention spans).

This response, however, was not always the case. It took a very specific series of events to occur. Namely, someone in politics had to be the offended party. This fortuitous event happened in 2002 in the infamous California Payroll Database Breach on April 2, 2002 (though it wasn’t caught until May 7, 2002). The Stephen P. Teale Data Center (renamed in 2005) had a couple of issues. Firstly, and most egregiously, “The server that was breached sat outside the Data Center’s firewall. No explanation was given for this anomaly.” In the cyber security realm, unprotected servers are fortunately rare while the excuse of no explanation is a little too common. However, the unprotected server was not the only thing that aided the hackers in their breach. They also had a server that was behind on patches. While the fault does lay at the door of coders who do not code perfectly on the first release, an argument can be made that when they release a patch for their own broken code, applying it is a generally acceptable practice.

Jokes aside, one of the two functioning servers had the important patch and “if the patch had been installed on both servers, ‘that attack would not have been successful’”. These two factors in tandem helped to create the incident that exposed 265,000 California state employees’ social security numbers, payroll deductions, and other PII info to the attackers. While over a quarter of a million people is quite a lot, according to Mark Rensch of security current, “the Governor, the Lieutenant Governor, and all of the members of the California legislature had their data at this data center”. This understandably put a bee in the bonnet of the Californian legislature and gave way to California’s SB 1386. As I’m not a legal expert of any sort, I’ll leave better people to explain that legislature.

So, what did we learn from this early intrusion into a database center? One, please have a firewall up. And if it’s up, definitely put your stuff behind it. Two, install your patches quickly and efficiently. Three, get some good guys to scan your network/vulnerabilities before the bad guys do. Four, if you do lose data, make sure that you’re not keeping politicians’ information or else there is going to be some very pointed legislation coming your way. Thanks for reading, if you do need some good guys to poke around your network, we at Mile High Cyber will certainly tell you what isn’t firewalled and what patches need to be updated … If only we’d been around in 2002.

References:

https://securitycurrent.com/why-we-have-breach-notification-all-wrong/

https://jolt.richmond.edu/jolt-archive/v10i1/article1.pdf