Secure SDLC

Tags

security soft-eng

Refers to software development life cycles which [see page 7, help] developers build more secure, less costly and security compliant software solutions.

Can be thought of as a game with [see page 7, two] players, The:

• Defender trying to avoid, find and fix vulnerabilities, and the
• Adversary/attacker trying to find and exploit one (or more) vulnerabilities.

Note: Previously hackers were motivated be fun (I.E. prestige). Nowadays it's more for profit, politics, goal-oriented.

We [see page 5, need] security to:

• Protect vital information while allowing access to those who need it.
• Provide authentication and access control for resources.
• Guarantee availability of resources (reliability).

Considerations

When evaluating a system we must consider:

• Who we're securing against?
• What types of attacks do we expect?
• What is the impact of those attacks?
• How can you secure against those attacks?

Causes of Insecure Code

64% of developers are not confident in their ability to write secure applications. -- Bill Gates, ([see page 25, RSA Conference 2005]).

The major causes of security vulnerabilities is lack of awareness and lack of knowledge.

In [see page 26, industry] there's no real incentive for secure software. Developers are more focused on writing new features over secure code. This leads to most developers never learning to produce secure code or to avoid it due to time concerns.

There is a trade-off between security and functionality.

Unless you think like an attacker you will not be aware of any potential threats.

How to build secure systems?

[see page 38, Three] important steps:

• Threat Modelling
• Secure programming: learning to write secure code.
• Security Testing: learn how to test the security of a system.

Secure systems often also present several security services.

Approaches

TODO: This is just approaches to develop software, secure SDLC is a proactive SDLC.

Intuitive Approach

Relying on the [see page 4, individual] knowledge and experience of the team members, with no security gates or restrictions during development. This approach generally leads to more security incidents and negative product reviews.

Reactive Approach

Having a see page 5, single security gate immediately before an application role-out.

Proactive Approach

Preventing security bugs before they're created, trying to mitigate the cost of bug solving during the later stages in the development cycle.

Phases

1. [see page 7, Security training] - make team aware of security concerns.
2. [see page 9, Requirements gathering] - Identify risks, threats and impact of private-data.
3. [see page 10, Planning & design] - Plan security features+tests+response.
4. [see page 11, Implementation/secure-development] - Secure programming, SAST, Code review
5. [see page 12, Verification & testing] - Check for flaws in SDLC-implementation.
6. [see page 14, Development] - Execute the security response plan, handle incidents, & security patches.

Microsofts SDLC

A [see page 15, variant] of Secure SDLC divided into 7 phases with every phase containing some security related activities.

McGraws Touchpoints

Security requirement must cover both:

• Functional vulnerabilities tied to cryptographic issues, and
• Emergent security-space found through building abuse cases identifying:
  • How the system should respond to attacks?
  • What should be protected?
  • From whom?

Benefits

[see page 17, Includes]:

• Build more secure software
• Help to address Security Compliance Requirements
• Reduce costs of maintenance
• Awareness of potential engineering challenges caused by mandatory security controls
• Identifications of shared security services and reuse of security strategies and tools
• Early identifications and mitigation of security vulnerabilities and problems
• Documentation of important security decisions made during the development