Web App Security with the Microsoft Simplified SDL
Published: February 16, 2011
Author: Chas Jeffries, Security Architect, Microsoft Services
Cloud computing brings significant advantages to developers enabling faster times from coding to deployment than we have ever seen. While these efficiencies have streamlined some tradition processes and historical logistical issues for environment preparation and deployment, the flip side is that it also makes it faster to deploy vulnerabilities we might have in our web application code. Therefore it is more important than ever to ensure that security is at the forefront of our minds and processes when we are designing and developing our web applications. This article will provide a brief overview of common threat considerations for web application development and deployment and will describe how you can leverage the Microsoft Simplified Security Development Lifecycle (SDL) to help mitigate those threats while achieving the speed and efficiency of cloud computing. While a supported cloud development scenario is for native code, this article will primarily focus on the managed web application scenario.
The Microsoft Simplified SDL provides us with a lightweight framework that allows us to realize the benefit of the SDL by focusing on those aspects of the SDL that deliver the greatest benefit with minimal effort. We do not compromise any of the quality of the complete SDL since the Simplified SDL follows each of the SDL phases and defines mandatory security activities that enable compliance for secure application development. It is important to note that the Microsoft SDL is based on three core concepts of education, continuous process improvement, and accountability. As we will discover, each one of these concepts is highly applicable when applied to web application development.
Figure 1 – Simplified SDL
Often times, web application development implies the use of an agile development methodology such as Extreme Programming (XP) or Scrum. Though not always a given, the nature of web application development lends itself to the use of these models as they use quick iterations and factor incremental release feedback into the lifecycle of the application. Fortunately, this doesn’t mean that you don’t get the benefit of including security in your chosen agile methodology as the Microsoft SDL team has published guidance for SDL-Agile. We will be discussing SDL-Agile in some detail in this article, though we recommend those that may just be picking up the SDL and factoring it into web application design carefully study the guidance for maximum benefit.
As we mentioned earlier, education is one of the core concepts of the Microsoft SDL. Having a common baseline of security education is essential for each member of the project development team. For web application development training could be a low cost and high ROI endeavor if the team is small. At a minimum, the core web application development team should be made familiar with each of the phases of the Simplified SDL and understand the requirements when applying these activities to agile development methodologies. The SDL recommends that each team member complete at least one security training course each year as a requirement. The Simplified SDL provides guidance on the minimum training foundation which should be included in that training.
Good security fundamentals dictate that we begin with the end in mind. It is important to point out that even though not explicitly stated; security is a customer requirement. Developing insecure applications will lead to dissatisfied customers...guaranteed! The good news is that since we are following the Simplified SDL, we begin with security requirements from the very beginning. Developing a solid understanding of the security expectations for the application from the very beginning is essential to a secure design.
Designing for security
As we dive deeper into our web application design, we should have a good understanding of the interconnections and dependencies of the application. Following the SDL, this is the time when we want to threat model our application. Developing a threat model is useful not only to understand the threats and how to mitigate them through design, but as a general design review process to understand the application’s interaction with its environment. Often in agile development methodologies, design artifacts are minimized. This is where a threat model is even more valuable as it may provide the only blueprint for the application that will persist between iterations. The threat model should be updated for each iteration, increment or sprint.
Web application development typically means that we will be using languages that provide insulation from some of the thorny security issues, such as buffer overflows, that we must deal with when writing unmanaged code. However that is not a reason to not approach development with a security mindset. Insecure code can be just as damaging to a web application as native code developed in C or C++. Things we will be concerned with in this phase might include (but certainly not be limited to) input validation (including protection against parameter manipulation), authentication, authorization, protecting sensitive or private data, session management, cryptography, exception management, and application auditing and logging.
Diving a bit deeper into the technical elements for secure code for web application development, we will consider more specific threats to web applications. Depending on our design, these threats might require us to consider protection against query string manipulation, cookie manipulation, cross-site scripting (XSS), and SQL injection. When user authentication and authorization methods are implemented to provide access to private or sensitive data, special attention must be paid to ensuring that these features are implemented in a secure manner.
Security testing and verification
Testing according to the full SDL is mostly likely too heavy for web app development, especially when factoring in an agile development methodology. As we mentioned earlier, Microsoft provides guidance on using the SDL for Agile development. That guidance recommends that not all testing and verification tasks be accomplished within an iteration or sprint, and instead at least one testing and verification task be completed per iteration or sprint. These tasks will include activities such as fuzzing and attack surface analysis. Refer to the figure below to understand sequencing testing and verification tasks into an agile process.
Figure 2 – SDL-Agile process
Automation is essential for testing and verification activities when following an agile methodology. Tools such as FxCop can greatly assist in this regard and should be run every iteration or sprint.
Considerations for release
When planning the release of web applications, security is a major consideration with novel aspects. Given the factors we face in the cloud that are different from release on our own premises such as tenancy issues (we may not know who we are sharing a server with) and lack of administrative control, we must carefully consider the dimension of security regarding configuration management and app control. Here we need to consider protecting the administrative interfaces to the application along with protection of configuration data and ensuring the integrity of the access model for the application is sound.
When following the Microsoft SDL, we perform a Final Security Review (FSR) before releasing our application to the cloud. However, the SDL-Agile process accommodates for a streamlined FSR procedure that accounts for the iterative or incremental nature of release when following an agile methodology. The FSR should not be viewed as a burden when applying it to an agile methodology. Instead, use the FSR to capture the design level issues under consideration for the next sprint using appropriate methods. The FSR becomes a valuable activity during this stage that will enable the project team to improve the security of the web app in the next release.
The end game
Okay, we have deployed our web app to the cloud and we are ready to move on to the next project. This is often the reality of things. With any luck we have included a servicing model into our design, though additionally by following the SDL we have developed a response plan that is security focused for the application. We can rest assured that should our application become subjected to any unforeseen threats over time, that we have a process in place to deal with those threats. We hope you have found this article helpful in understanding how the SDL can help you improve the security of your applications. We wish you luck in developing applications that will maximize the benefit of working with the cloud while keeping your customers’ experience and data secure along the way!
About the Author
Chas Jeffries is a Security Architect in Microsoft Services who focuses on Cyber Security and the Security Development Lifecycle. Prior to joining Microsoft Services was a Lead Program Manager for 10 years providing program management for the development of various applications for Microsoft.com and security components for the Microsoft Windows operating system. Chas is a CISSP and holds a MS in Computer Science from the University of Nebraska.