Applying “Security in Depth” Requires Documentation and Cooperation
When applied to software, the principle of Security in Depth helps us mitigate the fact that we will always produce flawed applications. In this case the flaws of which I am writing relate to the security of the application. Although we should always strive to create secure code, the fact is that exploitable vulnerabilities will eventually be discovered in our programs.
Certainly the odds of an exploit being discovered are based on the complexity of the application, the value of the data accessible through the exploited application and the quality of the security-related focus given to the application during the SDLC. Note that the value of the data accessible through the exploited application is not necessarily limited to what the application is supposed to access, but rather what is exposed by the exploit.
Since we know that we cannot produce “perfect” code, we need to plan for minimizing the impact of a successful exploit. In other words, we strive to make the value of the data accessible through the exploited application no greater than the value of the data the application is intended to access by an authenticated and authorized user. Security in Depth is a powerful approach to meeting this objective.
Security in Depth requires that each tier in our application enforce the same restrictions on information flow as the other tiers. For example, if our front-end is restricting input to a maximum length and escaping HTML and JavaScript strings, then the object and the persistence layers should do likewise. If a user is restricted to accessing certain data as part of the application’s operation, the database management software should enforce the same limitations.
The idea is that each component involved in the operation of the application acts as a security failsafe for the other components. If a coding error permits an attacker to inject SQL into the application, the database will prevent the crafted SQL statement from accessing more information than a legitimate user would have seen. When combined with the principle of Least Privilege (topic for another post), leveraging Security in Depth goes a long way toward reducing the impact of an exploit.
In order to effectively apply Security in Depth the requirements need to be defined with enough detail so that the designers of the front-end, mid-tier and back-end can all understand what operations are permitted and what data is accessible. Further, the constituents involved in designing and implementing the system must cooperate in order to achieve this security-centric agreement without slowing down the development cycle. Information Security is everyone’s responsibility and creating a secure application should be a source of pride not pain.
Having application requirements that explicitly document security-related information also increases the effectiveness of security testing. Tests can be crafted to poke at the security being enforced at each tier. Creating a Failure Mode and Effects Analysis (FMEA) centered on the risks to systems and data is one way to effectively create this documentation. I’ll discuss the use of an FMEA during the requirements phase in a future post.
Validating the use of Security in Depth should be a standard part of any architecture and design review process. The information necessary to successfully apply this principle must be documented before developers begin implementing a system. The key to this strategy is the consistent and independent application of security restrictions by each component. This is unlikely to occur if the implementation teams are not working from a unified source of requirements documentation.