Engineering is an exercise in working within constraints. Appsec increases those constraints, forcing developers to better understand the nuances of vulns and then decide how to prioritize and fix them.
Since 2004 the OWASP Top 10 has raised awareness of the types of weaknesses that plague web apps and the kinds of attacks that target them. Even trying to fit the abundance of attacks and weaknesses into a top ten list is an exercise in working within constraints. For their part, OWASP chose to label the entries as risks and refine the list by criticality.
The recent update for 2017 proposes two new entries, both of which strive to capture complex subjects under the constraints of 2–3 words. The next two sections summarize these new entries, A7 and A10.
A7. Insufficient Attack Protection
Insufficient attack protection (A7) covers the concepts of protect, detect, and respond to attacks against an app. These concepts echo three of the five functions named in the NIST Cybersecurity Framework. It’s a heavily overloaded item whose subtext is about asset inventory (where are your legacy apps) and risk management (how much should you invest in security tools for your apps).
Detection should be tied to response decisions and whether you actually care about that information or will take action on it. Log collection and monitoring has its place in standard DevOps practices for analysis and debugging of an app’s health. Adding “attack” alerts is only useful if you have a plan for reacting to them; otherwise they’re just noise and data that don’t convey information. There’s a distinction between traffic that has attack-like properties and traffic that is exploiting weaknesses in the app.
What’s notable about A7 is that it calls out additional components like IDS, WAF, and RASP to add the app’s ecosystem. For legacy apps, these might make sense since their deployment can be more cost-effective than rewriting code. For other apps, this trade-off may not make sense. Again, we’ve returned to a risk management decision that requires context about the app.
Also under this item’s description is the ability to patch quickly. This decision tree also branches between legacy apps and active apps. Legacy apps might benefit from WAF solutions whereas apps with active DevOps should have capabilities to deploy patches out of regular release cycles.
A10. Underprotected APIs
Underprotected APIs (A10) is an equally overloaded item, but more in the sense that it’s a reminder that the Top 10 items A1 through A9 apply equally to APIs. Modern web apps are often split between JavaScript-heavy frontends that interact with REST-based API backends via HTTP requests. Similar APIs may also serve native mobile apps, or be designed for other web apps to interact with.
In other words, appsec applies to endpoints that serve more than just web browsers. Those API endpoints may still have authentication weaknesses, cross-site scripting issues, or other vulns. And security testing should cover them as well.
Like A7, this relates to asset inventory (web-based APIs that aren’t for browsers are still web apps) and risk management (APIs need security testing, too).
Start with Zero
When we encounter constraints we must ask questions in order to make informed decisions. Both A7 and A10 have a basis in web asset inventory and risk management. This is like searching for the answers to, “What apps do I own, what weaknesses do they have, and how much effort should I put into them?”
Another way to frame this is in the vein of the OWASP Top 10 might be as the following zeroth entry:
A0. Under-developed risk classification
The spirit of this entry is to equip your DevOps (or DevSecOps) team with the tools to describe the risk associated with the OWASP Top 10 entries, evaluate that risk, and prioritize ways to reduce it.
Security testing will help answer the question about how much risk your app has now. There are many ways to do this, from code reviews to source code scanners to dynamic scanners to bug bounties and pen tests.
For example, pen tests identify weaknessess and vulns within a web app or API. Experienced pen testers can also provide insight into the impact a vuln might have on the app, its data, or its users; and the likelihood (or ease) of that vuln’s exploitation. That information plus context about the app’s criticality to business operations or the revenue it supports all contribute to its risk.
A DevOps team should strive to reduce risk over time by improving code, making design changes, increasing the speed at which patches can be deployed, or adding security tools like a WAF. By tracking risk over time, you can monitor trends and set goals to reduce risk by measurable amounts.
Consistent classification and tracking also leads to insights about how an app compares with others. The following graph is an example of visualizing relative risk. It plots apps relative to each other based on their average risk and number of vulns.
We can’t build apps that are perfectly secure against all threats, but we can manage the risk they accrue from vulns and the attacks they face. Classifying and qualifying vulns helps teams work more effectively within the constraints of secure app development. It informs the way we answer questions like, “How much should I worry about this app and what’s the first step I should take to protect it?”
Risk management, like app development, is a continuous process. The OWASP Top 10 gives DevOps teams a security reference. They can use it to classify vulns discovered by security testing, rate those vulns, and prioritze how to fix them — ideally improving deployment processes along the way.
