[Owasp-leaders] The OWASP Periodic Table Project

James Landis james.landis at owasp.org
Wed Mar 6 17:16:43 UTC 2013


Thanks for the feedback, Tony. Replies inline:


On Tue, Mar 5, 2013 at 9:51 PM, Tony UV <tonyuv at owasp.org> wrote:

> Firstly, I appreciate this initiative James and your time around this.  I
> too however am a bit perplexed on how this will be consumed beyond the
> theoretical in the setting of the SMB security practitioners, the
> enterprise security groups, vendors, and/ or security consulting firms.
>

This seems like an oddly specific selection of audiences. First, do you see
how the document would be consumed by browser/standard developers and
builders of perimeter technologies and web app frameworks? That is the most
important set of audiences being targeted by the document.

I don't think that these groups you list would use them in more than a
theoretical sense, other than to recommend to their respective engineering
teams that they use products and frameworks that are driving toward this
solution model, rather than try to keep playing vulnerability whac-a-mole
when XSS inevitably appears in the applications they try to build on flawed
platforms. This document would give weight to the argument that engineering
teams should build on secure frameworks rather than the latest JavaScript
web server or other hip trend. For existing applications, the document
gives weight to the argument about solving bug classes like XSS
holistically, rather than with hundreds of point fixes that leave the app
open for future mistakes.

This obviously begs the question - what frameworks meet these criteria? The
answer is: none yet, and that is the whole point of the document. Step one
is to agree about where to best solve these problems. Step two is to go out
and start pressuring builders of technology to build safer platforms for
web apps. Framework developers have always felt market pressure to build
features that developers like. This effort will help add the market
pressure to build security features that we security people like. Perhaps
there could even be a development project: OWASP Secure Struts, or other
such secure framework project.

This document is just a first step toward a better solution model.


> From a vuln perspective, on one extreme, you have lists managed by MITRE
> that relate to CVEs and corresponding CVSS.  As you and many know, there
> are very few products that have not adopted CVEs, so although far from
> perfect, the adoption is definitely widespread.  Beyond vulns, theres
> obviously weaknesses as well, of which, again a list of CWEs and
> corresponding CWSS values are also in relatively wide distribution.  Now I
> realize that both MITRE driven lists are mostly consumed by security
> products, versus SecOps or AppSec folks reading over these vast lists that
> are really not that easily consumed and organized.  Although CWEs and CVEs
> are much more extensive than the various top X lists out there, they are
> meant for different purposes, those being the following: understanding the
> genre of the vuln or weakness, understanding technical risk, and lastly how
> to remediate.  Going back to those top X, I’ve seen even those get consumed
> to further organize to a higher classification of CVEs by those same
> product vendors, which is unfortunate b/c they do offer so much more
> possibilities via other types of security disciplines that I won’t get into
> here.  Point or question being - is there a strong need for further vuln/
> weakness classification and if so, how do you foresee adoption/ consumption
> to the point of becoming an applied classification model for a given user
> base?
>

Some classification models don't seem to me to have a clear purpose.
Indeed, this table in my mind started out as a pure classification effort
to see if anything useful could be gleaned from the effort. However, the
model I settled on isn't to me as much a pure classification model as it is
an answer to the question: how can we eliminate as many bug classes as
possible with as little effort from individual web developers as possible?
We clearly need to answer this question differently from how we have been
approaching it for the last 20 years, since the only major bug class that
seems to have been eliminated from web apps is buffer overflow, and that
was certainly through no fault of our own.


>
> Some additional questions/ comments specific to the example URL you
> provided are the following:
>
> 1 - don’t you think that some of the vulns are splicing hairs and could be
> unified in their categorization?  (ex: brute force cookie id & cookie
> theft/ session hijacking  - both fall under the area of overall session
> management?)
>

Yes, I do think to some extent the existing names our industry has come up
with for bugs are a bit hair-splitting. I simply tried to capture as many
of them as I could with the names people are used to, without too much
duplication. The first month of the roadmap for the project is dedicated to
defining the format for the deliverable. So far I see arguments for several
different views of this information. The current view is largely for folks
who approach this problem from the perspective of vulns and weaknesses.
Another view might package up this information according to which solution
segment is being targeted (e.g. framework vs. perimeter), in which all
session management would likely be combined. I strongly suspect the final
document(s) will include both views.


> 2 - is the term ‘framework’ being misused and attempting to re-brand what
> looks like by its column contents as remediation or countermeasures?
>

I hope not! I specifically use framework to mean something like Ruby on
Rails, Struts, or even PHP the way it's used for web apps. The remediations
and countermeasures that are currently listed in the "generic framework"
column are things that anything calling itself a "secure" web framework
should have; ideally the framework would even make it impossible for users
of that framework to make a mistake which exposes the related
vulnerability. A "custom" framework includes the custom code that
enterprises build on top of these other frameworks that include common
business logic and APIs, which developers then build on top of in their
day-to-day work.

I hope it is clear now. There may be disagreement still about which columns
these remediations should land in, but we will iron that out during the
open comment period this summer.


>
> I think the idea is good, however, I’m wondering if the approach could be
> turned on its head to perhaps create a classification model of attacks vs
> vulns/ weaknesses.  I do know that CAPEC libraries exist for this, however,
> I think that people have more challenges in fathoming attack patterns than
> understanding vulns/ weaknesses and more can be done beyond CAPEC.
> Regardless of audience, developers, architects, netops people, etc - they
> get the vuln/ weakness, they just don’t understand how the attacks can
> manifest in the multitude of ways that they can.
>

Classification is fun! It's a good educational tool. But I'd rather focus
our energy on educating most people about only the small subset of
vulns/weaknesses they'd have to worry about if we solve everything else for
them. The target audiences for this document should be security experts
already; I hope to clarify and focus their efforts on making the ecosystem
safer for non-experts.



>
> Preemptive counter note: By know means do I mean that 100% of IT people
> (dev, sysadmins, DBAs, etc) get what these vulns mean and how they work, so
> no need to point the obvious.  There are orgs still that don’t even do the
> bare minimum and have never heard of SQLi or XSS, however, the point is
> that the periodic table of vulns would be ‘getting in line’ to the list of
> vuln resources that inform those that are noobs to the more proficient.
>

Nope, I don't want to be in that line at all. I want to get everything else
out of the line that doesn't need to be there in order to make those noobs
more proficient. The story the table tells is: "use these technologies over
here to build your apps, then only worry about these few things over here",
which is a much simpler story than "here's all the million things you
should worry about, and hey we organized them for you; good luck!"


>
>
> Tony UV
> ATL Chapter Lead
>
> Sent from tablet device - please excuse any typos
>
>  *From:* James Landis <james.landis at owasp.org>
> *Sent:* ‎March‎ ‎5‎, ‎2013 ‎6‎:‎56‎ ‎PM
> *To:* Abbas Naderi <abbas.naderi at owasp.org>
> *CC:* owasp-leaders at lists.owasp.org
> *Subject:* Re: [Owasp-leaders] The OWASP Periodic Table Project
>
> Glad you asked. On the main project page, click on the tab labeled
> "Periodic Table of Vulnerabilities". You'll see the first draft incarnation
> covering ALL known vulnerability classes. :) (Please let me know if you
> think I've missed one.)
>
> Or, click here:
> https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities#Periodic_Table_of_Vulnerabilities
>
>
> On Tue, Mar 5, 2013 at 3:52 PM, Abbas Naderi <abbas.naderi at owasp.org>wrote:
>
>> Hello guys,
>> Glad to hear another very useful projecting kicking in.
>> I think providing one or two examples of vulns plus the description and
>> solution the OWASP Periodic Table wants to offer would set things for most
>> of us, as it is really vague right now in my mind at least.
>> Thanks
>> -Abbas
>>
>> On ۱۶ اسفند ۱۳۹۱, at ۳:۲۰, James Landis <james.landis at owasp.org> wrote:
>>
>> I think the Periodic Table sits just one level of abstraction above this
>> argument. No matter where we finally land on the output encoding vs. input
>> validation debate, would we all agree that any generic secure web app
>> framework (e.g. "secure" rails, "secure" struts, etc.) should automatically
>> enforce both of them without requiring a developer to remember to call the
>> right validation or encoding function?
>>
>> A flexible framework would probably want to expose configuration options
>> for the filters and encoders, but for the first version of the document I'd
>> only want to get as far into the implementation details as is necessary to
>> make sure we know the solution is technically feasible and not going to
>> kill off the entire user base for the framework.
>>
>> -j
>>
>>
>> On Tue, Mar 5, 2013 at 1:31 PM, Dennis Groves <dennis.groves at owasp.org>wrote:
>>
>>>
>>>  * Other odd ball contexts need their own love, probably along the lines
>>>>> of IV.
>>>>>
>>>>
>>>> Would love to see some examples.
>>>>
>>>> And in general, input validation is great secure coding hygiene
>>>> practice and does indeed stop some injection (like when validating numeric
>>>> input that lands in a query). But to stop SQL Injection, it's all about
>>>> query parametrization (and proper design) for complete defense.
>>>>
>>>
>>> Is that because your thinking of remediation and we are thinking of root
>>> cause?
>>> In my mind root cause and remediation are not the same, one is a how
>>> (solution) the other is the why (reason). And I unfortunately, can not
>>> think of any examples. :/
>>>
>>>
>>> Dennis
>>>
>>> --
>>> [Dennis Groves](http://about.me/**dennis.groves<http://about.me/dennis.groves>),
>>> MSc
>>> [Email me](mailto:[email protected]**owasp.org <dennis.groves at owasp.org>)
>>> or [schedule a meeting](http://goo.gl/8sPIy).
>>>
>>> *This email is licensed under a [CC BY-ND 3.0](http://creativecommons.**
>>> org/licenses/by-nd/3.0/deed.**en_GB<http://creativecommons.org/licenses/by-nd/3.0/deed.en_GB>)
>>> license.*
>>>
>>> **Please do not send me Microsoft Office/Apple iWork documents.**
>>> Send [OpenDocument](http://fsf.org/**campaigns/opendocument/<http://fsf.org/campaigns/opendocument/>)
>>> instead!
>>> Stand up for your freedom to install [free software](http://www.fsf.org/
>>> **campaigns/secure-boot/**statement<http://www.fsf.org/campaigns/secure-boot/statement>
>>> ).
>>>
>>>  The idea that some lives matter less is the root of all that’s wrong
>>>> with the world. -- Paul Farmer
>>>>
>>> ______________________________**_________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/**mailman/listinfo/owasp-leaders<https://lists.owasp.org/mailman/listinfo/owasp-leaders>
>>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130306/9fedcf52/attachment-0001.html>


More information about the OWASP-Leaders mailing list