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.
Image via CrunchBase
As the clouds continues to roll in, (Sorry, I had to…), we are learning of more attacks being successful against organizations such as Google, Facebook, and others. The latest is from a security researcher, Christian Heinrich, located in Australia. He reverse engineered the algorithm Facebook uses to access your personal photos. Since Facebook is a massively distributed application, items such as photos and larger files are placed into a content distribution network (CDN) such as that provided by Amazon, Akamai, and others in order to reduce the load on Facebook’s servers. The thing is, the CDNs don’t integrate into Facebook’s authentication framework since the CDN just stores files and serves them to anyone that requests the proper filename. Guess the filename of the private photos for a person on Facebook, send the request to the CDN, and you get the photo in return.
And that is what led to an arrest and charges for a privacy breach. During his presentation, Heinrich demonstrated this vulnerability at Flickr, Facebook, and MySpace. He demonstrated how we could access the private photos of his fellow researcher, Chris Gatford’s, wife. One example showed a picture of Chris Gatford’s wife and child. The Queensland Police responded to a complaint, although we don’t know who filed the complaint, about Heinrich’s breach of Chris Gatford’s wife’s privacy caused by the demonstration. The Police responded by arresting a reporter for the Sidney Morning Herald, who had interviewed Heinrich about his presentation, and seized the reporter’s iPad.
Is this really Facebook’s or Flickr’s problem or the CDN’s? It most definitely is the content producer’s problem. The CDN network could provide authentication and more advanced security controls but that lowers performance by 30% or more for each transaction.
Ah, the old security versus performance argument. That age old argument is why this little and perhaps unknown arrest in Australia affects your organization whether you are using a CDN or not. When the performance versus security argument comes up during your career, the focus must be on the data type being discussed. Usually, the data type(s) being discussed including different types of data that need to be enhanced for performance to increase. It is likely that as you dive in deeper, many of pieces of data will not be private or confidential, but if they are you must stick to your security guns and only allow authenticated and authorized access to that data. The other data you can push out and optimize all the organization wants.
Your argument back to IT or development about the perceived performance gains they believe they can achieve by optimizing the data is one of analysis. You must ask to analyze the estimated increase in performance of only allowing the non-confidential data to be accessed without security controls. Meeting them halfway by only optimizing the non-confidential data results in them having to accept a 15% or 20% increase in performance, which may be less than what they were estimating, but it is better than no increase at all.
My article on Virtualization Security just went live on InformationWeek.com, if you want to read the juicy details (incoluding charts and graphs!), go read the article right now! Security Tips for Virtualization
The article is a summary of the 40+ page report I wrote for InformationWeek Analytics, the research division of InformationWeek. While researching for the report I needed to provide an update on virtualizaiton security that InformationWeek did in 2008, so I had the opportunity to meet and interview a couple CISOs in the cloud, SaaS, and traditional IT roles. It was clear that that is a lot of confusion when it comes to virtualizaiton security but all the CISOs said that virtualizaiton has moved from the test/qa areas into full fledged production and no one could stop it. The benefits far outweighed the security concerns.
So what are you going to do when you are told by IT that the beta virtualization environment is going into production in two weeks? Focus on preventing these common problems:
>> Loose controls: Implement strong change management that is auditable and mandates a separation of duties. The logins used to manage the virtual infrastructure must not have access to anything but the virtualization management software. Also, all virtualization infrastructure changes should be logged, and those logs reviewed by someone not on the virtualization team.
Events such as restarting VMs, creating new VMs, and adjusting hardware should always be correlated to reasons they were done.
>> Shoddy virtual network design: Virtual networks are complex, mainly because of the abstraction. Go slow, use Visio, and map it all out so proper segmentation is deployed and security control points (these are where security controls can be installed) are defined before the virtual network is created. Think about firewalls, IPS/IDS, Web application firewalls, and routing.
>> Unsecured physical data stores: Make sure the spot where your VMs and snapshots are stored is not easily accessible. If an attacker or malicious insider can access your virtual disk files, it’s game over. This includes backups. Don’t put backups of virtual disks on a public file server, ever.
>> Thinking VSAs will solve the problem: You don’t need virtual security appliances to manage most virtualization risks. Is there anything wrong with using your physical IDS/IPS or firewall and trunking the VLANs to the virtual switch? We don’t think so. Use what you have. If you want to add VSAs to address performance problems, fully test the appliances at adequate load before you buy.
>> Believing what you hear in the news is real risk: Don’t be reactionary. Thinking the latest virtualization attack you saw at Black Hat will affect you next week will only result in you having to take some real blue pills to reduce stress. Most of these attacks are still in the theoretical stage and simply aren’t practical for attackers because they don’t deliver quick ROI.
