Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

[Florian Weimer]

* 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 the real world.
> Based on what I see in CVE, it seems that the answer for item 2 is usually
> for one component to choose to conform to another's expectations, and that
> conforming component isn't always the one that "should" be changed.

The really hard things under (2), like the Java/firewall issue, are
not fixed at all.  Subsequent designs may address it (Silverlight) or
not (Flash, post-FTP firewall helpers).  The + + + A T H 0 problem is
in this cateogry, too.

It seems to me that many of those things are, in some sense, layering
violations, where one party attaches meaning to properties at a wholly
different layer.  For instance, the cluster of AS4_PATH issues (which
we can't afford not fixing, I think) stems from the fact that BGP has
both a message transport layer, and a message semantics layer (much
like RFC 821 vs RFC 822).  This view is not yet universally shared,
though.
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

[ljknews]

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 is it a flaw that the C stack grows in
> an incredibly stupid way?

That reasoning has a bit of not being able to see the forest
for the trees.

The root problem (and I do not care about the terminology)
is that the C programming language promotes the use of
uncounted strings.
-- 
Larry Kilgallen
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs

[Joe Teff]

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 -0400

Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless 
certificatioNs




On 3/18/09 5:29 PM, "Jeremy Epstein"  wrote:



> If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it



...then I'd say you have an overly simplistic view of the world.



Anyone who believes that a credential automatically conveys some magical

knowledge that you didn't have before is just as overly-simplistic as

someone who disparages all credentials equally. It just isn't a black and

white world. 



Paco

-- 

Paco Hope, CISSP, CSSLP

Technical Manager, Cigital, Inc

http://www.cigital.com/ [http://www.cigital.com/] ? +1.703.585.7868

Software Confidence. Achieved.





___

Secure Coding mailing list (SC-L) SC-L@securecoding.org

List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l 
[http://krvw.com/mailman/listinfo/sc-l]

List charter available at - http://www.securecoding.org/list/charter.php 
[http://www.securecoding.org/list/charter.php]

SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
[http://www.krvw.com/])

as a free, non-commercial service to the software security community.

___
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT)

[Gary McGraw]

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 review of high risk 
applications.

Jim Manico
j...@manico.net

On Mar 20, 2009, at 4:06 AM, "Goertzel, Karen [USA]"  
wrote:

Except when they're hardware bugs. :)

I think the differentiation is also meaningful in this regard: I can specify 
software that does non-secure things. I can implement that software 100% 
correctly. Ipso facto - no software bugs. But the fact remains that the 
software doesn't validate input because I didn't specify it to validate input, 
or it doesn't encrypt passwords because I didn't specify it to do so. I built 
to spec; it just happened to be a stupid spec. So the spec is flawed - but the 
implemented software conforms to that stupid spec 100%, so by definition it not 
flawed. 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] 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 (SC-L) SC-L@securecoding.org 

List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l 

List charter available at - http://www.securecoding.org/list/charter.php 

SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

[Gary McGraw]

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 by a local variable on the 
stack and a gets call) , it is a bug.  Or is it a flaw that the C stack grows 
in an incredibly stupid way?   hmm.  Necker defect.

gem

http;//www.cigital.com/~gem


On 3/20/09 2:28 PM, "Pravir Chandra"  wrote:

Well, it seems that there's an interesting nuance here. We don't really have a 
concrete definition for what software is (code, design, compiled bins, etc.). 
All of these things plus the subjective expectations from designers, users, and 
security folks tend to be the domain for how the term is used.

Now on to 'bug'... Same thing applies. A missing feature can be called a bug 
just as well as a flawed line of code (or even a specified feature that does 
something undesirable).

But, I'm of the mind that avoiding security problems in software comes down to 
specification and design. I know Gary likes to talk about security problems as 
bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful 
when trying to build secure software in general (however, it is helpful in 
convincing people that are bug-chasing to look elsewhere too). In fact, I'd be 
willing to be that for just about every software security problem we've dealt, 
I could give you a design/spec level solution that would prevent it in general 
(and make auditing and so forth incredibly streamlined).

p.



~ ~  ~ ~~~ ~~ ~
Pravir Chandra  chandralistorg
PGP:CE60 0E10 9207 7290 06EB   5107 4032 63FC 338E 16E4
~ ~~ ~~~ ~  ~ ~

-Original Message-
From: "Goertzel, Karen [USA]" 

Date: Fri, 20 Mar 2009 10:06:46
To: Benjamin Tomhave; Secure Code Mailing 
List
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
Alchemist(informIT)


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

[Gunnar Peterson]

>
> 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 world.
> Based on what I see in CVE, it seems that the answer for item 2 is  
> usually
> for one component to choose to conform to another's expectations,  
> and that
> conforming component isn't always the one that "should" be changed.

Those are both definitely apparent at design time. Paraphrasing Bob  
Blakley, applications are built on composition, but most security  
protocols are point to point and don't compose. So anyone who bothers  
to look at the end to end application will see massive gaps in the  
security protocols.

The "fix" is likely a decision between a sts/federation/proxy pattern,  
and a way to link policy to mechanism. WS-SecurityPolicy provides one  
such way to do specify the policy side.

-gunnar


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___