This post was written by Chris Romeo during his tenure at Security Journey.
As a bit of a thought experiment, I asked myself, “What if I had to develop an application security program with a budget of zero dollars? How would I do it?” People often talk about unlimited security budgets. Some of the largest companies in the world have gone on record to say that there is no limit to what they’ll spend on cybersecurity.
Looking across the industry, this is not the norm for most organizations. But you can create an application security program on a zero or limited budget.
Traditional application security programs include people, process, and tools. The people include your security champions or advocates who are passionate about security. Your constituents or consumers of the program include developers, testers, program managers, product managers, people managers, and executives.
The process consists of your secure development lifecycle, product security incident response (PSIRT) and bug bounty efforts. Tools provide automation of security test and include all the four-letter acronyms (SAST, DAST, IAST, RASP), and even a three-letter abbreviation (SCA). All of these pieces have one thing in common: They generally cost money to purchase or support.
OWASP is the hidden gem of the security world.
The key to application security on a budget is tapping into the OWASP universe. OWASP is the Open Web Application Security Project, a not-for-profit working group of the finest minds in application and software security. Volunteers create open-source security projects, gather a team to collaborate, and crank out the best guidance and tools on the planet. Just because they’re free doesn’t mean these projects don’t pack a massive amount of value. OWASP is the hidden gem of the security world.
Here’s how to put the OWASP project to work for your organization, no matter how big or small your budget.
Regardless of how much money you have in your budget, you likely have a set of goals in common with everyone else in the industry. First, you want to limit vulnerabilities in deployed code. Secondary program goals include building secure software and teaching developers to develop secure software, providing processes and tools for application security standardization, and demonstrating software security maturity through metrics and assessment.
Most people have sizable budgets and can purchase whatever they need (to a degree) to ensure program success. You can use OWASP to enhance your program in certain areas using the resources available. If you have a small budget or no budget, use OWASP to fill in missing spaces on your plan.
One word of caution before you jump headfirst into the OWASP pool: OWASP projects come and go. Some release, never to be heard from again. There is no guarantee that a project will ever reach a formal release or have a second version created. Use OWASP projects at your own risk. Spoiler alert: I think they are worth the risk.
The first group of OWASP projects is categorized as awareness, knowledge, and education. These projects focus on preparing the people in your organization to understand and apply the ways of application security.
The Top Ten is the original and seminal work within the OWASP universe, listing the top 10 web application security risks. This document can guide your entire team in understanding the most significant threats to your organization regarding web applications.
The first version of the Top Ten was released in 2003, and it has undergone many revisions over the years. The 2017 edition includes injection, broken authentication, sensitive data XML external entities (XXE), broken access control, security misconfiguration, cross-site scripting (XSS), insecure deserialization, using components with known vulnerabilities, and insufficient logging and monitoring.
The value of the Top Ten comes from the fact that risks are sorted using industry data, and high-level mitigations to fix these issues are presented. The Top Ten provides a foundational understanding of the most essential concepts in app sec. Teach it to everyone in your organization.
The Proactive Controls are written for developers, by developers, and it includes what your developers need to do to build better products. This is the concise guidance your developers need to counter each and every one of the Top Ten.
The current OWASP Proactive Controls are “Define Security Requirements,” “Leverage Security Frameworks and Libraries,” “Secure Database Access,” “Encode and Escape Data,” “Validate All Inputs,” “Implement Digital Identity,” “Enforce Access Control,” “Protect Data Everywhere,” “Implement Security Logging and Monitoring,” and “Handle All Errors and Exceptions.”
The value of the Proactive Controls comes from their concise nature (two to three pages per issue). While everyone in an engineering organization should understand the Top Ten, Proactive Controls are foundational knowledge for everyone who touches code.
Juice Shop is a vulnerable web application written specifically to contain the issues found in the Top Ten. Juice Shop provides developers with hands-on experience exploiting web application security issues. You can explain a problem to developers, but until they have laid their hands on the keyboard and exploited said issue, they have not truly understood it.
Juice Shop’s value is derived from the assimilation of crucial concepts through activities that lock in knowledge and make it practical.
Cheat Sheets provide a knowledge base for how to do things securely. Over the years, various OWASP volunteers have noted that there are issues that come up often in most web applications. These volunteers create a cheat sheet to describe the problem and offer a solution. As an example, there is a password storage cheat sheet. Storing passwords is often done poorly, leaving one of our most sensitive pieces of data vulnerable. The password storage cheat sheet describes issues to consider and also recommends solutions using various encryption algorithms and employing password hashes securely.
The Cheat Sheets provide a concise reference for solving the most challenging application security problems. Point your developers to this resource to help them avoid trying to answer the hard questions that already have decent and secure solutions.
The second group of OWASP projects involves process and measurement. Process and measurement help you to define, govern, and measure your program.
SAMM is the Security Assurance Maturity Model, and it provides a catalog and assessment methodology for measuring and building an application security program. SAMM provides high-level categories of governance, construction, verification, and operations. Each of these top-level categories has a series of subcategories. For example, governance includes strategy and metrics, policy and compliance, and education and guidance. Each subcategory contains guidance on how to build out a portion of your program.
As an assessment methodology, SAMM provides spreadsheets with questions for use in an assessment of your organization. The SAMM spreadsheet tools index and compile results, with charts and graphs you can share with your executive team.
SAMM provides a roadmap of where you are today and helps you build a plan for where you want to go with your program in the future.
ASVS is the Application Security Verification Standard. It is a collection of application security requirements, written in such a way as to be verifiable. ASVS defines four levels—cursory, opportunistic, standard, and advanced—and prescribes different depths of requirements based on your assessment for the criticality of a given application.
ASVS serves as a base set of requirements that you can build upon. Why create your own set of requirements for web application security when such a robust framework exists for your use? If you must produce something of your own, use the ASVS as a baseline to build upon.
OWASP’s advice on application threat modeling includes examples. Application security people all agree on the importance of threat modeling. This project provides a simplified approach to getting started. The basis of this methodology is asking four questions: What are we building? What can go wrong? What are we going to do about that? Did we do a good enough job?
Threat modeling is difficult at first. The OWASP application threat modeling project acts as a reference methodology for how you can teach all your developers to threat model.
The best security-focused code review begins with a secure code review checklist. The Code Review Guide provides you that checklist and also describes all the other things you must understand about code review for web applications, with example snippets of code and guidance on what to look for.
Code review is hard enough without a baseline checklist. Use the Code Review Guide to help your developers know what to look for.
Developers tend to lack knowledge of how to perform application-focused security testing. The Testing Guide explains how to test and provides a knowledge base on how to exploit web application vulnerabilities. The Testing Guide is an in-depth resource with examples that walk your developers through how various Top Ten issues play out.
The Testing Guide serves as a guide and a resource for when your developers need to understand a vulnerability type in more depth, and also for when they need to know how to test for a particular vulnerability class.
The third and final set of OWASP projects is tools. Tools provide automated methods to extend your program’s capabilities with a small investment in time.
ModSecurity is a plugin for the Apache webserver that allows it to act as a web application firewall. ModSecurity is managed and built from outside of OWASP, but the Core Rule Set is an OWASP project that defines the intelligence via rules that truly block web application threats at the webserver layer.
The value of the Core Rule Set is that it provides a web application firewall solution for free. And if for some chance you are questioning how useful this technology is, you should know that it is used in many of the commercial WAF solutions from service providers.
Dependency-Check identifies vulnerable third-party software in your build pipeline. Third-party software is riddled with vulnerabilities, and Dependency-Check provides an automated method to detect vulnerable software and break your build until the vulnerable software is eradicated.
There are many commercial offerings in the software composition analysis space, but pound for pound, my money is on Dependency Check and its sister project, Dependency Track, which adds enterprise-level management across your entire application fleet.
Last but certainly not least is the Zed Attack Proxy or ZAP. ZAP provides two primary functionalities, acting as a web proxy for manual web application security testing, and automating scanning capability, providing a DAST-like service.
The value of ZAP comes from placing it on developers’ desktops to enable them to perform manual app testing, and also from using it as a component of your build pipeline, as a simple scanning tool for running your web applications.
Doing application security on a budget is feasible, and in my mind, the wisest way you can approach your program, even if you have a budget with many zeroes on the end of it.
As you plan the rollout or augmentation of your program, remember to use OpenSAMM to assess your current program and future goals. Start small by choosing one item for awareness and education to launch your program. Evaluate the available projects in each category and build a one-to-two-year plan to roll each project out. While OWASP is free, the headcount is not; plan for the headcount to support your “free” program.
OWASP has a robust chapter program, so connect with fellow OWASP enthusiasts in your locale, and join the movement by starting a new project or collaborating on an existing one. It takes an industry working together to enable application security on a budget.