HP Protect 2015 Presentation with Denim Group's John Dickson and HP's Bruce Jenkins - Software security historically has been a bolt-on afterthought, frequently a "nice to do" and not a "must do" activity in many organizations. Despite the obvious need to build security in from the outset, organizations continue to struggle to gain momentum and focus resources in support of a structured and measurable software security assurance program. How can organizations determine the best-fit activities and appropriate resource allocation levels to adequately address software risk? How can security leaders know what other organizations are doing to produce more secure software? This session provides an overview of the Open Software Assurance Maturity Model (OpenSAMM) framework and illustrates how organizations can use it to give their security program the edge necessary to stay competitive in today's DevOps world and need-for-speed go-to-market strategies. The session includes case studies on how organizations are using comparative data and OpenSAMM benchmarking to realize measurable software security improvement. Originally shared here - https://sessioncatalog.hpglobalevents.com/go/agendabuilder.sessions/?l=19&sid=4026_2744&locale=en_US

1. © Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

2. Giving Your AppSec Program the Edge
Using OpenSAMM for benchmarking and
software security improvement
Bruce C Jenkins, CISSP
bcj@hp.com
John B. Dickson, CISSP
@johnbdickson

3. Bruce’s Background
• USAF 28-year Veteran
• AppSec Program Strategist
• HP Fortify Security Lead
• Electronics / IT Hobbyist & Observer
of Social Implications of IT

4. HP Enterprise Security | About
• Leading provider of security and compliance solutions built
around world class products
HP Voltage
• HP Enterprise Security portfolio focused on six key areas
• Application security
• Data security
• Endpoint security
• Operations security
• Security governance, risk, and compliance
• Network security

5. John’s Background
• Application Security Enthusiast
• Helps CSO’s and CISO’s with
Application Security Programs
• ISSA Distinguished Fellow
• Security Author and Speaker

6. Denim Group | Company Background
• Professional services firm that builds & secures
enterprise applications
• External application & network assessments
• Web, mobile, and cloud
• Software development lifecycle development (SDLC) consulting
• Secure development services:
• Secure .NET and Java application development & remediation
• Classroom secure developer training for PCI compliance
• Developed ThreadFix

7. Overview
• The Challenge of Securing Applications
• Software Assurance Frameworks and OpenSAMM
• OpenSAMM Benchmarking Update
• Questions and Answers

8. THE CHALLENGE OF SECURING
APPLICATIONS
Giving Your AppSec Program the Edge

9. Value and Risk Are Not Equally Distributed
• Some Applications Matter More Than
Others
• Value and character of data being managed
• Value of the transactions being processed
• Cost of downtime and breaches
• Therefore All Applications Should Not Be
Treated the Same
• Allocate different levels of resources to
assurance
• Select different assurance activities
• Also must often address compliance and
regulatory requirements

10. True Software Attack Surface Is Often Unknown
Software you
currently know about
Why do these usually merit consideration?
• Substantial monetary or brand value flows
through them
• Compliance requirements
(e.g., PCI, HIPAA, FFIEC, etc.)
• Formal SLAs with customers
• You’ve had one or more previous security
incidents (or near misses)
What’s normally in this category?
• Critical legacy systems
• Notable web applications
To assess application security, many organizations focus on obvious
software resources, but overlook their overall inventory of applications
and code from less obvious sources when they analyze their assets.

11. True Software Attack Surface Is Often Unknown
To assess application security, many organizations focus on obvious
software resources, but overlook their overall inventory of applications
and code from less obvious sources when they analyze their assets.
Add in the rest of the web
applications your organization
actually develops and maintains
What’s normally in this category?
• Critical legacy systems
• Notable web applications
Why do these usually merit consideration?
• Substantial monetary or brand value flows
through them
• Compliance requirements
(e.g., PCI, HIPAA, FFIEC, etc.)
• Formal SLAs with customers
• You’ve had one or more previous security
incidents (or near misses)

12. True Software Attack Surface Is Often Unknown
12
Add in the software
you bought from
somewhere
Why do these usually merit consideration?
• Substantial monetary or brand value flows
through them
• Compliance requirements
(e.g., PCI, HIPAA, FFIEC, etc.)
• Formal SLAs with customers
• You’ve had one or more previous security
incidents (or near misses)
What’s normally in this category?
• Critical legacy systems
• Notable web applications
To assess application security, many organizations focus on obvious
software resources, but overlook their overall inventory of applications
and code from less obvious sources when they analyze their assets.

13. True Software Attack Surface Is Often Unknown
Why do these usually merit consideration?
• Substantial monetary or brand value flows
through them
• Compliance requirements
(e.g., PCI, HIPAA, FFIEC, etc.)
• Formal SLAs with customers
• You’ve had one or more previous security
incidents (or near misses)
What’s normally in this category?
• Critical legacy systems
• Notable web applications
Don’t forget mobile and cloud
To assess application security, many organizations focus on obvious
software resources, but overlook their overall inventory of applications
and code from less obvious sources when they analyze their assets.

14. We Need Better Audit Coverage of Attack Surface

15. We Need Better Audit Coverage of Attack Surface

16. We Need Better Audit Coverage of Attack Surface

17. Application Testing Is Often Under Scoped
Application security testing goes well beyond simply running static and
dynamic scanners. For critical or high value applications, or those that
process sensitive data, thorough testing may actually include a
combination of several methods.
Unauthenticated
Automated Scan
Automated
Source Code
Scanning
Blind
Penetration
Testing
Manual Source
Code Review
Authenticated
Automated Scan
Informed Manual
Testing
Automated
Binary Analysis
Manual Binary
Analysis

18. Vulnerability Discovery-to-Fix Time Is Excessive
• The Verizon 2015 DBIR emphasizes that 99.9 percent of
exploited vulnerabilities were compromised more than a
year after the CVE* was first published.
How would you report to management that a “serious,” likely
exploitable vulnerability was present in your primary public facing
web site or 3rd party hosted portal for more than six months?
What compensating controls could you explain to placate
management that a serious vulnerability could not be exploited?
• HP Security Research reports that organizations in a
study execute an average of six automated static code
scans before critical vulnerabilities are remediated.**
How does this help you explain application risk?
*Common Vulnerabilities and Exposures, cve.mitre.org
**HP Cyber Risk Report 2015, hp.com/go/cyberrisk

19. SOFTWARE ASSURANCE FRAMEWORKS
AND OPENSAMM
Giving Your AppSec Program the Edge

20. Software Assurance Frameworks*
*Examples Only; not intended to be a comprehensive list
**OpenSAMM update scheduled for CY2015
2005 2006 2008** 2010 2010 2013

21. OpenSAMM Design Intent
The Software Assurance Maturity Model (SAMM) is an
open framework to help organizations formulate and
implement a strategy for software security that is tailored to
the specific risks facing the organization. The resources
provided by SAMM will aid in:
• Evaluating an organization’s existing software security practices
• Building a balanced software security assurance program in
well-defined iterations
• Demonstrating concrete improvements to a security
assurance program
• Defining and measuring security-related
activities throughout an organization
Source: Software Assurance Maturity Model

22. OpenSAMM Business Functions
• Start with the core activities tied to any organization
performing software development
• Named generically, but should resonate with any
developer or manager
Source: Software Assurance Maturity Model

23. OpenSAMM Security Practices
• From each of the Business Functions, three Security
Practices are defined
• Security Practices cover all areas relevant to software
security assurance
Source: Software Assurance Maturity Model

24. OpenSAMM in Practice
Example OpenSAMM Scorecard
Level 1
Maturity
Level
Activity
Business
Functions
# Security Practices/Phase A B
Governance
1 Strategy & Metrics 0.5 0 1
2 Policy & Compliance 0.5 0 1
3 Education & Guidance 0 0 0
Construction
4 Threat Assessment 0 0 0
5 Security Requirements 0.5 0 1
6 Secure Architecture 0 0 0
Verification
7 Design Review 0.5 0 1
8 Code Review 0 0 0
9 Security Testing 0 0 0
Deployment
10 Vulnerability Management 1 1 1
11 Environment Hardening 1 1 1
12 Operational Enablement 0 0 0
SAMM Valid Maturity Levels
0 Implicit starting point representing the activities in the Practice being unfulfilled
1 Initial understanding and ad hoc provision of Security Practice
2 Increase efficiency and/or effectiveness of the Security Practice
3 Comprehensive mastery of the Security Practice at scale
Legend
Objective Activity was met.
Objective Activity was not met.

25. OPENSAMM BENCHMARKING UPDATE
Giving Your AppSec Program the Edge

26. OpenSAMM Benchmarking Initiative
• Solve data contribution problem
• New data scheme & DB
• Anonymization & trust model
• Who contributes and roles
• Identify an independent data host
• Addressed the need for team-based data
• Help drive wider industry acceptance

27. Coalition of the Willing
• Aspect Security
• AsTech Consulting
• Denim Group
• Gotham Digital Science
• Security Innovation
• Veracode
• HP (Joining)
• WhiteHat Security (Joining)
• NetSpi (Joining)

28. Data Model – High Level
Public vs Private
• Public data contributed, with random identifiers for
• Organization the data relates to
• Team within that organization
• Organization that performed the assessment
• Private data – not contributed
• Maintained by assessor

29. Data Model – High Level (continued)
• Granularity
• Organization versus Team
• Organization / Team Metadata
• Employee/Developer/DevSec count (ranges) (team and org)
• Sector (org)
• Region (org)
• Differing depths of data supported
• Crowd sourced versus centrally sourced
• Inclusive, not exclusive
• Quality of data
• Give you what you need to make your own decisions

30. What Analysis?
• Ask comparative sector questions
• “I’m a 1+ in this practice – what are other organizations similar
to me?”
• Validate transformation plans, support existing plans
• “We’re looking to be leaders in this practice. We will be ahead
of the market”
• Find specific maturities within teams/orgs

31. So Where Do You Go From Here?

32. Potential Approaches
• Conduct limited scope OpenSAMM assessment of
software development activities for certain software
teams
• Security Testing
• Code Review
• Vulnerability Management
• Make high-level prioritization recommendations
• Based upon risk, team, and technologies
• Provide process improvement and automated scanning
transition recommendations

33. Questions and Answers
Bruce C Jenkins, CISSP
bcj@hp.com
John B. Dickson, CISSP
@johnbdickson

34. © Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Thankyou
Contact information