Michele MossOWASP AppSecDC 2010 Conference

November 10, 2010

People, Process, and Technology: OWASP Impact on the SwA Processes and Practices Working Group

2

Table Of Contents

Background

People, Technology, Process

Next Steps

People

Measures

Technology

3

What CIOs want

0

11

27

32

55

70

95

0 20 40 60 80 100

Other

Rich Feature Set

Convenience & Ease of Use

Software conforms to Requirements& Industry Standards

Ease of Integration & Configuration

Software free from securityvulnerabilities and malicious code

Reliabile software that functions aspromised

Percent

https://www.cioexecutivecouncil.com October 11, 2006 Press Release

4

100 apps written by 100 developers at 100 companies

What CIOs Get 83 apps have serious vulnerabilities

72 apps have cross site scripting

40 apps have SQL Injection

100 apps contain code of unknown origin

90 apps use un-patched libraries with known

flaws

5 apps have h ad a scan or pentest

1 app has had a manual security code review

0 apps provide any visibility into security

Why 1 company has a responsible appsec program

1 developer has any security training

Filename/RPS Number

Adapted from: The Open Web Application Security Project ,Jeff Williams, Aspect Security, SWA Forum Sept 2010

We Trust

We BlameWe Hide

5

Experience

Objectives

Drivers

Risks

SwA Requires Multi-disciplinary Collaboration

Vocabulary

Reserved Words

Priorities

Perspective

Without a common language we cannot communicate across disciplines

Software Acquisition

Information Assurance

ProjectManagement

SystemEngineering

SoftwareEngineering

Information Systems Security EngineeringSafety and

Security

Test &Evaluation

SoftwareAssurance

Source: https://buildsecurityin.us-cert.gov/swa/procresrc.html

Communication

Challenges

6

Table Of Contents

Background

People, Technology, Process

Next Steps

People

Measures

Technology

7

OPEN SAMM

– Open Software Assurance Maturity Model (SAMM) http://www.opensamm.org/ Open framework to help organizations formulate and implement a strategy for

software security tailored to specific risks

http://www.opensamm.org/downloads/SAMM-1.0.pdf

8

Implementation Lessons Learned

Who– Secure development SMEs– Developers

What– Measure progress (training, secure code

reviews, security change requests)– Internal policy

When– During product development process– During Leadership discussions – As part of development and acquisition reviews

Where– IT Development Organizations– IT Acquisition Organizations – IT Integrator Organizations

Why– Customer pressure– Reaction to an incident

Why Not– Compliance drivers don’t exist– Focus is on systems and networks – Secure software training is not given to

developers and architects

How– Executive leadership commitment– Translate ROI to project manager vocabulary

(cost, schedule, quality) – Start small and build – Use coding standards– Empower secure development to prevent a

product from moving to the next milestone– Avoid creating a new language – Leverage what is already known– Increase automation of menial tasksCourtesy of September 2010 SwA Panel SwA Practices

– Getting to Effectiveness in Implementation

9

Stakeholders

SupplierSupplier ExecutiveExecutive

AcquirerAcquirer PractitionerPractitioner

Organizations People

Web Goat

OWASP Top 10

Developer Guides

Checklists

ASVS

ESAPI

AntiSammy

Secure Coding Practices – Quick Reference

Testing GuideLegal Project

Secure Code Review

OSAMM

10

SwA Must Translate to Organizational and Mission/ Business Focused Stakeholders

Source: NIST 800-37 Guide for Applying the Risk Management Framework to Federal Information Systems A Security Life Cycle Approach

In a way that is applicable in diverse contexts (Defense, National Security, Finance, Heath care, Aviations, Telecommunications) and is not a source of liability or misunderstanding in acquisition decisions

TIER 3Information System

(Environment of Operation)

TIER 2Mission / Business Process

(Information and Information Flows)

TIER 1Organization(Governance)

11

Communication Across Organizational Stakeholders Is Critical to addressing ICT SCRM and SwA Challenges

The Assurance PRM Is A Holistic Framework that connects CMMI and RMM to facilitate communication

https://buildsecurityin.us-cert.gov/swa/proself_assm.html

Enterprise Assurance Support

ES 1 Establish and maintain organizational culture where assurance is an integral part of achieving the mission

ES 2 Establish and maintain the ability to support continued delivery of assurance capabilities

ES 3 Monitor and improve enterprise support to IT assets

Development Engineering

DE 1 Establish assurance requirements

DE 2 Create IT solutions with integrated business objectives and assurance

DE 3 Verify and Validate an implementation for assurance

Development Organization

DO 1 Establish the assurance resources to achieve key business objectives

DO 2 Establish the environment to sustain the assurance program within the organization

Development Project DP 1 Identify and manage risks

due to vulnerabilities throughout the product and system lifecycle

DP 2 Establish and maintain assurance support from the project

DP 3 Protect project and organizational assets

Acquisition and Supplier Management

AM 1 Select, manage, and use effective suppliers and third party applications based upon their assurance capabilities.

EnableResilient Technology

Define Business Goals

Sustained environment to achieve business goals through technology

Prioritize funds and manage risks

12

tech

protect sustain

Enterprise Leadership and Resilient Technology

Enable Resilient Technology

Define Business Goals

Sustained environment to achieve business goals through technology

Prioritize funds and manage risks

Development Engineering

CEO

CIO

Business Functions

CTO

CFO

COO

Development Project

Enterprise Assurance Support

Development Organization

Service Mission

Service Mission

Organization Mission

Ser

vice

people info tech facilities

Business Processes

Assets in Production

Adapted from: Source: November 2009 SwA Forum-Evolution in SwA Processes Panel – David White, SEI

13

A Resilient Technology Best Practices Cross Walk

You have been asked to ensure that the OWASP Top Ten (an assurance coding

Standard) are not in the Code

You can look at the OSAMM for guidance on how to do it

https://buildsecurityin.us-cert.gov/swa/proself_assm.html

14

Understand Assurance-Related Process Capability Expectations

Look to Standards for Assurance Process Detail

Understand Your Business Requirements for Assurance Build or Refine and Execute

Your Assurance Processes

Measure Your Results

Process Improvement Lifecycle - A Process for Achieving Assurance

Adapted from: Paul Croll, Computer Sciences Corporation, August 2007

15

The Solution Requires A Balance Of Benchmarks

The chicken…. (a.k.a. Process Focused Assessment )– Management Systems (ISO 9001, ISO 27001, ISO 2000)– Capability Maturity Models (CMMI, RMM, SSE-CMM )– Lifecycle Processes (ISO/IEEE 15288, ISO/IEEE 12207)– COBIT, ITIL, MS SDL, OSAMM, BSIMM

The egg … (a.k.a Product Focused Assessments)– SCAP - NIST-SCAP– ISO/OMG W3C – KDM, BPMN, RIF, XMI, RDF– OWASP Top 10– SANS TOP 25– Secure Code Check Lists– Static Code Analysis– Pen Test Results

16

SwA, SCRM, And Continuous Improvement Contribute To Operational Resilience

Compliance

Monitoring

Measurement and Analysis

Enterprise Focus

Incident Management and Control

Adapted from September 2010 SwA Forum, CERT RMM for Assurance , Lisa Young, SEI

MAEC

CAPEC

OVAL SCAP

Asset Management

Controls Applied to

CVSS,

CAPEC

MAEC,

KDM

How do we prevent this next time?

Are we being attacked?

Who is attacking and what do they want?

Are we at risk?

Applied to

Resilience Requirements Management

Apply Lessons LearnedVulnerability Analysis and Resolution

BPMN

17

People

Measures

Technology

Table Of Contents

Background

People, Technology, Process

Next Steps

18

ICTSupplyChain

Security

SystemsEngineering

RiskManagement

IT Resiliency

InformationSecurity

ApplicationSecurity

Supply Chain&

Logistics

Source: September 28, 2010 SwA Forum, Standards Landscape and ICT SCRM Study Period Update, Nadya Bartol, Booz Allen Hamilton

Filename/RPS Number

ICT SCRM And SwA Are Complex Multi-Disciplinary Challenges

Software Assurance (SwA)

Software Acquisition

Information Assurance

ProjectManagement System

Engineering

SoftwareEngineering

Information Systems Security Engineering

Safety and Security

Test &Evaluation

SoftwareAssurance

Source: https://buildsecurityin.us-cert.gov/swa/procresrc.html

19

SCRM Stakeholders

CIP

DoD DHS & IACommercial

Industry

SCRM STANDARDIZATIO

N

Enabled by Inform

ation Sharin

g

Other Users

SCRM “commercially acceptable global

standard(s)” must be derived from

Commercial Industry Best Practices.

US (CNCI) has vital interest in the global supply chain.

SCRM Standardization Requires Public-Private Collaborative EffortCourtesy of Don Davidson, OSD TMSN ,Chief of Outreach and Standardization

20

Standards Development Organizations Landscape: an SCRM Perspective

Courtesy of Don Davidson, OSD TMSN ,Chief of Outreach and Standardization

21

ISO/IEC 27036: Information technology – Security techniques –Information Security for Supplier Relationships (proposed title) Scope: This international standard covers information security in relationships between acquirers and

suppliers to provide appropriate information security management for all parties. In particular, it also includes management of information security risks related to these relationships.

The standard will be subdivided into the following parts:– Part 1 – Overview and Concepts– Part 2 – Common Requirements – Part 3 – Guidelines for ICT Supply Chain – Part 4 – Guidelines for Outsourcing

Relevant Documents to be considered– Management Systems: ISO/IEC 27000 family; ISO 28000, Supply Chain Resiliency; ISO/IEC 20000, IT

Service Management– Risk Management: ISO 31000, ISO/IEC 27005, and ISO/IEC 16085– Lifecycle Processes and Practices, software acquisition, and software assurance ISO/IEC/IEEE 15288

(systems), ISO/IEC/IEEE 12207 (software), IEEE 1062 (software acquisition), ISO/IEC15026 (software assurance)

– ISO TMB NWIP on Outsourcing

Courtesy of Nadya Bartol, Booz Allen Hamilton

22

ISO/IEC 27034 – Guidelines for Application Security Scope: The scope of this standard is to specify an application security life cycle, incorporating

the security activities and controls for use as part of an application life cycle, covering applications developed through internal development, external acquisition, outsourcing/offshoring1, or a hybrid of these approaches.

Purpose and justification: – The standard provides guidance to business and IT managers, developers, auditors, and end-users to

ensure that the desired level of security is attained in business applications in line with the requirements of the organization’s Information Security Management Systems (ISMS).

– Application security addresses all aspects of security required to determine the information security requirements, and ensure adequate protection of information accessed by an application as well as to prevent unauthorized use of the application and unauthorized actions of an application.

– Informational security concerns in business applications are to be addressed in all phases of the application life cycle, as guided by the organization’s risk management principles and the ISMS adopted.

– This standard will provide guidance to establishing security goals and includes controls to verify that security target level has been reached. Application Security without any validated controls is a security illusion, and may be more hazardous for the organization.

Courtesy of Nadya Bartol, Booz Allen Hamilton

23

ISO/IEC TR 24774:2010, Programming Language Vulnerabilities

Any programming language has vulnerabilities in its design– Sub-optimal coding practices can lead to security or safety failures

TR 24774 describes 71 classes of vulnerabilities in language-independent terms.

The second edition of the TR is now being drafted. It will add annexes that describe how to avoid the vulnerabilities in specific programming languages.– Annexes for C, Fortran, Ada and SPARK have been drafted.– We need experts in other languages, including scripting languages, to draft annexes.

Contact:– Convener: John Benito, benito@bluepilot.com– Secretary: Jim Moore, moorej@mitre.org

Courtesy of Jim Moore, MITRE

24

What’s next?

Continued collaboration to: – Reach and enable developers– Reach and enable executives– Develop and promote resources for us by developers and executives

Participation in international standardization efforts – SC7 TAG intersections through your SC7 TAG – CS1/SC27 – IEEE representative to the SC7 TAG– SC22

Participation through the SwA Working Groups and Forum

Stay Tuned …

25

Back-up

26

https://buildsecurityin.us-cert.gov/swa/proself_assm.html

The DHS SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts into a set of high-level goals and supporting practices (an evolution of the SwA community’s Assurance Process Reference Model)

The goals and practices are mapped to specific industry resources providing additional detail and real world implementation and supporting practices

• Assurance Focus for CMMI • Building Security In Maturity Model • Open Software Assurance Maturity Model • CERT® Resilience Management Model • CMMI for Acquisition • CMMI for Development • CMMI for Services • SwA Community’s Assurance Process Reference Model –Initial Mappings • SwA Community’s Assurance Process Reference Model - Self Assessment • SwA Community’s Assurance Process Reference Model – Mapping to Assurance Models

Other valuable resources that are in the process of being mapped include • NIST IR 7622: DRAFT Piloting Supply Chain Risk Management Practices for Federal Information Systems • NDIA System Assurance Guidebook • Microsoft Security Development Lifecycle • SAFECode