According to SAP 85% of cybersecurity attacks target the application layer. To be successful in defending against these attacks you need to use a variety of tools. In session we'll go into the various types application security tools and approaches, including SAST, DAST, RASP, PEN, as well as Open Source Vulnerability Management. We'll help you understand the differences between these tools and help you develop a plan for filling your application security toolbox.

1. Filling your AppSec Toolbox
Which Tools, When to
Use Them, and Why

2. Where Do I Start?
WAF
Fuzzing IAST
Pen
Testing
DAST
SAST
RASP
Architecture
Risk
Analysis
Threat
Modeling
Training

3. WEB APPLICATION VULNERABILITIES XSS AND SQL INJECTION EXPLOITATIONS
XSS AND SQL INJECTION EXPLOITS ARE
CONTINUING IN HIGH NUMBERS
Source: IBM X-Force Threat Intelligence Quarterly, 2014Source: IBM X-Force Threat Intelligence Quarterly, 2014
25%
20%
15%
10%
5%
0%
2009 2010 2011 2012 2013
WEB APPLICATION
VULNERABILITIES
33% OF VULNERABILITY DISCLOSURES ARE WEB
APPLICATION VULNERABILITIES
33%
Applications - The Weakest Link in the IT Security Chain

4. Attack types XSS Heart-
bleed
Physical
access
Brute
force
Misconfig
.
Watering
hole
Phishing SQLi DDoS Malware Un-
disclosed
January February March April May June July August September October November December
SQL Injection - Still Reliable For Breaching Applications
Source: IBM X-Force Threat Intelligence Quarterly 1Q
2015
SAMPLING OF
2014 ATTACKS
SQL injection accounted for
8.4% of attacks in 2014.
Source: IBM X-Force Threat Intelligence
Quarterly 1Q 2015

5. Investment Priority - “Security Risks” vs. Your “Spend”
MANY CLIENTS DO NOT PRIORITIZE APPLICATION SECURITY IN THEIR ENVIRONMENTS
35%
30%
25%
20%
15%
10%
5%
APPLICATION
LAYER
DATA
LAYER
NETWORK
LAYER
HUMAN
LAYER
HOST
LAYER
PHYSICAL
LAYER
SECURITY RISK
SPENDING
SPENDING DOES
NOT EQUAL RISK
Source: The State of Risk-Based Security Management, Research Study by Ponemon Institute, 2013

6. Application Security Goal: Build Security In
Earlier Visibility to Vulnerabilities Pays Dividends

7. Application Security Goal: Move “Left” in the SDLC
Analyze Design Implement Test Maintain
1x
6.5x
15x
100x
Source: IBM Systems Sciences Institute
Earlier Visibility to Vulnerabilities Pays Dividends

8. Tools

9. Static Analysis (SAST)
Inside Out View
• Testing of source code or binaries for unknown security vulnerabilities in custom code
• Advantages in buffer overflow, some types of SQL injection
• Provides results in source code
SDLC Ecosystem
Analyze Design Implement Test Maintain
Static Analysis
When Used
• First builds
• Continuous in Agile
Environment
1x
6.5x
15x
100x

10. Dynamic Analysis (DAST)
Outside In View
• Testing of compiled application in a staging environment to detect unknown security
vulnerabilities in custom code
• Advantages in injection errors, XSS
• Provides results by URL, must be traced to source
SDLC Ecosystem
Analyze Design Implement Test Maintain
1x
6.5x
15x
100x
When Used
• Pre-deployment
• Staging environment
required
Dynamic Analysis

11. Interactive Security Testing (IAST)
Outside In – with Benefits
• Runtime analysis
• Instruments the application to monitor behavior during attack
SDLC Ecosystem
Analyze Design Implement Test Maintain
1x
6.5x
15x
100x
When Used
• QA testing
• Continuous in Agile
IAST

12. Open Source Vulnerability Management
Identifies all open source to the version level, at any stage of the SDL
Provides information on associated risk
• License Risk
• Security Risk
• Operational Risk
When Used
• Design
• First commit
• Continuous monitoring
SDLC Ecosystem
Analyze Design Implement Test Maintain
1x
6.5x
15x
100x
Open Source Selection Detection and Notification

13. Challenges

14. GROWING ATTACK
SURFACE
NEW DEPLOYMENT
MODELS
Web, Mobile, Cloud, IoT
Containers, IT and Small
Security Teams
• Which apps are people using?
• How do I set internal policy
requirements for app security?
• Is my private / sensitive data
exposed by apps?
• Who is developing the apps?
• How do we prioritize the work
for the resources I have?
• What do we test and how do we
test it?
• How do we staff and improve
skills and awareness?
OPEN SOURCE
Increasing Portion of Code Base
• What policies are in place for
open source use?
• How are those policies
enforced?
• Who is tracking usage for new
vulnerabilities
14
Software Security Challenges

15. Changing Attack Surface
Web applications
Cloud applications and services
IoT
15
“If perimeter control is to
remain the paradigm of
cybersecurity, then the
number of perimeters to
defend in the Internet of
Things is doubling every
17 months.”
Dan Geer | RSA 2015

16. Containers can be vulnerable by
virtue of the code that runs inside
them
• OSS components running inside
containers represent potential
attack vectors
• Could cause problems for the
application itself
• Could cause more problems if
the container is running with the
–privileged flag set
Containers and DevOps

17. OPEN SOURCE EMBRACED BY THE ENTEROPEN SOURCE EMBRACED BY THE ENTERPRISE
OPEN SOURCE
• Needed functionality without
acquisition costs
• Faster time to market
• Lower development costs
• Broad support from communities
CUSTOM CODE
• Proprietary functionality
• Core enterprise IP
• Competitive differentiation
CUSTOM CODE
OPEN SOURCE

18. Recommendations

19. Initial Recommendations
Build Security In
• Don’t “bolt on” security after building software
Move left in the SDLC
• Involve security as early as possible
Measure everything you can
• Baseline allows you to track performance

20. The Right Tools for the Right Code
Security Requirements, Threat Modeling prior to coding
Static and Dynamic Analysis for Custom Code
Black Duck for Open Source
• Preproduction
• SDLC
• Continuous Monitoring
CUSTOM CODE
• SAST
• DAST
• IASTOPEN SOURCE
• Black Duck

21. The Right Tool at the Right Time
SDLC Ecosystem
Analyze Design Implement Test Maintain
Security Intelligence (including data sources)
Open Source Selection Detection and Notification
IAST
Dynamic Analysis
Static Analysis
SIEM
Vulnerability
Assessment

22. New Integrated and Secure Development Lifecycle
OSS Security
Requirements
OSS Risk Assessment
Guided OSS Selection
OSS Review Board
Broad coverage of
Open Source code
& snippets
Application Criticality
Ranking
OSS Controls
• Implement Open
Source Security
Controls
• Non-compliantOSS
Identification&
Reporting
• Correlationwith Bills
of Material
OSS Enforcement
Timely OSS
Vulnerability
Identification &
Reporting
Bug Severity
Remediation Advice
Correlation with Bills
of Material
Vulnerability
Monitoring
• Timely Vulnerability
Identification &
Reporting
• Remediation &
Mitigation Advice
Establish Security
Requirements
Create Quality Gates
Risk Assessments
Establish Design
Requirements
Analyze AttackSurface
Threat Modeling
Use Approved Tools
Deprecate Unsafe
Functions
Static Analysis
Dynamic Analysis
Fuzz Testing
Attack Surface Review
Incident Response
Plan
Final Security Review
Release Archive
REQUIREMENTS DESIGN BUILD TEST RELEASE
OPEN SOURCE
CUSTOM CODE

23. INTEGRATED
APPLICATION
SECURITY

24. Binary Repository Management
(Artifactory / Nexus)
Developers / IDE
(Eclipse)
Deployment Environments (Amazon /
Docker / VMWare / Openstack)
Continuous Integration Server
(Jenkins / TeamCity / Bamboo)
Test Automation Tools
(Selenium / JUnit)
Quality Management Tools
Bug Tracking Tools
Source Control Management (Git, CVS /
Subversion / Perforce)
Build Tools (Maven / Bundler)
Continuous Integration Environment
DAST / IAST
SAST / OSS
Bug Tracking
Integration
OSS
IDE integration

25. Custom Code Vulnerabilities
CUSTOM CODE VULNERABILITIES

26. Open Source Vulnerabilities – Black Duck

27. OPEN SOURCE VULNERABILITIES
Open Source Vulnerabilities

28. Holistic View – Custom and Open Source

29. Application development ecosystem is changing
• Open source provides increasing large foundation for custom
code.
Open source is here to stay (and growing)
• Saves development costs and accelerates time to market.
New paradigm requires new methodologies
• Best practices for custom code continues to require automated
testing.
• Best practices of open source requires full visibility and continuous
monitoring.
Key Takeaways

30. Q&A