What actually is OWASP?
For many development teams, OWASP is the go-to resource when starting to think about security. Usually we look at the “OWASP Top 10” (or say we do…) but there is much more to OWASP than that.
OWASP is the Open Web Application Security Project, or - more accurately - coming up on a hundred projects. These range from mature “Flagship” projects to up-and-coming “Lab” and “Incubator” projects, amongst a field of old and unloved wiki pages. Even though you see company policies issuing commandments to “follow the OWASP standards”, only a handful of them could be interpreted as “standards” or “guidelines”. So where to start, if you’re looking to get some good security guidance?
This post is going to provide what I consider the Top 5 OWASP Projects. We’ll answer two simple questions - what is it, and when’s the best time to use it.
The OWASP Top 10 is the most famous project for a reason, as it lists the ten mistakes that most commonly contribute to a website getting hacked. It gets updated every few years based on a mix of emperical data and industry opinion, with the most recent edition released in 2017.
The OWASP Top 10 is all about awareness. It’s the bare minimum set of threats that developers and testers should be aware of when building web applications or APIs. What the risk is, how to spot and address the vulnerability in your own code, and a bunch of links to more resources. It tries to be succinct and give good bang for buck.
Some examples are SQL Injection - where baddies send mean words to your database and get it to do things it shouldn’t, like spit out your user’s passwords - or Insufficient Logging & Monitoring - where you’re unable to detect, deal with, and/or learn from security incidents.
During Code Reviews: having the Top 10 in your peer code review checklist can help catch these low hanging fruit before they enter your code base. Many of the Top 10 can be picked up automatically by static code analysis tools too, which is great if you integrate it with your build pipelines.
During training: it’s really common to have this as a core part of training; learning what causes an issue, how to spot it, how to fix it.
It’s the other side of the OWASP Top 10 Risks. Where the Risks are things to avoid, the Proactive Controls are ten things to aim for to help make your product secure by design. Examples include “Enforce Access Controls”, “Encode and Escape Data”, “Implement Security Logging and Monitoring”.
It’s pretty straightforward stuff, but the value is in the explanations provided, and just as a reminder of “oh yeah, we should probably do that”. It’s targetted at builders - developers, architects, operations.
During Product / System Design The proactive controls are most useful at the start of a project and when new features are being developed.
OWASP JuiceShop is an intentionally vulnerable application so you can learn how to spot and exploit web application issues. It is seriously great. It has easy and hard challenges, and covers the OWASP Top 10 Risks. It has a free eBook to guide you along the way.
Testers will get a lot of value out of it, but developers should be using it too.
During training / professional development: Training courses will often use this or a similar tool; you can use it for free right now :) It’s something you can spend a bit of time on every now and again.
If you’re leading a team you could even run it as a team hackathon with a leaderboard.
OWASP ASVS is a big ole checklist of things to do. It’s very comprehensive and can be a little daunting, so they’ve split the checklist into three levels. Level 1 is things everyone should do, Level 3 is for apps in high-risk industries like banking or healthcare. The requirements are split into different focus areas.
An example Level 1 Authentication requirement is “Verify that user set passwords are at least 12 characters in length”. A Level 3 Data Protection requirement asks you to “Verify that regular backups of important data are performed and that test restoration of data is performed.”
Before go-live: if one team member sets aside a day they could probably smash through the whole thing up to Level 1 or Level 2, skipping over anything with an “N/A”. Create stories or issues for things you find are missing.
I find using the Excel version easiest in practice.
When creating security requirements: I haven’t seen this being done much in practice, but this would be a great source of acceptance criteria for Epics and Stories being developed.
OWASP SAMM is a guide on practices to establish in an organisation to mature its approach to security. There are three levels of increasing maturity, split across four main areas areas - Governance, Development, Testing and Operations. It provides key questions to ask and metrics to use to track success. Here’s an example within the Construction discipline (i.e. Development):
At Level 1 you’d want to “maintain list of recommended software frameworks” and ask the question “Are project teams provided with a list of recommended third-party components?”. Your success metrics include “>80% of development staff briefed on software framework recommendations in the past year”.
Then by Level 3 you’d want to “validate usage of frameworks, patterns, and platforms” and ask the question “are project teams audited for the use of secure architecture components?”. Your success metrics include “>50% of active projects using reference platforms”.
When creating an Application Security program: When you’ve got enough development teams to start wanting to mature your ad-hoc processes into something more defined, this is a great place to start. Clear metrics mean you can track the progress of your program over time.
When your customers start asking “what do you do for security”: You can self-assess yourself against this standard. Even if you don’t think you score very well, at least you’ll be able to use terminology your customer’s security teams will be familiar with, and indicate where you’re heading.
As well as those being my top 5 projects, I’ve put them in that order for a reason - they’re the order I think easiest to adopt as you mature your Software Development Lifecycle. If you have heard of the OWASP Top 10, then take a look at the Proactive Controls. If you’re familiar with all of them, it’s probably time to start implementing a formal security programme - and OWASP SAMM can help with that.
So where do you start? Start at the top of the list, and work your way down.
15 January 2020