ISC2 CSSLP domain 3: Secure software architecture and design

The Certified Software Security Lifecycle Professional (CSSLP) certification demonstrates knowledge of how to integrate security into the development lifecycle. This credential, issued by the ISC2, is broken into eight different domains.

The third domain of the CSSLP focuses on secure software architecture and design. This domain accounts for 14% of an applicant’s score on the CSSLP examination.

What is secure software architecture and design?

Secure architecture and design are essential to software security. This CSSLP domain focuses on identifying and managing security risks to an application. By carefully considering how an application is put together, a developer can avoid vulnerabilities and security issues created by insecure components or the interactions between them.

How will secure software architecture and design help my career?

Knowing how to design secure software is invaluable for a developer. Software security has become a top-of-mind concern for many organizations as data breaches and other embarrassing security incidents have become common. As a result, they are working to integrate security into all stages of the software development lifecycle via the adoption of DevSecOps and other initiatives.

Ensuring software security requires the ability to identify risks to an application’s security and to apply security best practices. These are the skill sets tested by Domain 3 of the CSSLP, and demonstrating them via this certification helps an applicant prove that they have the knowledge that more security-focused development teams are looking for.

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

The third domain of the CSSLP is focused on risk management and implementing software design and architecture best practices. The main components of this domain include:

1. Perform threat modeling: threat modeling involves identifying potential threats to software security. Accomplishing this requires knowledge of common threat actors, being able to map the software’s attack surface and the ability to ingest and analyze threat intelligence.
2. Define the security architecture: the security architecture of software includes the security controls designed to mitigate the threats identified during threat modeling. These controls also depend on the operating environment of the software and associated risks.
3. Performing secure interface design: interfaces connect software to users or other software and are a common source of security weaknesses. These interfaces should be designed to follow software security best practices (such as the use of input validation and sanitization) and to properly use any dependencies.
4. Performing architectural risk assessment: the design and architecture of software and its security can introduce security risks or oversights. An architectural risk assessment tries to identify these risks, enabling them to be managed or mitigated before development begins.
5. Model (non-functional) security properties and constraints: non-functional security properties and constraints cannot be easily measured and tested as part of the development process. These need to be modeled to ensure that existing security controls properly manage risk.
6. Model and classify data: applications process a variety of data, which both creates security risks (such as injection attacks) and the potential for data leaks. The data that an application will use should be modeled and classified to enable later testing and to ensure that sensitive data is appropriately protected.
7. Evaluate and select reusable secure design: existing solutions are available for solving many security problems, such as the use of X.509 certificates for credential management. After designing the application and security architecture, identify and integrate the necessary security technologies for those solutions.
8. Perform security architecture and design review: after the security architecture and design have been completed, they should undergo a design review. This helps to ensure that the architecture and design meet the software security requirements and that all identified risks are appropriately addressed.
9. Define secure operational architecture: applications will be deployed in operational environments, and these environments can have security impacts. Define the deployment topology and operational interfaces to ensure that the application integrates securely into its environment.
10. Use secure architecture and design principles, patterns and tools: when designing and developing an application, it is important to follow security best practices and use available tools to identify and correct any potentially exploitable errors.

Getting started with secure software design and architecture

Secure software design and architecture are based on knowledge of security best practices and common mistakes. To learn about secure design and architecture for software, start by reading standards and learning about the tools commonly used to address security issues in software. An understanding of the available tools and how to do things properly makes it much easier to avoid common and costly mistakes.

Sources

• CSSLP Certification Exam Outline, (ISC)²
• DevOps: Shift Left to Reduce Failure, DevOps.com
• The Ultimate Guide to the CSSLP, (ISC)²