Secure Coding mailing list archives
Bugs and flaws
From: Arian.Evans at fishnetsecurity.com (Evans, Arian)
Date: Mon, 6 Feb 2006 09:52:54 -0600
Sent: Thursday, February 02, 2006 7:50 PM I'm sorry, but it is just not possible to find design flaws by staring at code. gem
That is simply not true. <anecdotal_examples> [...] (I originally wrote out some anecdotal stuffs here that on reflection implied more organizational issues with providing poor design specification, ...and leaving design up to implementation choices...than providing examples of design choices that are obvious from implementation review.) </anecdotal> So while I politely disagree, my insufficient examples reinforce that there is a slippery inference slope here. This has been one of the more stimulating dialogues on SCL; thanks. -ae p.s.--the original response bounced the list due to being subscribed under an older email alias.
-----Original Message----- From: Jeff Williams [mailto:jeff.williams at aspectsecurity.com] Sent: Thu Feb 02 20:32:29 2006 To: 'Secure Coding Mailing List' Subject: RE: [SC-L] Bugs and flaws At the risk of piling on here, there's no question that it's critical to consider security problems across the continuum. While we're at it, the analysis should start back even further with the requirements or even the whole system concept. All of the representations across the continuum (rqmts, arch, design, code) are just models of the same thing. They start more abstract and end up as code. A *single* problem could exist in all these models at the same time. Higher-level representations of systems are generally eclipsed by lower level ones fairly rapidly. For example, it's a rare group that updates their design docs as implementation progresses. So once you've got code, the architecture-flaws don't come from architecture documents (which lie). The best place to look for them (if you want truth) is to look in the code. To me, the important thing here is to give software teams good advice about the level of effort they're going to have to put into fixing a problem. If it helps to give a security problem a label to let them know they're going to have to go back to the drawing board, I think saying 'architecture-flaw' or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone doesn't help distinguish it from 'bug' in the minds of most developers or architects. --Jeff Jeff Williams, CEO Aspect Security http://www.aspectsecurity.com -----Original Message----- From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan Sent: Wednesday, February 01, 2006 5:07 PM To: John Steven Cc: Will Kruse; Secure Coding Mailing List Subject: Re: [SC-L] Bugs and flaws John Steven wrote:I'm not sure there's any value in discussing this minutiafurther, but heregoes:We'll let the moderator decide that :)1) Crispin, I think you've nailed one thing. The continuum from: Architecture --> Design --> Low-level Design --> (to) Implementation is a blurry one, and certainly slippery as you move from 'left' to'right'.Cool.But, we all should understand that there's commensurate blur in ouranalysistechniques (aka architecture and code review) to assurethat as we sweepover software that we uncover both bugs and architectural flaws.Also agreed.2) Flaws are different in important ways bugs when it comes topresentation,prioritization, and mitigation. Let's explore by physicalanalog first.I disagree with the word usage. To me, "bug" and "flaw" are exactly synonyms. The distinction being drawn here is between "implementation flaws" vs. "design flaws". You are just creating confusing jargon to claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect ::= bug. A vulnerability is a special subset of flaws/defects/bugs that has the property of being exploitable.I nearly fell through one of my consultant's tables as Ileaned on it thismorning. We explored: "Bug or flaw?".The wording issue aside, at the implementation level you try to code/implement to prevent flaws, by doing things such as using higher quality steel (for bolts) and good coding practices (for software). At the design level, you try to design so as to *mask* flaws by avoiding single points of failure, doing things such as using 2 bolts (for tables) and using access controls to limit privilege escalation (for software). 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 _______________________________________________ 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. -------------------------------------------------------------- -------------- _______________________________________________ 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
Current thread:
- Bugs and flaws, (continued)
- Bugs and flaws Gary McGraw (Feb 02)
- Bugs and flaws Jeff Williams (Feb 02)
- Bugs and flaws Gary McGraw (Feb 03)
- Bugs and flaws James Stibbards (Feb 03)
- Bugs and flaws Crispin Cowan (Feb 03)
- Bugs and flaws Dana Epp (Feb 03)
- Bugs and flaws Crispin Cowan (Feb 07)
- Bugs and flaws Gary McGraw (Feb 02)
- Bugs and flaws Nick FitzGerald (Feb 03)
- Bugs and flaws Brian Chess (Feb 03)
- Bugs and flaws Nick FitzGerald (Feb 03)
- Bugs and flaws Evans, Arian (Feb 06)
- Bugs and flaws Evans, Arian (Feb 06)
- Where to read about construction quality software ljknews (Feb 06)
- Bugs and flaws Gary McGraw (Feb 06)
- Bugs and flaws Jeff Williams (Feb 07)
- Bugs and flaws Julie Ryan (Feb 07)
- Bugs and flaws Gunnar Peterson (Feb 07)
- Bugs and flaws Jeff Williams (Feb 07)
- Bugs and flaws Gary McGraw (Feb 06)