Fortunately, we’ve made a lot of progress in the last five-to-ten years. Many organizations follow a formal software development process now. The Rational Unified Process and Agile methods, like eXtreme Programming, are two of the most common.
However, when it comes to security, these process methodologies don’t have much meat. Virtually none, in fact.
To design, build, and deploy secure applications, organizations must integrate security into every facet of their application development lifecycle. They must include specific security-related activities in their process from requirements gathering through deployment.
There is an accepted five-step process for developing software. The table below shows the typical activities in a team development process. Each one has a unique benefit that enables an organization to move through the process in an orderly manner.
Security Requirements and Objectives: These help organizations think about security early on in the project. They represent specific security goals and constraints that affect the confidentiality, integrity and availability of important application data and the means by which that is accessed.
If these requirements aren’t specified they won’t be built or tested.
Threat Modeling: This helps the development team understand the vulnerabilities and threats a specific application may see in its deployed environment.
This is an exercise that can be done before coding has begun but is very useful to perform throughout the project lifecycle. The output will be a blueprint of where an application is potentially weak. There are several good reference guides to help with threat modeling, including a free threat modeling reference from NIST (National Institute of Standards and Technology).
Security Design Reviews: SDRs are an application structure review from a security perspective. They examine a number of aspects including deployment infrastructure, the overall application architecture and design at each layer or tier.
Security code reviews, on the other hand, are built on the premise that all code should be subject to inspection with an emphasis on identifying security vulnerabilities.
This best practice is a non-stop activity during the development and test phases. There are many excellent resources available for code reviews including those from Microsoft.
Building security test cases forces testers to think like malicious users. Instead of typical test cases, they need to construct “what if” scenarios. The testers must plan testing activities to demonstrate that the application has been hardened to block an attack or unintentional misuse.
Penetration Testing:This puts the application through the paces of a series of attacks. Output from the threat models can be reused here to establish the focus and scope of the testing.
For example, did the tester try a series of SQL injection attacks vs. cross-site scripting? Did the tester attack the user interface vs. the database server?
Final Security Review: This step is conducted prior to deployment and is the last look in the mirror before walking out the door.
Have all those weak spots found in the threat modeling and penetration testing phases been addressed? Have you made all the proper configuration settings in the database, Web server, and other areas to ensure they don’t introduce security vulnerabilities?
While this all sounds great the question you are probably asking is: “But how do I convince my boss?”
If the boss needs convincing on why security activities are important in software development, point him/her to any of the following references: ·
If the boss already knew about these fiascos, that’s good, because otherwise his or her head has been in the sand for the past nine months. But even if the fear of being the next ChoicePoint or Card Systems doesn’t instill great fear, tell him that these security activities can be implemented incrementally.
The activities to adopt first should be related to the security objectives identified. Most organizations find good results from adopting security requirements and objectives first, followed by security design review and threat modeling.
Security requirements and objectives set the stage for the rest of the activities, so it is wise to start there. Security design reviews give an early insight into potential problems, as does threat modeling, and both can be performed early where security defects are easier and less costly to fix.
The later-stage activities can easily be outsourced, as there are many capable experts to conduct security code reviews and penetration testing.
Ed Adams is CEO of Security Innovation, an independent provider of application security services that include security testing and training.