In the ever-evolving, fast-paced Agile development world, application security has not scaled well. Incorporating application security and testing into the current development process is difficult, leading to incomplete tooling or unorthodox stoppages due to the required manual security assessments. Development teams are working with a backlog of stories—stories that are typically focused on features and functionality instead of security. Traditionally, security was viewed as a prevention of progress, but there are ways to incorporate security activities without hindering development. There are many types of security activities you can bake into your current development lifecycles—tooling, assessments, stories, scrums, iterative reviews, repo and bug tracking integrations—every organization has a unique solution and there are positives and negatives to each of them. In this slide deck, we go through the various solutions to help build security into the development process.
Breaking the Kubernetes Kill Chain: Host Path Mount
AppSec in an Agile World
1. AppSec in an
Agile World
Wednesday, May 16
11:00AM
2018 Secure360 Twin Cities
@secure360 www.Secure360.orgfacebook.com/secure360
David Lindner
2. Who is this guy?
class Speaker {
let name = “David Lindner”
let title = “Chief Strategy Officer”
let company = ”nVisium"
let twitter = “@golfhackerdave”
var hobbies = [“Dadding”, ”Golf”,
“IoT/Mobile”, “Fishing”]
}
3. • Dev Types
• Security and the SDLC
• Integrating AppSec into Process
Agenda
4. • Need for executive level support
• Need for a program with governance, people, process, and tools
• Collaborative relationships between teams
• Authentication/Authorization, Input handing, crypto, logging…
• Need for Threat Models, Secure Design, etc.
• Still write code, for the most part…
What hasn’t changed
5. • Architecture patterns
• Development methodologies have changed
• The speed of development/deployment
• The need for tooling and automation has greatly increased
• The infrastructure that applications live on
• Who is responsible for the infrastructure
What has changed
6. The Changing State of Development
Waterfall Agile DevOps
Monolithic Apps
Physical Bare Metal Physical Bare Metal
VMs
Containers Public/Private
N-Tier Apps Microservices & APIs
8. • After development
• Usually perform yearly assessments
• Standalone tools
• Manual assessments
• Time consuming
• No real understanding of current security
posture
Waterfall and Application Security
10. • Early 1990s referred to as ”the application
development crisis”
• Time between business need and application was
about 3 years
• Snowbird meeting in Utah in 2001
• The Agile Manifesto
Agile Development
11. • Many different methodologies
• Extreme Programming (XP)
• Scrum
• Crystal
• Dynamic Systems Development Method (DSDM)
• Lean Development
• Feature-Driven Development (FDD)
• And more….
Agile Methodologies
17. Systems used to look like this
Client (Web
Browser)
Web
Application +
Apache
Tomcat
Database
Monolithic
18.
19. • Authentication
• Username
• Password, MFA
• Account Management
• Authorization
• Role-Based Access Control
• Attribute-Based Access Control
• Rule-Based Access Control
• Input Handling
• Test input for type, length, context
• Output encode contextually
• Privacy
• Need to know access to customer/client data
• Cryptography
• Standard algorithms, strengths, and modes
• What data to encrypt at rest/in transit
• Third-party libraries
• Maintain list of 3rd party dependencies
• Monitor updates to known dependencies
• Logging/Audit
• Standard format
• Criteria for what to/not to log and when
• Criteria for who should review and when
• Error and Exception Handling
• Criteria for error messages (include/not
include)
• When to fail open/closed
Security Standards should be technology agnostic. They should be fairly static, however, if
vulnerabilities are found without a matching standard, consider updating them.
Security Standards
20. • Understand the inherent risk of an application
• Prioritize resources and security investments
• Gain a better understanding of the risk presented by the applications
• Process for completion and maintenance of application catalog
• Inherent Risk
“…is an assessed level of raw or untreated risk; that is, the natural level of risk inherent
in a process or activity without doing anything to reduce the likelihood or mitigate the severity of a
mishap, or the amount of risk before the application of the risk reduction effects of controls.”
Gregory Monahan (2008). Enterprise Risk Management: A Methodology for Achieving Strategic Objectives. John Wiley & Sons.
• 20-25 Question survey to measure:
• People
• Process
• Infrastructure
• Data
Application Risk Categorization
21. • Least-Privilege
• Default-Deny
• Economy of Mechanism
• Complete Mediation
• Open Design
• Separation of Concern
• Least Common Mechanism
• Psychological Acceptability
• Defense-in-Depth
• And more…
Secure Design Principles
Resources:
OWASP Security by Design Principles
https://www.owasp.org/index.php/Security_by_Design_Principles
IEEE Avoiding Common Security Design Flaws
http://www.computer.org/cms/CYBSI/docs/Top-10-Flaws.pdf
23. • Scoping and Rules of Engagement
• In scope and out of scope targets
• Contact information
• Debriefing schedule
Scoping and
Rules of
Engagement
Pre-
engagement
and Recon
Vulnerability
Analysis
Exploitation
and Post
Exploitation
Reporting
Testing and Verification
24. • Pre-engagement and Recon
• Black box or white box?
• Permission to test all in scope targets?
• OSINT and Recon
Testing and Verification
Scoping and
Rules of
Engagement
Pre-
engagement
and Recon
Vulnerability
Analysis
Exploitation
and Post
Exploitation
Reporting
25. • Vulnerability Analysis
• Tools
• Manual discovery
Testing and Verification
Scoping and
Rules of
Engagement
Pre-
engagement
and Recon
Vulnerability
Analysis
Exploitation
and Post
Exploitation
Reporting
26. • Exploitation and Post Exploitation
• Create or recreate any exploits
• Document exploits
• Perform agreed upon level of post exploit activities
• Clean up exploit data
Testing and Verification
Scoping and
Rules of
Engagement
Pre-
engagement
and Recon
Vulnerability
Analysis
Exploitation
and Post
Exploitation
Reporting
27. • Reporting
• When and how long was the testing
• What process was followed
• What was found and what are the risk levels
• How can issues be recreated
• How can issues be fixed
Testing and Verification
Scoping and
Rules of
Engagement
Pre-
engagement
and Recon
Vulnerability
Analysis
Exploitation
and Post
Exploitation
Reporting
28. • Do you know what code is in your applications and who put it there
and when?
• Intentional malicious code
• Unintentional malicious code
• Open Source with unfriendly licensing
• Dependency Squatting
• Embarrassed Developer
Software Integrity
29. • Git
• Build a process to review with pull requests
• Restrict access to the Master branch (If not
Github, make the Git repo only writeable by
one user, and make it readable by all
others. That way they can fork and issue a
PR to the master.)
• Provide reviewers with review baseline
• Sign commits with PGP
• Ensure that all users are only internal
accounts
• If using GitHub, ensure that SSH keys are
not shared across accounts.
• Standard Review Baseline
• Develop a baseline to review commits
• Certain functions, keywords, size
• Initially not all commits would need to
be reviewed
• Automate many checks in later
phases
• Code Signing
• Verify code is what it should be
• Verifiable update mechanism
• Do you check for signature?
• Hash?
Software Integrity Examples
33. • So we have all these security practices….
• How do we go from Waterfall AppSec to a
more continuous security model?
• Tools are only so good
• False Positives
• Can’t handle assessing Access Control or
Environmental controls
• Manual is normally slow and a hindrance
What’s Next?
37. Discovery
• Review what you have, what you want to do,
what tools work best for you
• Make it an interactive process with artifact
reviews, face to face conversations, white
boarding
39. Implement Automation
• Use CI triggers to determine when scanning
activity is required
• Work with development teams to implement
unit-tests in the language or testing framework
already in use
• Determine how best to utilize messaging
services, notify the security teams as to when
scans begin and when the results should be
reviewed
41. Determine Risk and Actions
Risk Rating Testing Method Action Taken
High, Medium, Low Unit-Tests (All
environments)
Failing unit-tests should mean that code will not be
deployed until all the unit-tests pass, whether or not the
unit-test fails because it is broken or because the
application is vulnerable.
High, Medium Dynamic Scanning -
Production Env
Code should not enter production. The security team
should be notified immediately.
Low Dynamic Scanning -
Production Env
Remediation should be prioritized by an agreed timeline
between the security team and product managers.
High, Medium, Low Dynamic Scanning -
Alpha Env
Unless the vulnerability is a known false positive or an
issue that the security team has accepted as a necessary
risk, the code triggering new issues should be resolved
prior to moving any further in the development pipeline.
42. Security Implementation
• Integrate security testing into automation
• Create a system with early detection and efficient remediation
of security vulnerabilities that are part of the development
process
• Eliminate existing duplicate dependencies in order to de-
duplicate outstanding tickets and updated outstanding tickets
in JIRA.
43. • Current security issues
• With details
• Fixed issues
• New threats
• All tracked in bug tracker
Issue Tracking
45. OLD SDLC and Security Process
The old way to do it was to have a separate SDLC and security process with different
tracking systems. Who still does this?
UX
Workflow
Design
Coding
Testing
QA
SDLC
Bug Tracker
Report
Scope
Recon
Analyze
Exploit
Document
Security
Security Issues Tracker
46. • What is your application’s current security
posture?
• What is current? 1 year? 1 month? 1 day?
Current Security Posture?
47. • Scrum
• Analysis
• Planning
• Design
• Coding
• Testing
• Releases
NEW Secure SDLC Process
Integrate security into a defined process, don’t attempt to create a parallel security
process. Many activities within the SDLC process simply need to be done with a security
mindset, checklist, guide, or similar support.
Business Analysis
Define User
Stories
Refine
Feature List
-Business Requirements
-User Requirements
-Estimate
-Scoping
Sprint Planning Meeting
Daily Work
Sprint Review
UX
Workflow
Design
Coding
Testing
QA
SDLC
Threat Modeling
Secure Design Principles
IDE Tooling
Security Automation
Change Management
Defect Tracker
48. • What is your application’s current security
posture?
• What is current? 1 year? 1 month? 1 day?
Current Security Posture?
51. Process Integration
Integrate into the processes and existing workflows.
If they don’t exist, help create them.
Design
Design
Review
Code
Review
Test
Deploy
53. What did we learn?
• Application Security is hard, but we need to keep trying
• There is no easy button or one stop shop for everything you
may need
• Every org has different needs and requirements
• We all need to work together