Michele Moss OWASP AppSecDC 2010 Conference November 10, 2010 People, Process, and Technology: OWASP...
-
date post
20-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of Michele Moss OWASP AppSecDC 2010 Conference November 10, 2010 People, Process, and Technology: OWASP...
Michele MossOWASP AppSecDC 2010 Conference
November 10, 2010
People, Process, and Technology: OWASP Impact on the SwA Processes and Practices Working Group
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
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
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, [email protected]– Secretary: Jim Moore, [email protected]
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 …
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