sdlc introduction and process models - schedschd.ws/hosted_files/secappdev2017/94/secappdev2017 -...

SDLC Introductionand Process Models

Bart De Win

www.pwc.com

SecAppDev 2017

Bart De Win ?

•20 years of Information Security Experience

•Ph.D. in Computer Science - Application Security

•Author of >60 scientific publications

•ISC2 CSSLP certified

•Senior Manager @ PwC Belgium:

•Expertise Center Leader Trusted Software

•(Web) Application tester (pentesting, arch. review, code review, ...)

•Proficiency in Secure Software Development Lifecycle (SDLC) and Software Quality

• OWASP SAMM co-leader

• Contact me at [email protected]

SDLC Introduction and Process models SecAppDev 2017

2

Agenda

1. Motivation

2. Process Models

3. Agile Development

4. Good Practices

5. Conclusion

•SecAppDev 2017

•3

Application Security Problem

75% of vulnerabilities are application related

Training

Growing connectivityMobile

Software complexity

Better

Faster

Technology stacks

Cloud

Adaptability

SecAppDev 2017SDLC Introduction and Process models

4

Quality

CostSpeed of Delivery

Application Security Symbiosis


5

Application Security during Software Development

Bugs Flaws Cost

Analyse Design Implement Test Deploy Maintain


6

The State-of-Practice in Secure Software Development

Problematic, since:

• Focus on bugs, not flaws

• Penetration can cause major harm

• Not cost efficient

• No security assurance

- All bugs found ?

- Bug fix fixes all occurences ? (also future ?)

- Bug fix might introduce new security vulnerabilities


(Arch review) Pentest Penetrate & Patch


7

SDLC ?

Enterprise-wide software security improvement program

• Strategic approach to assure software quality

• Goal is to increase systematicity

• Focus on security functionality and security hygiene


SDLC


8

SDLC Objectives & Principles

To develop (and maintain) software in a consistent and efficient way with a

demonstrable & standards-compliant security quality, inline with

the organizational risks.


9

SDLC Cornerstones


10SecAppDev 2013

• Roles & ResponsibilitiesPeople

• Activities• Deliverables• Control Gates

Process

• Standards & Guidelines• Compliance• Transfer methods

Knowledge

• Development support• Assessment tools• Management tools

Tools & Components

Risk Training

Strategic ?

Organizations with a proper SDLC will experiencean 80 percent decrease in critical vulnerabilities

Organizations that acquire products and services with just a 50 percent reduction in vulnerabilitieswill reduce configuration management and incident response costs by 75 percent each.


11

Does it really work ?


12

(Some) SDLC-related initiatives

•Microsoft SDL

•BSIMM

•SP800-64

•TouchPoints

•CLASP

•SAMM

•SSE-CMM

•TSP-Secure

•GASSPSecAppDev 2017SDLC Introduction and Process models

13

http://www.gartner.com/silentlocalechooser.jsp?locale=wcw

http://www.gartner.com/silentlocalechooser.jsp?locale=wcw

Agenda

1. Motivation

2. Process Models


4. Good Practices

5. Conclusion

•SecAppDev 2017

•14

Selected Example: Microsoft SDL (SD3+C)


15

Training

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Content

• Secure design

• Threat modeling

• Secure coding

• Security testing

• Privacy

Why?


16

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Requirements

When you consider security and privacy at a foundational level

Project inception

Cost analysis

Determine if development and support costs for improving

security and privacy are consistent with business

needs


17

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Design

Establish and follow best practices for Design

≠ secure-coding best practices

Risk analysis

Threat modeling

STRIDE


18

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Implementation

Creating documentation and tools for users that address security and privacy

Establish and follow best practices for development

1. Review available information resources

2. Review recommended development tools

3. Define, communicate and document all bestpractices and policies


19

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Verification

Security and privacy testing

1. Confidentiality, integrity and availability of thesoftware and data processed by the software

2. Freedom from issues that could result insecurity vulnerabilities

Security push


20

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Release

Public pre-release review

Planning

Preparation for

incident response

1. Privacy

2. Security


21

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

Release

Sign-off process to ensure security, privacy and other policy compliance

Release to manufacturing/release to web

Outcomes:

- Passed FSR

- Passed FSR with exceptions

- FSR escalation

Final security and privacy review


22

Response

1. Training

2. Requirements

3. Design

4. Implementation

5. Verification

6. Release

7. Response

=> able to respond appropriately to reports of vulnerabilities in their software products, and to attempted exploitation of those vulnerabilities.

Execute Incident Response Plan


23

Process Models: wrapup

Microsoft SDL:

Mature, long-term practical experience

Heavyweight, ISV flavour

Several supporting tools and methods

Other process models exist, with their pro’s and con’s

In general, no process will fit your organization perfectly

Mix-and-Match + adaptation are necessary


24

•PwC

Agenda

1. Motivation

2. Process Models


4. Good Practices

5. Conclusion

•SecAppDev 2017

•25

•SDLC Introduction and Process models

Agile Models: Rationale and Fundamentals

• Many traditional, large-scale software development projects are going wrong

• Combination of business and technical causes

• Software is delivered late in the lifecycle

• Little flexibility during the process

Agile models focus on:

• Frequent interaction with stakeholders

• Short cycles

=> to increase flexibility and reduce risk


26

Agile Models: Scrum


27

Agile & Secure development: a mismatch ?


28

Agile Dev. Security

Speed & Flexibility Stable & Rigorous

Short cycles Extra activities

Limited documentation Extensive analysis

Functionality-driven Non-functional

Secure Agile is …

enablement, rather than control


29

Secure Agile – Where’s the difference ?


30SecAppDev 2013



Process


Knowledge


Tools & Components

Risk Training

Secure Agile: general principles

• Make security a natural part of the process, but don’t overdo

• lightweight, in-phase and iterative

• preventative and detective controls

• Be involved at key moments in the process

• Leverage important agile concepts

• Small steps at a time (i.e. continuous improvement)


31

User Stories

• Capture security requirements, policies and regulations in user stories

• Simple, concrete and actionable

• Reusable?

• Mark all user stories with security labels

• Integrate security into user stories as:

• Definition of Done

• Acceptance criteria


32

Threat Modelling & Abuser Stories

Consider writing application security risks as stories

• Security stories: “As a developer, I want to prevent SQLi into my application”

• Not a real user story (not relevant for product owner, but to help the development team)

• Never really finished

• Thinking like the bad guy: “User X should not have access to this type of data”

• Think about what users don’t want to and can’t do, how to trust users, what data is involved, …


33

Sprint Planning

• Features to be implemented per sprint are selected during sprint planning.

• Ensure security tasks are not “stuck” on the backlog

• Presence of security-savvy person during sprint planning

• Establish rules to deal with security stories

• Security labels can be used to drive selection


34

Example: MS SDL-Agile

Basic approach: Fit SDL tasks to the backlog as non-functional stories

Non-Technical vs. Technical

Requirement vs. Recommendation

Each SDL task goes in one of three types of requirements:


35

Every Sprint

BucketOne-Time

Example: Every-Sprint Requirements (excerpt)

• All team members must have had security training in the past year

• All database access via parameterized queries

• Fix security issues identified by static analysis

• Mitigate against Cross-Site Request Forgery

• Update Threat models for new features

• Use Secure cookies over HTTPS

• Link all code with the /nxcompat linker option

• Encrypt all secrets such as credentials, keys and passwords

• Conduct internal security design review


36

Example: Bucket Requirements (excerpt)

Bucket A: Security Verification

• Perform fuzzing (network/ActiveX/File/RPC/…)

• Manual and automated code review for high-risk code

• Penetration testing

Bucket B: Design Review

• Conduct a privacy review

• Complete threat model training

Bucket C: Planning

• Define or update the security/privacy bug bar

• Define a BC/DR plan


37

Example: One-Time Requirements (excerpt)

• Create a baseline threat model

• Establish a security response plan

• Identify your team’s security expert

• Use latest compiler versions


38

Security testing

• Automated testing is an important element in agile quality control

• For security, this can be realized by:

• Unit testing (e.g., authorisation checks, logging, …)

• Regression testing

• Static analysis (SAST) based on coding guidelines

• Dynamic analysis (DAST) based on scenarios and/or vulnerability tests

• Fuzzing


39

Thou shall use Iteration Zero

Many agile projects start with an “Iteration Zero” to

• Get the team together

• Choose tools and frameworks

• Get to know the domain

This is an opportunity for security too, to

• Assign security responsibles

• Select security tools

• Determine risk levels


40

Secure Agile process: key take-aways

Ensure that security-savvy people are involved at important phases:

• Planning game (to enhance/verify requirements)

• Development (daily follow-up)

• Review (to support acceptance)

• Retrospective (to improve dev. Practices for security)

Different profiles can be distinguished:

• Security architect

• Security engineer

• Risk Manager/Governance


42

Secure Agile – Where’s the difference ?


43SecAppDev 2013



Process


Knowledge


Tools & Components

Risk Training

Secure Agile Tool Chain: general principles

• Secure agile is about enabling, rather than controlling

• Embedding security tools to support development

• Given short sprint cycles, automation is important.

• Good tools do:

• Work continuously (to avoid developers being blocked)

• Integrate well into developer’s world

• Avoid causing too much overhead or confusion

• Evaluate carefully which tools to implement (and which to avoid)


44

Secure Coding

Integrate security tools in the development IDE’s:

• Support for secure coding guidelines

• Static analysis tools

Ensure common development environment:

• Programming run-time

• Security components (e.g., SSO IdP’s, ...)

Proper source control and versioning


45

Security testing

• Integrated with backlogs where appropriate


46

Daily

• Unit tests• Regression

tests• Peer

reviews

Per sprint

• Static Analysis

• Dynamic Analysis

• Fuzzing

Before release

• Penetration testing

Secure Build

Central build, using central configuration files

Consider:

• Code signing

• Obfuscation

• …


47

Secure Deploy / DevOps

• Automated deploy, using central configuration files

• Consider:

• Random key generation

• Appropriate key/certificate protection (config files, key stores, …)

• Proper hardening of application servers

• Security appliance configuration (e.g., WAF)

• Security monitoring

• …


48

Hybrid models

• Many companies are combining waterfall and agile

• Studies indicate better resulting quality

• For security, easier to hook into

• E.g., full architecture cycle


49

Best Practices / Lessons Learned

• Use small steps at a time – the agile way

• Build on agile concepts (backlog, retrospective)

• Find a way to prioritize security in the planning

• Use automation as much as possible

• Review samples independent of project sprints

• Rely on security champions

• E.g., security requirements, design review, code review

• Agile should not be an excuse for not having documentation


50

Agenda

1. Motivation

2. Process Models


4. Good Practices

5. Conclusion

•51

•SecAppDev 2017

Good Practices

•SecAppDev 2017•SDLC Introduction and Process models

•Application

Security

•Architecture &

Design•Secure Coding

•Testing•Process

•Development

Environment

•Knowledge &

Training

Keep it small and simple

Secure by design

Least privilege

Defense in depth

Threat Modelling

It’s everybody’s responsibility

Clear roles & agreements

Good documentation is important,

also in Agile

Sign your applications

Standardized dev. environment

Central code repository

Central build system

Controlled promotion mechanism

Continuous integration

Screen & scan external libraries

Regularly update tools & libraries

Host third-party libraries locally

Define a company standard

Validate input & encode output

Default deny

Avoid hardcoded passwords

Obfuscate client-side code

Protect against automated

attacks

Automated quality scanning

Peer review

Automated static analysis

Automated dynamic testing

Intelligent fuzzing can help

Integrate with bug tracking

systems

Security awareness training

Appoint security champions

Establish a central knowledge

portal

Use Google wisely

Don’t post internal code on Github

Reuse proven crypto

•52

SDLC impact

Difficult to predict, but:

• Projects are estimated to increase with 5 – 15% for security

• ROI is achievable taking maintenance and incident management into account

• SDLC capability costs approx. 1 FTE/100 developers


53

Agenda

1. Motivation

2. Process Models


4. Good Practices

5. Conclusion

•SecAppDev 2017

•54

Conclusions

SDLC is the framework for most of this week’s sessions

No model is perfect, but they provide good guidance

Take into account all cornerstones

Risk Management is key for rationalizing effort


55

SDLC Cornerstones


56SecAppDev 2013



Process


Knowledge


Tools & Components

Risk Training

sdlc introduction and process models - schedschd.ws/hosted_files/secappdev2017/94/secappdev2017 -...

Documents