As audit season is finally over, (over 65% of all our assessments and audits happen in Q4) we finally have a chance to grab a cup of coffee and look back at a couple trends in 2011 that we think separate the best security teams from the worst.
First, we need to discuss how we measure the quality of a security team. At Savid, it is pretty simple. Since we perform ethical hacking to assess security programs at organizations, if we got access to something we shouldn’t have, it counts as an intrusion in our books.
Most reviews of security controls look at what went wrong because it’s harder to learn from the successes. So let’s get the major failures of 2011 out of the way and then let’s talk about what our best clients did to prevent us from breaking in. Overall, most of the security programs we assessed had application security issues. However, 2011 was the worst we have ever seen in terms of the depth and breadth of application security issues – even though the majority of the security programs we tested were in compliance with regulations such as HIPAA, PCI, and GLBA.
Ok, so with that out of the way, what did the best security teams do to prevent our ethical hackers from breaking in? One Thing: Defense In Depth. 2011 was the first year where we saw significant advancements in defense in depth deployments among our clients. For example, we saw a noticeable increase in proper system hardening (using standards such as CIS and NIST) and reduction of excessive permissions that stopped our attacks cold.
Properly deploying defense in depth can be the distinction between a data breach requiring notification or a simple documented incident. The difference between the two for some organizations could be millions of dollars. Oh, and it also has a side effect of making most malware non-functional by preventing the malware from creating temporary files, accessing DLLs, etc. Remember, an attacker can’t exfiltrate data if the exfiltration tools won’t run!
So, how did the defense in depth stop our hacking? Most of the time we were able to get entry into a server or application but because of defense in depth we weren’t able to leverage that entry for any gain (such as privilege escalation, intellectual property, or personally identifiable information). For example, if we got access to an application via SQL injection, we weren’t able to execute any commands on the server because the SQL server was hardened to prevent usage of xp_cmd and the SQL service account had no local permissions on the box to do anything other than access the database files and folders. Another example is when we got access to a Linux system running a custom PHP login system via an upload vulnerable and a PHP Shell script. The hardening of Apache and the file system prevented our low privileged web server service account from reading local files, creating files, etc. Essentially, the account we got control of was useless and the attack vector wasted our time and effort.
Wasting an attacker’s time and effort is exactly what you as the defender want to do. Every minute an attacker is stalled or delayed is more time for your detective controls such as IDS/IPS, Logging, or even Tripwire like defenses to detect an attack. We recommend that every security program have a simple theme: If You Cannot Prevent It, Detect It. Leveraging defense in depth provides additional detection points along the attack path. Every time a low privileged user attempts to access the Accounting Share – detect it. Every time a server in your DMZ attempts to connect to a server in the internal network (which should be blocked by the firewall) detect it and respond to it. These are all indicators that the server is doing something it shouldn’t.
Our number one recommendation when deploying defense in depth with proper detection controls is the use of fake records – commonly called “honeytokens”. For example, if you have a public web application that has access to an internal database server through a firewall, place a fake record in the database using a randomly generated 30-64 character value. This record has no value and should never be accessed via normal web application use. If your firewall, web filter, or DLP system ever sees this traffic move across the network – something went wrong and you need to find out why.
Every year Verizon releases their Data Breach investigations Report and year after year they mention the same problem: The time between a breach occurring and detection of the breach is too long, sometimes it takes years! So this year, add some more defense in depth controls to your security program and watch how quickly it helps reduce the impact of a vulnerability.
When HIPAA was passed and made federal law by the Clinton administration in 1996, the fear of fines and even jail time sent the medical industry scrambling to beef up their patient data security by the 2003 deadline. However, for years afterwards, HIPAA remained a toothless tiger. Occasionally, it growled and violators were threatened to clean up their act. But it usually did not bite, as prosecutions were rare and usually mild.
Since no serious prosecutions have taken place since HIPAA went into effect in 2003, I and the medical industry have wondered if HIPAA is just a made-up boogeyman meant to frighten them into compliance.
All this changed on February 18 when the U.S. Department of Health and Human Services and the Federal Trade Commission issued a press release stating CVS had to pay $2.25 million to the U.S. government for HIPAA violations.
The HHS Office for Civil Rights (OCR) and the Federal Trade Commission caught the pharmacy chain red-handed disposing of empty pill bottles that contained patient data into dumpsters and trash containers outside select stores. Among other issues, CVS “failed to implement adequate policies and procedures to appropriately safeguard patient information during the disposal process; and failed to adequately train employees on how to dispose of such information properly.”
CVS Caremark Corp., the parent company of the 6,000 store pharmacy chain, must implement a robust corrective action plan that requires Privacy Rule compliant policies and procedures for safeguarding patient information in addition to its fine. CVS must also submit to a biennial audit by a third party to show their compliance.
Is HHS trying to set an example with the steep penalty? Is CVS the sacrificial lamb intended to inspire other delinquent HIPAA violators to clean up their act?
While many medical industry companies may have gambling with HIPAA violations, at least CVS learned it isn’t worth the risk. Besides the possible penalties, compromising personal patient data is a strike against the reputation of a company. And this can be more costly than any fine by the HHS.
