So OWASP has published the 2017 Top 10. For those that follow this stuff, you’ll notice that they went with RC2 (second release candidate). This means that they removed the highly-controversial A7 (“insufficient attack protection”) from RC1 and kept it off. Good decision, folks. The top ten isn’t, in my opinion, the place for vague, “pie in the sky” stuff that isn’t clearly defined, easily implementable, or otherwise something that folks can clearly and objectively meet.
The OWASP Top Ten is a little bit of a trap nowadays in some respects when it comes to implementability. Why? Because the PCI DSS is going to incorporate it more or less verbatim; ergo, including something like “insufficient attack protection”, while maybe reflective of solid (even one might argue necessary) security practice, doesn’t make it easy for folks in the payment space to meet their regulatory obligations. Which isn’t OWASP’s fault, but it’s the way it is. It’s the curse of having too much relevance.
So RC2 was pretty good. There are three new requirements — and DarkReading does a solid job of outlining what they are and going through the specifics. The tl;dr though is that they are: A8 insecure deserialization, A4 XML external entities (XXE), and A10 Insufficient Logging and Monitoring. In general, I give it a thumbs up. Someone could argue about the specifics, quibble about the order and so on (i.e. are XML issues really a large scale problem than misconfiguration?), but on the whole they’re pretty solid. The only one that I maybe, sort of, have an objection to is A10, “logging and monitoring.”
I have two issues with this one. First, it describes the lack of a control (or practice) rather than a “vulnerability”. Meaning, it describes something that should be there for a normative scenario but isn’t. Is that an application issue? Maybe it is maybe it isn’t. Philosophically, it seems to me like the purpose of a countermeasure is to mitigate <something>. That <something> is the vulnerability — the response is not. All of the other top 10 describe the <something>, not the response. For example, A1 doesn’t say “failure to implement a WAF, other filtering, or do appropriate prevention of injection issues.” Instead, it describes the root issue: injection. The new A10 is different in that it describes the response and not the issue. Another way of saying this is would be to ask the question: are you doing monitoring for it’s own sake or for some other purpose? To the extent that you are doing it for some reason, what (IMHO) should be on the list is that reason. To phrase this like the other ones, it would be something like “inability to detect relevant events or attacks in progress” for example.
The other issue I have with this is that it breaks one model of how folks employ the list. Because it doesn’t describe an issue with an application itself exactly; it describes something that is (or ought to be) a more holistic, integrated, and comprehensive monitoring approach. Meaning, an issue with the broader environment and ecosystem within which the application lives. Is lack of logging/monitoring a problem? Yes. Yes it is. Should organizations have better monitoring? Of course they should. Is logging and monitoring an issue with the application itself per se? That’s where I start to have some issues.
I care because one of the ways that people use the list (in addition to it being a de facto regulatory requirement because PCI), is to hand it off to developers or security teams and say “go address these.” Because the list is simple, direct, and straightforward, they know exactly how to address them, they are discrete in scope, and can usually be addressed by the developers with appropriate input from other teams. Can you do that with “failure to monitor”? Sort of. To address it well though is beyond the scope of just the application development or application security teams. It impacts ops, development, security, all sorts of other areas — for collection, storage, and review. So a security or development team could happily churn through the list until they get to this one, and then they need to go solve world hunger. If it, in fact, described the specific issue (as outlined above), it would rescope the issue to something that team could address on an an application-by-application basis though.
tl;dr — props to the OWASP team for an all-around solid set of updates. I’m skeptical about A10 — because I really think it could be phrased better — but I’ll live.