People, Process, and Technology: OWASP Impact on
the SwA Processes and Practices Working Group
Michele Moss
OWASP AppSecDC 2010 Conference
November 10, 2010
Table Of Contents
People
 Background
 People, Technology, Process
 Next Steps
Measures
Technology
1
What CIOs want
Reliabile software that functions as
promised
95
Software free from security
vulnerabilities and malicious code
70
Ease of Integration & Configuration
55
Software conforms to Requirements
& Industry Standards
32
Convenience & Ease of Use
27
Rich Feature Set
Other
11
0
0
20
40
60
80
100
Percent
https://www.cioexecutivecouncil.com October 11, 2006 Press Release
2
100 apps written by 100 developers at 100 companies
What CIOs Get
We
Trust
 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
We
Hide
We
Blame
flaws
 5 apps have h ad a scan or pentest
Why
 1 app has had a manual security code review
 1 company has a responsible appsec program
 0 apps provide any visibility into security
 1 developer has any security training
Adapted from: The Open Web Application Security Project ,Jeff Williams, Aspect Security, SWA Forum Sept 2010
Filename/RPS Number
3
SwA Requires Multi-disciplinary Collaboration
Project
Management
Information
Assurance
Software
Acquisition
System
Engineering
Communication
Challenges
Software
Assurance
Software
Engineering
 Vocabulary
 Experience
 Reserved Words  Objectives
Test &
Evaluation
Safety and
Security
Information
Systems
Security
Engineering
 Priorities
 Drivers
 Perspective
 Risks
Source: https://buildsecurityin.us-cert.gov/swa/procresrc.html
Without a common language we cannot communicate across
disciplines
4
Table Of Contents
People
 Background
 People, Technology, Process
 Next Steps
Measures
Technology
5
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
6
Implementation Lessons Learned
 Who
 Why
– Secure development SMEs
– Customer pressure
– Developers
– Reaction to an incident
 What
 Why Not
– Measure progress (training, secure code reviews,
security change requests)
– Compliance drivers don’t exist
– Internal policy
– Secure software training is not given to
developers and architects
– Focus is on systems and networks
 When
– During product development process
 How
– During Leadership discussions
– Executive leadership commitment
– As part of development and acquisition reviews
– Translate ROI to project manager vocabulary
(cost, schedule, quality)
 Where
– Start small and build
– IT Development Organizations
– Use coding standards
– IT Acquisition Organizations
– Empower secure development to prevent a
product from moving to the next milestone
– IT Integrator Organizations
Courtesy of September 2010 SwA Panel SwA Practices
– Getting to Effectiveness in Implementation
– Avoid creating a new language
– Leverage what is already known
– Increase automation of menial tasks
7
Stakeholders
People
Organizations
OSAMM
ESAPI
Checklists
Supplier
Executive
Secure Code
Review
OWASP Top 10
AntiSammy
Acquirer
ASVS
Practitioner
Web Goat
Developer Guides
Legal Project
Secure Coding
Practices – Quick
Reference
Testing Guide
8
SwA Must Translate to Organizational and Mission/ Business Focused
Stakeholders
TIER 1
Organization
(Governance)
TIER 2
Mission / Business Process
(Information and Information Flows)
TIER 3
Information System
(Environment of Operation)
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
9
Communication Across Organizational Stakeholders Is
Critical to addressing ICT SCRM and SwA Challenges
Development Project
Define Business Goals
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
Acquisition and Supplier
Management
AM 1 Select, manage, and use
effective suppliers and
third party applications
based upon their
assurance capabilities.
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
Prioritize
funds and
manage risks
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
Enable
Resilient
Technology
Sustained
environment to
achieve
business goals
through
technology
The Assurance PRM Is A Holistic Framework that connects CMMI and RMM to facilitate communication
https://buildsecurityin.us-cert.gov/swa/proself_assm.html
10
Enterprise Leadership and Resilient Technology
COO
CEO
Prioritize funds and manage
risks
Business
Functions
CFO
Define Business Goals
Development Organization
CIO
Service
Sustained environment to achieve
business goals through technology
Enterprise Assurance Support
tech
CTO
protect
sustain
Business Processes
Organization
Mission
Assets in Production
Service
Service
Mission
Mission
people
info
tech
facilities
Adapted from: Source: November 2009 SwA Forum-Evolution
in SwA Processes Panel – David White, SEI
Enable Resilient Technology
Development Project
Development Engineering
11
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
12
Process Improvement Lifecycle - A Process
for Achieving Assurance
Measure Your Results
Understand Your Business
Requirements for Assurance
Understand Assurance-Related
Process Capability Expectations
Build or Refine and Execute
Your Assurance Processes
Look to Standards for
Assurance Process Detail
Adapted from: Paul Croll, Computer Sciences Corporation, August 2007
13
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
14
SwA, SCRM, And Continuous Improvement Contribute To
Operational Resilience
Are we being
attacked?
Compliance
Incident
Management
and Control
OVAL
SCAP
C
A
P
E
C
How do we prevent
this next time?
Resilience
Requirements
Management
Who is attacking and
what do they want?
Enterprise
Focus
Monitoring
B
P
M
N
Measurement
and Analysis
Vulnerability
Analysis and
Resolution
Are we at
risk?
Controls
Applied to
Asset
Management
Adapted from September 2010 SwA Forum, CERT RMM for Assurance , Lisa Young, SEI
15
Table Of Contents
People
 Background
 People, Technology, Process
 Next Steps
Measures
Technology
16
ICT SCRM And SwA Are Complex Multi-Disciplinary
Challenges
Software Assurance (SwA)
Project
Management
Information
Assurance
Software
Acquisition
Systems
Engineering
Risk
Management
IT
Resiliency
ICT
Supply
Chain
Security
Supply Chain
&
Logistics
Test &
Evaluation
Information
Security
Software
Assurance
Safety and
Security
System
Engineering
Software
Engineering
Information
Systems
Security
Engineering
Source: https://buildsecurityin.us-cert.gov/swa/procresrc.html
Application
Security
Source: September 28, 2010 SwA Forum, Standards Landscape and
ICT SCRM Study Period Update, Nadya Bartol, Booz Allen Hamilton
Filename/RPS Number
17
SCRM Stakeholders
US (CNCI) has vital interest in the global supply chain.
Other Users
CIP
SCRM “commercially
acceptable global
standard(s)”
must be derived from
Commercial Industry Best
Practices.
DoD
DHS & IA
Commercial
Industry
SCRM Standardization Requires Public-Private Collaborative Effort
Courtesy of Don Davidson, OSD TMSN ,Chief of Outreach and Standardization
18
Standards Development Organizations Landscape:
an SCRM Perspective
Courtesy of Don Davidson, OSD TMSN ,Chief of Outreach and Standardization
19
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
20
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
21
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
22
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 …
23
Back-up
24
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
25