Secure Coding mailing list archives
(Software Risk)--was-->Bugs and flaws
From: Arian.Evans at fishnetsecurity.com (Evans, Arian)
Date: Wed, 8 Feb 2006 12:36:32 -0600
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, letstalk aboutthe WMF flaw in particular. Do we believe that the best way for Microsoft to find similar design problems is to do codereview? Orshould they use a higher level approach? Were they correct in saying (officially) that flaws such asWMF are hardto anticipate?I have heard some very insightful security researchers fromMicrosoftpushing an abstract notion of "attack surface", which isthe amount ofcode/data/API/whatever that is exposed to the attacker. Todesign forsecurity, 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 withparametersprovided 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. -------------------------------------------------------------- --------------
Current thread:
- (Software Risk)--was-->Bugs and flaws Evans, Arian (Feb 08)