Reduce Security Risk in
Your Development
Part III: Secure Code Review
Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA
www.rallydev.com
#SecureDev
©2013
What We’ll Cover Today
• Recap of Secure Agile Development key
topics
• How does secure code review fit in an
Agile workflow?
• Code review documentation
• Tips & Tricks
www.rallydev.com
#SecureDev
©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
Our Secure Code Review Motto
It’s not done until
it’s provably
secure.
www.rallydev.com
©2013
The Last Puzzle Piece: Code Review
www.rallydev.com
©2013
Why do we perform code review?
• Detect potential issues early
• More effective than post-completion vulnerability
testing
• One layer of defense-in-depth
• “Inside the barn” viewpoint
www.rallydev.com
©2013
What code review is and isn’t
Code review is..
• A great opportunity for
everyone to learn
• One component of a
complete secure
lifecycle strategy
• Difficult to do
consistently and well
• Essential to modern-day
development teams
www.rallydev.com
Code review isn’t..
• Foolproof
• An opportunity to
discredit your coworkers
• Personal
• A checkbox
©2013
Secure code review high-level steps
1. Review Agile Threat Map for the product
2. Review the code for the security tests relevant to
the user story/task
– Ensure the code for the tests verify both the desired
functionality, and the lack of undesired functionality (from a
security standpoint)
– Execute test code against a known noop/broken module
– Execute test code against “good” module
3. Review code repo diffs for possible areas of
weakness
www.rallydev.com
©2013
Why write/execute tests first?
• Provable security
• Builds a lifetime of security (and value!) into the
product
– Ensures future changes don’t negate security controls
• Removes significant subjectivity from secure
review process
www.rallydev.com
©2013
Reviewers: Pair programming
environment
• In pair programming environment, the pair
members can review each other’s code
• Best practice is one writes the tests, one writes
the module code
• Pairs should rotate frequently (not just for secure
code review reasons!)
www.rallydev.com
©2013
Reviewers: Non-Pair Programmers
• In non-paired programming, another qualified
coder on the team should act as the reviewer
– This is a dedicated coder, not a dedicated security
person
• If possible, qualified coder should be selected
randomly
• For extremely small teams, consider trading
review services with an external team
www.rallydev.com
©2013
Tool-assisted review
• Lots of great tools out there!
• Keep in mind that automated tools catch only a
small percentage of security vulnerabilities
• Even with a tool, you should be performing testdriven development, testing, and review by
qualified coders
www.rallydev.com
©2013
Code review pitfalls
• Don’t perform secure code review outside of iterations
– As tempting as this may be, this forms a habit that security can
be deferred
– It’s not “done” until it’s secure
• Make sure reviewers are always “fresh”
– Frequent rotation of programming pairs
– Randomized selection of non-paired reviewers
• Make sure reviewers understand what they are looking at
– If it’s just a checkbox, you’re missing the point
• Perform reviews in context
– Review Agile Threat Map before each review session
• Don’t code/excuse security workarounds
– If another layer/module is the problem, schedule a defect to fix it
rather than accept “yet another hack”
www.rallydev.com
©2013
Documenting Code Review
• Every code review step/result should be visible to
the team
– Transparency is key
• Code review documentation is important for
training and retrospectives
• No documentation of review? Wasn’t reviewed.
www.rallydev.com
©2013
Managing code review in Rally
• VIDEO HERE
www.rallydev.com
©2013
But.. But..
How do we know what to look for when
performing code review??
www.rallydev.com
©2013
Issues to watch for.. Input Validation
• Conduct all data validation on a trusted system (e.g.,
The server)
• There should be a centralized input validation routine
for the application
• Validate all client provided data before processing,
including all parameters, URLs and HTTP header
content (e.g. Cookie names and values). Be sure to
include automated post backs from JavaScript, Flash
or other embedded code
• Validate data type, range, and length
• Validate all input against a "white" list of allowed
characters, whenever possible
www.rallydev.com
©2013
Issues to watch for.. Authentication
• Require authentication for all pages/resources, except those
specifically intended to be public
• All authentication controls must be enforced on a trusted
system (e.g., The server)
• Establish and utilize standard, tested, authentication services
whenever possible
• All administrative and account management functions must be
at least as secure as the primary authentication mechanism
• If your application manages a credential store, it should ensure
that only cryptographically strong one-way salted hashes of
passwords are stored and that the table/file that stores the
passwords and keys is write-able only by the application. (Do
not use the MD5 algorithm if it can be avoided)
www.rallydev.com
©2013
Issues to watch for.. Session Mgmt
• Use the server or framework’s session management controls.
The application should only recognize these session identifiers
as valid
• Session identifier creation must always be done on a trusted
system (e.g., The server)
• Session management controls should use well vetted
algorithms that ensure sufficiently random session identifiers
• Logout functionality should fully terminate the associated
session or connection
• Disallow persistent logins and enforce periodic session
terminations, even when the session is active. Especially for
applications supporting rich network connections or connecting
to critical systems. Termination times should support business
requirements and the user should receive sufficient notification
to mitigate negative impacts.
www.rallydev.com
©2013
Issues to watch for.. Data Protection
• Implement least privilege, restrict users to only the
functionality, data and system information that is required to
perform their tasks.
• Protect all cached or temporary copies of sensitive data stored
on the server from unauthorized access and purge those
temporary working files a soon as they are no longer required.
• Encrypt highly sensitive stored information, like authentication
verification data, even on the server side. Always use well
vetted algorithms.
• Protect server-side source-code from being downloaded by a
user.
• Do not store passwords, connection strings or other sensitive
information in clear text or in any non-cryptographically secure
manner on the client side.
www.rallydev.com
©2013
Issues to watch for.. General
• Use tested and approved managed code rather than
creating new unmanaged code for common tasks.
• Utilize task specific built-in APIs to conduct operating
system tasks. Do not allow the application to issue
commands directly to the Operating System, especially
through the use of application initiated command shells.
• Protect shared variables and resources from
inappropriate concurrent access.
• Explicitly initialize all your variables and other data stores,
either during declaration or just before the first usage.
• Avoid calculation errors by understanding your
programming language's underlying representation and
how it interacts with numeric calculation.
www.rallydev.com
©2013
Issues to watch for..
• See these, and many more, great ideas of issues
to watch for in the OWASP Secure Coding
Practices Quick Reference Guide available at
https://www.owasp.org/index.php/OWASP_Secur
e_Coding_Practices_-_Quick_Reference_Guide
www.rallydev.com
©2013
Quick recap
• Secure code review should be grounded in:
– 1. Agile Threat Map
– 2. Test Driven Development
• Code reviewers always need to be FRESH and
CAPABLE
• Results of code review should always be
documented, even if “no issues”
• Need ideas what to look for? Use available
resources such as OWASP for ideas.
www.rallydev.com
©2013
Questions?
Contact me:
trent@appliedtrust.com
Twitter: @trenthein
www.rallydev.com
#SecureDev
©2013
Sign-up: www.rallydev.com/agilewebinars
www.rallydev.com
©2013
Go Agile. Go Rally.
www.rallydev.com
#SecureDev
©2013