Author: Blaine Wilson
April 2007
by Blaine Wilson, Application Architect, Reynolds & Reyolds
Many of the articles we read on application security discuss very specific implementation issues such as SQL Injection and buffer overflows. These articles focus on implementation flaws that sneak into our applications while actually writing the code. While these topics are important, they are not the beginning or end of security. Many people believe addressing these issues will make their applications secure, but this is far from the truth. Dr. James Walden from Northern Kentucky University gave statistics at the 2007 Ohio Information Security Conference showing 50% of security flaws being implementation defects and 50% being application design defects. So what is a design defect and an implementation defect? I heard I should plan security as early in the development life cycle as possible, but what does this mean? This article will cover the phases of the Software Development Life Cycle and will outline the security tasks that should be occurring in each phase.
The Initiation Phase is where the life cycle begins. We realize a need and come up with a rough plan on how we can meet the need. Most of the details on what we are building will not be clear, but we should be able to figure out why we are building our application. We talk with the customer and establish a list of what they need the application to do (called the customer requirements). This is where the first design flaw can get introduced into your application and where security needs to begin. The first design flaw occurs when you fail to define what needs to be protected. Before you can define how to protect the sensitive data in your application, you have to know what you are protecting. We take the customer requirements and define the data the application will be working with. We classify the data into categories such as consumer personally identifiable information, consumer financial information, consumer medical information, etc. We compare the classified data against government regulations, your company’s information security policy and industry best practices to create the security requirements for the application.
During the Design Phase we create a design to meet the customer and security requirements created during the Initiation Phase. We know what we are trying protect and now we are to figure out how to protect it. The second design flaw occurs when your design fails to meet the security requirements of the application. You should create a security design to meet the security requirements. Review the design and confirm all of the security requirements have been met by the design.
The Development Phase is where we build the application we planned during the previous phase. You will want to pull out those articles on SQL Injection, buffer overflows, etc. and make sure you have not accidentally introduced application implementation flaws. There are many tools available to assist with finding implementation defects in your code. These tools can be expensive and will not find design flaws. Conduct code reviews to confirm the security design as been met. Code reviews can also be a cost effective way to find implementation flaws.
The Testing Phase confirms the customer requirements have been met. The testing should include checks for both design and implementation flaws. Use the security requirements to create test cases for design flaws. Once again, you will pull out the articles on implementation flaws to create test cases for implementation flaws. There are many tools available to assist with security testing for implementation defects, but keep in mind many of these tools can be destructive. Make sure you know exactly how your test tool will impact your application, your data and your network.
The Deployment Phase is when we deliver the application to the customer. This is where host implementation flaws can occur. While the application implementation flaws were introduced by our development team during the development phase, host flaws occur by not protecting the computers the applications are residing on. Most operating system vendors have documentation on hardening their systems to remove these types of security flaws. Use this documentation to strengthen your host computer and make sure you test it. Keep in mind some of the computers will be in your customer’s control and you will not have the opportunity to harden these computers. If this is the case, you should put together security recommendations to help your customers to protect themselves.
We have covered the basic phases of the Software Development Life Cycle and the basic security tasks that should be occurring in each phase. Security is not single task that can be accomplished once and forgotten, but instead needs to introduced at the beginning of the life cycle and built on in every phase.
About the Author: Blaine Wilson is an application architect at the Reynolds and Reynolds Company and is a member of the Dayton Chapter of the ISSA.
Disclaimer: The opinions or statements expressed here are my own and should not be taken as a position, opinion, or endorsement of the Reynolds and Reynolds Company or the Dayton ISSA.
