Design is a fundamental part of any mature Software Development Lifecycle (SDLC). During the design phase, the architecture of a software system is specified. The specification is then used by developers to implement the desired architecture. Given its prominent role in determining how the software is implemented, it is essential that secure design practices are followed so that the system produced will be secure.

One way to characterize the maturity of the security related activities of the of any phase of the SDLC is to use the OWASP Software Assurance Maturity Model (SAMM).

Image

Figure 1 – OWASP SAMM with a focus on Design

In this framework, the SDLC is broken down into 5 business functions. The activities of a given business function are grouped into 3 security practices, which are further broken down into 2 “streams” per practice. The three practices for the Design business function are Threat Assessment, Security Requirements and Security Architecture.

Threat Assessment

The first practice in the Design business function is Threat Assessment. The two streams in Threat Assessment are Application Risk Profile and Threat Modeling. The Application Risk Profile stream is concerned with determining the risk profile for the application under development. Factors such as exposure to the internet, the types of data stored and the availability requirements all play a role in determining the risk profile for the application. The risk profile will help provide guidance on the level of security controls needed to protect the application.

The second stream of the Threat Assessment practice is Threat Modeling. Threat modeling is an exercise where the system is analyzed for threats that the system may be exposed to during operation. Before a threat model can be completed, the basic architecture and data flows for the system must be specified. One common technique used for threat modeling is STRIDE, which provides a framework for classifying threats.

Each component and data flow will be analyzed to determine if any threats from these categories are applicable to that component or flow. Any threats found should be recorded and tickets created for them in the defect or requirements tracking system to ensure remediation, tracking and testing of the issue.

Security Requirements

The second practice is Security Requirements, which consists of Software Requirements and Supplier Security. The Software Requirements stream involves specifying the security-related requirements for the system under development. Just as the required functionality and attributes of a software system need to be captured in requirements, so, too, do the security-related attributes and functionality of the system. These will be dictated in large measure by the risk profile of the application being developed. A high-risk, high-exposure application will have much more stringent security requirements than a low-risk, low-exposure one.

Security requirements not only apply to in-house software, but also to external third-party providers. The Supplier Security stream covers this case and should encompass both software and service providers. It is important that the security requirements are applied to all suppliers, as well as in-house development, since third-party components play such a large role in modern software development.

Security Architecture

The third practice of the Design business function is Security Architecture, which can be broken down into Architecture Design and Technology Management. Architecture Design covers the basic architecture of the system, while Technology Management concerns the underlying technologies that are used to implement the architecture.

When designing a secure software system, it is essential to incorporate secure design principles in the design process. Some of the fundamental principles that need to be considered are:

Using these principles will help prevent design-related security vulnerabilities that are often more difficult to detect and fix than run-of-the-mill coding vulnerabilities.

All software systems depend upon a set of technologies for their development, testing and deployment. These include development tools, deployment tools, databases and operating systems. The particular technologies employed will impact the overall security posture of the software, and so is important to understand the security implications of the technologies chosen to implement the system. The system needs to be designed taking these implications into account. The system should also utilize the technologies in standard ways, where the security implications are well understood. Best practices for each technology should always be followed.

Threat Assessment, Security Requirements and Security Architecture are all essential parts of designing secure software. Neglecting any of them will expose the system to unnecessary risk. The next post will further explore the threat assessment practice.