Security as a Function of Agility and Complexity

January 23, 2007

It occurs to me that security, in general, has historically been measured as a function of a few inputs: Pro-activity (locking up early), accuracy (locking things correctly), and completeness (locking all the doors). What's missing from this equation is the fact that people often lock their valuables away and assume that they're safe indefinitely that way. All codes, passwords, and locks degrade in value over time, and need to be replaced with better models. In any inherently insecure medium, such as the moving parts of software, security naturally erodes as requirements shift.

There's a common misconception that security follows the rules of superposition. That something that has been secured (A), combined with something else that has been secured (B) will also be secure. The physical analogy with locks breaks down with more complex mediums, such as software, due to the intrinsic interdependence between modules. A might call procedures in B that call back into procedures in A. The interfaces between modules may add arbitrary amounts of code complexity when pieced together.

So, what to do about this situation? Two remedies: Scan for software security issues frequently. Scan whole programs not just parts of programs. An analysis can't simply scan module 'A' and expect module 'B' to play ball. This is made more difficult when you only have source code to module 'A', and not module 'B'. This officially makes the problem harder to deal with than most people would like to admit.

On top of coverage, one must expect to scan more frequently as the threat landscape changes.

Bump keys changed the game for physical security and the majority of locks built need to be replaced with different mechanisms to solve this problem. Thankfully, when the equivalent of the bump key comes to software (as remote vulnerabilities often do in operating systems), we can often upgrade it automatically when remedies are made available.

Agility, the ability to respond quickly to new threats when recognized, is of utmost importance. Old versions of software need to be scanned for new problems, as deprecation is purely the desire of the software producer, and not its eventual owners, who are generally satisfied with something that has 'just worked' for a long time.

Agility and automation are effectively the same thing in software security. The ability to automatically respond is required to manage vulnerability detection in legacy or deprecated versions of software, especially as the threat landscape changes. The digital immune system needs to be 'always-on', and deal with the occasional infection with speed and then come to recognize problems quicker the next time they surface.

Make application security a constant, automated process, not a turnkey, one-off effort.