Technology-specific Security Standards

[list-procurare at secureconsulting.net (Benjamin Tomhave)]

In my experience, a tiered approach is useful.  The higher up you are in the
policy framework, the more general and time-enduring the content should be.
The farther you progress down the framework to a more detailed level, the
more perishable the content will be, out of necessity.  The reason that
we've adopted specific guidance bound at the technical level is because
implementers need it.  They're not security experts (usually) and do not
necessarily grok security the same way a seasoned (salty?) security person
might.

A couple colleagues and I actually chatted about this around the same time
that the original message here is timestamped, in the context of application
security standards.  The approach we're planning to adopt is to provide
good, minimally-specific guidance in our formal standards documents (e.g.
"implement input validation") and the produce living implementation guides
(possibly in a wiki form) that can be referenced in relation to the
standards.  We'll see how this works in reality, but it seems to be a nice
mix in theory between provide specific requirements without getting so far
into the weeds that it will require constant rewriting as the underlying
technologies change.

fwiw.

-ben

---
Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM
falcon at secureconsulting.net
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/

"We must scrupulously guard the civil rights and civil liberties of all
citizens, whatever their background. We must remember that any oppression,
any injustice, any hatred is a wedge designed to attack our civilization."
-President Franklin Delano Roosevelt
 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of John Steven
> Sent: Wednesday, May 23, 2007 2:39 PM
> To: SC-L at securecoding.org
> Subject: [SC-L] Technology-specific Security Standards
>
> All,
>
> My last two posts to Cigital's blog covered whether or not to 
> build your security standards specific to a technology-stack 
> and code-centric or to be more general about them:
>
> http://www.cigital.com/justiceleague/2007/05/18/security-guida
> nce-and-its-%e
> 2%80%9cspecificity-knob%e2%80%9d/
>
> And
>
> http://www.cigital.com/justiceleague/2007/05/21/how-to-write-g
> ood-security-g
> uidance/
>
> Dave posted a comment on the topic, which I'm quoting here:
> -----
> Your point about the ?perishability? of such prescriptive 
> checklists does make the adoption of such a program fairly 
> high maintenance. Nothing wrong with that, but expectations 
> should be set early that this would not be a fire and forget 
> type of program, but rather an ongoing investment.
> -----
>
> I agree, specifying guidance at this level does take a lot 
> more effort; you get what you pay for eh? I responded in turn 
> with a comment of my own. I've seen some organizations 
> control this cost effectively and still get value:
>
> See:
> http://www.cigital.com/justiceleague/2007/05/18/security-guida
> nce-and-its-%e
> 2%80%9cspecificity-knob%e2%80%9d/#comment-1048
>
> Some people think my stand controversial...
>
> What do you guys think?
>
> ----
> John Steven
> Technical Director; Principal, Software Security Group
> Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 
> 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>
> Blog: http://www.cigital.com/justiceleague
> Papers: http://www.cigital.com/papers/jsteven
>
> http://www.cigital.com
> Software Confidence. Achieved.
>
>
> _______________________________________________
> 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
> SC-L is hosted and moderated by KRvW Associates, LLC 
> (http://www.KRvW.com) as a free, non-commercial service to 
> the software security community.
> _______________________________________________