Integrating security into Continuous Delivery

Integrating Security
into Continuous
Delivery
Thomas Stiehm, CTO
tom.stiehm@coveros.com

© Copyright 2012 Coveros, Inc.. All rights reserved. 1

About Coveros

 Coveros helps organizations accelerate the delivery of
business value through secure, reliable software


SecureAgileTM Development Process
adaptability
transparency
Agility is…
simplicity
STRATEGY roadmap
funding
unity
goals

vision RELEASE secure
estimation
release plan

backlog
risk ITERATION
threat review
analysis Iteration plan retrospective
burndown model
secure DAILY regression
pen defensive
code standup
testing coding I
review
design CONTINUOUS
velocity TDD collaboration
security refactoring integration
stories testing

secure testing
burnup
tests risk
Working software

Assures time-to-market while achieving security objectives

SecureAgileTM Security Practices

 Threat Modeling
 Risk Analysis
 Pen Testing
 Security Stories
 Secure Code Review
 Defensive Coding and Design
 Secure Testing
– Static Code Analysis
– Automated Security Testing


Threat Modeling

 Threat modeling is the process of defining a system’s attack
surface to support application risk assessments and to determine
appropriate security controls. This includes assets that may be
compromised and vulnerabilities that can be used to attack the
system.
Enabler

SQL
Commands
Process SQL
Input Database Target

Form in
XML
Enabler
User Input
ID=48983 SQL Injection
Classic Attack Surface Example
Figure Source: Carnegie Mellon University
Figure Source: Carnegie Mellon University © Copyright 2012 Coveros, Inc.. All rights reserved. 5

Risk Analysis

 Identify areas of risk in the system, including:
– Requirements
– Design
– Architecture
 Use abuse cases to drive risk based testing
 Build scenarios based on identified risks
 Use risk scenarios to drive security
requirements
 Test risk conditions explicitly


Pen Testing

 Penetration Testing or Pen Testing, is the
process of attacking a system like a
malicious outsider in order to evaluate the
security of the system
 Perform penetration testing for risks
uncovered throughout the lifecycle
 Penetration testing is not a substitute for
automated secure code review


Security Stories

 Why write Security Stories?
– To make sure all explicit security requirements,
both functional and non-functional, are
documented and can be used to guide secure
development and testing activities

 Develop misuse and abuse cases that capture non-
normative behavior (attacks) according to your
threat model
 Think like a potential attacker and use your
knowledge of the system architecture and risks
 Drive test plans from the abuse cases
 Also write functional security stories

Misuse / Abuse Case Development

 Purpose: Define the possible mechanisms an adversary
might exploit to compromise your system

 Approach:
 “User shall not …” pattern
– Misuse cases are extensions to stories that highlight
ways in which the system might be misused accidentally
– Abuse cases are extensions to stories that highlight
ways in which the system might be abused on purpose

 Results:
– Insight into potential abuses that can be avoided and
tested


Defensive Design

 Software is designed to be secure through:
– Identification and integration of security controls
based upon the threat model
– Use of security protection mechanisms for software
startup, reboot, and shutdown procedures
– Appropriate and comprehensive error and
exception handling of all critical functions
– Use of code libraries that have been vetted for
security
– Use of off-the-shelf components for encryption,
random number generation, and other complex
mathematical calculations


Defensive Coding

 Secure coding is done through:
– Avoiding known dangerous coding constructs,
system calls and programming short cuts
– Continued security scans of new code at each
check-in
– Proper integration and testing of secure design
features


Secure Testing

 There are a variety of testing types that must be
performed during agile development iterations to
assure application security
– Functional security testing – testing the capabilities and
integration of security controls into the application
– Non-functional security testing – testing against the
misuse and abuse cases developed during story
creation
– Risk-based testing – testing the application against the
identified threats within the threat model
 Automation is required for continuous security
testing
 Leverage security testing tools, either Open Source
or Commercial tools

Secure Code Review

 Start with automated secure code review tools to
find known issues and pinpoint areas in the code to
review manually
 Review sections of the code manually, focus on
areas that the automated tools found to contain a
lot of issues, bugs cluster
 Real-time secure code review can be done as part
of pair programming
 Train developers how to do secure code reviews
 Automated security analyzers should be run as part
of a continuous integration process to identify
known coding weaknesses during all builds


Why Integrate Application Security into CD?

 To make your application more secure
 To reduce the cost of Application Security
 To increase the overall quality of your code
base
 To protect your application from attackers
 To demonstrate compliance with security
requirements
 To make yourself a hero


Why Application Security is Difficult

 Security is an aspect of an application, it isn’t
an application feature.
 No Product Owner will ever pick security
over application features
 Most developers aren’t security experts, very
few are even application security aware,
most discount security threats or
consequences
 Implementing Application Security processes
can be expensive, both in terms of cost to
acquire commercial applications and the cost
of implementing and maintaining

Maturity Model for Security Testing

 Level 0: No Security Testing
 Level 1: Unit Testing and Static Analysis
 Level 2: Automated Deploys and Functional
Testing
 Level 3: Automated security testing using
scanners and proxies
 Level 4: Automated Configuration
Management
 Level 5: Continuous Delivery


What Static Analysis Does

 Finds potential defects or flaws in an
application by analyzing the application
source code
 All code can be analyzed include:
– Java/C#/C/C++/PHP/Etc.
– SQL
– JavaScript
– XML
– Most languages used by Enterprise
Developers
– Remember: Context Matters

What Static Analysis Finds

 Static Analysis can find:
– Common errors
– Unused variables
– SQL injection
– Cross-Site Scripting (XSS)
– Hard-coded passwords
– I.E. Things we know about
 Static Analysis can’t find:
– Zero Day Vulnerabilities
– Architectural Flaws
– Things we don’t know about

Static Analysis Tools

 Static Analysis:
– Open Source
 Sonar for many languages
 PMD for Java
 FindBugs for Java
 PHPMD for PHP
 FxCop for .Net
 PyChecker for Python
 pylint for Python
– Commercial
 Coverity
 Fortify
 Built into Visual Studio Ultimate
 Audit Static Analysis Findings

Scanner
 Web application scanners:
– Open Source
 w3af
 wapiti
 Skipfish
– Commercial
 AppScan
 Cenzic Hailstorm
 WebInspect
 Complete system scans
 OpenVAS
 Nmap
 Nikto2
 Nessus
 Audit scanner findings

Proxies

 Proxies:
– Better coverage
– XSS and Cross-Site Request Forgery
(XSRF)
– Data leakage
– URLs for logs to augment spidering
– Web application proxies:
 OWASP Zed Attack Proxy (ZAP)
Project
 OWASP WebScarab
 Ratproxy

Open Source vs. Commercial

 There are advantages and disadvantages of both
 Open Source Advantage:
– Free to acquire
– Often has a community around it
 Open Source Disadvantage:
– Limit free support (requires more experienced users)
 Commercial Advantage:
– Often better reporting tools (including more help and
vulnerability explanations, better for less experienced
users)
– Paid Support (someone to blame for issues)
 Commercial Disadvantages:
– Limited community
– Cost $$

Issues in CD

 Some security testing tools can take a long,
long time to run
– Ex. A 2 million line of code Java application can
take 12-24 hours to complete a Fortify scan
 So plan for some security testing to happen
outside of the 15 minute build CI schedule
 Expect push back when you implement this
from:
– Developers
– Product Owners
– Your Management
– Your Security Group

Security Finding Remediation

 Create a Remediation Plan (POA&M)
 Include scope of remediation:
– All issues vs. Critical and High
– Time frame for remediation
 Expect Development push bask:
– That is the way it works
– We don’t have time for that
– It is open source, we can’t fix it officially
 Security Office Negotiation
 Remediation can take a really long time


Implementing Agile Application Security

 Adopt and use an application security process from the
beginning of the project
 Create application security requirements with the functional
application requirements
 Lead the security requirements process, sell the value of
good security practices to the business
 Development teams need software security training, early
 Security practices needs to be burned-in and made part of
how the team works
 Security work should be done by experienced, technically
strong developers
 Create application security standards and practices, monitor
compliance with the standards
 Put security controls into your base software architecture

Implementing Agile Application Security

 Use security tools such as static code analysis and web
scanners to verify security controls
 Conducting manual security verification like code reviews
and penetration testing
 Use outside security testers to break the system and look
for holes
 Problems found in security testing need to be added the
team’s backlog
 Security tests don’t always fit in time boxes so, if needed,
run them as parallel engagements
 Consider a “hardening sprint” to focus on fixing the security
problems found through security testing


Thank You


Supplemental Material


Vulnerabilities

 OWASP Top Ten:
– https://www.owasp.org/index.php/Top_10_2010

 2011 CWE/SANS Top 25 Most Dangerous Software
Errors
– http://cwe.mitre.org/top25/

 There is a lot of overlap as there are major
categories that generate a lot of vulnerabilities
 For Example:
– Injection Attacks and
– Misconfigurations


Integrating security into Continuous Delivery

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Integrating security into Continuous Delivery

Similar a Integrating security into Continuous Delivery (20)

Más de Tom Stiehm

Más de Tom Stiehm (8)

Último

Último (20)

Integrating security into Continuous Delivery

Notas del editor