Refactoring Security Design

This book is mainly about patterns. It describes a set of security patterns and how, when, and why to use them. It also discusses a methodology for building secure applications using patterns. Often, though, you are not starting from scratch when attempting to secure an application. Furthermore, you rarely choose all of the right patterns and strategies in the design the first time around. To address this, we need to adopt Refactoring.

Refactoring is, as defined by Martin Fowler, "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior" [Fowler1]. So, why do we want to make a change to the software if we do not need to change its behavior? The answer is that we want to make the system easier to understand and maintain so that we can eliminate any unknown vulnerabilities hiding in the obscurity of a complex design or code implementation. Refactoring leads to simplicity, and security always favors simplicity over complexity.

As Joshua Kerievsky put it, "When you refactor, you relentlessly poke and prod your code to improve its design" [Kerievsky1]. He also goes on to state that the only way to refactor safely is to continuously test the changes. In the case of security pattern refactoring, this involves the functional, white box, and black box testing. Once the refactoring is complete and well-tested, you are left with a better overall design that will be more future-proof. Many of the security holes we see today are not the artifacts of a poor initial design or implementation. Instead, they are the result of series of add-ons and work-arounds that led to overly complex code and inevitably to bugs that are attributable to that complexity. Continuous refactoring protects applications from becoming buggy by continuing to simplify and refine the design and code.