Did you know that OWASP maintains a project designed to help you learn how to perform source code security reviews? In this video, learn about the OWASP Code Review Project.
- [Instructor] If you're looking for a step-by-step guide to performing a source code security review, then the OWASP Code Review Guide is the first resource you should check out. This guide begins with considerable information on what a code security review actually is and on how to scope it. How to couple these code security reviews with online penetration tests. And it also includes a methodology for integrating code security reviews into your SDLC. OWASP built this guide to align with the top 10 web application security risks. For each item in the Top Ten the code review guide includes specific code snippets that demonstrate how those flaws might appear in your source code. More importantly, the guide shows instructors what to review and how to validate that the code is resistant to certain attacks. The guide also includes detailed references for further reading. Using resources that are both internal to OWASP and hosted on external sites like MITRE, USENIX, php.net, and microsoft.com, just to name a few. The code review guide focuses on offline application security testing activities. While the testing guide shifts that focus to online testing. Using both resources in tandem will have a huge positive impact on your application security testing activities. I cover the testing guide in detail in my online application security testing course. But for now know that you should consider both guides to be integral to your application security program. One of the reasons I think so highly of the code review guide is that it brings topics like maturity and risk into your application security conversations. The project team understands the importance of applying risk-based intelligence to code security reviews in order to get the most Combining that intelligence with threat modeling, you can build a core set of tests that are more likely to reflect actual attacks your application could experience once it goes live. It's also critical for developers and security testers alike to understand how external business drivers impact code security review activities. The guide was written with three specific audiences in mind. It was written for management teams who won't be doing the actual testing, but still need some understanding of what testing will be performed and why it's important. It was also written for software leads who need to understand the relationship between code reviews and code security reviews. Most importantly, it was written for the secure code reviewer who's going to be doing most, if not all, of the hands-on work. By writing this guide with all three audiences in mind, the project team created a resource that brings these three groups together, increasing the likelihood that the resulting processes will find adoption across the entire organization. The guide goes into detail regarding a number of factors to consider when developing your internal code security review processes. The alignment with the Top Ten risks is obviously core to the guide, but it also provides both purpose and context to help everyone involved develop a better understanding of why we're performing code security reviews in the first place. OWASP urges testers to consider the number of lines of code in scope for your reviews as well. Larger, more complex programs are more likely to be exposed to security flaws. And you'll need to determine how in depth your code security reviews can be. If you don't have time or resources to perform the level of review that you feel is necessary, you'll likely want to compensate with additional scrutiny during your online testing. As we discussed earlier, knowing which programming languages are in play is crucial. And the OWASP guide underscores that fact. The guide also urges you to consider available resources, the time those resources can allocate to testing, and the deadlines that are going to influence your testing activities. With respect to threat modeling, the code review guide applies two separate models, STRIDE and DREAD. If you've done any threat modeling in the past, chances are you're somewhat familiar with one or both of these models. The STRIDE threat model was developed by a pair of Microsoft employees. It focuses on six potential threats, spoofing a user's identity, tampering with the integrity of the application, repudiation, information disclosure, denial of service attacks, and elevation of privilege. By considering these six threat types when assessing your source code, it helps your testers focus their efforts on risks to confidentiality, integrity, availability, and so on. The DREAD threat model also came from the Microsoft space. This model relies on five threat categories to determine which threats represent the greatest risk to an application. Damage, if an attack was successful, how bad would it be? Reproducibility, once one person figures out how to execute the attack how hard would it be for them or others to repeat it? Exploitability, how hard is it to actually execute the attack? Affected users, how many people would be impacted by a successful attack? And discoverability, how simple is it for an attacker to find this threat. OWASP suggests that testers might use this threat model to assign a more traditional score using the risk equals likelihood times impact equation. We're going to cover both STRIDE and DREAD in more detail later on in this course. When building out a code security review process, you personally run the risk of being overwhelmed by the scope of the effort and by the imbalance between potential threats and available security resources. The OWASP Code Review Guide can help simplify that process considerably, shifting your mindset from overwhelmed to empowered. Download the guide. Download the guide and build it into your process. You'll be hard pressed to find a better resource for this purpose.
- Security frameworks
- OWASP Top Ten
- Building Security In Maturity Model (BSIMM)
- Planning your testing projects
- Creating security policies
- Source code reviews
- Application threat modeling
- Offline testing for OWASP Top Ten vulnerabilities