<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: What is ISO 17799, ISO 27000, PCI Credit Card Standard</title>
	<atom:link href="http://geek.michaelgrace.org/2009/12/iso-17799-iso/feed/" rel="self" type="application/rss+xml" />
	<link>http://geek.michaelgrace.org/2009/12/iso-17799-iso/</link>
	<description>All my geek in one place</description>
	<lastBuildDate>Fri, 30 Jul 2010 15:48:03 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: John Whelan</title>
		<link>http://geek.michaelgrace.org/2009/12/iso-17799-iso/comment-page-1/#comment-459</link>
		<dc:creator>John Whelan</dc:creator>
		<pubDate>Fri, 11 Dec 2009 03:29:44 +0000</pubDate>
		<guid isPermaLink="false">http://geek.michaelgrace.org/?p=1159#comment-459</guid>
		<description>Mike, 

I think that this is a fairly good overview of a few of the security standards out there.  They are really there to give organizations a framework to work within when building a security program, and help those companies make sense of, and plan for, security. 

The government has other similar standards (SP800-53, FISMA, etc) that govern how government agencies protect their data (I know from experience), and any regulated company is subject to some standard or another. 

Standards ARE good, in that they create an ideal - the things you should include in a security program.   You are quite correct in that their major drawback is that they also tend to promote a &quot;checkbox&quot; mentality in the organizations that adopt them.   The &quot;checkbox&quot; mentality is one in which things are done so that you can mark off the appropriate checkbox, and not because of a desire to improve security.  Because of that, it&#039;s often done half-heartedly, or worse - sloppily. 

Companies that are regulated (or do business with the government) will do as little as possible to meet their security obligations.  The reason for that is simple economics (doing more costs money, and there&#039;s no impetus for them to do more).   Until that changes, and there are motivators driving organizations to focus on actually securing their data/network/systems,  this is unlikely to change.  An organization often must feel the pain of NOT properly managing security in order for them to start managing security properly. 

I&#039;m being a little too long winded here,  so I&#039;m sorry for that.   

Overall - great post!

(I work in Infosec,   and have been a systems security officer for a government contractor, so speak from experience)</description>
		<content:encoded><![CDATA[<p>Mike, </p>
<p>I think that this is a fairly good overview of a few of the security standards out there.  They are really there to give organizations a framework to work within when building a security program, and help those companies make sense of, and plan for, security. </p>
<p>The government has other similar standards (SP800-53, FISMA, etc) that govern how government agencies protect their data (I know from experience), and any regulated company is subject to some standard or another. </p>
<p>Standards ARE good, in that they create an ideal &#8211; the things you should include in a security program.   You are quite correct in that their major drawback is that they also tend to promote a &#8220;checkbox&#8221; mentality in the organizations that adopt them.   The &#8220;checkbox&#8221; mentality is one in which things are done so that you can mark off the appropriate checkbox, and not because of a desire to improve security.  Because of that, it&#8217;s often done half-heartedly, or worse &#8211; sloppily. </p>
<p>Companies that are regulated (or do business with the government) will do as little as possible to meet their security obligations.  The reason for that is simple economics (doing more costs money, and there&#8217;s no impetus for them to do more).   Until that changes, and there are motivators driving organizations to focus on actually securing their data/network/systems,  this is unlikely to change.  An organization often must feel the pain of NOT properly managing security in order for them to start managing security properly. </p>
<p>I&#8217;m being a little too long winded here,  so I&#8217;m sorry for that.   </p>
<p>Overall &#8211; great post!</p>
<p>(I work in Infosec,   and have been a systems security officer for a government contractor, so speak from experience)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tweets that mention What is ISO 17799, ISO 27000, PCI Credit Card Standard – Michael Grace -- Topsy.com</title>
		<link>http://geek.michaelgrace.org/2009/12/iso-17799-iso/comment-page-1/#comment-458</link>
		<dc:creator>Tweets that mention What is ISO 17799, ISO 27000, PCI Credit Card Standard – Michael Grace -- Topsy.com</dc:creator>
		<pubDate>Wed, 09 Dec 2009 19:39:47 +0000</pubDate>
		<guid isPermaLink="false">http://geek.michaelgrace.org/?p=1159#comment-458</guid>
		<description>[...] This post was mentioned on Twitter by Mike Grace, Chris Carnduff. Chris Carnduff said: What is ISO 17799, ISO 27000, PCI Credit Card Standard – Michael Grace http://bit.ly/8Tm5o5 [...]</description>
		<content:encoded><![CDATA[<p>[...] This post was mentioned on Twitter by Mike Grace, Chris Carnduff. Chris Carnduff said: What is ISO 17799, ISO 27000, PCI Credit Card Standard – Michael Grace <a href="http://bit.ly/8Tm5o5" rel="nofollow">http://bit.ly/8Tm5o5</a> [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
