Aug 28, 2009 (08:08 PM EDT)
5 Security Lessons From Real-World Data Breaches

Read the Original Article at InformationWeek

1   2   3  
The unwritten rule among companies is that the less said about security breaches, the better. For every public revelation of stolen data there are dozens of breaches that don't make the news.

This code of silence might avoid angering partners and customers, and sidestep a public relations mess, but it makes it harder for the industry as a whole to learn from mistakes and improve information security and risk management practices. That's why this article draws on direct observations from real-world security breaches on which we've performed forensic investigations, to help companies understand how breaches happen and what to do about them.

InformationWeek Reports

Neohapsis, the company we work for, has performed investigations on some of the largest thefts of sensitive data. After hundreds of cases, we can unequivocally state that attackers are more sophisticated than ever. They can adeptly exploit lax security controls and sloppy operational practices and are armed with weapons from common network management tools to custom malware. Information security tactics and technology also have advanced, but not at the same pace.

The good news is that there are reasonable, well-understood methods to mitigate many of the breaches we have seen; we just need to get these methods more widely implemented.

We'll start by describing three real-world breaches.

A company's Web sites often serve as a beachhead for attackers. In one investigation we performed at a financial services firm, the attackers exploited a vulnerability they found in a Web application on a public-facing Web server. The server didn't house any critical data and wasn't particularly important to the organization, and the exploit wasn't particularly impressive, either; the attackers found a SQL injection vulnerability and then used an "xp_cmdshell" function to pull down their tools to get a foothold onto the server. Because the organization didn't consider the server or the application particularly critical, there weren't many monitoring controls around them, and the exploit went unnoticed.

The attackers used the compromised server as their home base. They deployed tools and scanners and spent several months meticulously mapping the network without being detected. Once they found the systems that contained the data that they were looking for, they simply copied the information, put it into a Zip file, and moved it out.

The organization had standard antivirus and firewall technology, but the only reason it became aware of the attack was the real-world use of the stolen data; if not for that, the organization likely would have remained ignorant of the breach.

In another investigation we conducted, the attackers worked from the same playbook, compromising a Web-based e-commerce server at an online retailer. However, once the attackers made their way to the database systems to look for credit cards, they discovered the database with the credit card numbers was encrypted. Chalk one up for the good guys, right? Unfortunately, the decryption keys were stored on the same systems, so the attackers literally had the keys to the kingdom.

What Keeps Security Pros Up At Night?
Our 2009 security survey covers it all.
Finally, we've worked on several cases in which attackers gained entry through point-of-sale systems.

The point-of-sale system vendor's support team used common remote access applications such as VNC to gain access to the systems for support and troubleshooting. But the vendor used the same remote access password for every customer. The attackers knew the password and simply ran bulk scans for other systems matching a similar profile. The rest was easy.

We've abstracted five essentials lessons from these and other real-world intrusions: Get serious about Web application security; add layers of security controls; understand the limits of security technology; review third-party systems; and know that bad incident response is worse than no incident response.