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

Timur 'x' Khrotko (owasp) timur at owasp.org
Fri Sep 26 23:18:52 UTC 2014


A) "I say we have a nomenclature problem that needs to be solved."

Yes, this is the prominent problem here.
Next step is to take action -- what would it be, Jim?! :)


B) T10 Risks - the latter word was the original subject

My guess is that if we had a taxonomy/nomenclature and cared about its
business compatibility we wouldn't name the elements of top 10 'risks'.
And from the business perspective those named cases of exploitable
application failures or quality issues are not risks per se.

"[W]e thought [it] was important because organizations care about risks,
not vulns."
- understandable enough, but a forced use of the term imo, and probably
incorrect from the business perspective itself.
And isn't it a marketing or communication gain over the need to keep the
appsec discipline clear? (see problem #1 above)

Dave, I know that your understanding of the topic below is more established
than mine, just for the sake of the discussion I would put that: 'risk' has
quite a reserved meaning in business, so it is debatable to use it bit
loosely if connecting to the business domain is important.

Let's revisit the logic of the term: Simon referred to the MoR/BCM
definitions, which represent variations on the essence of the 'risk'
concept in business, which comes from the probability theory and relates to
the expected value: probability x damage (harm, loss, opportunity, etc).
low probability x huge damage > high risk; high probability x moderate
damage > moderate risk; etc.
"Quantitative risk assessment requires calculations of two components of
risk (R):, the magnitude of the potential loss (L), and the probability (p)
that the loss will occur." - http://en.wikipedia.org/wiki/Risk_assessment .
And this is how we calculate in finances.

T10 project uses the very same principle:
https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
(which also refers to:
http://en.wikipedia.org/wiki/Factor_analysis_of_information_risk )

So there is an established concept of risk behind T10 with a model
compatible with the business domain:
https://www.owasp.org/index.php/Top_10_2013-Risk
It correctly defines concepts for my taste. (I guess it's use of weakness,
impact, attack words is not exactly compatible with MITRE, but that was not
a requirement before).
In my interpretation it says that the top 10 elements are rated by their
technical impact, high in terms that they are expectable
<http://www.urbandictionary.com/define.php?term=expectable> x harmful -
harmful from the technical perspective.
And we don't know anything about their business impact (harm) and the
business risk related to them (business harm x probability).

However we may rely on the shortcut that technical risks are business
risks, and from the BCM perspective it probably makes sense - but! I still
insist, that T10 elements are not instances of the risk class. Business
understandable risk is eg. 'loss of utility power'. From the T10 the
'Sensitive Data Exposure' sounds like risk for business but they don't know
that we mean the risk of attack based on an exploit using sensitive data,
which in our context mostly means passwords, session ids, credit card data,
etc. - keys for an attack.

The other 9 are like they sounds: types of security related application
quality issues or kinds of attacks based on application quality issues.

Business wants to mitigate risks associated with the sensible
probability and harm resulting from security incidents (or violations)
leveraging on (exploiting) the application quality issues, be it an attack
or a failure. Business may want to be helped by OWASP with a standard set
of security quality requirements regarding webapps they use. The actual
requirements are to be derived from the risk assessment of the business
situation the webapp is used in. These requirements are to use standard
wording and refer to standard types of attacks to prevent and
vulnerabilities to avoid. The current T10 hardly connects to this major
practical need. Or is it somehow?


Regards:
timur

PS: My guess is, that we have to provide a more flexible set of clauses,
which can roughly match some standard risk situations that risk assessments
are able to identify.
A very distant reference may be the Incoterms clauses:
http://en.wikipedia.org/wiki/Incoterms
- In a trade contract you identify the general clause in three letters plus
the place and add some custom terms to it to reflect your actual situation,
but the major part of your agreement is covered by the standard clause.

On Wed, Sep 24, 2014 at 9:40 PM, Jim Manico <jim.manico at owasp.org> wrote:

> Dave,
>
> Sounds like the OT10 team did the best they could with a difficult
> decision. A few brief notes...
>
> > something like what CWE-79 does: “Improper Neutralization of Input
> During Web Page Generation”.
>
> This is actually called, "Improper Neutralization of Input During Web
> Page Generation ('Cross-Site Scripting')" so the secondary title sure
> leads me to believe that Mitre considers XSS to be a straight up
> weakness.
>
> Regardless, your team made tough choices and I see why. Perhaps we can
> go over those choices again when the next OT10 process begins?
>
> Someone asked me who my favorite OWASPer was and I said "Dave Wichers"
> right away. Why? Because even in the heat of difficult conversations
> and disagreement, you continue to send me suggestions to make the wiki
> better. (I'll get the current list done soon). Everyone makes mistakes
> and disagreements are common in our industry and community. But what
> makes OWASPers shine in my opinion is technical collaboration. Thank
> you Dave for continuing with your donations, even when (especially
> when) we do not necessarily see eye-to-eye. Hat tip to you.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>
> > On Sep 24, 2014, at 8:21 AM, Dave Wichers <dave.wichers at owasp.org>
> wrote:
> >
> > something like what CWE-79 does: “Improper Neutralization of Input
> During Web Page Generation”.
> _______________________________________________
> 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/20140927/7fa24ece/attachment.html>


More information about the OWASP-Leaders mailing list