The third lesson is to understand the limits of your security systems. We have antivirus, firewalls, network and host intrusion detection systems, authentication, PKI, VPNs, NAC, vulnerability scanners, data loss prevention tools, security information, event management platforms--and yet the breaches go on.
That's because controls aren't progressing as fast as the capabilities of attackers. We have worked several cases where systems with fully updated antivirus signatures failed to detect active Trojan horses, key loggers, and sniffers. Most signature development cycles still work from an outdated assumption that a successful piece of malware will be widespread, letting the vendor become aware of it and construct a signature. Also, attackers use packers to hide malware from virus scanners.
Vulnerability scanners also aren't keeping up with released vulnerabilities and can't currently do effective application scanning. Intrusion detection and prevention suffers many of the same shortcomings as antivirus products.
What's an IT team to do? For starters, place the appropriate level of trust on a technology--and no more. Don't expect your antivirus to spot custom malware. Use vulnerability scanners only as a secondary test to make sure your patch management system is working. Assume your firewall will block automated scans but that a skilled attacker will make it past the perimeter units.
Intrusion detection and prevention systems can be useful at times, but we often find router Netflow data and firewall "allow" logs provide a better view of where attackers went, and help in measuring the extent of a breach.
From an operational standpoint, consider deploying event management technology to get a picture of activity across multiple systems, or at least implement centralized log management to help search, review, and store logs.
Also consider the skill and motivation of your adversary and what controls might be necessary to detect their presence. Understanding their capabilities is becoming increasingly important.
4. Trust But Verify
The fourth lesson is simple but often forgotten: Review third-party systems. As our point-of-sale example shows, security due diligence should be performed by an internal team or a third-party application security firm. Don't miss low-hanging fruit such as changing default passwords.
5. Plan For Incidents
Finally, be aware that bad incident response can be worse than none at all. We often deal with organizations whose IT teams destroy evidence, intentionally or otherwise, by rebuilding systems, wiping drives, purging sections of databases, or giving third-party providers access to compromised systems. Finding the problem becomes tougher, and might destroy or compromise evidence that could be used in criminal prosecution.
Have basic procedures in place--even as basic as "do nothing until you check the incident response procedure." There's much free material, ranging from the NIST 800-61 guide to Visa's "If Compromised" guidelines. Both documents can easily be found with a Web search.
Security breaches are painful for companies and the IT pros involved but silence isn't always the best response. Pulling back the curtain on common mistakes helps businesses understand what they're up against.
Greg Shipley ([email protected]), Tyler Allison, and Tom Wabiszczewicz work in Neohapsis' Chicago office.
Illustration by Jupiterimages