Re: [SC-L] RE: The role static analysis tools play in uncovering elements of design

2006-02-07 Thread Crispin Cowan
Jeff Williams wrote:
 I think there's a lot more that static analysis can do than what you're
 describing. They're not (necessarily) just fancy pattern matchers.
 ...
 Today's static analysis tools are only starting to help here. Tools focused
 on dumping out a list of vulnerabilities don't work well for me. Too many
 false alarms.  Maybe that's what you meant by 'inhibit'.
   
In the general case, I think that any kind of analysis tool (static
analyzer, fuzzing tool, debugger, whatever) focuses the analyst's
attention on whatever aspects the tool author thought was important.
Whether this is a good or bad thing depends on whether you agree with
the author.

Using no tools at all just imposes a different bias filter, as humans
are (relatively) good at spotting some kinds of patterns, and not others.

Crispin

 --Jeff
  
 Jeff Williams, CEO
 Aspect Security
 http://www.aspectsecurity.com
 email: [EMAIL PROTECTED]
 phone: 410-707-1487
  
 
 From: John Steven [mailto:[EMAIL PROTECTED] 
 Sent: Friday, February 03, 2006 1:40 PM
 To: Jeff Williams; Secure Coding Mailing List
 Subject: The role static analysis tools play in uncovering elements of
 design 

 Jeff,

 An unpopular opinion I’ve held is that static analysis tools, while very
 helpful in finding problems, inhibit a reviewer’s ability to find collect as
 much information about the structure, flow, and idiom of code’s design as
 the reviewer might find if he/she spelunks the code manually.

 I find it difficult to use tools other than source code navigators (source
 insight) and scripts to facilitate my code understanding (at the
 design-level). 

 Perhaps you can give some examples of static analysis library/tool use that
 overcomes my prejudice—or are you referring to the navigator tools as well?

 -
 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

   
 snipped
 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 
 snipped
 
 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
   

-- 
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] RE: The role static analysis tools play in uncovering elements of design

2006-02-05 Thread Brian Chess
Jeff Williams [EMAIL PROTECTED] wrote:

 I think there's a lot more that static analysis can do than what you're
 describing. They're not (necessarily) just fancy pattern matchers.


Jeff, you raise a important point.  Getting good value out of static
analysis requires a second component in addition to a fancy pattern
matcher.  You also need a good set of fancy patterns (aka rules)
to match against.

Understand that when I say ³fancy pattern², I don¹t mean ³regular
expression².  More formally, I mean program property.  Taint
propagation, state transitions, feasible control flow paths,
alias analysis, etc. are all important if you¹d like to build
a tool, but if you¹re contemplating how to best apply a tool,
all of your interaction will be of the form

³Show me places in the program where property X holds²

and the goal of the tool is to match the code against the property
you've specified.  For a good initial user experience, a tool
needs to come with a well-constructed default set of rules.  For
aiding in program understanding, it needs to allow you to easily
add new rules of your own construction.

The number of false alarms you get from a good static analysis
tool is directly related to how aggressive the tool is in finding
constructs that might be what you're looking for. As an example, I'll
use a question you posed: are there any paths around the
encryption?  If you're going to bet your life that there aren't
any such paths, then you'd like the tool to make conservative
assumptions and allow you to manually review anything that might
possibly match the pattern you've specified. If you only have a
passing interest in the property, then you'd prefer the tool weed
out paths that, while not impossible, are not likely to be of
interest.  Maybe some code will help illustrate my point:

  if (b) {
panic();
  else {
buf = encrypt(buf);
  }
  return buf;

Would you like to be warned that buf may be returned unencrypted?
This code fragment guarantees that either buf is encrypted or
panic() is called.  But usually control doesn't return from a
function named panic().  The problem is, that's not universally
true; sometimes panic() just sets a flag and the system reboot
happens shortly thereafter.

Whether or not you want to see this path depends on how important
it really is to you that encryption is absolutely never bypassed.
Your tolerance for noise is dictated by the level of assurance
you require.

Brian


___
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] RE: The role static analysis tools play in uncovering elements of design

2006-02-04 Thread Jeff Williams
I think there's a lot more that static analysis can do than what you're
describing. They're not (necessarily) just fancy pattern matchers.

Static analysis can add security meta-information to a software baseline. If
the tool knows which methods are related to which security mechanisms, it
can help you find, navigate, and understand their design. The tools help me
generate a security 'view' of a software baseline.

Does the application do encryption? Is it centralized? What algorithms are
used? What data flows are affected? Are there any paths around the
encryption? Where are the keys stored? Is there proper error handling and
logging for the encryption mechanism? Static analysis tools make answering
all these questions easier.

Today's static analysis tools are only starting to help here. Tools focused
on dumping out a list of vulnerabilities don't work well for me. Too many
false alarms.  Maybe that's what you meant by 'inhibit'.

--Jeff
 
Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com
email: [EMAIL PROTECTED]
phone: 410-707-1487
 

From: John Steven [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 03, 2006 1:40 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: The role static analysis tools play in uncovering elements of
design 

Jeff,

An unpopular opinion I’ve held is that static analysis tools, while very
helpful in finding problems, inhibit a reviewer’s ability to find collect as
much information about the structure, flow, and idiom of code’s design as
the reviewer might find if he/she spelunks the code manually.

I find it difficult to use tools other than source code navigators (source
insight) and scripts to facilitate my code understanding (at the
design-level). 

Perhaps you can give some examples of static analysis library/tool use that
overcomes my prejudice—or are you referring to the navigator tools as well?

-
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

  
snipped
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 
snipped

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