Software is ubiquitous, even in places you wouldn't imagine. Software is so seamlessly interwoven into the fabric of modern living that it fades into the background without notice. We interact with software not only on home or office computers, but in our routine everyday activities—as we drive to the office in our cars, as we buy things at the supermarket, as we withdraw cash from an ATM, and even when we listen to music or make a phone call.
Just as software is everywhere, flaws in most of that software are everywhere too. Flaws in software can threaten the security and safety of the very systems on which they operate. The best way to prevent such vulnerabilities in software is to proactively incorporate security and other non-functional requirements into all phases of Software Development Lifecycle (SDLC).
We have also written a companion article on software security from the perspective of managing the application development process, looking at valuable concepts from OWASP's CLASP methodology and tools for building developer awareness.
Security Activities in the SDLC—An Overview
Security begins from within
The only reliable way to ensure that software is constructed secure and resilient is by integrating a security and resilience mindset and process throughout the entire software development life cycle (SDLC). From the earliest days of software development, studies have shown that the cost of remediating vulnerabilities or flaws in design are far lower when they're caught and fixed during the early requirements/design phases than after launching the software into production. Therefore, the earlier you integrate security processes into the development life cycle, the cheaper software development becomes in the long haul.
Many of these security processes are often just "common sense" improvements, and any organization can adopt them into its existing environment. There is no one right way to implement these processes—each organization will have to fine-tune and customize them for a specific development and operating environment. These process improvements add more accountability and structure into the system too.
Also see Security Testing of Custom Software Applications, excerpted from the authors' 2010 book Secure and Resilient Software Development, on CSOonline.com
Figure 1 provides a high-level overview of the fundamental security and resilience processes that should be integrated into the various SDLC phases, from requirements gathering to deployment. Each process yields its own findings, and recommendations are prepared for appropriate changes to design, architecture, source code, use of third-party components, deployment configurations, and other considerations to help you to better understand and reduce risk down to an acceptable level. Here you will find guidance on practices that you should consider implementing in each phase of the SDLC:
[Figure 1—Security in SDLC]
SDLC Phase Zero - Developer Training
Even though training does not fit directly into any particular SDLC phase, it plays a very important role in improving the overall security and resilience of developed software. Training should be a prerequisite for anyone who has a role anywhere in the software development environment. All developers and other technical members of the software design/development/test teams should undergo security training that explains the responsibilities of their role, establishes the expectations for their part for security and resilience, and provides best practices and guidance for developing high-quality software.
Training is most effective when it is custom-made to focus on the area of expertise/interest of the target audience (developers, QA, project managers, etc) and includes organization-specific processes, terminology, and practices.
SDLC Phase One: Requirements gathering and analysis
[Security in the Requirements Phase]
The key security and resilience activities during the requirements gathering and analysis phase are intended to map out and document the nonfunctional requirements (NFRs) for the system under development. It is vital to have these ready before the translation of business requirements into technical requirements begins; designers need to understand the constraints they are expected to face and be prepared to answer the call for security and resilience, as well as other NFRs. To be effective, business systems analysts and systems designers should be sure they are very familiar with the environment in which they are operating, by reviewing and maintaining their knowledge about:
- Organizational security policies and standards
- Organizational privacy policy (which may have varying requirements in different places)
- Regulatory requirements (Sarbanes-Oxley, HIPAA, etc.)
- Other relevant industry standards (PCI DSS, ANSI-X9 for banks, etc.)
NFRs are then mapped against the critical security and resilience goals of:
- Confidentiality and privacy
- Integrity
- Availability
- Non repudiation
- Auditing
Finally, these security requirements are prioritized and documented for subsequent phases.
SDLC Phase Two: Systems design
[Security in the Design Phase]
Threat modeling and design reviews are the two major security and resilience processes that you will encounter during the design phase. There are two classes of vulnerabilities:
- Design-related
- Implementation-related vulnerabilities.
While the latter are very easy to find, the former are very expensive and time-consuming to locate and fix if they are not detected early enough in the SDLC. Security subject-matter experts should be deeply involved with the project during this phase to ensure that no bad design issues creep into the design and architecture of the software or the system. Figure 3 illustrates the inputs and deliverables mapped for this phase.
Detailed threat modeling is an excellent way to determine the technical security posture of an application to be developed or under development. It consists of four key steps:
- Functional decomposition
- Categorizing threats
- Ranking threats
- Mitigation planning
The next activity in this phase is the security design review. A security subject-matter expert, who is not a member of the core development team, usually carries out the design review with the key objective of ensuring that the design is "secure from the start." These reviews are typically iterative in nature. They start with the high-level design review and then dive deeply into each component or module of the software.
SDLC Phase Three: Development
[Security in the Development Phase]
Activities in the development phase often generate implementation-related vulnerabilities. Static analysis and peer review are two key processes to mitigate or minimize these vulnerabilities.
Static Analysis
Static analysis involves the use of automated tools to discover issues within the source code itself:
- Bug finding (quality perspective)
- Style checks
- Type checks
- Security vulnerability review
Automated security review tools tend to have a high percentage of false positives, but they are very efficient at catching the low-hanging vulnerabilities that plague most application software (lack of input validation, SQL injection, etc.). Static analysis cannot, however, detect all types of vulnerabilities or security policy violations—that is where manual peer review becomes important.
Peer Review
A peer review process is far more time-consuming than automated analysis, but it is an excellent control mechanism to ensure the quality and security of the code base. Developers review each others' code and provide feedback to the owners (original coders) of the different modules so they can make appropriate changes to fix the flaws discovered during the review. Developers can accomplish this with or without the use of specialized tools.
Unit Testing
Unit testing is another key process that many organizations fail to perform regularly but is important from a security and resilience perspective. Unit testing helps to prevent bugs and flaws from reaching the testing phase. Developers can validate certain boundary conditions and prevent vulnerabilities such as buffer overflows, integer over- or underflows, etc., within a module or sub-module of an application. See Figure 4 for a diagram of the security activities in the development phase.
SDLC Phase Four: Testing phase
[Security in the Test Phase]
The test phase is critical for discovering vulnerabilities that were not located and fixed earlier. The first step in the test process is to build security test cases. Sometimes these test cases are documented as the nonfunctional requirements they relate to are collected and analyzed in earlier SDLC phases. A key input to this process is the systems requirements documentation. The (security) test team uses all the assumptions and business processes captured to create several security test cases. Security testers then use these test cases during dynamic analysis of the application. The software is loaded and operated in the test environment and tested against each of the test cases. A specialized penetration testing team is often deployed during this process. These manual security reviews are very effective in discovering business logic flaws in the application.
Dynamic analysis also consists of using automated tools to test for security vulnerabilities. Just like static analysis tools, these tools are also very efficient in ensuring "code complete" scanning coverage and catching high-risk vulnerabilities such as cross-site scripting, SQL injection, etc.
These tests are iterative in nature and result in a list of vulnerabilities that are then ranked for risk and prioritized. The development team then fixes these errors and sends the remediated code back for regression testing.
SDLC Phase Five: Deployment phase
[Security in the Deployment Phase]
The deployment phase is the final phase of the SDLC, when the software is installed and configured in the production environment and made ready for use by its intended audience.
A key part of managing changes is to use a Change Advisory Board (CAB). A CAB offers the multiple perspectives necessary to ensure good decision making. A CAB is an integral part of a defined change management process designed to balance the need for change with the need to minimize inherent risks. For example, the CAB is responsible for oversight of all changes in the production environment. As such, it fields requests from management, customers, users, and IT1.
During the deployment phase, security subject-matter experts who may or may not be part of the change advisory board perform a final security review to ensure that the security risks identified during all the previous phases have been fixed or have a mitigation plan in place. During this phase, the development team coordinates with the release management and production support teams to create an application security monitoring and response plan. The production support team, in conjunction with the network/ security operation center, uses this plan during the operation of the application to manage security incidents and engage the appropriate teams for response and remediation.
Next: Proven best practices for security software development
Proven best practices for secure software development
To aid in designing new high-quality software once both the functional and nonfunctional requirements are approved and understood, application security and resilience principles and best practices are essential tools in developing solutions, since there are no universal recipes for high-quality software development. Principles help designers and developers to "do the right things" even when they have incomplete or contradictory information.
Also see 'Code security: SAFEcode report highlights best practices' on CSOonline.com
Principle 1: Apply Defense in Depth
The principle of defense in depth emphasizes that security is increased markedly when it is implemented as a series of overlapping layers of controls and countermeasures that provide three elements needed to secure assets: prevention, detection, and response.
Defense in depth, both as a military concept as well as implementation in software and hardware, dictates that security mechanisms be layered in a manner such that the weaknesses of one mechanism are countered by the strengths of two or more other mechanisms.
Think of a vault as an example. A bank or jewelry store would never entrust its assets to an unguarded safe alone. Most often, access to the safe requires passing through layers of protection that may include human guards, locked doors with special access controls (biometrics such as fingerprints or retinal scans, electronic keys, etc.), or two people working in concert to gain access (dual control). Furthermore, the room where the safe is located may be monitored by closed-circuit television, motion sensors, and alarm systems that can quickly detect unusual activity and respond with the appropriate actions (lock the doors, notify the police, or fill the room with tear gas).
In the software world, defense in depth dictates that you should layer security devices in series that protect, detect, and respond to likely attacks on the systems. The security of each of these security mechanisms must be thoroughly tested before deployment to help gain the needed confidence that the integrated system is suitable for normal operations. After all, a chain is only as good as its weakest link.