InformationWeek’s August 31, 2009 issue included a nice article from the folks at Neohapsis (Greg Shipley, Tyler Allison, Tom Wabiszczewicz) titled Breach Diaries: 5 lessons learned from the front lines of today’s major data thefts. I’d link to the article, but InformationWeek wants you to register first. Lame, because the article hits key points very well which I’ll very briefly list. Some of the thoughts are my own below, but many are yoinked from the article. I share this because, as the article states in the beginning, the business tendency to shut up about breaches is making it harder for security to improve.

1. Get serious about web security. Web apps are being widely used as attack vectors. WAFs buy time, but the root issue is code. Review apps and incorporate security into dev cycles.

2. Add secondary controls. This includes internal firewalls, network segmentation, encryption, database monitoring. Implementing them is not enough. Implement them with a purpose, audit the settings/policies/configs, and watch the logs. Arguably weighted in the reverse order!

3. Know your limits. Most (hell, all!) security technology has limitations. Know them and lean on those techs only as much as they should be leaned on. Fill in the gaps with other solutions (usually watching events, traffic, anomalies, etc) and diligence. I really think this is where staff will make or break you, not the technology.

4. Trust but verify. Wake up every morning and say this until you live this.

5. Plan for incidents. This is another “duh” item, but a tougher one when you get down to it. For instance, how often does a security breach happen compared to a simple system outage/issue/mistake? A vast majority of the time an admin attends to an issue, the response is to rebuild or do things that destroy data. I’d argue that once an incident is truly suspected, then IR policies come into play, but for day-to-day work, I would usually suspect that systems or evidence may get destroyed or at least tainted. Really, this might come down to being careful to keep logs and audit trails and events separate from day-to-day ops.