[Owasp-topten] [Owasp-leaders] Released: OWASP Top 10 – 2017 Release Candidate

Osama Elnaggar oelnaggar04 at gmail.com
Thu Apr 13 00:29:23 UTC 2017


Jeremiah's tweet regarding A0 isn't actionable by developers and is more in
the domain of operations or governance whereas A7 is.  A7 just needs to be
re-worded and I think split up into:

* as a developer, how are you going to detect attacks?
* as a developer, how are you going to protect against detected attacks?
* as a developer, how are you going to enable quick patching when either
your application is vulnerable or the 3rd party libraries you use are?

For the first, a developer could take the initiative to log all sensitive
actions in the application + things that violate the security policy
defined when they tackled the other OWASP Top 10 areas.  They can then
decide to output this in JSON so they can be easily consumed by logging
solutions within the environment and to feed their SOC teams with the
necessarily visibility.

Tackling protection is more difficult for a developer but there are
libraries that developers can use to help protect against brute forcing.
These won't protect against all attacks but can at least protect against
things such as password brute-force attacks quite easily.  At the very
least, the developer can ensure that these will be detected and that they
are providing their security operations teams with the necessary logs to
detect these attacks.

The last one is probably the most difficult for a developer to tackle as
this is border-line outside the scope of the developer.  But then again,
the "Security Misconfiguration" and "Using Components with Known
Vulnerabilities" are also borderline outside the scope of the developer.  A
developer may launch their application with components that are up-to-date
and don't have know vulnerabilities but this isn't going to last for long.
Slide 13 from Jeremiah's talk about Cyber Insurance (
https://www.blackhat.com/docs/us-16/materials/us-16-Grossman-An-Insiders-Guide-To-Cyber-Insurance-And-Security-Guarantees.pdf)
covers
the average time to fix in days for Known web vulnerabilities found with
the average around 130 days.  So this last point is basically saying: bugs
will be found on your site.  How quickly will you patch them (either
permanently in the code if the vulnerability is in your code and not a 3rd
party component or virtually using a WAF, RASP, etc. until it can be fixed
and a new deployment rolled out)?  Having this issue on the table and
addressed by developers, project managers, operations, etc is great.
Security vulnerabilities can be given greater weight and teams can try to
streamline the process for developing, testing, and rolling out patches.
WAFs and RASP can add an additional layer of security until these issues
are patched in the code.  Not having something like this is the reason that
we see 100+ days of exposures for known web applications as highlighted in
the presentation above.

Thanks.

—

Osama Elnaggar

On April 13, 2017 at 12:35:39 AM, Dave Wichers (dave.wichers at owasp.org)
wrote:

The data set we collected for the 2017 Top 10 and the basic analysis we did
on it is in this folder on github:
https://github.com/OWASP/Top10/blob/master/2017/datacall/. Its a simple
excel spreadsheet.

And both A7 and A10 are a bit complex (or at least new), so we plan to
write or augment some articles on the OWASP Wiki itself to provide further
explanation. A single page is very hard to get all your ideas/points across
for a complex category clearly (esp. A7).

-Dave


On Wed, Apr 12, 2017 at 5:09 AM, psiinon <psiinon at gmail.com> wrote:

> Another concern I have is the transparency of this project.
> Who made the decisions? Was it a couple of individuals? A team?
> And on what basis were the decisions made?
>
> I'm not criticizing how it was done, partly because it seems to be very
> opaque :) I've certainly not seen any meaningful discussions about the doc
> on this list before the RC1 was released.
> And I'm not suggesting it actually needs to be changed, eg by putting it
> to a common vote either - that brings its own set of problems ;)
> However the categories and ordering (still) look to me to be very
> subjective. There may well be data behind them but its the interpretation
> that is key.
> I think that a document explaining the process and thoughts behind the
> interpretation would really help - I dont think its needs to be in the Top
> 10 doc but I think this info should be there for those of us who care about
> it. I also want to see a summary of the data collected.
> How can we review any of the RCs if we dont understand on what basis they
> were created?
>
> Cheers,
>
> Simon
>
> On Wed, Apr 12, 2017 at 8:31 AM, psiinon <psiinon at gmail.com> wrote:
>
>> As per Jeremiah's tweet https://twitter.com/jeremiahg/
>> status/851562562634137600 I think one of the biggest security risks to
>> any medium-large organization is unknown sites / applications and
>> functionality.
>> Not having a category like this in the Top 10 feels like a huge omission
>> to me.
>> Who here in an organization of any non trivial size is not worried about
>> what they dont know has been deployed?
>>
>> Cheers,
>>
>> Simon
>>
>> On Mon, Apr 10, 2017 at 3:36 PM, Dave Wichers <dave.wichers at owasp.org>
>> wrote:
>>
>>> OWASP Leaders!
>>>
>>>
>>>
>>> The Release Candidate for the OWASP Top 10 – 2017 is now available!
>>> (Attached)
>>>
>>>
>>>
>>> *It’s also available for Download here
>>> <https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf>*
>>>
>>>
>>>
>>> Please forward to all the developers and development teams you know!!
>>> I’d love to get feedback from them too, and to start immediately raising
>>> awareness about what’s changed in this update to the OWASP Top 10. The
>>> primary change is the addition of two new categories:
>>>
>>>
>>> *2017-A7: Insufficient Attack Protection*
>>>
>>> *2017-A10: Underprotected APIs*
>>>
>>>
>>>
>>> We plan to release the final version of the OWASP Top 10 - 2017 in July
>>> or Aug. 2017 after a public comment period ending June 30, 2017.
>>>
>>>
>>>
>>> Constructive comments on this OWASP Top 10 - 2017 Release Candidate should
>>> be forwarded via email to OWASP-TopTen at lists.owasp.org. Private
>>> comments may be sent to dave.wichers at owasp.org .  Anonymous comments
>>> are welcome.  All  non-private comments will be catalogued and published at
>>> the same time as the final public release.  Comments recommending
>>> changes to the items listed in the Top 10 should include a complete
>>> suggested list of changes, along with a rationale for any changes. All
>>> comments should indicate the specific relevant page and section.
>>>
>>>
>>>
>>> Your feedback is critical to the continued success of the OWASP Top 10 Project.
>>> Thank you all for your dedication to improving the security of the world’s
>>> software for everyone.
>>>
>>>
>>>
>>> Thanks, Dave
>>>
>>>
>>>
>>> OWASP Top 10 Project Lead
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>
>>
>> --
>> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
>>
>
>
>
> --
> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
>

_______________________________________________
Owasp-topten mailing list
Owasp-topten at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-topten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170412/441edbcd/attachment-0001.html>


More information about the Owasp-topten mailing list