lto:goertzel_ka...@bah.com>
-Original Message-
From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave
Sent: Thu 19-Mar-09 19:28
To: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
Alchemist(informIT)
Why are we differentiating between
st
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
Tom, Ben, All,
I thought I'd offer more specifics in an attempt to clarify. I train people
here to argue your position Ben: security vulnerabilities don't count unless
they affect development.
wed. It is, however, non-secure.
--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com
-Original Message-
From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave
Sent: Thu 19-Mar-09 19:28
To: Secure Code Mailing List
Subject: Re: [SC-L
sessment on security bugs only
> - I think we need to bring the worlds of software development and
> security analysis together more. Divided we (continue to) fail.
>
> And Gary, this is not a critique of just your comment, but of
> WebAppSec at large.
>
> - Jim
>
>
> - O
lf of Benjamin Tomhave
> Sent: Thu 19-Mar-09 19:28
> To: Secure Code Mailing List
> Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
> Alchemist(informIT)
>
> Why are we differentiating between "software" and "security" bugs? It
> seems to me t
ring the worlds of software development and
>> security analysis together more. Divided we (continue to) fail.
>>
>> And Gary, this is not a critique of just your comment, but of
>> WebAppSec at large.
>>
>> - Jim
>>
>>
>> - Original Message
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
Alchemist(informIT)
Why are we differentiating between "software" and "security" bugs? It
seems to me that all bugs are software bugs, ...
___
Secure Coding mailing list
). It would still, however, result
> in poor security.
>
> -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454
> goertzel_ka...@bah.com
>
>
>
>
> -Original Message----- From: Benjamin Tomhave
> [mailto:list-s...@secureconsulting.net] Sent: Fri 20
ent, but of
> WebAppSec at large.
>
> - Jim
>
>
> ----- Original Message - From: "Gary McGraw"
> To: "Steven M. Christey" Cc: "Sammy Migues"
> ; "Michael Cohen" ; "Dustin
> Sullivan" ; "Secure Code Mailing List&q
l Message -
From: "Gary McGraw"
To: "Steven M. Christey"
Cc: "Sammy Migues" ; "Dustin Sullivan"
; "Secure Code Mailing List"
Sent: Wednesday, March 18, 2009 11:54 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(
ven M. Christey"
Cc: "Sammy Migues" ; "Michael Cohen"
; "Dustin Sullivan" ;
"Secure Code Mailing List"
Sent: Thursday, March 19, 2009 2:50 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
> Hi Steve,
>
>
ustin Sullivan"
; "Secure Code Mailing List"
Sent: Wednesday, March 18, 2009 11:54 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
> Hi Steve,
>
> Many of the top N lists we encountered were developed through the
> consistent use
Sent: Thursday, March 19, 2009 2:50 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
> Hi Steve,
>
> Sorry for falling off the thread last night. Waiting for the posts to
> clear was not a great idea.
>
> The top N lists we observed among t
ot;
Cc: "Sammy Migues" ; "Dustin Sullivan"
; "Secure Code Mailing List"
Sent: Wednesday, March 18, 2009 11:54 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
> Hi Steve,
>
> Many of the top N lists we encountered were de
Hi Gary,
On Mar 19, 2009, at 16:27, Gary McGraw wrote:
> Hi Stephan,
>
> In my view, it would be even better to study the difference in
> external bug emphasis (as driven by full disclosure and the CVE) and
> internal bug emphasis (as driven by an organization's own top N list).
That is a br
Hi Stephan,
In my view, it would be even better to study the difference in external bug
emphasis (as driven by full disclosure and the CVE) and internal bug emphasis
(as driven by an organization's own top N list). Once again, this is a
difference in emphasis you might put as "reactive" versus
Hi Steve,
Sorry for falling off the thread last night. Waiting for the posts to clear
was not a great idea.
The top N lists we observed among the 9 were BUG lists only. So that means
that in general at least half of the defects were not being identified on the
"most wanted" list using that B
Hi Kevin,
Any discipline with the word "science" in its name probably isn't. I have a
dual PhD in two of those fields (computer science and cognitive science), so I
ought to know.
I mostly agree with your assessment of many industry coders and IT people (most
of whom do NOT have a background
Steve,
You saw my talk at the OWASP assurance day. There was a brief diversion about
the number of "business logic" problems and "design flaws" (coarsely lumped
together in my chart). That 'weight' should indicate that-at least in the
subset of clients I deal with-flaws aren't getting short-shr
On Mar 18, 2009, at 23:14, Steven M. Christey wrote:
> I believe this is reflected in public CVE data. Take a look at the
> bugs
> that are being reported for, say, Microsoft or major Linux vendors
> or most
> any product with a long history, and their current number 1's are
> not the
> sa
Gary McGraw wrote:
> We had a great time writing this one. Here is my favorite
> paragraph (in the science versus alchemy vein):
> "Both early phases of software security made use of any sort
> of argument or 'evidence' to bolster the software security
> message, and that was fine given the start
On Wed, 18 Mar 2009, Gary McGraw wrote:
> "Both early phases of software security made use of any sort of argument
> or 'evidence' to bolster the software security message, and that was
> fine given the starting point. We had lots of examples, plenty of good
> intuition, and the best of intention
On Wed, 18 Mar 2009, Gary McGraw wrote:
> Because it is about building a top N list FOR A PARTICULAR ORGANIZATION.
> You and I have discussed this many times. The generic top 25 is
> unlikely to apply to any particular organization. The notion of using
> that as a driver for software purchasing
Hi Steve,
Many of the top N lists we encountered were developed through the consistent
use of static analysis tools. After looking at millions of lines of code
(sometimes constantly), a ***real*** top N list of bugs emerges for an
organization. Eradicating number one is an obvious priority.
On Wed, 18 Mar 2009, Gary McGraw wrote:
> Many of the top N lists we encountered were developed through the
> consistent use of static analysis tools.
Interesting. Does this mean that their top N lists are less likely to
include design flaws? (though they would be covered under various other
B
Hi Steve,
Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. You
and I have discussed this many times. The generic top 25 is unlikely to apply
to any particular organization. The notion of using that as a driver for
software purchasing is insane. On the other hand if o
hi sc-l,
The BSIMM is a sizeable document, so digesting it all at once can be a
challenge. My monthly informIT column this month explains the BSIMM in a much
easier to digest, shorter form. The article is co-authored by Brian and Sammy.
BSIMM: Confessions of an Alchemist
http://www.informit.c
27 matches
Mail list logo
