Secure Development Lifecycle

there are three pillars of software security: risk management, which comprises the risk analysis and tracking and mitigation of that risk. The second pillar is what is known as 'touchpoints', where we integrate software security best practices into the SDLC.

Finally, the third pillar is the knowledge pillar. This is the process of gathering, encapsulating and sharing security knowledge. Think CWE/CVE.

Touchpoints

Thus far, we haven't really touched on these (get it?). These are a set of best practices for the artefacts we produce during software development. The best practices are numbered according to their effectiveness and performance. For example:

1. Code review
2. Risk analysis
3. Penetration testing
4. Risk-based security tests
5. Abuse cases
6. Security requirements
7. Security operations

These are all underpinned by external review, and apply at different aspects of the SDLC. The lower the number, the more important an aspect it is.

Code Review with a Tool

This applies to the code artefact. We make use of static analysis tools to identify common vulnerabilities that might've been missed in the development process. For example, buffer overflows, which are easy to catch with some static analysis.

Architectural Risk Analysis

This happens at the design and specification phase. We inspect and analyse the proposed product methodically, to see what architectural flaws we might have, for example, missing authentication.

Penetration Testing

This is done on the running system, and we test it in a black box manner, seeing what data we can exfiltrate without the correct user privileges. This can only be done once the software is complete.

Risk-Based Security Testing

This is also done on the running system, and we look at the security features chosen, then apply attack patterns or misuse cases to see what we can do, for example, trying to elevate our own privileges. This part of testing can be applied at the unit level before completion of the full software.

Abuse/Misuse Cases

This is implemented at the requirements stage, and is where we think like an attacker and what they might try and do. For example, we might try spoofing.

Security Requirements

This part is done at the requirements stage, and is where we specify the functional security requirements and security properties the application needs.

Security Operations

This runs on the deployed systems as part of the SecOps group of operations.

Microsoft SDLC

This is a process to apply to software development with the main objectives to minimise the number of security-related vulnerabilities found in the design, code, and documentation. It is intended to catch and eliminate these are early as possible, with the overall goal of reducing the number and severity of the security vulnerabilities.

It also improves the protection of users' privacy when using the service. The SDLC can be visualised as follows:

Security Training

This is the first step of the SDLC and looks at the current organisational knowledge on security and privacy, then establishes training criteria for these programmes. It also sets out the minimum training frequency and the minimum acceptable group training thresholds.

Requirements

At this phase, we can consider the security at the outset of the project. Requirements for both privacy and security are laid out, and contacts are established for the maintenance of this.

At this stage, a bug tracker and job assignment system is also made, with privacy and security bug bars, which set out priority levels for different privacy and security threats.

Design

At this phase, we define and document the overall security architecture, and security critical components. The design requirements encapsulate these security ideas as requirements and also show how to implement them. The design phase also looks at the attack surface of the application, and this is where threat modelling is also performed.

Implementation

This involves a 'full spectrum' review to determine the processes, documentation and tools for secure development and operation of the system. This specification also gives the build tools and options, which are approved by the security adviser. There is also a list of banned APIs distributed, and static analysis of the code is performed as the code is written.

Verification

This part of the project is started as soon as possible once the code is complete, and involves dynamic analysis of the program, looking for memory corruption, user privilege issues, and other critical security issues.

Fuzz testing can also be introduced, in addition to another review of the threat model and attack surface. Any design or implementation changes to the system are accounted for and all new attack vectors created as a result of this have been reviewed and mitigated.

Release

This part of the project details a clear support policy, and how teams will prepare for a software security emergency, such as a zero day exploit coming to light. There is a team assigned to continually doing incidence response, and an emergency response plan is created with points of contact for different departments.

As part of the release, there is also an on-call contact that can make decisions on what to do available 24/7. Before making the software public, we verify the requirements have been met and that we do not know of any security vulnerabilities.

Software can then be released to the public, either to manufacturing (RTM), or to web (RTW), but this is only with a complete security plan, customer documentation, and an archive of the source code, symbols and threat models.

Response

We hope this never happens but if we plan for failure, then we are much better equipped if and when the system fails.

Process Improvement

Following successful implementation of the SDLC, we can look at what it's helped us do. Just looking for bugs doesn't make the software secure, and we need to introduce these formal techniques to ensure that the software remains secure.

The process needs the C-suite on board, and willing to work with the SDLC in the long run. SDLC is a continuous and ongoing process improvement with a lot of different things to implement. It needs incentives and consequences for the big companies to see it as worthwhile to implement.

Building Security in Maturity Model (BSIMM)

This is a model for software security with domains within the business, and the practices that need to be followed. This is outlined in the table below.

Software Assurance Maturity Model (SAMM)

This is another security model that can be followed: