A7 Colin Watson and Tin Zaw feedback

[vanderaj]

Further to your request for assistance with making the text of A7 more inclusive of our project's automated threats, as well as all four of the issues you mentioned. We feel that including other risks in A7 as well as"Insufficient Anti-Automation", dilutes this common and usually easily exploitable risk. This increases confusion about how to address the various issues. However, for the purposes of this reply we will assume A7 will continue to be the stated small collection of different risks. We have not attempted to address anyone else's concerns with A7, but should note that our project is technology and vendor agnostic, and our suggested changes to the wording of A7 avoid the mention of specific technologies, or products, or services. We welcome the Top Ten project's attempt to raise awareness of automated threat weaknesses/vulnerabilities that often go un-mentioned, yet are of real concern and impact to application owners.

1. Full page text We realise there are constraints on space, and therefore we have mocked up an updated page to ensure our suggested changes would fit in. Changes sections are marked in the colour magenta in the PNG at https://www.owasp.org/index.php/File:Owasp-a7-suggestions.png
2. Short description The short description of A7 on page 7 of RC1 does not seem to include all the issues A7 is meant to include. It is currently

   The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.

Based on your other emails to the Top Ten mailing list, our project believes it might be better as:

The majority of applications and APIs lack the basic ability to detect, prevent and respond to manual and automated attacks. This includes insufficient attack detection, insufficient attack response, insufficient countermeasures against automated threats, and insufficient ability to patch quickly.

3. Title Whilst of course we would have liked to see "Insufficient Anti-Automation" as a single issue, we accept your project's desire to aggregate this with some other issues. We do not mind too much the name "Insufficient Attack Protection" but it may suggest to some it is more of an operational thing, rather than encompassing the many countermeasures that can be considered through the whole of the software development life cycle. Yes there are design flaws and implementation bugs in this item! Our project has not been able to come up with a suggested better title that includes all the aspects to be considered. Most Top Ten issues are 3-4 words long, although we note that A1 is just "Injection". One suggestion - which we feel is weak - is simply to name A7 "Automation", but this is a poor munging together of meaning: a) Automated attacks and b) Automation of detection and response defenses [to both manual and automated attacks]. However, it does remove any other descriptive, and thus, judgemental words.

[itscooper]

I very much like the fact that A7 includes the detection and prevention of manual attacks as well. As a pentester, when I'm testing a network, I am regularly being called out and noticed during successful attacks because SecOps are getting alerts etc. This almost never happens when I successfully compromise web applications and APIs, and I think this is a major issue given that many organisations are shifting towards web-based technologies.

Although I completely understand the rationale of being more specific, I personally think that manual attack detection and prevention deserves more that being an honorable mention, and closely related enough that it makes sense to bundle.

[vanderaj]

This risk is going to be removed as per community feedback at the Project Summit, survey data and revised data call. Thank you for your input on this matter.