software security initiatives

33
Copyright © 2009 - The OWASP Foundation Permission 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 Morana OWASP Lead TISO Citigroup Application Security For E-Government

Upload: marco-morana

Post on 10-May-2015

4.090 views

Category:

Technology


4 download

DESCRIPTION

OWASP e-gov presentation in Rome November 5th 2009

TRANSCRIPT

Page 1: Software Security Initiatives

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

Page 2: Software Security Initiatives

OWASP 2

Building the Rationale For Software Security

Page 3: Software Security Initiatives

OWASP 3

Building Awareness Cases Around Secure Software

Analysts, incidents, compliance, security costs all point to the same target

?

?

Page 4: Software Security Initiatives

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

Page 5: Software Security Initiatives

OWASP

Which Vulnerabilities Are Mostly Exploited For Attacks ?

5

SOURCE: Breach Security The WHID 2009, August 2009

Page 6: Software Security Initiatives

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

Page 7: Software Security Initiatives

OWASP 7

What is your company approach toward application security ?

Page 8: Software Security Initiatives

OWASP 8

Software Security Maturity And Metrics Driven Standard Approaches

Page 9: Software Security Initiatives

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

Page 10: Software Security Initiatives

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)

Page 11: Software Security Initiatives

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

Page 12: Software Security Initiatives

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

Page 13: Software Security Initiatives

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

Page 14: Software Security Initiatives

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

Page 15: Software Security Initiatives

OWASP 15

Moving From Tactical to Strategic Planning

From: Reactive Security, Pen Tests, Catch and Patch

To: Metrics, Risk Management, Holistic Security

Page 16: Software Security Initiatives

OWASP

Standard Software Security Maturity Models: SAMM, BSIMM

16

Page 17: Software Security Initiatives

OWASP

Code Review Activities And Capability Levels: BSIMM

17

I am here

Page 18: Software Security Initiatives

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

Page 19: Software Security Initiatives

OWASP

Prerequisite #1 For Software Security Initiative: Acquire People with the Right Skills

19

Page 20: Software Security Initiatives

OWASP 20

From Application Security to Software Security Vulnerability Assessments

AutomatedAutomatedVulnerabilityVulnerabilityScanningScanning

AutomatedAutomatedStatic CodeStatic Code

AnalysisAnalysis

ManualManualPenetrationPenetrationTestingTesting

ManualManualCodeCode

ReviewReview

Page 21: Software Security Initiatives

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

Page 22: Software Security Initiatives

OWASP 22

Define Software Security Engineering Processes

Page 23: Software Security Initiatives

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)

Page 24: Software Security Initiatives

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

Page 25: Software Security Initiatives

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

Page 26: Software Security Initiatives

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

Page 27: Software Security Initiatives

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)

Page 28: Software Security Initiatives

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

Page 29: Software Security Initiatives

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

Page 30: Software Security Initiatives

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

Page 31: Software Security Initiatives

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

Page 32: Software Security Initiatives

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

Page 33: Software Security Initiatives

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