{"id":683,"date":"2017-11-22T15:52:11","date_gmt":"2017-11-22T15:52:11","guid":{"rendered":"https:\/\/securitycurve.com\/?p=683"},"modified":"2017-11-22T15:52:11","modified_gmt":"2017-11-22T15:52:11","slug":"owasp-rc2-and-insufficient-logging-and-monitoring","status":"publish","type":"post","link":"https:\/\/securitycurve.com\/?p=683","title":{"rendered":"OWASP, RC2, and “Insufficient Logging and Monitoring”"},"content":{"rendered":"

So OWASP has published the 2017 Top 10<\/a>.\u00a0 For those that follow this stuff, you’ll notice that they went with RC2<\/a> (second release candidate).\u00a0 This means that they removed the highly-controversial A7 (“insufficient attack protection”) from RC1<\/a> and kept it off.\u00a0 Good decision, folks.\u00a0 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.<\/p>\n

The OWASP Top Ten is a little bit of a trap nowadays in some respects when it comes to implementability.\u00a0 Why?\u00a0 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.\u00a0 Which isn’t OWASP’s fault, but it’s the way it is.\u00a0 It’s the curse of having too much relevance.<\/p>\n

So RC2 was pretty good.\u00a0 There are three new requirements — and DarkReading does a solid job<\/a> of outlining what they are and going through the specifics.\u00a0 The tl;dr though is that they are: A8 insecure deserialization, A4 XML external entities (XXE), and A10 Insufficient Logging and Monitoring.\u00a0 In general, I give it a thumbs up.\u00a0 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.\u00a0\u00a0The only one that I maybe, sort of, have an objection to is A10, “logging and monitoring.”<\/p>\n

I have two issues with this one.\u00a0 First, it describes the lack of a control (or practice) rather than a “vulnerability”.\u00a0 Meaning, it describes something that should be there for a normative scenario but isn’t.\u00a0 Is that an application issue?\u00a0 Maybe it is maybe it isn’t.\u00a0 Philosophically, it seems to me like the purpose of a countermeasure is to mitigate <something>.\u00a0 That <something> is the vulnerability — the response is not.\u00a0 All of the other top 10 describe the <something>, not the response.\u00a0 For example, A1 doesn’t say “failure to implement a WAF, other filtering, or do appropriate prevention of injection issues.”\u00a0 Instead, it describes the root issue: injection.\u00a0 The new A10 is different in that it describes the response and not the issue.\u00a0 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?\u00a0 To the extent that you are doing it for some reason, what (IMHO) should be on the list is that reason.\u00a0 To phrase this like the other ones, it would be something like “inability to detect relevant events or attacks in progress” for example.<\/p>\n

The other issue I have with this is that it breaks one model of how folks employ the list.\u00a0 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.\u00a0 Meaning, an issue with the broader environment and ecosystem within which the application lives.\u00a0 Is lack of logging\/monitoring a problem?\u00a0 Yes.\u00a0 Yes it is.\u00a0 Should organizations have better monitoring?\u00a0 Of course they should.\u00a0 Is logging and monitoring an issue with the application itself per se<\/em>?\u00a0 That’s where I start to have some issues.<\/p>\n

I care because one of the ways that people use the list (in addition to it being a de facto<\/em> regulatory requirement because PCI), is to hand it off to developers or security teams and say “go address these.”\u00a0 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”?\u00a0 Sort of.\u00a0 To address it well though is beyond the scope of just the application development or application security teams.\u00a0 It impacts ops, development, security, all sorts of other areas — for collection, storage, and review.\u00a0 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.\u00a0 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.<\/p>\n

tl;dr — props to the OWASP team for an all-around solid set of updates.\u00a0 I’m skeptical about A10 — because I really think it could be phrased better — but I’ll live.<\/p>\n","protected":false},"excerpt":{"rendered":"

So OWASP has published the 2017 Top 10.\u00a0 For those that follow this stuff, you’ll notice that they went with RC2 (second release candidate).\u00a0 This means that they removed the highly-controversial A7 (“insufficient attack protection”) from RC1 and kept it off.\u00a0 Good decision, folks.\u00a0 The top ten isn’t, in my opinion, the place for vague, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[4],"tags":[86],"class_list":["post-683","post","type-post","status-publish","format-standard","hentry","category-security","tag-owasp"],"_links":{"self":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts\/683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=683"}],"version-history":[{"count":0,"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts\/683\/revisions"}],"wp:attachment":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}