25
Crawl-Walk-Run: How to get your Secure Development Program off the ground and running Monday, March 23, 2015 3:15-4:15 PM Brian Glas Principal Consultant Secure Development Program Services

ISW15 Crawl-Walk-Run Secure SDLC - Brian Glas

Embed Size (px)

Citation preview

Crawl-Walk-Run: How to get your

Secure Development Program off the ground

and running

Monday, March 23, 2015

3:15-4:15 PM

Brian Glas

Principal Consultant

Secure Development Program Services

Presentation will be available

at: www.misti.com/downloadDownload password is available in your Show Guide

Slide 3

Aspect Security since 2012 Secure Development Program Services

14 years of development and security experience Aspect Security General Dynamics IT FedEx Services

full stack developer, application assessor, technical lead, incident response, anti-malware engineer, application architect, infosec manager, security consultant, and dad…

Brian Glas

Slide 4

Identify the key components of a successful Secure Development Program

Define processes to enable development teams to build secure applications

Understand how to start integrating security into Waterfall, Agile, and DevOps

Incorporate Application Security risk into your Risk Management Framework and other key initiatives

Learn how a Secure Development Program can justify its own existence

Key Points

Slide 5

The Real Challenge

Applicatio

n Securit

y

Slide 6

Built-in or Bolt-on?

Slide 7

Key Components of SecDev Program

Slide 8

Secure Development Program Target

· Coverage

· Risk

·Po

rtfol

io

· Time

Business andExecutive Management

SoftwareDevelopment

Securityand Audit

Visibility

You know you are doing well when…

Application Security risks and controls are visible

Application Security decisions are informed

Application Security investments move from operational to strategic

The program justifies its own existence

Slide 9

Capability Assessment / Improvement Plan

Slide 10

Measure the inherent risk of applications Artifacts from security activities can satisfy RMF

reqs

Risk Management

Slide 11

No support = no budget Critical to success of the program Not just security, but all related organizations

Roadshow / Demonstrate They read a lot They hear a lot They need to see it.

Executive Sponsorship

40 percent of all nerve fibers connected to the brain are linked to the retina. – Jensen, 1996Approximately 65 percent of the population are visual learners. – Mind Tools, 1998The brain processes visual information 60,000 faster than text. – 3M Corporation, 200190 percent of information that comes to the brain is visual. – Hyerle, 2000

Slide 12

Training & Awareness -> Learning System

· 80% of development cost is fixing defects

· Global Grade: D - 60%

· Secure Coder Analytics

· $1 spent = $30 of productivity

· 70% reduction in identified vulnerabilities

*IBM Learning

*NIST 2002

*Aspect Security 2014

*Client Testimonial

*NIST 2002

Slide 13

You can’t code your way out of a flawed design You can’t simply test your code secure The last thing a developer wants to read is

another doc

Application Security Knowledge Domains

Subject

Target

OtherAttributes (optional)

Policy Decision Point

Policy Enforcement Point

Access Control Policy

Decision Object

(1)

(5b)

(5a)

(2) (4c)

(4a)

(4b)

(3a) (3b)(1) An authenticated subject (user or system) makes a request to perform an action on a target and encounters a PEP; the subject is identified by a separate IAM.(2) The PEP decides whether to allow or deny the request by consulting a PDP(3) The PDP obtains any necessary attributes to make a decision.(4) The PDP consults the ACP to determine the access decision that should be made given the request and attributes which is communicated to the PEP via a DO.(5) The PEP allows or denies access to the target based on the DO.

Identification and Authentication

Mechanism

Subject

Target

OtherAttributes (optional)

Policy Decision Point

Policy Enforcement Point

Access Control Policy

Decision Object

Identification and Authentication

Mechanism

(B)

(A)

(E)

(C)

(D)

(F) (G)

(H)

Slide 14

Slide 15

Slide 16

Common Security Activities Threat Modeling, Secure Design Review, Secure

Code Review, Security Testing, Secure Deployment Review

Need to be tailored, not drop in

Security Activities

Slide 17

Slide 18

Waterfall != Agile != DevOps Their processes are different, don’t expect the

same security process to work for all

Integration with different methodologies

ELABORATION CONSTRUCTION TRANSITION

Use Case Iterations Development Sprints Sub-Releases

INCEPTION

Business Requirements

High Level Architecture

Secure Frameworks

Secure Architecture

Patterns

Secure Design Patterns & Principles

Common Security

Services/APIs

Complete or Update ASRL

Architecture Threat Model

Use Cases for Functional

Areas

Development & Test Cases

Code Review

Vulnerability Assessment

Penetration Testing

Secure Deployment

Review

Risk Management

Decision to deploy

Security Control

Test Cases

2 34

51

2 34

51

2 34

51

Secure Requirements

Secure Configuration

Checklists

Software Security Knowledge Domains

Update Threat Modelfor changes in Arch

User Story/Task Design

Secure Design Review

2 34

51

Performance/QA Testing

Development Activity

GRC Activity

App Sec Activity

2 34

51

Application Security Risk Level (ASRL)

2 34

51 2 3

45

1

Automation

Dev Team/Local Sec

Independent

AppSec Team

AppSec (High Rigor)

Slide 19

Slide 20

ELABORATION CONSTRUCTION TRANSITION

Use Case Iterations Development Sprints Sub-Releases

INCEPTION

Business Requirements

High Level Architecture

Secure Frameworks

Secure Architecture

Patterns

Secure Design Patterns & Principles

Common Security

Services/APIs

Complete or Update ASRL

Architecture Threat Model

Use Cases for Functional

Areas

Development & Test Cases

Code Review

Vulnerability Assessment

Penetration Testing

Secure Deployment

Review

Risk Management

Decision to deploy

Security Control

Test Cases

2 34

51

2 34

51

2 34

51

Secure Requirements

Secure Configuration

Checklists

Software Security Knowledge Domains

Update Threat Modelfor changes in Arch

User Story/Task Design

Secure Design Review

2 34

51

Performance/QA Testing

Development Activity

GRC Activity

App Sec Activity

2 34

51

Application Security Risk Level (ASRL)

2 34

51 2 3

45

1

Automation

Dev Team/Local Sec

Independent

AppSec Team

AppSec (High Rigor)

Slide 21

Leveraging Automation

Slide 22

Automation is an Essential Piece

Development Build Test Production

Application Security Continuous Integration Process (ASCIP)

Requirements

Report

Scan

Re

me

dia

te

Ass

ess

Source Code

Developers

Team LeadsManagers

CISOs

Ensure vulnerabilities are addressed before

applications are put into production

Build Server

Enterprise

Automated Scans

Assessm

ent

Data

Co

nfig

uratio

n

Man

agem

ent

O

nboa

rdin

g

Reports andDashboards

IDE

Scans

Reports and

Dashboards

Rem

edia

tion

Gui

danc

e

Security Requirements

Definition

Slide 23

Establish metrics early on Positive Metrics

Vulnerabilities found earlier Security control based

Risk reduction Training Impact Application Coverage Risk Trends

Vulnerability Trends Application architecture

Secure Development Program Metrics

Slide 24

“Move Left” – Security from the beginning, not the end

“Know thyself” – Understand what you have and where

“Line of Sight” – Expected security model to implementation

“Just Do It” – Build security to enable the business “Show me the money” – Metrics that clearly show

gains

Summary

THANK YOU!

Brian GlasTwitter: @infosecdad

Email: [email protected]

LinkedIn: https://

www.linkedin.com/pub/brian-glas

Please Remember To Fill Out Your

Session Evaluation Forms!