Blog Series: Get Familiar with the SDL-LOB Process, Introduction to Phase Two: Design for LOB
Hello, Anmol here. This is a continuation of my blog series on the SDL-LOB process. In my last blog entry I talked about Phase 1: Requirements for LOB . Let’s discuss Phase Two: Design for LOB. As you read my blog series on the SDL-LOB process, I will try to share experiences and lessons learned from an Information Security group perspective.
Phase Two is all about ensuring that application follows “Secure by Default” principle.
There are 2 key tasks to be executed in this phase:
· Threat Modeling
· Design Review
Both of these activities are aimed towards identifying security design flaws upfront in the lifecycle and helping in reducing the number of security bugs propagating on to the next stages. It is far more resource intensive and cumbersome to mitigate issues identified during verification phase and even costlier if identified in production time. Let me illustrate this by an example shown below:
Let’s assume that your design did not consider validating user controlled input and output encoding strategy. This would result in developers coding and developing the application without deviating from the final design which lacked specific security considerations in the first place. This would eventually result in 100s of “Cross Site Scripting” bugs turning up during verification stage. I am sure no application team would want that to happen. Wouldn’t it be nice if we followed few design time activities which would call out specific security considerations that need to be followed by the development team in the context of the application?
To learn more read the detailed Design phase tasks here and also watch my podcast "Security Design Reviews" where I discuss more why security should be "baked" into the application starting with the Design phase. Next time, I’ll talk about Phase Three: Implementation for LOB.
Here are some additional resources
-Anmol Malhotra
Senior Security Engineer
ACE Team