Building Secure Software - Building Secure Software - Lecture Slides, Slides of Software Engineering

Download Building Secure Software - Building Secure Software - Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

Building Secure Software

Three Pillars of Software Security

• Risk Management
• Software Security Touchpoints
• Knowledge

Touchpoints

• System-wide activity: from design to testing and feedback

• Focus on security from ground up

• Touchpoints:

1. Code review

2. Architectural risk analysis

3. Penetration testing

4. Risk-based security testing

5. Abuse cases

6. Security requirements

7. Security operations

8. External Analysis

Knowledge

• Gathering, encapsulating, and sharing security

knowledge

• Knowledge catalogs: principles, guidelines, rules,

vulnerabilities, exploits, attack patterns, historical

risks

• Knowledge categories:

– Prescriptive knowledge

– Diagnostic knowledge

– Historical knowledge

• Applied along the SDLC

Software Security Touchpoints

• Best Practices

• Both White Hat (constructive) and Black Hat

(destructive) activities

• Throughout the SDLC

Application of Touchpoints

Requirement and

Use cases

Architecture

and Design

Test Plans Code

Tests and

Test Results

Feedback from

the Field

5. Abuse cases
   6. Security Requirements
      2. Risk Analysis

External Review

4. Risk-Based

Security Tests

1. Code Review

(Tools)

2. Risk Analysis
   3. Penetration Testing
      7. Security

Operations

Architectural Risk Analysis

• Artifact: Design and specification

• System must be coherent and present a uniform security front

• Document assumptions and identify possible attacks

• Both at specification-based architecture stage and class-

hierarchy design stage

• White hat

Requirement and Use cases

Architecture and Design Test Plans^ Code^

Tests and Test Results

Feedback from the Field

5. Abuse cases
   6. Security Requirements
      2. Risk Analysis

External Review

4. Risk-Based Security Tests
   1. Code Review (Tools)
      2. Risk Analysis
         3. Penetration Testing
            7. Security Operations

Penetration Testing

• Artifact: system in its environment

• Understanding fielded software in its environment

• Information supplied by architectural risk analysis

• Who does it?

• Black Hat

Requirement and Use cases

Architecture and Design Test Plans^ Code^

Tests and Test Results

Feedback from the Field

5. Abuse cases
   6. Security Requirements
      2. Risk Analysis

External Review

4. Risk-Based Security Tests
   1. Code Review (Tools)
      2. Risk Analysis
         3. Penetration Testing
            7. Security Operations

Abuse Cases

• Artifact: requirements and use cases

• Describe system behavior under attack

• Explicit coverage of

– What should be protected

– From whom

– For how long

• White Hat + Black Hat

Requirement and Use cases

Architecture and Design

Test Plans Code

Tests and Test Results

Feedback from the Field

5. Abuse cases
   6. Security Requirements
      2. Risk Analysis

External Review

4. Risk-Based Security Tests
   1. Code Review (Tools)
      2. Risk Analysis
         3. Penetration Testing
            7. Security Operations

Security Requirements

• Artifact: Requirements

• Security explicitly worked into the

requirements level

• Both functional security and emergent

characteristics

• White Hat

Requirement and Use cases

Architecture and Design

Test Plans Code Tests and Test Results

Feedback from the Field

5. Abuse cases
   6. Security Requirements
      2. Risk Analysis

External Review

4. Risk-Based Security Tests
   1. Code Review (Tools)
      2. Risk Analysis
         3. Penetration Testing
            7. Security Operations

External Analysis

• Evaluate security by outside members

• Why?

• Advantages/disadvantages

Requirement and Use cases

Architecture and Design

Test Plans Code

Tests and Test Results

Feedback from the Field

5. Abuse cases
   6. Security Requirements
      2. Risk Analysis

External Review

4. Risk-Based Security Tests
   1. Code Review (Tools)
      2. Risk Analysis
         3. Penetration Testing
            7. Security Operations

When to Apply Security?

• Economical consideration: early is better

• Effectiveness of touchpoints:

– Economics

– Which software artifacts are available

– Which tools are available

– Cultural changes

• Bad: reactive strategy  need: secure

development

• See slides of Kromholz: Assurance – A Case for the

V-Model,

https://syst.eui.upm.es/conference/sv03/papers/

V-Chart%20200309Kromholz08.ppt

Worst Practices to Avoid

From T. Demopoulos, “Worst Practices in Developing Secure Software

1. Assuming only “important’ SW needs to be secure

2. Emphasizing hitting deadlines over “good code”

3. Having IT make all risk management decisions

4. Not considering security during the entire SDLC

5. Assuming the SW won’t be attacked

6. Not doing any security testing

7. Not planning for failure

8. Counting on “security through obscurity”

9. Disallowing bad input instead of only allowing good input

10. SW that is not secure by default

11. Coding your own cryptography

Who Should Care?

• Developers

• Architects

• Other builders

• Operations people

Do not start with security people.

Start with software people.