Reduce Security Risk in
Your Development
Part II: Creating an Agile SSDLC
Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA
www.rallydev.com
#SecureDev
©2013
What We’ll Cover Today
• How is secure Agile development
different?
• Creating a User Story with integrated
security
• Security Tasks and Testing
• Managing security Defects
• Security architecture
• Agile Threat Map
www.rallydev.com
#SecureDev
©2013
Quick Recap of Session 1
•
Information security overview
•
What are the most common threats?
•
How to protect sensitive data, both from a
methodology and technology standpoint
•
Standards and tools
–
www.rallydev.com
NIST SP 800-53A, OpenSAMM, OWASP
©2013
How is Secure Agile Development Different?
Agile
Traditional /
Waterfall
• Distinct security-focused
project phases, often at
beginning and end of
project
• Security skills brought in
from outside project,
often disconnected from
dev/test resources
• Specific security testing
phase, often at end of
project.
www.rallydev.com
Security
Timing
• Every iteration considers
security, but is not
limited by it.
Security
Resources
• Every team member is
responsible for security.
Security skills are
embedded in the team.
Security
Validation
• Hybrid security and
functionality testing,
throughout project.
©2013
Secure Agile Development
Guiding Principles
• Product value improves with security.
• Security is integral to the product, not an
afterthought.
• Outside security resources (standards, threats,
experts) provide background, not a cage.
www.rallydev.com
©2013
Agile security myths - 1
• Myth: I’m a developer / product
owner / scrum master. Security
is someone else’s job.
– Reality: The complex threats
facing applications today requires
everyone to be thinking about
security.
–Secure business logic
–Secure coding practices
–Secure test methods
–Secure data architecture
–Secure deployment environment
www.rallydev.com
©2013
Agile security myths - 2
• Myth: Compliance with an
Information Security Standard
isn’t Agile
– Reality: Compliance with an
Information Security Standard,
such as NIST SP 800-53A, is
actually easier in an Agile
environment, because “baking in”
security in smaller pieces allows
for simple compliance test cases
and less backtracking
www.rallydev.com
©2013
Secure User Stories
• The #1 tenet of secure Agile development is to
“bake” security into every user story
• Remember: Stories should be defined such that the
lowest level child story can be implemented and
accepted in a single iteration
– Any security component(s) of the story, therefore, must be
lightweight
– What is the most basic security functionality required for
the story to be compliant?
– Don’t let security define the user story. Let the user story
define the security.
www.rallydev.com
©2013
Great, Secure User Stories
(from Write a Great User Story, by Ronica Roth)
www.rallydev.com
©2013
VIDEO DEMO 1
• VIDEO DEMO – Creating a great user story with
security elements included in Acceptance Criteria
and Definition of Done
www.rallydev.com
©2013
Secure User Story DON’Ts
• DON’T change the user story template
“As a <user type>, I want to <function> so that <benefit>”
NOT “As a <user type>, I want to <function> so that
<benefit> and <yadda yadda yadda security drivel here>”
• DON’T create “Security Epics”
• DON’T assign secure user story creation to “the
security guy/gal”
• DON’T put technical security tasks in the user story
itself.
www.rallydev.com
©2013
Security Tasks
• For each user story, the Developer should create
tasks necessary to meet security acceptance
criteria
• Developer should also detail any security testing
tasks, as part of defining all the testing tasks for
the story
• Security review may also be added as a task,
assigned to a security specialist
www.rallydev.com
©2013
VIDEO DEMO 2
• VIDEO DEMO – Adding security related tasks
and testing to a user story
www.rallydev.com
©2013
Security Defects
• Security defects may be identified
– As part of iteration testing
– After product deployment
• Tagging security defects makes them easier to
identify and prioritize
• Once defined, security defects are managed
along with other defects as part of iteration
acceptance and scheduling
www.rallydev.com
©2013
VIDEO DEMO 3
• VIDEO DEMO – Security defect management
www.rallydev.com
©2013
Security Architecture
From The Principles of Agile Architecture by
Alex Yakyma and Dean Leffingwell, with contributions from Ryan Martens and Mauricio Zamora
www.rallydev.com
©2013
Security Architecture
[..] in the context of secure Agile enterprise software
systems, we need both: fast, local control of emergent
design so that teams react appropriately to changing
security requirements without excessive attempts to
future risk proof the system, and global control of
Intentional Architecture, the guidance needed to
assure that the system as a whole has conceptual
integrity and efficacy security. Achieving the right
balance of emergent design and intentional
architecture drives effective secure evolution of the
system [..]
From The Principles of Agile Architecture by
Alex Yakyma and Dean Leffingwell, with contributions from Ryan Martens and Mauricio Zamora
www.rallydev.com
©2013
Agile Threat Mapping
• Assessment of key threats to business value,
process, or data set
• Tied to real-world, known threats – not
“theoretical”
• Communicated to all team members
• Completed by team, not by “security guy/gal”
www.rallydev.com
©2013
Agile Threat Mapping Template
<Business Value>
or
<Business Process>
or
<Data Set>
•
•
•
•
•
•
<Business Value>
or
<Business Process>
or
<Data Set>
Confidentiality: (High,
Med, Low)
Integrity: (High, Med,
Low)
Availability: (High,
Med, Low)
•
A1 – Injection
A3 – Cross-site
Scripting
A6 – Sensitive Data
Exposure
•
•
www.rallydev.com
•
•
•
<Business Value>
or
<Business Process>
or
<Data Set>
Confidentiality: (High,
Med, Low)
Integrity: (High, Med,
Low)
Availability: (High,
Med, Low)
•
A1 – Injection
A3 – Cross-site
Scripting
A6 – Sensitive Data
Exposure
•
•
•
•
•
<Business Value>
or
<Business Process>
or
<Data Set>
Confidentiality: (High,
Med, Low)
Integrity: (High, Med,
Low)
Availability: (High,
Med, Low)
•
A1 – Injection
A3 – Cross-site
Scripting
A6 – Sensitive Data
Exposure
•
•
•
•
•
Confidentiality: (High,
Med, Low)
Integrity: (High, Med,
Low)
Availability: (High,
Med, Low)
A1 – Injection
A3 – Cross-site
Scripting
A6 – Sensitive Data
Exposure
©2013
Checking Our Work
www.rallydev.com
©2013
Questions?
Contact me:
trent@appliedtrust.com
Twitter: @trenthein
www.rallydev.com
#SecureDev
©2013
Up Next:
Agile Secure Code Review
July 24th | 10am ET
Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA
www.rallydev.com
#SecureDev
©2013
Go Agile. Go Rally.
www.rallydev.com
#SecureDev
©2013