ISC2 CSSLP

ISC2 CSSLP domain 2: Secure software requirements

The Certified Software Security Lifecycle Professional (CSSLP) credential is issued by the (ISC)². Those who earn it demonstrate knowledge of how to develop secure code. Eight different domains make up the CSSLP.

Domain 2 of the CSSLP focuses on the development of secure software requirements. This domain accounts for 14% of an applicant’s grade on the CSSLP examination.

What are the secure software requirements?

All software has requirements that define what the software should be able to do. Software security requirements are just like any other requirement but are more focused on ensuring that software only does what it is supposed to and nothing else. They ensure that software is compliant with applicable regulations and has protections in place against potential misuse and abuse.

How will learning secure software requirements help my career?

The goal of development is to create software that meets the user’s needs and development requirements. Historically, most requirements for software development have focused on functionality or what the software is designed to do.

This focus on functionality without an equal focus on security results in software that is vulnerable to exploitation and can be exploited and subverted by a malicious user. The rise of the DevSecOps, Shift Left and similar movements are designed to ensure that software requirements include security requirements as well.

Domain 2 of the CSSLP is focused on creating effective security requirements for the software. Learning how to do so and demonstrating those skills by earning a CSSLP certification is excellent preparation for and can help a student differentiate themselves when seeking a role as a developer in organizations adopting modern DevSecOps principles.

What’s covered in CSSLP Domain 2 of the exam?

The second domain of the CSSLP is designed to test a student’s knowledge of every stage of the process of developing security requirements for the software. (ISC)² has broken this down into seven primary stages:

1. Define software security requirements: software security requirements can be functional (based on business requirements, use cases and user stories) or non-functional (operational, deployment and systemic qualities).
2. Identify and analyze compliance requirements: data protection laws like GDPR, HIPAA, PCI DSS and others define requirements for protecting certain types of sensitive data. Software with access to protected data must meet the requirements of applicable regulations.
3. Identify and analyze data classification requirements: different types of data have different security requirements, and performing data classification is vital to ensuring that data is protected at the appropriate level. Classification labels should include data ownership, labeling (sensitivity and impact), types (structured and unstructured) and lifecycle information (retention, disposal and more).
4. Identify and analyze privacy requirements: GDPR, CCPA and similar regulations define the rights of data subjects (access, consent, disposition and more), data retention requirements and other rules. Software should be designed to be able to comply with these and other privacy requirements.
5. Misuse and abuse cases: software should operate securely even in the face of malicious users. Software security requirements should include an analysis of how the software can be misused and abused and the protections that will be put in place to prevent this.
6. Develop security requirement traceability matrix (SRTM): an SRTM tracks each of the software’s security requirements and its implementation details, schedule and required resources. This ensures that all security requirements are fulfilled and nothing is overlooked during the development and deployment process.
7. Ensure security requirements flow down to suppliers/providers: software security depends on the security of third-party partners as well, such as suppliers, providers and more. After security requirements are defined, they need to be enforced via contracts down the supply chain.

Getting started with software security requirements

Good requirements are essential for developing good software, and the ability to create good security requirements is vital to ensuring that this software does what it is intended to do securely. Earning a CSSLP credential demonstrates that a student not only knows how to develop good security requirements but also can ensure that they are appropriately tracked and fulfilled both internally and by an organization’s partners.

Like any software requirements, security requirements are defined by stakeholders, which, in this case, include users, regulators and more. High-level familiarity with the GDPR and similar regulations can be invaluable when it comes to determining where security requirements should be derived from and best practices for creating them.

 

Sources

• CSSLP Certification Exam Outline, (ISC)²
• DevOps: Shift Left to Reduce Failure, DevOps.com
• What is DevSecOps?, Red Hat