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.
If you’re unhappy with the current Payment Card Industry Data Security Standard (PCI DSS) then now is your chance to complain. The PCI SSC Council has announced a feedback period where you can have the opportunity to “provide detailed and actionable feedback in an effort to revise future editions of the Council’s standards to improve payment data security.”
You may air your grievances during the phase two of the lifecycle process, between July 1 and November 1. The SSC Council is looking to hear from merchants, processors, financial institutions, and other key stakeholders – and I’m sure they are in for an earful. (Like how the only thing you need to be a QSA in North America is 30k, a Highschool education, and 4 days of training)
Many are unsatisfied with the “checklist” format of PCI compliance. They commonly point out how this switches the goal from overall security and risk management to simply compliance. Some of these standards don’t seem to help security at all, such as configuration management. PCI compliance should not be the goal, but it ought to serve as a jumping off point towards promoting better security practices. But too many organizations either have a purely audit-based mentality while others regard the compliance as a frustrating burden.
Does the recent data breach of Heartland Payment Systems prove PCI is useless? Maybe not, but it isn’t 100% effective either. Of course we know nothing can be in security. But does it even provide reasonable security and assurance?
There are some who call PCI DSS “security theatre.” (Like me!) It makes organizations put on a show of security that makes them feel safe, but doesn’t actually do anything. Many organizations even perform their own self-assessments and there is no incentive for them to report anything less than fully compliant.
If you’ve got a bone to pick with the PCI SSC Council over these issues, then you can use their online feedback tool to “proactively propose and discuss revisions to the next iteration of the Council’s standards.” But if you want to complain in person, you can attend their “Community Meetings” in Las Vegas or Prague.
