Application of Secure Software Development Life Cycle (SDLC) for PCI DSS Implementation.
Introduction
The Secure Software Development Life Cycle (SDLC), or simply SDL (Secure Development Lifecycle) is an approach to software development that emphasizes security from the outset.
In this article, we will explore what SDL and threat modeling are, discuss the benefits of incorporating security into the development process, examine PCI DSS requirements related to SDLC, and conclude with the importance of adopting a security-first approach in software development.
Benefits of SDL
The quote describes the benefit from another perspective.
“The cost of removing an application security vulnerability during the design phase ranges from 30-60 times less than if removed during production.” NIST, IBM, and Gartner Group
Let's briefly review the SDL.
MICROSOFT
One of the best points to start is to explore Microsoft SDL practices.
What are the Microsoft SDL practices?
The Security Development Lifecycle (SDL) consists of a set of practices that support security assurance and compliance requirements.
The SDL helps developers build more secure software by reducing the number and severity of vulnerabilities in software while reducing development costs.
The cycle consists of 12 practices
Practice #1 - Provide Training
Practice #2 - Define Security Requirements
Useful links:
Practice #3 - Define Metrics and Compliance Reporting
Useful Links:
Practice #4 - Perform Threat Modeling
Useful Links:
Practice #5 - Establish Design Requirements
Practice #6 - Define and Use Cryptography Standards
Useful Links:
Practice #7 - Manage the Security Risk of Using Third-Party Components
Useful Links:
Practice #8 - Use Approved Tools
Useful Links:
Practice #9 - Perform Static Analysis Security Testing (SAST)
Useful Links:
Practice #10 - Perform Dynamic Analysis Security Testing (DAST)
Useful Links:
Practice #11 - Perform Penetration Testing
Useful Links:
Practice #12 - Establish a Standard Incident Response Process
Useful Links:
OWASP
If take Owasp, it divides SDL into the stages
1. Requirements definition
2. Design
3. Development
4. Testing
5. Implementation
There are many good posts and articles on https://owasp.org/.
Threat Modeling
One of the crucial points or stages of the SDL is Threat Modeling.
In Owasp SDL Stage 2 consider the Threat Modeling.
According to Microsoft SDL (Practice #4 - Perform Threat Modeling.)
Threat modeling is a core element of the Microsoft Security Development Lifecycle (SDL). It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.
There are five major threat modeling steps:
Threat modeling should be part of your routine development lifecycle, enabling you to progressively refine your threat model and further reduce risk.
Owasp SDL Stage 2 considers the Treat Modeling.
According to OWASP the Treat Modeling Process consists of the following steps (https://owasp.org/www-community/Threat_Modeling_Process#introduction)
Tools for Threat Modeling
PCI DSS Requirements Related to SDL
PCI DSS, the Payment Card Industry Data Security Standard, includes several requirements related to SDL:
Bespoke Software
Bespoke software is developed for the entity by a third party on the entity’s behalf and per the entity’s specifications.
Custom Software
Custom software is developed by the entity for its own use.
Development of software has a dedicated/separate Requirement in PCI DSS, Requirement 6 Develop and Maintain Secure Systems and Software.
Let us read the requirement once again Develop and Maintain Secure Systems and Software ... it sounds like an SDL, is not it?
领英推荐
Let us dive into the Requirement 6.
-Documented.
-Kept up to date.
-In use.
-Known to all affected parties
6.1.2 Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
6.2 Bespoke and custom software are developed securely
6.2.1 Bespoke and custom software are developed securely, as follows:
- Based on industry standards and/or best practices for secure development.
-In accordance with PCI DSS (for example, secure authentication and logging).
Incorporating consideration of information security issues during each stage of the software development lifecycle
6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
-On software security relevant to their job function and development languages.
-Including secure software design and secure coding techniques.
Including, if security testing tools are used, and how to use the tools for detecting vulnerabilities in software.
6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:
-Code reviews ensure code is developed according to secure coding guidelines.
-Code reviews look for both existing and emerging software vulnerabilities.
Appropriate corrections are implemented prior to release
6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
-Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices. Reviewed and approved by management prior to release.
6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
-Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
-Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
-Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
-Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
-Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms. Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
6.3 Security vulnerabilities are identified and addressed.
6.3.1 Security vulnerabilities are identified and managed as follows:
-New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
-Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
-Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered
6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management
6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
-Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).
6.4 Public-facing web applications are protected against attacks.
6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
-Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
-At least once every 12 months and after significant changes.
-By an entity that specializes in application security.
-Including, at a minimum, all common software attacks in Requirement 6.2.4.
-All vulnerabilities are ranked in accordance with requirement 6.3.1.
-All vulnerabilities are corrected.
-The application is re-evaluated after the corrections
OR
-Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
-Installed in front of public-facing web applications to detect and prevent web-based attacks.
-Actively running and up to date as applicable.
-Generating audit logs.
Configured to either block web-based attacks or generate an alert that is immediately investigated.
6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
-Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
-Actively running and up to date as applicable.
-Generating audit logs.
Configured to either block web-based attacks or generate an alert that is immediately investigated.
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
-A method is implemented to confirm that each script is authorized.
-A method is implemented to assure the integrity of each script.
An inventory of all scripts is maintained with written justification as to why each is necessary.
6.5 Changes to all system components are managed securely.
6.5.1 Changes to all system components in the production environment are made according to established procedures that include:
-Reason for, and description of, the change.
-Documentation of security impact.
-Documented change approval by authorized parties.
-Testing to verify that the change does not adversely impact system security.
-For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. Procedures to address failures and return to a secure state.
6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable
6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls.
6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
6.5.5 Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements
6.5.6 Test data and test accounts are removed from system components before the system goes into production.
Conclusion:
In a world where data breaches and cyber threats are ever-present, the Secure Software Development Life Cycle (SDLC) is not just an option; it is a necessity. Incorporating security into every phase of software development, SDLC reduces risks, saves costs, enhances reputation, and ensures regulatory compliance. By implementing the principles of SDLC, organizations can build robust, secure software that withstands the challenges of our increasingly interconnected world. As demonstrated by Bill Gates' "Trustworthy Computing" letter, security in software development is not only a technological requirement but a moral obligation to protect users' data and privacy.
Useful links