<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.11" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Security Guidance and its “Specificity Knob”</title>
	<link>http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/</link>
	<description>The Cigital Software Security and Quality Blog</description>
	<pubDate>Fri, 25 Jul 2008 16:17:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.11</generator>

	<item>
		<title>by: jOHN</title>
		<link>http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/#comment-1048</link>
		<pubDate>Wed, 23 May 2007 15:47:57 +0000</pubDate>
		<guid>http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/#comment-1048</guid>
					<description>Dave,

You correctly emphasize the Level of Effort (LoE) associated with such standards. This isn't one of those "Duh, it's simple, just get off your butt and do it" things. Technology-specific standards require at least a dedicated staff of one and help from others distributed throughout the organization. That means commitment.

Dave speaks from experience, by the way. His organization does an outstanding job of making sure that both security and development folk have knowledge about critical vulnerabilities and emerging best practices from the industry at large.

From my perspective, obtaining critical mass of an initial set of standards requires the most LoE. Neither Developers nor Security Analysts will "come and get it" if when they initially explore they only find sparse and/or superficial guidance. I recommend building (or buying) a critical mass. What to tackle first? Well, what problems do you find most often when you assess your organization's applications?

Once your organization obtains critical mass, I suggest using a distributed work-force for continued standard development and update. Your Security Analysts (conducting application reviews), Security Architects (helping out with secure design), and even savvy Developers (who might have created a nifty way around session forgery for their own use) all represent exceptional sources of new standards to be folded in. Whether or not the security group "buys back" the time these people spend developing standards depends on specifics of your org.

If you successfully create an environment of contribution, that one dedicated resource I prescribed should be responsible for coordinating, collecting, editing, vetting, and distributing standards. This person acts like an Editor in Chief of standards and may involve an editorial board of internal and/or external reviewers. Certainly, including Development Champions who can vouch for the practicality of given guidance aides in reception of and buy-in for standards.   

What do you guys think out there?
-jOHN</description>
		<content:encoded><![CDATA[<p>Dave,</p>
<p>You correctly emphasize the Level of Effort (LoE) associated with such standards. This isn&#8217;t one of those &#8220;Duh, it&#8217;s simple, just get off your butt and do it&#8221; things. Technology-specific standards require at least a dedicated staff of one and help from others distributed throughout the organization. That means commitment.</p>
<p>Dave speaks from experience, by the way. His organization does an outstanding job of making sure that both security and development folk have knowledge about critical vulnerabilities and emerging best practices from the industry at large.</p>
<p>From my perspective, obtaining critical mass of an initial set of standards requires the most LoE. Neither Developers nor Security Analysts will &#8220;come and get it&#8221; if when they initially explore they only find sparse and/or superficial guidance. I recommend building (or buying) a critical mass. What to tackle first? Well, what problems do you find most often when you assess your organization&#8217;s applications?</p>
<p>Once your organization obtains critical mass, I suggest using a distributed work-force for continued standard development and update. Your Security Analysts (conducting application reviews), Security Architects (helping out with secure design), and even savvy Developers (who might have created a nifty way around session forgery for their own use) all represent exceptional sources of new standards to be folded in. Whether or not the security group &#8220;buys back&#8221; the time these people spend developing standards depends on specifics of your org.</p>
<p>If you successfully create an environment of contribution, that one dedicated resource I prescribed should be responsible for coordinating, collecting, editing, vetting, and distributing standards. This person acts like an Editor in Chief of standards and may involve an editorial board of internal and/or external reviewers. Certainly, including Development Champions who can vouch for the practicality of given guidance aides in reception of and buy-in for standards.   </p>
<p>What do you guys think out there?<br />
-jOHN
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: David Smith</title>
		<link>http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/#comment-1046</link>
		<pubDate>Wed, 23 May 2007 14:58:43 +0000</pubDate>
		<guid>http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/#comment-1046</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>Your point about the &#8220;perishability&#8221; 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.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
