1. Reduce Security Risk in Your Development
Part III: Secure Code Review
Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA
#SecureDev

2. 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
#SecureDev

3. How is Secure Agile Development Different?
Traditional / Waterfall
Agile
Security Timing
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.
Every iteration considers security, but is not limited by it.
Every team member is responsible for security. Security skills are embedded in the team.
Hybrid security and functionality testing, throughout project.
Security Resources
Security Validation

4. 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.

5. Our Secure Code Review Motto
It’s not done until it’s provably secure.

6. The Last Puzzle Piece: Code Review

7. 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

8. What code review is and isn’t
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
Code review isn’t..
Foolproof
An opportunity to discredit your co-workers
Personal
A checkbox

9. Secure code review high-level steps
Review Agile Threat Map for the product
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
Review code repo diffs for possible areas of weakness

10. 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

11. 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!)

12. 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

13. 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 test-driven development, testing, and review by qualified coders

14. 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”

15. 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.

16. Managing code review in Rally
VIDEO HERE

17. But.. But..
How do we know what to look for when performing code review??

18. 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

19. 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)

20. 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.

21. 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.

22. 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.

23. 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

24. 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.

25. Contact me: trent@appliedtrust.com Twitter: @trenthein
Questions?
Contact me:
#SecureDev

26. Sign-up: www.rallydev.com/agilewebinars

27. Go Agile. Go Rally.
#SecureDev