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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Steven > Sent: Wednesday, May 23, 2007 2:39 PM > To: SC-L@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@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. > _______________________________________________ > _______________________________________________ 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
