New SDLC: Security Development Life Cycle
When I heard Security Development Life Cycle, my first reaction was, is it really possible?
But, as always, Microsoft surprised me with the introduction of SDL. I just went through a paper published by Microsoft and , I have included most of the points ‘as-is’ in this article.
What is SDLC or Security Development Life Cycle?
It is a simple framework for the pragmatic inclusion of security practices in the software development process. It outlines a series of discrete, non-proprietary security development activities that when joined with effective process automation and solid policy guidance represent the steps necessary for an organization to objectively claim compliance with the Microsoft SDL as defined by the “Advanced” level in the SDL Optimization Model.
Just stress on few keywords in the above definition for ex: ‘security practices’ , ‘series’ , ‘organization’ , ‘compliance’. Now, we can try and and relate these terms in a generic manner, first of all by ‘generic practices’- we mean that SDL is not a hand written document but these are few practices which originated from individual or group’s experiences. Second, ‘series’ implies that these are a chain of steps or guidelines which are followed in an organized manner to achieve the goal. Third, ‘organization’ – this is the most important keyword which stresses on a dynamic SDLC dependent on an organization’s needs. It basically holds the due share of an organization in applying SDLC. Fourth and Last, ‘compliance’- which says set your standards and I’ll follow. This is the basic need of industry and widely accepted as a criteria in every organization.
What are the activities expected?
To achieve Security, Integration of secure development concepts into an existing development process is required. Here, we have mentioned all the stages of our other SDLC [Software Development Life Cycle] combined with security concepts to achieve our new SDLC [Security Development Life Cycle].
We will see what all security concepts can be accumulated at each stage of SDLC.
Pre-SDL Requirements: Security Training
SDL Practice 1: Training Requirements
All members of a software development team(developers, testers, and program managers) must receive appropriate training to stay informed about security basics and recent trends in security and privacy.
Basic software security training should cover foundational concepts such as:
- Secure design, including the following topics:
• Attack surface reduction
• Defense in depth
• Principle of least privilege
• Secure defaults
- Threat modeling, including the following topics:
• Overview of threat modeling
• Design implications of a threat model
• Coding constraints based on a threat model
- Secure coding, including the following topics:
• Buffer overruns (for applications using C and C++)
• Integer arithmetic errors (for applications using C and C++)
• Cross-site scripting (for managed code and Web applications)
• SQL injection (for managed code and Web applications)
• Weak cryptography
- Security testing, including the following topics:
• Differences between security testing and functional testing
• Risk assessment
• Security testing methods
- Privacy, including the following topics:
• Types of privacy-sensitive data
• Privacy design best practices
• Risk assessment
• Privacy development best practices
• Privacy testing best practices
The preceding training establishes an adequate knowledge baseline for technical personnel. As time and resources permit, training in advanced concepts may be necessary. Examples include, but are not limited to, the following:
• Advanced security design and architecture
• Trusted user interface design
• Security vulnerabilities in detail
• Implementing custom threat mitigations
Phase One: Requirements
SDL Practice 2: Security Requirements
Requirement Phase allows development teams to identify security and privacy needs in a way that minimizes any disruption to plans and schedules. Security and privacy requirements analysis is performed at project inception and includes specification of minimum security requirements for the application as it is designed to run in its planned operational environment and specification and deployment of a security vulnerability/work item tracking system.
SDL Practice 3: Quality Gates/Bug Bars
Quality gates and bug bars are used to establish minimum acceptable levels of security and privacy quality. A project team must negotiate quality gates (for example, all compiler warnings must be triaged and fixed prior to code check-in) for each development phase. A bug bar is a quality gate which is used to define the severity thresholds of security vulnerabilities—for example, no known vulnerabilities in the application with a “critical” or “important” rating at time of release. The bug bar, once set, should never be relaxed.
SDL Practice 4: Security and Privacy Risk Assessment
Security risk assessments (SRAs) and privacy risk assessments (PRAs) are mandatory processes that identify functional aspects of the software that require deep review. Such assessments must include the following information:
1. (Security) Which portions of the project will require threat models before release?
2. (Security) Which portions of the project will require security design reviews before release?
3. (Security) Which portions of the project (if any) will require penetration testing by a mutually agreed upon group that is external to the project team?
4. (Security) Are there any additional testing or analysis requirements the security advisor deems necessary to mitigate security risks?
5. (Security) What is the specific scope of the fuzz testing requirements?
6. (Privacy) What is the Privacy Impact Rating? The answer to this question is based on the following guidelines:
• P1 High Privacy Risk. The feature, product, or service stores or transfers PII, changes settings or file type associations, or installs software.
• P2 Moderate Privacy Risk. The sole behavior that affects privacy in the feature, product, or service is a one-time, user-initiated, anonymous data transfer (for example, the user clicks on a link and the software goes out to a Web site).
• P3 Low Privacy Risk. No behaviors exist within the feature, product, or service that affect privacy. No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user’s behalf, and no software is installed.
Phase Two: Design
SDL Practice 5: Design Requirements
It is critically important to consider security and privacy concerns during the design phase. There is a basic difference between “secure features” and “security features”. Secure features are defined as features whose functionality is well engineered with respect to security, including rigorous validation of all data before processing or cryptographically robust implementation of libraries for cryptographic services. The term security features describes program functionality with security implications, such as Kerberos authentication or a firewall.
Design specifications should describe security or privacy features that will be directly exposed to users, like user authentication and authorization before allowing use of a privacy feature. Also, It should also describe how to securely implement all functionalities.
SDL Practice 6: Attack Surface Reduction
Attack surface reduction is a means of reducing risk by giving attackers less opportunity to exploit a potential weak spot or vulnerability. Attack surface reduction includes restricting access to system services, applying the principle of least privilege, and employing layered defenses wherever possible.
SDL Practice 7: Threat Modeling
Threat modeling allows consideration of security issues at the component or application level. It favors involvement of program/project managers, developers, and testers, and represents the primary security analysis task performed during the software design stage.
Phase Three: Implementation
SDL Practice 8: Use Approved Tools
Development teams should use the latest version of approved tools to take advantage of new security analysis functionality and protections.This list of tools should be approved by the security advisor for the project team.
SDL Practice 9: Deprecate Unsafe Functions
Project teams should analyze all functions and APIs that will be used in conjunction with a software development project and prohibit those that are determined to be unsafe. Many commonly used functions and APIs are not secure in the face of the current threat environment. These functions should be replaced with safer alternatives.
SDL Practice 10: Static Analysis
Static analysis of source code provides a scalable capability for security code review and can help ensure that secure coding policies are being followed. The security team and security advisors should be aware of the strengths and weaknesses of static analysis tools and be prepared to augment static analysis tools with other tools or human review as appropriate.
Phase Four: Verification
SDL Practice 11: Dynamic Program Analysis
Run-time verification of software programs is necessary to ensure that a program’s functionality works as designed. This verification task should specify tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.
SDL Practice 12: Fuzz Testing
Fuzz testing is a specialized form of dynamic analysis used to induce program failure by deliberately introducing malformed or random data to an application. The fuzz testing strategy is derived from the intended use of the application and the functional and design specifications for the application.
SDL Practice 13: Threat Model and Attack Surface Review
Although re-work is avoided but sometimes it is fruitful to re-review threat models and attack surface measurement of a given application. This review ensures that any design or implementation changes to the system have been accounted for, and that any new attack vectors created as a result of the changes have been reviewed and mitigated.
Phase Five: Release
SDL Practice 14: Incident Response Plan
Every software release subject to the requirements of the SDL must include an incident response plan. The incident response plan should include:
• A emergency response plan (ERP) that identifies the appropriate engineering, marketing, communications, and management staff to act as points of first contact in a security emergency.
• On-call contacts with decision-making authority that are available 24 hours a day, seven days a week.
• Security servicing plans for code inherited from other groups within the organization.
• Security servicing plans for licensed third-party code, including file names, versions, source code, third-party contact information, and contractual permission to make changes (if appropriate).
SDL Practice 15: Final Security Review
The Final Security Review (FSR) is a deliberate examination of all the security activities performed on a software application prior to release. The FSR includes an examination of threat models, exception requests, tool output, and performance against the previously determined quality gates or bug bars. The FSR results in one of three different outcomes:
• Passed FSR. All security and privacy issues identified by the FSR process are fixed or mitigated.
• Passed FSR with exceptions. All security and privacy issues identified by the FSR process are fixed or mitigated and/or all exceptions are satisfactorily resolved. Those issues that cannot be addressed (for example, vulnerabilities posed by legacy “design level” issues) are logged and corrected in the next release.
• FSR with escalation. If a team does not meet all SDL requirements and the security advisor and the product team cannot reach an acceptable compromise, the security advisor cannot approve the project, and the project cannot be released.
SDL Practice 16: Release/Archive
Software release to manufacturing (RTM) or release to Web (RTW) is conditional on completion of the SDL process. The security advisor assigned to the release must certify (using the FSR and other data) that the project team has satisfied security requirements.
In addition, all pertinent information and data must be archived to allow for post-release servicing of the software. This includes all specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, license and servicing terms for any third-party software and any other data necessary to perform post-release servicing tasks.
These are the guidelines or practices which can be adapted to achieve security in SDLC. We recommend use of Security Development Life Cycle, so for more information, please visit msdn site.