[PPT] - Development*Process*for*Secure* So2ware Development Processes ( PowerPoint Presentation

SLIDE 1

DevelopmentProcessforSecure So2ware

SLIDE 2

Development Processes

(Lecture outline)

Emphasis on „building secure software” as opposed to

„building security software”

Major methodologies

– Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints

Building Security In Maturity Model – BSIMM

492*

SLIDE 3

Development Processes

(Lecture outline)

Emphasis on „building secure software” as opposed to

„building security software”

Major methodologies

– Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints

Building Security In Maturity Model – BSIMM

493*

SLIDE 4

Microsoft Security Development Cycle

http://www.microsoft.com/security/sdl/default.aspx

494*

SLIDE 5

Development Processes

(Lecture outline)

Emphasis on „building secure software” as opposed to

„building security software”

Major methodologies

– Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints

Building Security In Maturity Model – BSIMM

495*

SLIDE 6

Open Web Application Security Project

OWASP

https://www.owasp.org/

Collect resources

for Web applications

– Top ten security flaws – Various security testing tools – Various security control means

e.g., code review guide
CLASP – Comprehensive Lightweight Application

Security Process

496*

– Injection – Cross-site Scripting (XSS) – Broken authentication and session management – Insecure direct object references – Cross-site request forgery (CSRF) – Security misconfiguration – Insecure cryptographic storage – Failure to restrict URL access – Insufficient transport layer protection – Unvalidated redirects and forwards

SLIDE 7

Open Web Application Security Project

OWASP

https://www.owasp.org/

Collect resources

for Web applications

– Top ten security flaws – Various security testing tools – Various security control means

e.g., code review guide
CLASP – Comprehensive Lightweight Application

Security Process

497*

– Injection – Cross-site Scripting (XSS) – Broken authentication and session management – Insecure direct object references – Cross-site request forgery (CSRF) – Security misconfiguration – Insecure cryptographic storage – Failure to restrict URL access – Insufficient transport layer protection – Unvalidated redirects and forwards

https://www.owasp.org/index.php/ OWASP_Appsec_Tutorial_Series

SLIDE 8

CLASP

https://www.owasp.org/index.php/Category:OWASP_CLASP_Project

Goal:

– move security concerns into the early stages of the software development lifecycle, whenever possible

Set of process pieces that can be integrated into

any software development process

– Introduction to the Concepts behind CLASP to get started – Seven key Best Practices – High-level Security Services (authorisation, authentication, …) – Core Security Principles – Roles – Activities – Process engineering and roadmaps – Checklisted Coding Guidelines – Vulnerabilities that occur in source code – Searchable Vulnerability Checklist

498*

SLIDE 9

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

499*

SLIDE 10

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

People should consider

security to be an important project goal

Train all team members
Make people aware of

security setting

Institute accountability for

security issues

Appoint a project security
fficer
Institute rewards for

handling of security issues

500*

SLIDE 11

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

Security analysis of

requirements and design

– Threat modelling

Source-level security review
Security tests

501*

SLIDE 12

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

Treat security requirements

same way as functional requirements

Define security policy
Identify attack surface
Identify resources and trust

boundaries

Identify misuse cases
Specify operational

environment

502*

SLIDE 13

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

Annotate classes with

security properties

Apply principles of secure

design

Manage resources
Manage contracts and

interfaces

503*

SLIDE 14

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

Address reported security

issues

Manage security issue

disclosure process

504*

SLIDE 15

CLASP Best Practices

Institute awareness programs
Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational security

guidelines

Select metrics
Collect data
Evaluate results

505*

SLIDE 16

CLASP Best Practices

Institute awareness

programs

Perform application

assessments

Capture security

requirements

Implement secure

development practices

Build vulnerability

remediation procedures

Define and monitor metrics
Publish operational

security guidelines

Build operational security

guide

Specify database security

configuration

506*

SLIDE 17

Development Processes

(Lecture outline)

Emphasis on „building secure software” as opposed to

„building security software”

Major methodologies

– Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints

Building Security In Maturity Model – BSIMM

507*

SLIDE 18

Seven Security Touchpoints

G. McGraw, “Software Security: Building Security In”

508*

“All software projects produce at least one artifact: source code”

SLIDE 19

Seven Security Touchpoints

G. McGraw, “Software Security: Building Security In”

509*

“All software projects produce at least one artifact: source code”

1. Code review (tools)
2. Risk analysis
3. Penetration test
4. Risk-based security test
5. Abuse analysis
6. Security requirements
7. Security attacks

* External analysis

SLIDE 20

Code review (tools)

Aim: catching implementation bugs early
Tool helps to achieve good code coverage
Aim for good, not perfect

510*

SLIDE 21

Risk analysis

Create description of

architecture

– Start with one page – Forest-level view

Attack resistance

– Use checklists of known attacks – Example: Microsoft STRIDE

Spoofing, Tampering,

Repudiation, Info disclosure, Denial of service, Elevation of privilege

Ambiguity analysis

– Discover new risks – Find unclear parts in how the system works – Trust, data sensitivity, threat models

Weakness analysis

– Impact of external software dependencies – Platform (hardware, OS) – Frameworks – Called services

511*

Combine risks and consider business impact Rank risks Find solutions

SLIDE 22

Penetration test

Use the source

– Otherwise people send time on reverse- engineering system

Apply business

priorities

– Logic flaw vs. XSS flaw – XSS is important if it contributes towards compromising business logic

Use in-house QA

department

– They already know the system – Use tools and training to add security testing skills

Test more than once
Incorporate the findings

back into development

512*

Attack on a system with the intention of finding security weaknesses, potentially gaining access to it, its functionality and data

SLIDE 23

Risk-based security test

Test based on priorities

– Architectural risks – Risks discovered during code review

Test malicious input

– Use fuzzing tool

513*

SLIDE 24

Abuse analysis and Security requirement

Security is not a set of features
How system should react to illegitimate use
Like use cases, but with malicious users

514*

SLIDE 25

*515**

1. Input validation and

Representation

2. API Abuse
3. Security Features
4. Time and State
5. Error Handling
6. Code Quality
7. Encapsulation

* Environment

Seven Pernicious Kingdoms

Tsipenyuk*et#al.,*2005*

SLIDE 26

External analysis

Unfortunately

– Software architects, developers, and testers are largely unaware of the software security problems

Good news

– They acknowledge that security problems exists!

Bad news

– Barely begun to apply the security solutions

516*

SLIDE 27

Development Processes

(Lecture outline)

Emphasis on „building secure software” as opposed to

„building security software”

Major methodologies

– Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints

Building Security In Maturity Model – BSIMM

517*

SLIDE 28

Building Security in Maturity Model

Empirical approach to secure software design
Gathered data from 42 large-scale software

security initiatives

– Tech companies (e.g., Adobe, Google, Microsoft,…) – Financial companies (e.g., DTCC, Wells Fargo)

Added only activities seen in the real world

– Actual practices, not best practices

518*

SLIDE 29

Software Security Framework

12 practices in 4 domains
Each practice consists of activities
110 activities in total
Each activity at least in one company
No company that does it all

519*

SLIDE 30

Software Security Framework

520*

SLIDE 31

Four Domains

Governance

– Organize, manage, and measure a software security initiative – Staff development

Intelligence

– Collections of corporate knowledge used in carrying out software security activities throughout the

rganization

– Collections include both proactive security guidance and

rganizational threat modeling
SSDL Touchpoints

– Analysis and assurance of particular software development artifacts and processes – All software security methodologies include these practices

Deployment

– Traditional network security and software maintenance organizations – Software configuration, maintenance, and other environment issues have direct impact on software security

521*

SLIDE 32

Software Security Framework

522* # # EXAMPLE#

Goal: transparency of expectations and accountability for results

Level 1: Attain a common understanding of direction

and strategy

– Publish process, evolve as necessary – Create evangelism role/internal marketing – Educate executives – Identify gate locations, gather necessary artefacts – Require security sign off

Level 2: Align behaviour with strategy and verify

behaviour

– …

Level 3: Practice risk-based portfolio management

– …

SLIDE 33

Development Processes

Emphasis on „building secure software” as opposed to

„building security software”

Major methodologies

– Microsoft's Security Development Lifecycle – OWASP CLASP – Cigital's Security touchpoints

Building Security In Maturity Model – BSIMM

523*

SLIDE 34

528*

Final slide

Don't do anything just because somebody else does
Apply the scientific method

– „a method of procedure that has characterized natural science since the 17th century, consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses.”

http://oxforddictionaries.com/