[Owasp-alabama] old news, new news?

owasp-alabama at lists.owasp.org owasp-alabama at lists.owasp.org
Thu Feb 11 14:07:38 EST 2010


No I think its just you and I.

I also hope to map the owasp common numbering up with external stuff, as
OWASP doesn't currently have anything along the lines of the CAPEC. (but we
all probably agree that the niche filled by CAPEC is important)


-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org
--
"Si vis pacem, para bellum"
--


On Thu, Feb 11, 2010 at 1:02 PM, <owasp-alabama at lists.owasp.org> wrote:

>
> On Feb 11, 2010, at 12:50 PM, owasp-alabama at lists.owasp.org wrote:
>
> > So as far as using the ASVS, I find it to be appropriate for more general
> type documentation. The problem I run into is when more information is
> necessary, for example:
> >
> > V5.1 Verify that the runtime environment
> >      is not susceptible to buffer
> >      overflows, or that security controls
> >      prevent buffer overflows.
>
> For this particular item, I too would have to argue that the semantics for
> this item are a bit too specific to a particular type of memory corruption
> vulnerability.
> This should really probably fall into a general memory corruption
> vulnerability which would also include heap based overflows, identifying the
> vulnerability, identifying exploitability, format string attacks, integer
> overflows etc etc.
>
> To stop just at 'buffer overflow', there are just too many variables to say
> 'we stopped it because we saw a classic strcpy(.. ) overflow.
>
>
> > When developing a standardized process, this simple isn't enough
> information or detail. It leaves a number of things hanging out there:
> >
> > 1) Who's responsibility is this?
> > 2) What methods were used to 'ensure' that this was truly mitigated
> > 3) What methods were to test and validate they didn't exist in a
> live-fire environment
> > 4) What about variations in risk dealing (accept, mitigate, transfer).
>
> I totally agree.
> Identifying risks where we just shoot from the hip on an entire
> vulnerability class leaves many things open to interpretation and eventually
> labeled a false-positive if the analyst or developer doesn't appropriately
> understand the vulnerability likewise the vulnerability class in which it
> falls into.
>
> > So what I'm getting at here is that I LOVE the ASVS, and I've work with
> MIke (the guy who wrote it) quite a bit. Problem is, there isn't a link to
> anything outside of to provide additional guidance. Hence: this:
> >
> > http://www.owasp.org/index.php/Common_OWASP_Numbering
> >
> > This project is one I plan to lead, once it is off the ground. It's
> primary goal is to link all available resources to each other, so ASVS 5.1
> == OWASP-DV-004 (testing guide) or whatever.
>
> Giving a bit of perspective which isn't entirely within the owasp bubble
> one could check out:
>
> http://capec.mitre.org
>
> Is there anyone else on the list? Hoping this banter will spur on other
> members. (this isn't negative against you brad, just throwing this out
> there)
>
> In other news;
>
> http://googlechromereleases.blogspot.com/2010/02/stable-channel-update.html
>
> | Daniel Uriah Clemens
> | Packetninjas L.L.C | | http://www.packetninjas.net
> | c. 205.567.6850      | | o. 866.267.8851
> "Moments of sorrow are moments of sobriety"
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Owasp-alabama mailing list
> Owasp-alabama at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-alabama
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-alabama/attachments/20100211/25925768/attachment-0001.html 


More information about the Owasp-alabama mailing list