Re: [SC-L] Bugs and flaws
Kevin, Jeff Payne and I were talking about this last night. Jeff's position was, ...Or, you could just use the existing quality assurance terminology and avoid the problem altogether. I agree with you and him; standardizing terminology is a great start to obviating confusing discussions about what type of problem the software faces. Re-reading my post, I realize that it came off as heavy support for additional terminology. Truth is, we've found that the easiest way to communicate this concept to our Consultants and Clients here at Cigital has been to build the two buckets (flaws and bugs). What I was really trying to present was that Security people could stand to be a bit more thorough about how they synthesize the results of their analysis before they communicate the vulnerabilities they've found, and what mitigating strategies they suggest. I guess, in my mind, the most important things with regard to classifying the mistakes software people make that lead to vulnerability (the piety of vulnerability taxonomies aside) is to support: 1) Selection of the most effective mitigating strategy -and- 2) Root cause analysis that will result in changes in software development that prevent software folk from making the same mistake again. - John Steven Principal, Software Security Group Technical Director, Office of the CTO 703 404 5726 - Direct | 703 727 4034 - Cell Cigital Inc. | [EMAIL PROTECTED] 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 From: Wall, Kevin [EMAIL PROTECTED] John Steven wrote: ... 2) Flaws are different in important ways bugs when it comes to presentation, prioritization, and mitigation. Let's explore by physical analog first. Crispin Cowan responded: 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'm not sure if this will clarify things or further muddy the waters, but... partial definitions taken SWEBOK (http://www.swebok.org/ironman/pdf/Swebok_Ironman_June_23_%202004.pdf) which in turn were taken from the IEEE standard glossary (IEEE610.12-90) are: + Error: A difference.between a computed result and the correct result + Fault: An incorrect step, process, or data definition in a computer program + Failure: The [incorrect] result of a fault + Mistake: A human action that produces an incorrect result Not all faults are manifested as errors. I can't find an online version of the glossary anywhere, and the one I have is about 15-20 years old and buried somewhere deep under a score of other rarely used books. My point is though, until we start with some standard terminology this field of information security is never going to mature. I propose that we build on the foundational definitions of the IEEE-CS (unless there definitions have bugs ;-). -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] Bugs and flaws
Hi all, When I introduced the bugs and flaws nomenclature into the literature, I did so in an article about the software security workshop I chaired in 2003 (see http://www.cigital.com/ssw/). This was ultimately written up in an On the Horizon paper published by IEEE Security Privacy. Nancy Mead and I queried the SWEBOK and looked around to see if the new usage caused collision. It did not. The reason I think it is important to distinguish the two ends of the rather slippery range (crispy is right about that) is that software security as a field is not paying enough attention to architecture. By identifying flaws as a subcategory of defects (according the the SWEBOK), we can focus some attention on the problem. From the small glossary in Software Security (my new book out tomorrow): Bug-A bug is an implementation-level software problem. Bugs may exist in code but never be executed. Though the term bug is applied quite generally by many software practitioners, I reserve use of the term to encompass fairly simple implementation errors. Bugs are implementation-level problems that can be easily discovered and remedied. See Chapter 1. Flaw-A design-level or architectural software defect. High-level defects cause 50% of software security problems. See Chapter 1. In any case, I intend to still use these terms like this, and I would be very pleased if you would all join me. gem 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] Bugs and flaws
In the manufacturing world, which is far more mature than the software development world, they use the terminology of design defect and manufacturing defect. So this distinction is useful and has stood the test of time. Flaw and defect are synonymous. We should just pick one. You could say that the term for manufacturing software is implementation. So why do we need to change the terms for the software world? Wouldn't design defect and implementation defect be clearer and more in line with the manufacturing quality discipline, which the software quality discipline should be working towards emulating. (When do we get to Six Sigma?) I just don't see the usefulness of calling a design defect a flaw. Flaw by itself is overloaded. And in the software world, bug can mean an implementation or design problem, so bug alone is overloaded for describing an implementation defect. At @stake the Application Center of Excellence used the terminology design flaw and implementation flaw. It well understood by our customers. As Crispin said in an earlier post on the subject, the line is sometimes blurry. I am sure this is the case in manufacturing too. Architecture flaws can be folded into the design flaw category for simplicity. My vote is for a less overloaded and clearer terminology. -Chris P.S. My father managed a non-destructive test lab at a jet engine manufacturer. They had about the highest quality requirements in the world. So for many hours I was regaled with tales about the benefits of performing static analysis on individual components early in the manufacturing cycle. They would dip cast parts in a fluorescent liquid and look at them under ultraviolet light to illuminate cracks caused during casting process. For critical parts which would receive more stress, such as the fan blades, they would x-ray each part to inspect for internal cracks. A more expensive process but warranted due to the increased risk of total system failure for a defect in those parts. The static testing was obviously much cheaper and delivered better quality than just bolting the parts together and doing dynamic testing in a test cell. It's a wonder that it has taken the software security world so long to catch onto the benefits of static testing of implementation. I think we can learn a lot more from the manufacturing world. On Thu, 2 Feb 2006, Gary McGraw wrote: Hi all, When I introduced the bugs and flaws nomenclature into the literature, I did so in an article about the software security workshop I chaired in 2003 (see http://www.cigital.com/ssw/). This was ultimately written up in an On the Horizon paper published by IEEE Security Privacy. Nancy Mead and I queried the SWEBOK and looked around to see if the new usage caused collision. It did not. The reason I think it is important to distinguish the two ends of the rather slippery range (crispy is right about that) is that software security as a field is not paying enough attention to architecture. By identifying flaws as a subcategory of defects (according the the SWEBOK), we can focus some attention on the problem. From the small glossary in Software Security (my new book out tomorrow): Bug-A bug is an implementation-level software problem. Bugs may exist in code but never be executed. Though the term bug is applied quite generally by many software practitioners, I reserve use of the term to encompass fairly simple implementation errors. Bugs are implementation-level problems that can be easily discovered and remedied. See Chapter 1. Flaw-A design-level or architectural software defect. High-level defects cause 50% of software security problems. See Chapter 1. In any case, I intend to still use these terms like this, and I would be very pleased if you would all join me. gem 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] Bugs and flaws
Hi Weld, You make a very good point. I think we have lots to learn from manufacturing. As a matter of practice, I usually use the terms that you suggested as modifiers and say: implementation bug design flaw software defect As long as there is a clear way to separate the two ends of the slippery spectrum, I will be happy. But I'm still gonna say bug and flaw for short even when I mean the really long involved things above! Simplify. gem 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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] Bugs and flaws
Architecture is also an overloaded term, often meaning either a design (the output of architects) or the implementation of certain types of design (the output of engineers). Hoping to clarify Chris's comment on architecture flaws: architecture defects as in the defects in the output produced by architects are design flaws; architecture defects as in the defects in the output of programmers/coders/engineers are implementation flaws. FWIW, I agree with Chris, design flaw and implementation flaw seem better/more descriptive/less confusing than revised definitions for flaw and bug. (Then again, I once worked at @stake..., on the other hand, IIRC this terminology is more consistent with what you find in Ross Anderson's classic Security Engineering.) Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Wysopal Sent: Thursday, February 02, 2006 4:35 PM To: Gary McGraw Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws In the manufacturing world, which is far more mature than the software development world, they use the terminology of design defect and manufacturing defect. So this distinction is useful and has stood the test of time. Flaw and defect are synonymous. We should just pick one. You could say that the term for manufacturing software is implementation. So why do we need to change the terms for the software world? Wouldn't design defect and implementation defect be clearer and more in line with the manufacturing quality discipline, which the software quality discipline should be working towards emulating. (When do we get to Six Sigma?) I just don't see the usefulness of calling a design defect a flaw. Flaw by itself is overloaded. And in the software world, bug can mean an implementation or design problem, so bug alone is overloaded for describing an implementation defect. At @stake the Application Center of Excellence used the terminology design flaw and implementation flaw. It well understood by our customers. As Crispin said in an earlier post on the subject, the line is sometimes blurry. I am sure this is the case in manufacturing too. Architecture flaws can be folded into the design flaw category for simplicity. My vote is for a less overloaded and clearer terminology. -Chris P.S. My father managed a non-destructive test lab at a jet engine manufacturer. They had about the highest quality requirements in the world. So for many hours I was regaled with tales about the benefits of performing static analysis on individual components early in the manufacturing cycle. They would dip cast parts in a fluorescent liquid and look at them under ultraviolet light to illuminate cracks caused during casting process. For critical parts which would receive more stress, such as the fan blades, they would x-ray each part to inspect for internal cracks. A more expensive process but warranted due to the increased risk of total system failure for a defect in those parts. The static testing was obviously much cheaper and delivered better quality than just bolting the parts together and doing dynamic testing in a test cell. It's a wonder that it has taken the software security world so long to catch onto the benefits of static testing of implementation. I think we can learn a lot more from the manufacturing world. On Thu, 2 Feb 2006, Gary McGraw wrote: Hi all, When I introduced the bugs and flaws nomenclature into the literature, I did so in an article about the software security workshop I chaired in 2003 (see http://www.cigital.com/ssw/). This was ultimately written up in an On the Horizon paper published by IEEE Security Privacy. Nancy Mead and I queried the SWEBOK and looked around to see if the new usage caused collision. It did not. The reason I think it is important to distinguish the two ends of the rather slippery range (crispy is right about that) is that software security as a field is not paying enough attention to architecture. By identifying flaws as a subcategory of defects (according the the SWEBOK), we can focus some attention on the problem. From the small glossary in Software Security (my new book out tomorrow): Bug-A bug is an implementation-level software problem. Bugs may exist in code but never be executed. Though the term bug is applied quite generally by many software practitioners, I reserve use of the term to encompass fairly simple implementation errors. Bugs are implementation-level problems that can be easily discovered and remedied. See Chapter 1. Flaw-A design-level or architectural software defect. High-level defects cause 50% of software security problems. See Chapter 1. In any case, I intend to still use these terms like this, and I would be very pleased if you would all join me. gem This electronic message transmission contains information that
Re: [SC-L] Bugs and flaws
John Steven wrote: Re-reading my post, I realize that it came off as heavy support for additional terminology. Truth is, we've found that the easiest way to communicate this concept to our Consultants and Clients here at Cigital has been to build the two buckets (flaws and bugs). My main problem with this terminology is that I have only ever seen it coming from Cigital people. The rest of the world seems to treat flaw and bug as synonyms. The distinction here is between design flaw and implementation flaw. There doesn't seem to be anything in these words that suggest one is larger scale than the other. From dictionary.com we have: flaw^1 http://www.answers.com/flawr=67(flô) pronunciation /n./ 1. An imperfection, often concealed, that impairs soundness: /a flaw in the crystal that caused it to shatter./ See synonyms at blemish http://www.answers.com/main/ntquery;jsessionid=75e32c5vb2csr?method=4dsid=1555dekey=B0319900gwp=8curtab=1555_1sbid=lc04b. 2. A defect or shortcoming in something intangible: /They share the character flaw of arrogance./ 3. A defect in a legal document that can render it invalid. Bug http://www.answers.com/bugr=67 is a little more arcane, and the only relevant part is far down the document where it discusses the history with Grace Hopper: bug An unwanted and unintended property of a program or piece of hardware, esp. one that causes it to malfunction. Antonym of /feature/ http://www.answers.com/main/ntquery?method=4dsid=2291dekey=%2FF%2Ffeature.htmlgwp=8curtab=2291_1. Examples: “There's a bug in the editor: it writes things out backwards.” “The system crashed because of a hardware bug.” “Fred is a winner, but he has a few bugs” (i.e., Fred is a good guy, but he has a few personality problems). Historical note: Admiral Grace Hopper (an early computing pioneer better known for inventing /COBOL/ http://www.answers.com/main/ntquery?method=4dsid=2291dekey=%2FC%2FCOBOL.htmlgwp=8curtab=2291_1) liked to tell a story in which a technician solved a /glitch/ http://www.answers.com/main/ntquery?method=4dsid=2291dekey=%2FG%2Fglitch.htmlgwp=8curtab=2291_1 in the Harvard Mark II machine by pulling an actual insect out from between the contacts of one of its relays, and she subsequently promulgated /bug/ http://www.answers.com/main/ntquery?method=4dsid=2291dekey=%2FB%2Fbug.htmlgwp=8curtab=2291_1 in its hackish sense as a joke about the incident (though, as she was careful to admit, she was not there when it happened). For many years the logbook associated with the incident and the actual bug in question (a moth) sat in a display case at the Naval Surface Warfare Center (NSWC). The entire story, with a picture of the logbook and the moth taped into it, is recorded in the /Annals of the History of Computing/, Vol. 3, No. 3 (July 1981), pp. 285--286. What I was really trying to present was that Security people could stand to be a bit more thorough about how they synthesize the results of their analysis before they communicate the vulnerabilities they've found, and what mitigating strategies they suggest. Definitely. I think there is a deep cultural problem that people who fix bugs or flaws tend to over-focus on the micro issue, fixing the specific coding vulnerability, and ignore the larger architectural error that allows the coding defect to be exploitable and cause damage. In the case at hand, the WMF bug would be much less dangerous if there were not so many ways to induce IE to invoke WMF decoding without asking the user. 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@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] Administrative: whitelisting on SC-L
Hi SC-L folks: I don't mean to intrude in the bug and flaw debate, but I do want to make sure that you're all aware of the whitelisting that I'm doing on the list these days, since I switched the list management from Majordomo to Mailman. Specifically, in order to cut down on spam, I have Mailman set to drop any posting sent from _any_ address that is not explicitly subscribed to the list. That means, for example, if you subscribe via an email exploder or alias at your site, that your submissions get automatically /dev/nulled. The solution, for anyone that wants to post and is subscribed similarly to the above scenario, is to subscribe your personal address and set it to NOT receive SC-L postings. That way, your mail alias/exploder will continue to function as you set it up, AND you'll be able to post. Since I get ZERO notification when messages (mostly spam) are dropped by the whitelist, I have no way of knowing who is in this situation. So, if you want the ability to post, drop me a note and I'll be happy to set you up with a no-mail subscription. (Don't worry, you won't/shouldn't get duplicates.) Cheers, Ken van Wyk SC-L Moderator ___ 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
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 minutia further, but here goes: 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 our analysis techniques (aka architecture and code review) to assure that as we sweep over software that we uncover both bugs and architectural flaws. Also agreed. 2) Flaws are different in important ways bugs when it comes to presentation, prioritization, and mitigation. Let's explore by physical analog 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 I leaned on it this morning. 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@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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] Bugs and flaws
I spent Phase One of both my academic and professional careers working on hardware fault models and design for testability. In fact, the first static analysis tool I wrote was for hardware: it analyzed Verilog looking for design mistakes that would make it difficult or impossible to perform design verification or to apply adequate manufacturing tests. Some observations: - The hardware guys are indeed ahead. Chip designers budget for test and verification from day one. They also do a fair amount of thinking about what's going to go wrong. Somebody's going to give you 5 volts instead of 3.3 volts. What's going to happen? The transistors are going to switch at a different rate when the chip is cold. What's going to happen? A speck of dust is going to fall on the wafer between the time the metal 2 layer goes down and the time the metal 3 layer goes down. What's going to happen? - The difference between a manufacturing defect and a design defect is not always immediately obvious. Maybe two wires got bridged because a piece of dust fell in exactly the right spot. Maybe two wires got bridged because you made a mistake in your process physics and you need 50 nm of tolerance instead of 0.5 nm. You'd better figure it out before you go into full-swing manufacturing, or big batches of defective chips could kill your profit margins and drive your customers away at the same time. For that reason, diagnosing the cause of failure is an important topic. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Wysopal Sent: 02 February 2006 21:35 To: Gary McGraw Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws In the manufacturing world, which is far more mature than the software development world, they use the terminology of design defect and manufacturing defect. So this distinction is useful and has stood the test of time. Flaw and defect are synonymous. We should just pick one. You could say that the term for manufacturing software is implementation. So why do we need to change the terms for the software world? Wouldn't design defect and implementation defect be clearer and more in line with the manufacturing quality discipline, which the software quality discipline should be working towards emulating. (When do we get to Six Sigma?) I just don't see the usefulness of calling a design defect a flaw. Flaw by itself is overloaded. And in the software world, bug can mean an implementation or design problem, so bug alone is overloaded for describing an implementation defect. At @stake the Application Center of Excellence used the terminology design flaw and implementation flaw. It well understood by our customers. As Crispin said in an earlier post on the subject, the line is sometimes blurry. I am sure this is the case in manufacturing too. Architecture flaws can be folded into the design flaw category for simplicity. My vote is for a less overloaded and clearer terminology. -Chris P.S. My father managed a non-destructive test lab at a jet engine manufacturer. They had about the highest quality requirements in the world. So for many hours I was regaled with tales about the benefits of performing static analysis on individual components early in the manufacturing cycle. They would dip cast parts in a fluorescent liquid and look at them under ultraviolet light to illuminate cracks caused during casting process. For critical parts which would receive more stress, such as the fan blades, they would x-ray each part to inspect for internal cracks. A more expensive process but warranted due to the increased risk of total system failure for a defect in those parts. The static testing was obviously much cheaper and delivered better quality than just bolting the parts together and doing dynamic testing in a test cell. It's a wonder that it has taken the software security world so long to catch onto the benefits of static testing of implementation. I think we can learn a lot more from the manufacturing world. On Thu, 2 Feb 2006, Gary McGraw wrote: Hi all, When I introduced the bugs and flaws nomenclature into the literature, I did so in an article about the software security workshop I chaired in 2003 (see http://www.cigital.com/ssw/). This was ultimately written up in an On the Horizon paper published by IEEE Security Privacy. Nancy Mead and I queried the SWEBOK and looked around to see if the new usage caused collision. It did not. The reason I think it is important to distinguish the two ends of the rather slippery range (crispy is right about that) is that software security as a field is not paying enough attention to architecture. By identifying flaws as a subcategory of defects (according the the SWEBOK), we can focus some attention on the problem. From the small glossary in Software Security (my new book out tomorrow): Bug-A bug is an implementation-level software problem. Bugs
RE: [SC-L] Bugs and flaws
I'm sorry, but it is just not possible to find design flaws by staring at code. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 minutia further, but here goes: 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 our analysis techniques (aka architecture and code review) to assure that as we sweep over software that we uncover both bugs and architectural flaws. Also agreed. 2) Flaws are different in important ways bugs when it comes to presentation, prioritization, and mitigation. Let's explore by physical analog 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 I leaned on it this morning. 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@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@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
RE: [SC-L] Bugs and flaws
Um, so if there is no documentation you can't find design flaws? --Jeff -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 8:50 PM To: Jeff Williams; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws I'm sorry, but it is just not possible to find design flaws by staring at code. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 minutia further, but here goes: 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 our analysis techniques (aka architecture and code review) to assure that as we sweep over software that we uncover both bugs and architectural flaws. Also agreed. 2) Flaws are different in important ways bugs when it comes to presentation, prioritization, and mitigation. Let's explore by physical analog 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 I leaned on it this morning. 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@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@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,
RE: [SC-L] Bugs and flaws
Not unless you talk to the designer. You might get lucky and find a design problem or two by looking at code, but that usually doesn't work. That's not to say that all systems have adequate documentation about design (not to mention requirements that you correctly cited before)! They don't. When they don't, you have to try to construct them. Doing them from code is very difficult at best. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] Sent: Thu Feb 02 20:59:14 2006 To: Gary McGraw; 'Secure Coding Mailing List' Subject:RE: [SC-L] Bugs and flaws Um, so if there is no documentation you can't find design flaws? --Jeff -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 8:50 PM To: Jeff Williams; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws I'm sorry, but it is just not possible to find design flaws by staring at code. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 minutia further, but here goes: 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 our analysis techniques (aka architecture and code review) to assure that as we sweep over software that we uncover both bugs and architectural flaws. Also agreed. 2) Flaws are different in important ways bugs when it comes to presentation, prioritization, and mitigation. Let's explore by physical analog 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 I leaned on it this morning. 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@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)
RE: [SC-L] Bugs and flaws
That's not my experience. I believe there are many design problems you can find more quickly and, more importantly, accurately by using the code. I find this to be true even when there is a documented design -- but there's no question in the case where all you have is code. In fact, if the design isn't fairly obvious in the code, then that's a security problem in itself. Unless it's clear, developers won't understand it and will make more mistakes. Static analysis tools can help a lot here. Used properly, they can provide design-level insight into a software baseline. The huge advantage is that it's correct. --Jeff -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 9:06 PM To: [EMAIL PROTECTED]; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws Not unless you talk to the designer. You might get lucky and find a design problem or two by looking at code, but that usually doesn't work. That's not to say that all systems have adequate documentation about design (not to mention requirements that you correctly cited before)! They don't. When they don't, you have to try to construct them. Doing them from code is very difficult at best. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] Sent: Thu Feb 02 20:59:14 2006 To: Gary McGraw; 'Secure Coding Mailing List' Subject:RE: [SC-L] Bugs and flaws Um, so if there is no documentation you can't find design flaws? --Jeff -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 8:50 PM To: Jeff Williams; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws I'm sorry, but it is just not possible to find design flaws by staring at code. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 minutia further, but here goes: 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 our analysis techniques (aka architecture and code review) to assure that as we sweep over software that we uncover both bugs and architectural flaws. Also agreed. 2) Flaws are different in important ways bugs when it comes to presentation, prioritization, and mitigation. Let's explore by physical analog 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 I leaned on it this morning. 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
RE: [SC-L] Bugs and flaws
In the manufacturing world, manufacturing defects are defects that were not intended by the design. With software, an implementation defect is a defect that is not indended by the design. That is where I see the analogy. A factory worker forgetting to put on a washer or installing a polarized capacitor backwards is similar to a programmer neglecting to check a return code or being off by one in a length calculation. In both disciplines, to increase quality you could say don't do that, you could add a quality process that tests for the correct implementation, or best, you could make it impossible for the mistake to happen. So I guess I see a lot of similarities between the manufacturing process and the software implementation process. Sure its not a perfect analogy. Nothing seems to be between the physical and digital worlds. As you say, many of the flaws created during what is traditionally known as implementation are low-level design errors but at the very end of the continuum they are simply mistakes. -Chris On Thu, 2 Feb 2006, David Crocker wrote: I don't think this analogy between software development and manufacturing holds. There are no manufacturing defects in software construction, unless one counts a buggy chip (e.g. Pentium FPU or similar) or perhaps a buggy compiler. Software instructions execute predictably and are not subject to the problems of defective materials, difficulties in keeping dimensions within a precise tolerance, or wear and tear. If some small bolt in my car fails because the bolt met its manufacturer's specification but was not strong enough to withstand the loads it was subjected to, that is a low-level design error, not a manufacturing error. Similarly, I view coding errors as low-level design errors. David Crocker, Escher Technologies Ltd. Consultancy, contracting and tools for dependable software development www.eschertech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Wysopal Sent: 02 February 2006 21:35 To: Gary McGraw Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws In the manufacturing world, which is far more mature than the software development world, they use the terminology of design defect and manufacturing defect. So this distinction is useful and has stood the test of time. Flaw and defect are synonymous. We should just pick one. You could say that the term for manufacturing software is implementation. So why do we need to change the terms for the software world? Wouldn't design defect and implementation defect be clearer and more in line with the manufacturing quality discipline, which the software quality discipline should be working towards emulating. (When do we get to Six Sigma?) I just don't see the usefulness of calling a design defect a flaw. Flaw by itself is overloaded. And in the software world, bug can mean an implementation or design problem, so bug alone is overloaded for describing an implementation defect. At @stake the Application Center of Excellence used the terminology design flaw and implementation flaw. It well understood by our customers. As Crispin said in an earlier post on the subject, the line is sometimes blurry. I am sure this is the case in manufacturing too. Architecture flaws can be folded into the design flaw category for simplicity. My vote is for a less overloaded and clearer terminology. -Chris P.S. My father managed a non-destructive test lab at a jet engine manufacturer. They had about the highest quality requirements in the world. So for many hours I was regaled with tales about the benefits of performing static analysis on individual components early in the manufacturing cycle. They would dip cast parts in a fluorescent liquid and look at them under ultraviolet light to illuminate cracks caused during casting process. For critical parts which would receive more stress, such as the fan blades, they would x-ray each part to inspect for internal cracks. A more expensive process but warranted due to the increased risk of total system failure for a defect in those parts. The static testing was obviously much cheaper and delivered better quality than just bolting the parts together and doing dynamic testing in a test cell. It's a wonder that it has taken the software security world so long to catch onto the benefits of static testing of implementation. I think we can learn a lot more from the manufacturing world. On Thu, 2 Feb 2006, Gary McGraw wrote: Hi all, When I introduced the bugs and flaws nomenclature into the literature, I did so in an article about the software security workshop I chaired in 2003 (see http://www.cigital.com/ssw/). This was ultimately written up in an On the Horizon paper published by IEEE Security Privacy. Nancy Mead and I queried the SWEBOK and looked around to see if
