* Steven M. Christey:
> Two areas that don't seem to immediately lend themselves to design/spec
> level solutions are (1) transitive trust and (2) interaction errors
> between multiple components that are all working correctly. I'd love to
> hear from people who've had to solve these problems in
At 11:41 PM -0400 3/20/09, Gary McGraw wrote:
> once long ago I spilt a bottle of wine with dan geer
> we argued for hours about whether a buffer overflow was
> a bug or a flaw. if you find one in a code pile (say,
> caused by a local variable on the stack and a gets call) ,
> it is a bug. Or i
I notice certs like CISSP when hiring. It says the person has a basic
understanding of all IS security areas. Nothing more. If someone can't pass
the CISSP then I have to wonder why.
-Original Message-
From: Paco Hope
To: "SC-L@securecoding.org"
Date: Thu, 19 Mar 2009 11:36:45 -0
hi all,
my preference is to lead with an Architectural Risk Analysis (and has been
since 1997).
gem
http://www.cigital.com/~gem
On 3/20/09 3:07 PM, "Jim Manico" wrote:
This is why I'm not fond if leading with a tool. I prefer to lead with
architectural/design analysis and targeted manual r
hi pub,
once long ago I spilt a bottle of wine with dan geer in Palo Alto to lament his
dead disk drive. we decided the conference sucked anyway and proceeded to the
Cowper. we argued for hours about whether a buffer overflow was a bug or a
flaw. if you find one in a code pile (say, caused b
>
> Two areas that don't seem to immediately lend themselves to design/
> spec
> level solutions are (1) transitive trust and (2) interaction errors
> between multiple components that are all working correctly. I'd
> love to
> hear from people who've had to solve these problems in the real worl
