We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byRegina Haddaway
Modified about 1 year ago
www.rallydev.com ©2013 Reduce Security Risk in Your Development Part III: Secure Code Review #SecureDev Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA
www.rallydev.com ©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 #SecureDev
www.rallydev.com ©2013 How is Secure Agile Development Different? 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. Agile Traditional/ Waterfall 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 Timing Security Resources Security Validation
www.rallydev.com ©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 Code review isn’t.. Foolproof An opportunity to discredit your co- workers Personal A checkbox
www.rallydev.com ©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 test- driven 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.. How do we know what to look for when performing code review??
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: firstname.lastname@example.org Twitter: @trenthein #SecureDev
www.rallydev.com ©2013 Sign-up : www.rallydev.com/ agilewebinars
www.rallydev.com ©2013 Go Agile. Go Rally. #SecureDev
©2013 Reduce Security Risk in Your Development Part II: Creating an Agile SSDLC #SecureDev Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA.
It’s always better live. MSDN Events Security Best Practices Part 2 of 2 Reducing Vulnerabilities using Visual Studio 2008.
Designing Security In Web Applications Andrew Tomkowiak 10/8/2013 UW-Platteville Software Engineering Department
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
ASP.NET 2.0 Security Alex Mackman CM Group Ltd
Chapter 6: Hostile Code Guide to Computer Network Security.
Information Networking Security and Assurance Lab National Chung Cheng University 1 Top Vulnerabilities in Web Applications (I) Unvalidated Input: Information.
SEC835 Runtime authentication Secure session management Secure use of cryptomaterials.
Martin Kruliš by Martin Kruliš (v1.0)1.
Jun 12, 20081/14 A Security Review Process for Existing Software Applications DRAFT Gabriele Garzoglio Computing Division, Fermilab.
INFORMATION ASSURANCE POLICY. Information Assurance Information operations that protect and defend information and information systems by ensuring their.
PHP: Further Skills 02 By Trevor Adams. Topics covered Persistence What is it? Why do we need it? Basic Persistence Hidden form fields Query strings Cookies.
Design Principles and Common Security Related Programming Problems.
By Ramesh Mannava. Overview Introduction 10 secure software engineering topics Agile development with security development activities Conclusion.
Access Control Methodologies Chapter 2. Basics of Access Control Access control is a collection of methods and components –Supports confidentiality (protects.
OWASP Mobile Top 10 Why They Matter and What We Can Do BSides Columbus 2015January 19 th, 2015.
Microsoft Retail Stores DCCA Tool MRS DCCA – MS Finance USER TRAINING PRESENTATION.
Security Planning and Administrative Delegation Lesson 6.
Information Security What is Information Security?
Information Networking Security and Assurance Lab National Chung Cheng University The Ten Most Critical Web Application Security Vulnerabilities Ryan J.W.
Security Issues with PHP PHP installation PHP programming Willa Zhu & Eugene Burger.
Testing - an Overview September 10, What is it, Why do it? Testing is a set of activities aimed at validating that an attribute or capability.
Lecture 14 – Web Security SFDV3011 – Advanced Web Development 1.
11 DESIGNING A PUBLIC KEY INFRASTRUCTURE Chapter 9.
Principles of Computer Security: CompTIA Security + ® and Beyond, Third Edition © 2012 Principles of Computer Security: CompTIA Security+ ® and Beyond,
Security - Why Bother? Your projects in this class are not likely to be used for some critical infrastructure or real-world sensitive data. Why should.
Web2.0 Secure Development Practice Bruce Xia
D ATABASE S ECURITY Proposed by Abdulrahman Aldekhelallah University of Scranton – CS521 Spring2015.
Environmental Council of States Network Authentication and Authorization Services The Shared Security Component February 28, 2005.
CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Web Security.
Chapter 17: WEB COMPONENTS By Chuong Vu. Chapter Contents Current Web Components and Concerns Web protocols – SSL/TLS, HTTP/HTTPS, DAP/LDAP, FTP/SFTP.
Feedback #2 (under assignments) Lecture Code:
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation.
1 IT420: Database Management and Organization Session Control Managing Multi-user Databases 24 March 2006 Adina Crăiniceanu
Linux Security. Authors:- Advanced Linux Programming by Mark Mitchell, Jeffrey Oldham, and Alex Samuel, of CodeSourcery LLC published by New Riders Publishing.
CCSB223/SAD/CHAPTER141 Chapter 14 Implementing and Maintaining the System.
Chapter 12 Network Security. Security Policy Life Cycle A method for the development of a comprehensive network security policy is known as the security.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
SEC835 OWASP Top Ten Project. Top Ten Web App Vulnerabilities OWASP top ten web application vulnerabilities – 2007 report Vulnerabilities A1 - Cross Site.
Chapter 2: Testing in Software Life Cycle MNN1063 System Testing and Evaluation.
® IBM Software Group © 2007 IBM Corporation Best Practices for Session Management
The OWASP Foundation Web Application Security Host Apps Firewall Host Apps Database Host Web serverApp serverDB server Securing the.
© 2017 SlidePlayer.com Inc. All rights reserved.