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

Timur 'x' Khrotko (owasp) timur at owasp.org
Mon Sep 22 21:49:35 UTC 2014


(Introducing a new word is probably a workaround in order not to face the
fundamental problem which Jim exposed.)

Any community has to operate with an agreed vocabulary, without a common
language we can not speak about AppSec seriously.
Our maturity in this regard probably resembles the early state of
psychology, we know that there are mental problems, but we do not know yet
what to call disorder, deviance, attitude, borderline, etc. So we talk
about objectively sensible problems: flaws, bugs and misconfigurations
exploitable by hackers, but have no system of terms describing our world,
that is we still lack an established concept of our field. One can cure
mental problems without knowing basic concepts of psychology.

Top 10 deals with some phenomena that reflects reality so we can talk day
and night about that things, but when you try to attach T10 to a contract
as a professional requirement, QA specification it turns out that you
can't. One can only say, oh dear developer, do not forget to avoid that mmmm
vulnerabilities or mmmm risks mmmm whatever Top 10 antipatterns mmmm you
know the list of dangers maintained by that respectful organization.

http://www.infosecisland.com/blogview/22951-Why-You-Shouldnt-Use-the-OWASP
-Top-10-as-a-List-of-Software-Security-Requirements.html
http://blog.silentsignal.eu/2014/03/31/owasp-top-10-is-overrated/


On Mon, Sep 22, 2014 at 8:59 PM, Kristian Erik Hermansen <kristian.hermansen
@gmail.com> wrote:

> How about calling them the OWASP Top 10 Security "Hazards"? :) In
> fact, this is a proper definition according to insurance and US
> government disaster models...
>
> On Mon, Sep 22, 2014 at 11:12 AM, Jim Manico <jim.manico at owasp.org> wrote:
> > Yes, this mirrors what I've been trying to express. Per OWASP, a
> > vulnerability exists in a specific application, not a term to be used to
> > describe the issue in a generalized way.
> >
> > "A vulnerability is a hole or a weakness in the application" is what the
> > OWASP wiki current says.
> >
> > OWASP wiki considers an attack to be, "...the techniques that attackers
> > use....". This is also close to Mitre.
> >
> > Michael, even though there is an established norm here, they are broadly
> > abused and the definitions both at OWASP and Mitre are up for
> > interpretation. The OWASP Top Ten Risks, for example, describes attacks
> and
> > weaknesses. These are only risks when they exist in specific systems.
> >
> > --
> > Jim Manico
> > @Manicode
> > (808) 652-3805
> >
> > On Sep 22, 2014, at 2:02 PM, Michael Coates <michael.coates at owasp.org>
> > wrote:
> >
> > Seems we're trying to reinvent the wheel here. We should reference
> > established taxonomies with clear definitions. Then compare the
> definitions
> > with the Top 10 approach and resolve discrepancies, if any.
> >
> > Do we agree or disagree with what we have on OWASP already?
> >
> > https://www.owasp.org/index.php/Category:Vulnerability
> >
> > Other sources:
> > https://cve.mitre.org/about/terminology.html
> > http://en.wikipedia.org/wiki/Vulnerability_(computing)
> >
> > (repeat for all terms - vulnerability, attack, risk, etc)
> >
> >
> >
> >
> > --
> > Michael Coates
> > Chairman, OWASP Board
> > @_mwc
> >
> >
> > On Mon, Sep 22, 2014 at 10:50 AM, Josh Sokol <josh.sokol at owasp.org>
> wrote:
> >>
> >> I would agree with this Jim.  Inclusion of a control is only risk
> >> mitigation if there is a risk that you are mitigating.
> >>
> >> ~josh
> >>
> >> On Mon, Sep 22, 2014 at 12:25 PM, Jim Manico <jim.manico at owasp.org>
> wrote:
> >>>
> >>> I am being pedantic, but you need to be when talking about
> nomenclature,
> >>> Josh. We are supposed "experts" on AppSec and can't get it straight.
> This is
> >>> a pretty big problem industry-wide in my opinions.
> >>>
> >>> Inclusion of a control is not in and of itself risk mitigation.
> >>>
> >>> Implementing a •control• that addresses a specific •exploitable
> weakness•
> >>> in a live system (a vulnerability in a live system) is risk mitigation.
> >>>
> >>> For example, you may have lack of query parameterization but no
> database,
> >>> so thats not a real weakness or vuln that needs to be addressed.
> >>> --
> >>> Jim Manico
> >>> @Manicode
> >>> (808) 652-3805
> >>>
> >>> On Sep 22, 2014, at 1:16 PM, Josh Sokol <josh.sokol at owasp.org> wrote:
> >>>
> >>> I know what he said.  I was expounding on it.  Lack of those is a
> >>> weakness, sure.  Inclusion of those is risk mitigation.  That's all I'm
> >>> suggesting there.
> >>>
> >>> ~josh
> >>>
> >>> On Mon, Sep 22, 2014 at 12:08 PM, Jim Manico <jim.manico at owasp.org>
> >>> wrote:
> >>>>
> >>>> > And in Bill's example, parameterized queries, input validation, and
> >>>> > output encoding would be considered risk mitigation.
> >>>>
> >>>> Bill said LACK OF parameterized queries and others which is a
> >>>> •weakness•, not risk mitigation.
> >>>>
> >>>> --
> >>>> Jim Manico
> >>>> @Manicode
> >>>> (808) 652-3805
> >>>>
> >>>> > On Sep 22, 2014, at 12:59 PM, Josh Sokol <josh.sokol at owasp.org>
> wrote:
> >>>> >
> >>>> > And in Bill's example, parameterized queries, input validation, and
> >>>> > output encoding would be considered risk mitigation.
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Regards,
>
> Kristian Erik Hermansen
> https://www.linkedin.com/in/kristianhermansen
> https://google.com/+KristianHermansen
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>

-- 
Email us to enforce secure link with your mail servers (domain).
This message may contain confidential information - you should handle it 
accordingly.
Ez a levél bizalmas információt tartalmazhat, és ekként kezelendő.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140922/e69266c8/attachment-0001.html>


More information about the OWASP-Leaders mailing list