Attacks/Breaches
8/27/2009
12:00 PM
Connect Directly
RSS
E-Mail
50%
50%

5 Security Lessons From Real-World Data Breaches

We break the code of silence on data breaches to show how criminals operate -- and how you can thwart them.

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.

DIG DEEPER
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.

Previous
1 of 3
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0103
Published: 2014-07-29
WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files.

CVE-2014-0475
Published: 2014-07-29
Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.

CVE-2014-0889
Published: 2014-07-29
Multiple cross-site scripting (XSS) vulnerabilities in IBM Atlas Suite (aka Atlas Policy Suite), as used in Atlas eDiscovery Process Management through 6.0.3, Disposal and Governance Management for IT through 6.0.3, and Global Retention Policy and Schedule Management through 6.0.3, allow remote atta...

CVE-2014-2226
Published: 2014-07-29
Ubiquiti UniFi Controller before 3.2.1 logs the administrative password hash in syslog messages, which allows man-in-the-middle attackers to obtains sensitive information via unspecified vectors.

CVE-2014-3020
Published: 2014-07-29
install.sh in the Embedded WebSphere Application Server (eWAS) 7.0 before FP33 in IBM Tivoli Integrated Portal (TIP) 2.1 and 2.2 sets world-writable permissions for the installRoot directory tree, which allows local users to gain privileges via a Trojan horse program.

Best of the Web
Dark Reading Radio