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

Jerry Hoff jerry at owasp.org
Tue Sep 30 02:33:00 UTC 2014


I would respond respectfully that everything looks easy in retrospect, and that standardizing terminology at the planet level for anything is no easy task.

However, I agree fully that you should "never use a top 10 list as the basis of your security program" (Hoff's Law), and that it would be a beautiful thing is the top 10 turned into a methodology that particular data could be applied against to calculate an organizations top appsec risks.

Anyone up for a top 10 methodology summit in 2015... Preferably in the sunny city of Fort Lauderdale Florida (perfect in between point for Europe, South America and North America in my opinion) :) 

--
Jerry Hoff
jerry at owasp.com
@jerryhoff

> On Sep 29, 2014, at 22:23, Jim Manico <jim.manico at owasp.org> wrote:
> 
> Getting terminology "right" for our organization is, I state with respect, a low bar of achievement.
> 
> I suggest we list different choices like Mitre, ISO and perhaps even an OWASP specific set of definitions, and encourage our resources to state which definitions they choose to use.
> 
> That way we do not "mandate" anything, but •ask• projects to state what they are using.
> 
> Better?
> 
> --
> Jim Manico
> @Manicode
> (808) 652-3805
> 
>> On Sep 29, 2014, at 6:46 PM, Timur 'x' Khrotko (owasp) <timur at owasp.org> wrote:
>> 
>> (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 flaws".
>> 
>> 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:
>> https://www.owasp.org/index.php/Top_10_2013-What%27s_Next_for_Organizations
>> - 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 developed").
>> 
>> 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?
>> 
>> Regards:
>> 
>> timur
>> 
>> 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 accordingly.
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> _______________________________________________
> Owasp-community mailing list
> Owasp-community at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140929/d6ec1524/attachment-0001.html>


More information about the OWASP-Leaders mailing list