Secure Coding mailing list archives

Re: Security Standard Branding & Expectation Checklists


From: "Jeff Williams @ Aspect" <jeff.williams () aspectsecurity com>
Date: Sun, 11 Jan 2004 16:29:42 +0000

I'm sensing two different approaches to application security/assurance here.
I'll call them "proven secure" and "no known flaws." They sound similar, but
under the hood they're completely different. Philosophically, it boils down
to whether you think the *absence* of a class or classes of vulnerabilities
is any measure of "assurance"?  Since new classes of flaws are discovered
very rarely, I believe that it is.

The "no known flaws" approach is almost diametrically opposed to the formal
modeling "proven secure" approach of the Orange Book and its progeny. The
problem of producing a formally secure design is so complex (expensive) that
all the emphasis in the proven secure approach is on the design. Yet many
(most?) of the security problems we have to deal with are implementation
problems that a formal design simply doesn't address.

The "no known flaws" approach sets out a list of vulnerabilties to avoid,
and forces developers to deal with them. This approach is more focused on
the implementation, although its effects trickle back throughout the
process, personnel, and design. The "no known flaws" approach puts exactly
the right incentives on the developers, as they have a concrete list of
vulnerabilities to avoid.

I think that it is quite possible and useful to produce a reasonable
standard/checklist/requirement that details the classes of vulnerabilities
that have been addressed in a system/product. For web applications, we built
the OWASP Top Ten to serve as just such a list
(http://www.owasp.org/documentation/topten).  I would be far more
comfortable with a web application designed and built to avoid that list of
problems than one with a CC evaluation.

I totally agree with Dave Wheeler's semi-rant that we can do far better than
we are doing today. Sure, in theory it's as hard as the Halting Problem, but
so is the *actual* halting problem, and we're still designing and building
plenty of useful software.

--Jeff

Jeff Williams
Aspect Security
http://www.aspectsecurity.com


----- Original Message ----- 
From: ljknews
To: [EMAIL PROTECTED]
Sent: Saturday, January 10, 2004 9:29 AM
Subject: RE: [SC-L] Security Standard Branding & Expectation Checklists


At 10:02 PM +0000 1/9/04, David Crocker wrote:

Although total security assurance is a hard problem, some sorts of security
assurance (e.g. freedom from buffer overflow vulnerabilities) are easy and
inexpensive to achieve, if the right development approach is taken and they
are
goals from the start.

If the right _language_choice_ is made, buffer overflows cannot cause
execution of attacker-provided code.








Current thread: