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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Gary McGraw
Sent: Monday, February 06, 2006 11:13 PM
To: Brian Chess; sc-l@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:[EMAIL PROTECTED]
Sent: Sat Feb 04 00:56:16 2006
To: sc-l@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@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@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
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/
_______________________________________________
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