Security is an Awesome Product Feature Mark P. Hahn Director of - - PowerPoint PPT Presentation

DevSecOpsDays Pittsburgh 2020

Security is an Awesome Product Feature

Mark P. Hahn

Director of Cloud Strategies and DevOps Ciber Global, LLC, an HTC Global Company

425-749-9501, mhahn@ciber.com, https://www.linkedin.com/in/markphahn/

DevSecOpsDays Pittsburgh 2020

Security is an Awesome Product Feature

Mark P. Hahn

Director of Cloud Strategies and DevOps Ciber Global, LLC, an HTC Global Company

425-749-9501, mhahn@ciber.com, https://www.linkedin.com/in/markphahn/

This talk was presented at DevSecOpsDays in July of 2020

https://devsecopsdayspittsburgh2020.sched.com/

The event was hosted by the Software Engineering Institute at CMU

https://www.sei.cmu.edu/ These are the annotated slides with my speaker notes to make it readable as a standalone document. Additional references are also included.

Mark Hahn is Ciber's Practice Director for Cloud and Dev/Ops

• Frameworks. He has 25+ years of experience as a Principal Architect

delivering large-scale systems, including Wall Street trading systems, multinational retail payments systems and supply chain systems. Mark practices and coaches continuous delivery techniques that improve delivery timelines and increase system reliability, including Lean software development and continuous improvement. A rare high-level professional who maintains excellent hands-on technical proficiency, Mark has been with Ciber for 8 years.

DevSecOpsDays Pittsburgh 2020

Brakeing Down Security Podcast

“teams want to work on awesome features, not security, and they don't realize that security is an awesome feature”

• @noid

https://brakeingsecurity.com/2019-044-noid-and-dave-dittrich-discusses-recent-keybase-woes-part-1

DevSecOpsDays Pittsburgh 2020

Brakeing Down Security Podcast

“teams want to work on awesome features, not security, and they don't realize that security is an awesome feature”

• @noid

https://brakeingsecurity.com/2019-044-noid-and-dave-dittrich-discusses-recent-keybase-woes-part-1

The origin for this talk was this quote from the Brakeing Down Security podcast in December 2019 by Brian ”@Noid” Harden. Brian had recently given a presentation at Seattle BSides about how to find security champions in development teams so one person on the team understands the concerns of the information security team. My thought was that the whole development team should understand that security is an awesome feature. In fact, it is the development team’s responsibility to lead the charge for security in their product. Empowered DevOps teams should not only be responsible for creating viable features, they are also responsible for product stability and

• trustworthiness. Hence, they need to shift left on security, and make it a

first class product feature.

DevSecOpsDays Pittsburgh 2020

https://en.wiktionary.org/wiki/awesome

Etymology

From awe + -some; compare Old English eġeful (“fearful; inspiring awe”).

Adjective

awesome (comparative more awesome or awesomer, superlative most awesome or awesomest) (dated) Causing awe or terror; inspiring wonder or excitement. [from 1590– 1600.] The waterfall in the middle of the rainforest was an awesome sight. The tsunami was awesome in its destructive power. (colloquial) Excellent, exciting, remarkable. That was awesome! Awesome, dude!

DevSecOpsDays Pittsburgh 2020

https://en.wiktionary.org/wiki/awesome

Etymology

From awe + -some; compare Old English eġeful (“fearful; inspiring awe”).

Adjective

awesome (comparative more awesome or awesomer, superlative most awesome or awesomest) (dated) Causing awe or terror; inspiring wonder or excitement. [from 1590– 1600.] The waterfall in the middle of the rainforest was an awesome sight. The tsunami was awesome in its destructive power. (colloquial) Excellent, exciting, remarkable. That was awesome! Awesome, dude!

The word “awesome” is an adjective for comparison, which implies that we are making a choice about relative value of something. In this case it is the relative value of working on application security versus work on some

• ther product feature.

DevSecOpsDays Pittsburgh 2020

DevOps / DevSecOps Drives Business Value

Plan Build Monitor Deploy Test

Continuous Integration

Idea! Product.

DevOps Toolchain DevSecOps Toolchain

Create Plan Configure Detect Verify Preproduction Predict Respond Continuous Continuous Improvement Configuration Continuous Continuous Deployment Learning Continuous Monitoring Continuous Integration Monitoring And Analytics Monitoring And Analytics

DevSecOpsDays Pittsburgh 2020

DevOps / DevSecOps Drives Business Value

Plan Build Monitor Deploy Test

Continuous Integration

Idea! Product.

DevOps Toolchain DevSecOps Toolchain

Create Plan Configure Detect Verify Preproduction Predict Respond Continuous Continuous Improvement Configuration Continuous Continuous Deployment Learning Continuous Monitoring Continuous Integration Monitoring And Analytics Monitoring And Analytics

The reason for the product is to create some business value for an

• rganization. DevOps, or DevSecOps is a method (or a collection of

methods) for focusing on business value and agreeing on a set of work to create or enhance business value. Which ever model you use for managing your work, the key is the value that the organization derives. I prefer the simpler wheel on the right over the more complex models

• n the right. Development teams need to complete trips around the

wheel to deliver running software, and working on security features are simply circuits around the wheel.

DevSecOpsDays Pittsburgh 2020

Empowered Teams Drive Business Value

Empowered teams are responsible for all phases of software development.

Plan Build Monitor Deploy Test

Continuous Integration

Idea! Product.

PO DL DV DV DV DV DV

DevSecOpsDays Pittsburgh 2020

Empowered Teams Drive Business Value

Empowered teams are responsible for all phases of software development.

Plan Build Monitor Deploy Test

Continuous Integration

Idea! Product.

PO DL DV DV DV DV DV

Development teams working to deliver business value must recognize that “Cybersecurity is a business problem, not a technical problem.” That phrase is the title of the first chapter in the book Fire Doesn’t Innovate by Kip Boyle, ISBN-10: 1544513194.

DevSecOpsDays Pittsburgh 2020

Automated Delivery Toolchain

PO DL DV DV DV DV DV EC VP DR US US US IA CP SA SR T1 OP PM BA PD Senior Leadership Business Owners End Users SRE and Operations Information Security

DevSecOpsDays Pittsburgh 2020

Automated Delivery Toolchain

PO DL DV DV DV DV DV EC VP DR US US US IA CP SA SR T1 OP PM BA PD Senior Leadership Business Owners End Users SRE and Operations Information Security

Development teams need to evaluate the input and needs of many different constituencies when ranking security features versus business features. This is a negotiation process which developments may not be good at. The tool that teams can use to risk modeling and threat analysis to help quality and then quantify the security risk to their system. The book Threat Modeling: Designing for Security by Adam Shostack, ISBN: 9781118809990 is a good staring point. The STRIDE model provides a workable starting point for analysis that can easily be used by development teams. EC = Executive VP = Vice President DR = Director PM = Product Management BA = Business Analyst PD = Product Designer US = User SR = SRE T1= Tier 1 OP = Operations IA = InfoSec Analyst CP = Compliance SA = Security Analyst

DevSecOpsDays Pittsburgh 2020

Relative Valuations

• Hard Requirements
• Regulatory mandates
• Important Requirements
• TLS and up to date cypher suites
• OAuth2
• Good Ideas
• Multifactor Authentication
• Encryption at rest
• Correct Session Timeouts
• Nice to Haves
• Application Firewall

DevSecOpsDays Pittsburgh 2020

Relative Valuations

• Hard Requirements
• Regulatory mandates
• Important Requirements
• TLS and up to date cypher suites
• OAuth2
• Good Ideas
• Multifactor Authentication
• Encryption at rest
• Correct Session Timeouts
• Nice to Haves
• Application Firewall

One way to set priorities is to use a qualitative ranking and make judgements between different features. The quality descriptors can

• vary. When threat modeling, security risks are
• ften described with qualifiers likelihood and for
• impact. The qualifiers can then be used to sort

and rank security risks, and choose mitigations to work on. However, the qualitive rankings for security may be difficult to compare to the qualifiers used to describe and rank business features.

DevSecOpsDays Pittsburgh 2020

Monetary Valuation

2019 IBM / Ponemon Data Breach Report

Average Cost of a data breach

$3.92 million

Average size of a data breach

25,575 record

Cost per lost record

$150

Time to identify and contain a data breach

279 days

GDPR CCPA

€20 million

• r up to 4% of the annual worldwide turnover

$62.5 million

($2,500 pre consumer) + Lawsuits

DevSecOpsDays Pittsburgh 2020

Monetary Valuation

2019 IBM / Ponemon Data Breach Report

Average Cost of a data breach

$3.92 million

Average size of a data breach

25,575 record

Cost per lost record

$150

Time to identify and contain a data breach

279 days

GDPR CCPA

€20 million

• r up to 4% of the annual worldwide turnover

$62.5 million

($2,500 pre consumer) + Lawsuits

Another way to set priorities is to use a monetary evaluation to compare to business features which have monetary models. This can prove difficult however, when deciding

• n how to use the values for possible large fines

which are now making headlines. Such a large value looks like it trumps all other concerns. But it also can make the conversations uncomfortable.

DevSecOpsDays Pittsburgh 2020

Gartner: 12 Things to Get Right for Successful DevSecOps

1. Adapt the security testing tools and processes to the developers 2. Quit trying to eliminate all vulnerabilities during development 3. Identify and remove known open-source vulnerabilities 4. Don’t expect to use traditional dast/sast without changes 5. Train all developers on the basics of secure coding 6. Adopt a security champion model 7. Secure infrastructure with automation and infrastructure as code (IoC) 8. Implement strong version control on all code and components 9. Implement secrets management

• 10. Adopt an immutable infrastructure mindset
• 11. Rethink how service delivery incidents, including security, are handled
• 12. Use dynamic access provisioning for developers in DevSecOps

DevSecOpsDays Pittsburgh 2020

Gartner: 12 Things to Get Right for Successful DevSecOps

1. Adapt the security testing tools and processes to the developers 2. Quit trying to eliminate all vulnerabilities during development 3. Identify and remove known open-source vulnerabilities 4. Don’t expect to use traditional dast/sast without changes 5. Train all developers on the basics of secure coding 6. Adopt a security champion model 7. Secure infrastructure with automation and infrastructure as code (IoC) 8. Implement strong version control on all code and components 9. Implement secrets management

• 10. Adopt an immutable infrastructure mindset
• 11. Rethink how service delivery incidents, including security, are handled
• 12. Use dynamic access provisioning for developers in DevSecOps

This is from a Gartner report entitled 12 Things to Get Right for Successful DevSecOps, Published: 19 December 2019, ID: G00450792. That report also contains the DevSecOps diagram shown on a preceding slide.

DevSecOpsDays Pittsburgh 2020

OWASP OpenSAMM Model Overview

Governance Design Implementation Verification Operations Strategy and Metrics Threat Assessment Secure Build Architecture Assessment Incident Management Policy and Compliance Security Requirements Secure Deployment Requirements- driven Testing Environment Management Education and Guidance Security Architecture Defect Management Security Testing Operational Management

DevSecOpsDays Pittsburgh 2020

OWASP OpenSAMM Model Overview

Governance Design Implementation Verification Operations Strategy and Metrics Threat Assessment Secure Build Architecture Assessment Incident Management Policy and Compliance Security Requirements Secure Deployment Requirements- driven Testing Environment Management Education and Guidance Security Architecture Defect Management Security Testing Operational Management

This is from the open source OpenSAMM project from OWASP. See https://owasp.org/www- project-samm/ and https://owaspsamm.org/. OpenSAMM contains a lot of good advice about what to do for security, but less information on how to do it. That’s a discussion for another presentation.

DevSecOpsDays Pittsburgh 2020

Iterative Approach

Iteration

Secure Architecture Automated Repeatable Builds Capacity and Stress Testing Environment Hardening Event Rates

Iteration

Risk Modeling Software Supply Chain Analysis Static Application Security Testing Automated Infrastructure as Code Attack Surface

Iteration

Threat Assessment Container Scanning Fuzz / Chaos Testing Canary Deployments Incident Response

Iteration

• ● ●
• ● ●
• ● ●
• ● ●
• ● ●

Plan Build Test Deploy Monitor

DevSecOpsDays Pittsburgh 2020

Iterative Approach

Iteration

Secure Architecture Automated Repeatable Builds Capacity and Stress Testing Environment Hardening Event Rates

Iteration

Risk Modeling Software Supply Chain Analysis Static Application Security Testing Automated Infrastructure as Code Attack Surface

Iteration

Threat Assessment Container Scanning Fuzz / Chaos Testing Canary Deployments Incident Response

Iteration

• ● ●
• ● ●
• ● ●
• ● ●
• ● ●

Plan Build Test Deploy Monitor

My recommendation is that teams adopt an agile iterative approach. While there are lot of different security features you should add, they can be ranked and included as the product lifecycle plays out. Also, many of these security features are also excellent business features. For example, monitoring event rates is good for both security and for product management.

DevSecOpsDays Pittsburgh 2020

Application Trust

• The business value of a system cannot be realized if the system

is not trustworthy. To gain that trust information security requirements must be addressed.

• In many organizations, security features are added as

requirements in a category called “non-functional requirements”.

• This category devalues these features. Product owners and

development teams must value security aspects of the product as first-class features.

DevSecOpsDays Pittsburgh 2020

Application Trust

• The business value of a system cannot be realized if the system

is not trustworthy. To gain that trust information security requirements must be addressed.

• In many organizations, security features are added as

requirements in a category called “non-functional requirements”.

• This category devalues these features. Product owners and

development teams must value security aspects of the product as first-class features.

If a client, or user, cannot trust the system to prevent their data from being exposed, then they will likely find a different product to use. Conversely, if a product demonstrates strong security features, then clients and users will choose that system over others that are less secure.

DevSecOpsDays Pittsburgh 2020

DevSecOpsDays Pittsburgh 2020

This was the nifty break slide created during my presentation by an in-house sketch artist.

DevSecOpsDays Pittsburgh 2020

www.htcinc.com www.caretech.com www.ciber.com Headquarters

3270 West Big Beaver Road Troy, MI 48084, U.S.A Phone: 248.786.2500 Toll-free: 833-609-4950

Thank you

Reimagine technology to accelerate your business