Bugs and flaws

[jjchryan at gwu.edu (Julie Ryan)]

8 principles with 2 more from physical security that "apply only  
imperfectly to computer systems"

http://www.cap-lore.com/CapTheory/ProtInf/Basic.html


On Feb 7, 2006, at 9:59 AM, Jeff Williams wrote:

> I'm not sure which of the three definitions in Brian's message you're  
> not
> concurring with, but I think he was only listing them as strawmen  
> anyway.
>
> In any case, there's no reason that static analysis tools shouldn't be  
> able
> to find errors of omission. We use our tools to find these 'dogs that  
> didn't
> bark' every day.
>
> The tools can identify, for example, places where logging, input  
> validation,
> and error handling should have been done. With a little work teaching  
> the
> tool about your application, assets, and libraries, it's easy to find  
> places
> where encryption, access control, and authentication should have been  
> done
> but haven't.
>
> In your hypothetical, if the API isn't ever invoked with an identity  
> and a
> secret, there can't be authentication. If there's no call to an access
> control component, we know at least that there's no centralized  
> mechanism.
> In this case, the tool could check whether the code follows the  
> project's
> standard access control pattern. If not, it's an error of omission.
>
> If I remember correctly, Saltzer and Schroeder only suggested 8  
> principles.
> Your hypo is closest to complete mediation, but touches on several  
> others.
> But, in theory, there's no reason that static analysis can't help  
> verify all
> of them in an application.
>
> --Jeff
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org  
> [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Gary McGraw
> Sent: Monday, February 06, 2006 11:13 PM
> To: Brian Chess; sc-l at securecoding.org
> Subject: RE: [SC-L] Bugs and flaws
>
> Hi all,
>
> I'm afraid I don't concur with this definition.  Here's a (rather  
> vague)
> flaw example that may help clarify what I mean.  Think about an error  
> of
> omission where an API is exposed with no A&A protection whatsoever.   
> This
> API may have been designed not to have been exposed originally, but  
> somehow
> became exposed only over time.
>
> How do you find errors of omission with a static analysis tool?
>
> This is only one of salzer and schroeder's principles in action.  What  
> of
> the other 9?
>
> gem
>
> P.s. Five points to whoever names the principle in question.
>
> P.p.s. The book is out www.swsec.com
>
>  -----Original Message-----
> From:         Brian Chess [mailto:brian at fortifysoftware.com]
> Sent: Sat Feb 04 00:56:16 2006
> To:   sc-l at securecoding.org
> Subject:      RE: [SC-L] Bugs and flaws
>
> The best definition for "flaw" and "bug" I've heard so far is that a  
> flaw is
> a successful implementation of your intent, while a bug is  
> unintentional.  I
> think I've also heard "a bug is small", a flaw is big", but that  
> definition
> is awfully squishy.
>
> If the difference between a bug and a flaw is indeed one of intent,  
> then I
> don't think it's a useful distinction.  Intent rarely brings with it  
> other
> dependable characteristics.
>
> I've also heard "bugs are things that a static analysis tool can  
> find", but
> I don't think that really captures it either.  For example, it's easy  
> for a
> static analysis tool to point out that the following Java statement  
> implies
> that the program is using weak cryptography:
>
>     SecretKey key = KeyGenerator.getInstance("DES").generateKey();
>
> Brian
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
Julie J.C.H. Ryan, D.Sc.
Assistant Professor
Engineering Management and System Engineering
George Washington University

An NSA certified Center of Academic Excellence in Information Assurance  
Education

http://www.seas.gwu.edu/~jjchryan/
http://www.seas.gwu.edu/~infosec/