developmentprocessforsecure so2ware

Development*Process*for*Secure*So2ware

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*





493*

Microsoft Security Development Cycle

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

494*





495*

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

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

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*

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*








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

officer •  Institute rewards for

handling of security issues

500*








guidelines

•  Security analysis of requirements and design –  Threat modelling

•  Source-level security review •  Security tests

501*








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*








guidelines

•  Annotate classes with security properties

•  Apply principles of secure design

•  Manage resources •  Manage contracts and

interfaces

503*








guidelines

•  Address reported security issues

•  Manage security issue disclosure process

504*


•  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*







•  Define and monitor metrics •  Publish operational

security guidelines

•  Build operational security guide

•  Specify database security configuration

506*





507*

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

508*

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

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

Code review (tools)

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

510*

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

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

Risk-based security test

•  Test based on priorities –  Architectural risks –  Risks discovered during code review

•  Test malicious input –  Use fuzzing tool

513*

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*

*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*

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*





517*

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*

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*


520*

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 organization

–  Collections include both proactive security guidance and organizational 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*


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

–  …

Development Processes




523*

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/

Creativity – your key to secure software

development*process*for*secure* so2ware

Documents

developmentprocessforsecure so2ware