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:
- Security Standard Branding & Expectation Checklists Jared W. Robinson (Jan 07)
- Re: Security Standard Branding & Expectation Checklists Brett Hutley (Jan 08)
- Re: Security Standard Branding & Expectation Checklists Crispin Cowan (Jan 08)
- Re: Security Standard Branding & Expectation Checklists Jared W. Robinson (Jan 08)
- Re: Security Standard Branding & Expectation Checklists Crispin Cowan (Jan 09)
- RE: Security Standard Branding & Expectation Checklists David Crocker (Jan 10)
- RE: Security Standard Branding & Expectation Checklists ljknews (Jan 10)
- Re: Security Standard Branding & Expectation Checklists Jeff Williams @ Aspect (Jan 11)
- Re: Security Standard Branding & Expectation Checklists Jared W. Robinson (Jan 08)