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

Jim Manico jim.manico at owasp.org
Mon Sep 22 18:12:38 UTC 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140922/5921b858/attachment.html>


More information about the OWASP-Leaders mailing list