[Owasp-leaders] [Owasp-community] [Owasp-topten] OT10 Risks?

Timur 'x' Khrotko (owasp) timur at owasp.org
Tue Sep 30 01:44:19 UTC 2014

(Disclaimer: (a) I represent the devil's advocate here, dissatisfaction
with my provocative statements will be taken instrumentally, not
personally:) b) While T10-criticism is the major point of my election
"campaign", I have no chance to be elected, so consider me as someone
expressing minority opinion here in a harsh way for the sake of a probably
important debate.)

The problem manifests in this very thread,  imo. T10 is the holy thing of
OWASP, criticism regarding it is boring heresy (a topic for trolls), and we
are better to carry on with it as it was established by the fathers of our
church ten years ago in a very different historical situation, carry on
with a comfortably shared illusion that it works well on the fields of
application development, and will in late 2010s too.

0. While there is certain professional criticism regarding the T10, I am
not qualified to represent that issue, and accept T10 as it is as the most
authoritative classification of "the most critical web application security

1. Practically T10 is an awareness something. Our own usage recommendation:
"Adopting the OWASP Top Ten is perhaps the most effective first step
towards changing the software development culture within your organization
into one that produces secure code." In order to call T10 a tool we should
have provided instructions how to use this tool. As per the cited
statement, T10 serves an introductory material, an ABC to introduce
vulnerabilities, and in conjunction with the cheat sheets teaches their
mitigation. That's what T10 is, an ABC. Instructions for the further "steps
towards changing the software development culture" are here:
- which generally refers to SAMM, the latter refers to T10 once
("Additional coverage of commonplace software vulnerabilities is also
desirable such as a Top 10 list appropriate to the software being

2. Probably you have success stories how to take a group of developers and
teach them the basics from A1 to A10, without making them bored at A4.
Probably it would be very helpful to share the case studies of methodology
how to use T10 as the ABC of AppSec in the realworld organizations, how to
let it "simply work". Probably we still leave the real world alone with the
T10, without a map of where and how use it. Making the issue visible does
not prevent developers from giving a toss about it and continue producing
crap code. Appsec practices must become gut practice. Changing habits and
washing minds is an art. Teaching English language is boring and difficult,
to make courses work we have colorful students' books with funny stories
and clever teacher's books with instructions. T10 has to become much more
accessible and usable in order to address the root cause.

3. Let's not promote T10 for purposes it is not suitable for. It can't be
used as an AppSec requirements addendum of a dev contract, its content is
not supposed to be legally binding. We should not support the fallacy that
there are universal AppSec requirements without prior risk assessment. And
business/management has nothing to do with the T10 and its content.

4. Let OWASP be more associated with projects that are more practical
today. Projects that are more suitable for integration into
business/organizational process of software development. And probably let's
create a usable webapp appsec requirements standard.

What's your opinion?



PS. War on narcotic drugs - also an example of an extraordinary important
issue failing among other things due to our poor vocabulary and misuse of
concepts. Marijuana and heroin are both referred to as narcotic drugs,
while the harm of the former is million times less than that of the latter.
Alcohol and tobacco are not covered by the anti-drug campaigns, while both
are top narcotic drugs as well, and while social damages and health risks
of the alcohol are much higher than that of marijuana. Etc.
On Sep 29, 2014 11:35 PM, "Eoin Keary" <eoin.keary at owasp.org> wrote:

> Hey,
> My final email on this subject as I suspect many people are tired of this
> thread (including me).
> Success: yes top 10 has more than any project promoted appsec awareness.
> It has promoted such that if all apps covered the items listed in the top
> 10 the global Internet would be more secure. It's easy to consume,
> understand and focus on insecurity point-by-point. It is simply a very
> effective awareness document. Kudos to Dave and Jeff Williams.
> Purpose: awareness. It promotes awareness. Simple. It works. Regardless of
> intellectual constructs, points of view, academic malarkey, it simply
> works. Why complicate things.
> Engineering is about simplicity not complexity.
> Has the top 10 changed in any major way since its inception? No.
> Why? We are still developing crap code . Our industry grows and grows but
> nothing changes. Like the "war on drugs". Root cause is what needs to be
> addressed.
> Eoin Keary
> Owasp Global Board
> +353 87 977 2988
> On 29 Sep 2014, at 22:09, "Timur 'x' Khrotko (owasp)" <timur at owasp.org>
> wrote:
> "Does the top 10 work? Yes. ... Does the OWASP top 10 serve its purpose?
> Sure."
> Eoin, could you please explain, what you mean by (a) its successful
> working and (b) its purpose?!
> On Mon, Sep 29, 2014 at 10:31 PM, Eoin Keary <eoin.keary at owasp.org> wrote:
>> So Dave Wichers explanation was succinct and worked. What's wrong with
>> looking at the Top 10 from that standpoint?
>> The top 10 also needs to be accessible for non security folks (the point
>> of owasp awareness). Getting dragged into semantics and nomenclature is
>> pointless if the only people who give a toss are owasp members. Does the
>> top 10 work? Yes. Does the average developer give a toss about naming? No.
>> Does the OWASP top 10 serve its purpose? Sure.
>> Eoin Keary
>> Owasp Global Board
>> +353 87 977 2988
>> On 24 Sep 2014, at 08:30, Simone Onofri <simone.onofri at gmail.com> wrote:
>> Dear Jim,
>> Literally speaking it is correct e.g. a SQL Injection is not a Risk as by
>> definition, but in the latests editions of TOP 10 are getting into some
>> analysis like Risk Analysis of most frequent "issues" on Web Application
>> Security (I am using issues as a generic term) and I think with a little
>> edits can became also "correct" by definition.
>> Let me explain with two examples with the most generic defintion of Risk
>> that can be taken from M_o_R / ISO 31000 and ISO 27000:
>>  - M_o_R [1]: "An uncertain event or set of events that, should it occur,
>> will have an effect on the achievement of objectives. A risk is measured by
>> a combination of the probability of a perceived threat or opportunity
>> occurring and the magnitude of its impact on objectives. " We can remap on
>> our context is something like "An uncertain event that, should occur, will
>> have an effect on the achievement of IT Security objectives". An important
>> concept in this definition is that it is not bad. It depends. If the effect
>> is positive we can call it an opportunity (but it is not the case of our
>> TOP 10), if the effect is negative is it also called a threat in M_o_R.
>>  - ISO 27000 [2]: "effect of uncertainty on objective" in which effect it
>> is a deviation (positive or negative) and generating an impact but we are
>> not sure that the event which actualise the risk. how it is possible to
>> actualise a risk? if the asset (something that has a value for the
>> organization) or a control (a measure we can use to modify the risk) has a
>> vulnerability, which is a weakness that can be exploited by threats (is the
>> potential cause) during an attack (the attempt to destroy, expose, alter,
>> disable, steal or gain unauthorized access to or make unauthorized use of
>> an asset) by someone or something.
>> In particular in 27000 definition I see more concepts and analysis on
>> latest TOP 10 version. Taking an example of Injection [3], with a specific
>> example of a SQL Injection, as described:
>> We have some assets (e.g. the application, the database, the data into
>> database) and if we have some weaknesses ( read "Security Weaknesses" -
>> e.g. no or poor input validation, poor written code with inline sql queries
>> and not prepared statements), someone or something (read "Threat Agent"),
>> causing a specific Impact (and I love the separation of Technical and
>> Business impact in TOP 10).
>> And the section "How Do I Prevent 'Injection'?" sounds like "which kind
>> of Controls" I can use to protect.
>> TOP 10 talks about the Analysis of most common Risks that can occur with
>> the most frequent weaknesses/vulnerabilities, talking in ISO language.
>> My two cents,
>> Simone
>> [1]
>> https://www.exin.com/assets/exin/frameworks/126/glossaries/english_glossary_of_terms_mor_201404.pdf
>> [2] http://standards.iso.org/ittf/licence.html
>> [3] https://www.owasp.org/index.php/Top_10_2013-A1-Injection
>> On Sun, Sep 21, 2014 at 10:40 PM, Jim Manico <jim.manico at owasp.org>
>> wrote:
>>> Aloha Community and Leaders,
>>> During the many hallway conversations had at AppSec USA in Denver,
>>> AppSec nomenclature came up on a number of occasions. I heard several
>>> folks claim that the "OWASP Top Ten •Risks•" was mis-named and that
>>> the list is not really risks.
>>> Is this a fair perspective? What should it be?
>>> I am uncertain of this myself and am asking to trigger a intelligent
>>> conversation; I in no way wish to harm the many volunteers who have
>>> made the various OT10 lists happen.
>>> Thoughts?
>>> Aloha,
>>> --
>>> Jim Manico
>>> @Manicode
>>> (808) 652-3805
>>> _______________________________________________
>>> Owasp-topten mailing list
>>> Owasp-topten at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-topten
>> _______________________________________________
>> Owasp-community mailing list
>> Owasp-community at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-community
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> This message may contain confidential information - you should handle it
> accordingly.

This message may contain confidential information - you should handle it 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140930/cc3f21c3/attachment-0001.html>

More information about the OWASP-Leaders mailing list