software security initiatives
DESCRIPTION
OWASP e-gov presentation in Rome November 5th 2009TRANSCRIPT
Copyright © 2009 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.
The OWASP Foundation
OWASP
http://www.owasp.org
How to start a software security initiative within your organization: a maturity based and metrics driven approach
Marco MoranaOWASP LeadTISO Citigroup
Application Security For E-Government
OWASP 2
Building the Rationale For Software Security
OWASP 3
Building Awareness Cases Around Secure Software
Analysts, incidents, compliance, security costs all point to the same target
?
?
OWASP
What PCI-DSS Compliance say regarding application security ?
4
[PCI-DSS] 6 Develop and Maintain Secure Systems and Applications All vulnerabilities must be corrected. The application must be re-evaluated after the
corrections. The application firewall must detect and prevent
web based attacks such as cross site scripting and SQL injection.
[PCI-DSS] 11 Regularly Test Security Systems and Processes
[PCI-DSS] 11.3.2 External application layer penetration test. For web applications, the tests should include, at a
minimum, testing for OWASP T10 vulnerabilities
OWASP
Which Vulnerabilities Are Mostly Exploited For Attacks ?
5
SOURCE: Breach Security The WHID 2009, August 2009
OWASP
What the “experts” say about application security ?
“75% of security breaches happen at the application”- Gartner
“Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” – Gartner
92 % of reported vulnerabilities are in applications not in networks - NIST
“If only 50 percent of software vulnerabilities were removed prior to production … costs would be reduced by 75 percent” - Gartner
The cost of fixing a bug in the field is $30,000 vs. $ 5,000 during coding –NIST
6
Majority of incidents , about 70-75% occur at the application layers, cost savings in fixing vulnerabilities in source code are about 70-80 % instead of fixing during field tests
OWASP 7
What is your company approach toward application security ?
OWASP 8
Software Security Maturity And Metrics Driven Standard Approaches
OWASP
Software Security Maturity and Metrics
Maturity makes executives aware of how the software security effort compares to everyone else’sAssess capabilities and make them visiblePoint to goals and activity needs to reach themProvide the context for software security activities
Measurements allow to articulate a case for software security backed with dataAnalyze vulnerability assessment processes and dataPoint to software security root causes Identify historical vulnerability gaps and trendsPrepare a plan for software security improvements
9
OWASP 10
Defect Management/Cost Metrics
Process Metrics Is code validated against
security coding standards? Is design of developers trained,
using organizational security best practice technology, architecture and processes
Management Metrics
% of applications rated “business-critical” that have been security tested
% of projects that where developed with the SDL
% of security issues identified by lifecycle phase
% of issues whose risk has been accepted
% of security issues being fixed
Average time to correct vulnerabilities
Business impact of critical security incidents.
Most of my vulnerabilities are coding and design issues
But are mostly found during pen test in UAT
The cost of fixing them in UAT is 10 X during coding (unit tests)
OWASP 11
Vulnerability Management Metrics
Process Metrics Is code validated against
security coding standards? Is design of developers trained,
using organizational security best practice technology, architecture and processes
OWASP 12
Essential Plan For Software Security Initiatives
1. Assess the maturity level of the software security of the organization
2. Define the standards, software security process and training
3. Implement software security engineering activities as part of the SDLC1. Security Requirements2. Secure Design and Threat Modeling3. Secure Coding Guidelines and Security Code Review4. Security Testing 5. Secure Deployment
4. Measure and manage risks during the SDLC5. Optimize and improve
OWASP 13
Capability Maturity Models (CMM)
CMM 1: InitialAd hoc process, Focus on Individual Competence, Unpredictable Cost,
Schedule and Quality
CMM 2: RepeatableIntuitive process control, Focus on project administration, mostly
reactive process management
CMM 3: DefinedQualitative process control. Focus on process and
organization, proactive process management
· Security Issues addressed by patching existing applications
· Hire security consulting company to perform ethical hacking/pen testing
· Vulnerability scans for High risk applications
· Security Coding Standards documented
· Source Code Analysis tools tested
· Vulnerability Assessment process defined for all applications
· Source code analysis process for critical applications
· Vulnerability metrics used for risk assessment
CMM 4:ManagedQuantitative process control. Focus on
product and process quality
CMM 5: OptimizingContinuous process
improvement. Focus on Investment in process
automation
· Security is able to measure progress in detecting and fixing vulnerabilities earlier in the SDLC
· Software risks are managed during the SDLC· Engineering is able to management costs for vulnerabilities
· New opportunities for improve software security with adoption of new tools/process are identified during design, development and tests
· Inefficient security activities are identified and replaced
Visibility Into The Software Security Process Maturity Level
OWASP 14
Software Security Activities Mapped to CMM
Initial to Repeatable: From CMM Level 1 to Level 2Penetrate and patch ad-hoc approachExisting high risk applications are pen tested Incidents lead to in-depth vulnerability tests
Defined to Managed: From CMM Level 2 to Level 3Vulnerabilities are tracked and managed per applicationAll development projects are pen tested and source
code analyzed Managed to Optimizing: From CCM Level 4 to Level
5Metrics is correlated and analyzed at each phase of the
SDLC and risks are proactively managedRisk measurements are used for improving security
engineering and risk management processes
OWASP 15
Moving From Tactical to Strategic Planning
From: Reactive Security, Pen Tests, Catch and Patch
To: Metrics, Risk Management, Holistic Security
OWASP
Standard Software Security Maturity Models: SAMM, BSIMM
16
OWASP
Code Review Activities And Capability Levels: BSIMM
17
I am here
OWASP
Software Security Maturity Curve Example
18
Time
CMM Level 1Initial
(Ad Hoc)
CMM Level 2Repeatable(Reactive
Processes)
CMM Level 3Defined
(Proactive)
CMM Level 4Managed(Product Driven)
CMM Level 5Optimizing
(Service Driven)
Catch & Patch
Ethical HackingSecure Code Reviews
on existing Applications
Software Security Risks Identified and Managed At Different Checkpoints During the SDLC
Improve Coverage of Software Security Risk Assessments, Identify Gaps and Opportunities
So
ftw
are
Sec
uri
ty C
apab
ility
Lev
el
Vulnerability AssessmentsSource Code Analysis
Secure Coding StandardsBefore Product Release
OWASP
Prerequisite #1 For Software Security Initiative: Acquire People with the Right Skills
19
OWASP 20
From Application Security to Software Security Vulnerability Assessments
AutomatedAutomatedVulnerabilityVulnerabilityScanningScanning
AutomatedAutomatedStatic CodeStatic Code
AnalysisAnalysis
ManualManualPenetrationPenetrationTestingTesting
ManualManualCodeCode
ReviewReview
OWASP
From Source Code Analysis to Application Threat Modeling
21
Users
Request
Responses
DM
Z (User/W
eb Server Boundary)
Message Call
Account/ TransactionQuery Calls
Web Server
ApplicationServer
Application Calls
Encryption +Authentication
Encryption + Authentication
Financial Server
Authentication Data
Restricted N
etwork
(App &
DB
Server/Financial Server Boundary)
DatabaseServer
Application Responses
FinancialData
Auth Data
MessageResponse
SQL Query Call
CustomerFinancial
Data
Internal (Web Server/ A
pp & D
B Server B
oundary)
Injection flaws CSRF,Weak Session Mgmt,Weak business rule and authorizationMalicious file executionInsecure Object reference
XSS, XFS, SQL Injection, Weak AUTHN AUTHZ FlawsForceful browsingInformation Disclosure Via errors & Files
Broken Authentication, Connection with DB PWD in clear
Broken Authentication/ AuthZ Lack of Synch Session Management
Insecure Storage, poor or non-existent cryptographic controls
I. Phishing,II. Privacy
Violations,III. Financial LossIV. Identity TheftV. System
Compromise, Data Alteration, Destruction
VI. Reputation loss
Insecure TransitURL Parameter Tampering
Insecure Storage, poor or non-existent cryptographic controls
OWASP 22
Define Software Security Engineering Processes
OWASP 23
Essential Software Security Metrics
Define where:Tracking security defects throughout the SDLC
Define what qualitatively:Root causes: requirements, design, code, applicationType of the issues (e.g. bugs vs. flaws vs. configuration)Severity (Critical, High, Medium, Low)SDLC Lifecycle stage where most flaws originating in
Define how quantitatively:% of Critical, High, Medium, Lows for application% of vulnerabilities closed/openVulnerability density (security bugs/LOC)
OWASP 24
Defect Taxonomy in Support of Root Cause Analysis and Defect Containment ObjectivesAnalysis to support focused remediation, risk prioritization and tracking:Security Design Flaws
Introduced because of errors in design Can be identified with threat modeling and manual
code reviewsSecurity Coding Bugs
Coding errors that result in vulnerabilities Can be identified with secure code reviews and/or tools
Security Configuration Issues Introduced after tests because of a change in secure
configuration of either the application, the server and the infrastructure components
Can be identified by testing the application close to production staging environment
OWASP 25
Specific Compliance Driven Metrics: PCI-DSS and OWASP T10 Example
Security Metrics – The Latest From Metric 2.0, Korelogic: http://www.issa-centralva.org/presentations/SecurityMetrics09122007.pdf
OWASP 26
Examples of Software Security Metrics
Process Metrics Evidence that security-
check points are enforced Secure code analysis Vulnerability
assessments Evidence that source code
is validated against security standards (e.g. OWASP ASVS)?
Evidence of security oversight by security officers, SME: Security officers signing
off design documents SME participate to secure
code review Security officer complete
risk assessments Training coverage on
software security
Management Metrics % of security issues
identified by lifecycle phase
% of issues whose risk has been accepted vs. % of security issues being fixed
% of issues per project over time (between quarter to quarter)
% of type of issues per project over time
Average time required to fix/close vulnerabilities during design, coding and testing
Average time to fix issues by issue type
Average time to fix issue by application size/code complexity
OWASP
Essential Elements For Adoption an Assimilation of Software Security Initiatives
27
People, Commitment, Awareness and Training
Software Security Standards
Software Security Frameworks and Risk Management Processes
Software Security Tools
Security=Commitment x ( Tools + Processes^2)
OWASP
Finally: Ensure Continuous Support To The Software Security Initiative
28
Development directors: show that developers are getting better to code defensively
Project Managers: shows hat projects are on schedule and moving on target and testing cycles for vulnerabilities are shorter translating in cost savings
Information Security Officers: show that applications security posture is improving over time by proactively manage risks in compliance with information security standards and processes
OWASP 29
Q&Q U E S T I O N SQ U E S T I O N SA N S W E R SA N S W E R S
OWASP 30
Thanks for listening, further references
Applied Software Measurement: Assuring Productivity and Qualityhttp://www.amazon.com/Applied-Software-Measurement-Assuring-Productivity/dp/0070328269
PCI-Data Security Standard (PCI DSS)https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
A CISO’s Guide to Application Securityhttp://www.nysforum.org/committees/security/051409_pdfs/A%20CISO'S%20Guide%20to%20Applica
tion%20Security.pdf
PCI
http://www.breach.com/resources/whitepapers/downloads/WP_TheWebHackingIncidents-2009.pdf
ROSIhttp://www.infosecwriters.com/text_resources/pdf/ROSI-Practical_Model.pdfhttps://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/business/677-BSI.htmlhttp://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/
55/Default.aspx
Gartner study on phising: http://www.gartner.com/it/page.jsp?id=565125)UC Berkeley Center for Law and Technology on identity theft
http://repositories.cdlib.org/cgi/viewcontent.cgi?article=1045&context=bclt
OWASP
Further references con’t
Gartner 2004 Press Releasehttp://www.gartner.com/press_releases/
asset_106327_11.html
Software Assurance Maturity Modelhttp://www.opensamm.org/
The Software Security Framework (SSF)http://www.bsi-mm.com/ssf/
SEI Capability Maturity Model Integration CMMihttp://www.sei.cmu.edu/cmmi/
The Microsoft Security Development LifeCyclehttp://msdn.microsoft.com/en-us/security/
cc448177.aspx
31
OWASP
Further references con’t
The Seven Touchpoints of Software Securityhttp://www.buildsecurityin.com/concepts/
touchpoints/
OWASP CLASPhttp://www.owasp.org/index.php/
Category:OWASP_CLASP_Project
ITARC Software Security Assurancehttp://iac.dtic.mil/iatac/download/security.pdf
Internet Crime Compliant Centerhttp://www.ic3.gov/default.aspx
32
OWASP
Further references con’t
OWASP Education Module Embed within SDLChttp://www.owasp.org/index.php/
Education_Module_Embed_within_SDLC
Producing Secure Software With Software Security Enhanced Processeshttp://www.net-security.org/dl/insecure/INSECURE-
Mag-16.pdf
Security Flaws Identification and Technical Risk Analysis Through Threat Modelinghttp://www.net-security.org/dl/insecure/INSECURE-
Mag-17.pdf
33