Security debt: SDLC for the best, plan for the worst

Microsoft's Trustworthy Computing initiative celebrated its 10th anniversary in 2012. Many diligent companies have adopted secure software development life cycles aimed at delivering more secure products or protecting their own assets. These initiatives are "front-end" heavy, that is to say, they invest significant time and resources in the early stages of development through security threat modeling, code reviews, penetration testing, and the like -- all in an attempt to build more secure products from the start -- the front-end.

For all the value these front-end efforts provide, they aren't perfect. Complex systems can be difficult for even experienced experts to fully understand. Trust boundaries too often aren't. Applications aren't always accurately decomposed. Threats may be missed or under-estimated. Despite their best efforts, organizations still find themselves compromised and having to respond to breaches. Nevertheless, I have no doubt the problems would be worse if these organizations weren't investing in these front-end activities.

Given the inevitability of breaches, many organizations should focus some portion of their SDLC-like initiatives on the "back-end" of security -- the incident response, investigation and remediation side. Having an IR plan is a start, dedicated head-count for IR is a good step, but think beyond that. If you have an IR team but don't give them the tools to do their job effectively, the costs of inefficient investigations and inadequate remediations add up quickly.

Many organizations invest on the front-end to build secure systems. Mature organizations recognize that even their best efforts will fail and they make investments to build systems that facilitate incident detection, response and remediation.

Go ahead and threat model your apps, review the code, pen test them, but go beyond that. Design applications to log information that will be meaningful for incident responders. Design your systems to forward logs to secure locations where they can be reviewed by automated systems and manually using efficient interfaces. Architect your information systems to facilitate efficient investigations. Enable your investigators with tools for collecting data from hundreds, thousands, tens of thousands of systems worldwide. Plan your deployments for maximum efficiency, but remember when the shit hits the fan, some cycles will be needed for investigations, factor that in to your capacity planning.

Security debt doesn't just come from bugs in your code. If you're not designing your systems to make investigations efficient, you're accruing debt that will eventually come calling.