(Software Risk)--was-->Bugs and flaws

[Arian.Evans at fishnetsecurity.com (Evans, Arian)]

Before I go further, the second version of the email below
(the rewritten & readable one that made the list) has some
specific outlines and questions...there is *clearly* much
common ground here but lacking a standardized frame of reference
for language...how do we go about shoring up our terminology?

IEEE? Whitepaper? Wait until a book seeps into our collective
dialogue (if)? Completely unrealistic goal?

Per Risk, I think we have no business discussing Risk in this
context, and I avidly delete it from any scope of work I get my
hands on; we can provide raw material to enhance accuracy of Risk
analysis, but IRL Risk != CISSP def (threat of loss * likelihood
of occurrence * 3.14159). Risk = Loss (or impact, which ultimately
leads to some form of loss) to any C lvl or internal audit function.

The breakdown I have been using is RTAWV...the definitions are
currently liquid and running:

Risk (loss or impact (which usually results in loss in the long run))

Threat (what is the potential issue that creates Risk, implication of an attack?)

Attack (what vehicle to actualize a Threat; exploit vector)

Weakness (what is the pattern/condition that results in potential for Attackability?
...or, "why" can a thing be exploited and how did it get that way?)

Vulnerability (what is the particular (unique or plural instance) that can be exploited)

----

Here is a rough webified example:

Risk
Financial Loss, Repudiation, Market Goodwill (impact == loss == $$$$$)

Threat
Elevation of Privilege; Forged Transaction

Attack (A: Spoofing of User Identity)
A1 Session Fixation
A1-2 Session Token Multiple Entity Re-use

Weakness
Insecure Authorization Mechanism; session tokens not tied to authentication state
Insecure Session Handling; session tokens lack relative and absolute use conditions,
and have no entity-use restrictions

Vulnerability(ies)
Session token set a priori authentication on page X
Session token infinite harvesting by unique entity (IP) on pages X,Y

Architecture:
If there is a finding here, it is more along the lines of "you picked a
framework that abstracts the session handling to an object level that
provides you no visibility or manual control over what goes on under the
hood, and you have no technical specification concerning session handling
other than "sticky, and no explicitly defined security goals"

Implementation:
Clearly, there several simple implementation issues here, and maybe a few
tricky ones if you don't keep session state in a db or somewhere that you
can easily perform some correlation between A&A and entity & actual session
tokens in use (the cookies, perhaps).

Thoughts?

I am ultimately concerned about how we standardize the technical
language (e.g.-defect analysis and categorization discussion) since
the business language already exists.

-ae




> -----Original Message-----
> From: Gary McGraw [mailto:gem at cigital.com] 
> Sent: Monday, February 06, 2006 10:13 PM
> To: Evans, Arian; Crispin Cowan; Secure Coding Mailing List; 
> Kenneth R. van Wyk
> Subject: RE: [SC-L] Bugs and flaws
>
>
> I'm with you on this threat modeling thing...which is the 
> process  meant to lay flaws bare.  I like to call it "risk 
> analysis" of course (using american war nomenclature instead 
> of british/australian).  STRIDE is an important step in the 
> right direction, but a checklist approach has essential 
> creativity constraints worth pondering.
>
> My only point in making the distinction clear (bugs vs flaws) 
> is to make sure that we don't forget design, requirements, 
> and early lifecycle artifacts in our rush to analyze code.
>
> Please do both (touchpoints 1 and 2 in Software Security).
>
> gem
>
>  -----Original Message-----
> From:         Evans, Arian [mailto:Arian.Evans at fishnetsecurity.com]
> Sent: Fri Feb 03 18:29:29 2006
> To:   Crispin Cowan; Gary McGraw; Secure Coding Mailing List; 
> Kenneth R. van Wyk
> Subject:      RE: [SC-L] Bugs and flaws
>
> per WMF// Let's face it, this was legacy, possibly deprecated 
> code that
> was likely low on the security things-to-do list. I suspect 
> MS, like the
> rest of the world, has resource limitations regarding 
> analyzing all their
> various product/api entry points for security implications.
>
> Which is one of the reasons I think threat modeling came in 
> vogue, and I
> think a threat model would flag this in bright red for review, but you
> need resources with quite a bit of knowledge and time to 
> build that model,
> and again, since this was legacy functionality...
>
> fyi// on attack surface: http://www-2.cs.cmu.edu/~wing/
>
> There are several ppls that have done nice work here; it fits 
> hand-in-glove
> with threat modeling concepts, which fits hand in glove with 
> this whole
> equivocal dialogue about design/implementation verbiage.
>
> This whole discussion underscores the real issue we have, which is
> a common language.
>
> So how to fix it? A taxonomy and terminology guide; simple, concise.
>
> There's plenty of folks on this list a lot smarter than I am, so it is
> nice to see that a majority agree on what I think the key issues are:
> communicating (a) accurate and (b) actionable data, or expanded:
>
> 1. Defect Definition
> 2. Defect Classification
> 3. Defect Identification
> 4. Defect Implication (communicating defect implication as goal)
>
> By example I mean:
>
> 1. Format String, weak crypto use, define what & why are 
> these security defects?
> 2. Implementation Defect, Design Defect, bug, flaw, blah
> 3. How do we identify these defects in software?
> 4. Implication: RTAWV (Risk, Threat, Attack, Weakness, Vuln) 
> & communication
> to both technical, and non-technical audience.
>
> I added Weakness at the TRIKE group's suggestion, and it has 
> significantly
> helped in classification instead of using two confusing vuln 
> categories.
>
> There is obviously a many-to-one mapping between 
> threat->attack<-weakness
> and even from vuln to weakness, depending on how we define 
> vuln. (I have
> defined vuln as "a particular instance or attackable instance 
> of a weakness").
>
> This is *valuable* information to the person trying to solve 
> issues in this
> problem domain, but I rarely find it well understood by 
> non-appsec folks.
>
> I have attempted to address and communicate this in a short 
> paper titled:
> ::Taxonomy of Software Security Analysis Types:: 
>
> (Software Security Analysis == defined as == Software 
> Analysis for Defects
> with Security Implications, implications being contextual.)
>
> Is significantly weakened if at the end of the day no one 
> knows what I mean
> by design weakness, implementation defect, goblins, etc. So I 
> will need
> all your help in shoring up the language.
>
> My reason for distinction of "security as a defect 
> implication" is that
> defects are sometimes clear; the implications are not always 
> clear and do
> not always follow from the defects. Defects are neither a 
> necessary nor
> sufficient condition for security implications (obviously), but it the
> implications most people solving problems care about, not 
> defect language.
>
> Much of this is underscored in the IEEE software defect 
> terminology, but
> look at our current industry ambiguity between attacks and 
> vulnerabilities!
>
> I continue to encounter wildly equivocal uses of the words 
> Threat, Attack,
> Vulnerability, Flaw, Defect, Artifact (and associated phrases 
> like "security-
> artifact"), Fault, Bug, Error, Failure, Mistake, MFV 
> (multi-factor vulnerability)
> in our collective software security dialogue and literature.
>
> I am *not* *married* to any particular verbiage; my goal is a common
> language so we can have more effective dialogue,
>
> Arian J. Evans
> FishNet Security
>
> 816.421.6611 [fns office]
> 816.701.2045 [direct] <--limited access
> 888.732.9406 [fns toll-free]
> 816.421.6677 [fns general fax]
> 913.710.7045 [mobile] <--best bet
> aevans at fishnetsecurity.com [email]
>
> http://www.fishnetsecurity.com
>
>
>
>
>
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org 
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
> > Sent: Friday, February 03, 2006 2:12 PM
> > To: Gary McGraw
> > Cc: Kenneth R. van Wyk; Secure Coding Mailing List
> > Subject: Re: [SC-L] Bugs and flaws
> >
> >
> > Gary McGraw wrote:
> > > To cycle this all back around to the original posting, lets 
> > talk about
> > > the WMF flaw in particular.  Do we believe that the best way for
> > > Microsoft to find similar design problems is to do code 
> review?  Or
> > > should they use a higher level approach?
> > >
> > > Were they correct in saying (officially) that flaws such as 
> > WMF are hard
> > > to anticipate? 
> > >   
> > I have heard some very insightful security researchers from 
> Microsoft
> > pushing an abstract notion of "attack surface", which is 
> the amount of
> > code/data/API/whatever that is exposed to the attacker. To 
> design for
> > security, among other things, reduce your attack surface.
> >
> > The WMF design defect seems to be that IE has too large of an attack
> > surface. There are way too many ways for unauthenticated remote web
> > servers to induce the client to run way too much code with 
> parameters
> > provided by the attacker. The implementation flaw is that the 
> > WMF API in
> > particular is vulnerable to malicious content.
> >
> > None of which strikes me as surprising, but maybe that's just me :)
> >
> > Crispin
> > -- 
> > Crispin Cowan, Ph.D.                      
> > http://crispincowan.com/~crispin/
> > Director of Software Engineering, Novell  http://novell.com
> >     Olympic Games: The Bi-Annual Festival of Corruption
> >
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc - 
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - 
> > http://www.securecoding.org/list/charter.php
>
>
>
>
> --------------------------------------------------------------
> --------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein 
> is intended
> solely for the recipient and use by any other party is not 
> authorized.  If
> you are not the intended recipient (or otherwise authorized 
> to receive this
> message by the intended recipient), any disclosure, copying, 
> distribution or
> use of the contents of the information is prohibited.  If you 
> have received
> this electronic message transmission in error, please contact 
> the sender by
> reply email and delete all copies of this message.  Cigital, 
> Inc. accepts no
> responsibility for any loss or damage resulting directly or 
> indirectly from
> the use of this email or its contents.
> Thank You.
> --------------------------------------------------------------
> --------------