A Verizon 2009 DBIR supplement has been released and I’ve finally looked it over. If you don’t have much time, just browse the intro, and then read the Case Example sections (pg 7-21) for each attack type and the Conclusion section (pg 22). While there are still questions on specifics (aren’t there always?), this is far more information than we had before!

A few things pop into mind as I read down the case examples. Egress controls. Policy and administrative access. Noticing strange behavior. Termination policy (That guy must have been laughing at his former employer’s IT staff every time he connected!). Endpoint integrity (and policy). Default passwords (ouch; vendors install your shit better, too!). Endpoint security. SQL injection, network segmentation, egress flow monitoring. SQL injection and egress monitoring (impressed that this org even bothered to parse logs for SQLi, although obviously not an always-on practice with months old findings). Vendor/provider security and notification (#9 is really interesting, and a very hard one to combat/monitor). Proper authentication and help desk training (another team in IT that is evaluated by customer service [i.e. doing what the customer asks] as opposed to doing the right thing; often not paid enough to care, to be honest). Web app flaw. Physical theft and storing of card information (does anyone do regular rounds just to make sure nothing is stolen or added to things like this?). Log/authentication attempt monitoring and web app flaws (another ouch, but another one that so few really do). Endpoint security (RAM scraping…wow!). The phishing attack is interesting, as it involves training and pretty good log watching.

I really like the Conclusion section, especially the bulleted lessons is stresses.

In looking at these specific cases, it really pops out that we have a mix of “easy” and “advanced” security concepts here. Egress and deeper log analysis I consider more advanced topics because they take time and staff to really properly tackle. Other attacks should be easy, but are hard to get people to fix, like SQL injection or application flaws. To most business units, if it appears to work, then the project and capitalization are over. Evaluating, fixing, and testing something that doesn’t immediately appear to affect the bottomline gets pushed off.