<?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/"
		xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: But Network Solutions was compliant, weren&#8217;t they?</title>
	<atom:link href="http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/</link>
	<description>The views of one man on security, privacy and anything else that catches his attention.  The views expressed on this blog do not reflect the views of my employer or anyone other than myself.</description>
	<lastBuildDate>Thu, 02 Feb 2012 21:45:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Sean</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-5048</link>
		<dc:creator>Sean</dc:creator>
		<pubDate>Fri, 21 Aug 2009 13:25:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-5048</guid>
		<description>For everyone that continues to say PCI failed because of the recent breaches, just proves that if they are running any security or compliance programs for their organizations that they could likely be the next name on the list of data breaches, simply because they don’t get the PCI DSS!!  They just don’t get that PCI DSS is just a security baseline (and a pretty good one at that) and you must go beyond getting the ROC and maintain compliance as a program not a project.  Projects have an end date, which means if you treat PCI like a project, then the day after the project is completed you will probably not be compliant.  I strongly agree with your friend, quite blaming the standard and take ownership for your own failures.</description>
		<content:encoded><![CDATA[<p>For everyone that continues to say PCI failed because of the recent breaches, just proves that if they are running any security or compliance programs for their organizations that they could likely be the next name on the list of data breaches, simply because they don’t get the PCI DSS!!  They just don’t get that PCI DSS is just a security baseline (and a pretty good one at that) and you must go beyond getting the ROC and maintain compliance as a program not a project.  Projects have an end date, which means if you treat PCI like a project, then the day after the project is completed you will probably not be compliant.  I strongly agree with your friend, quite blaming the standard and take ownership for your own failures.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Network Security Blog &#187; Thursday night PCI articles</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4979</link>
		<dc:creator>Network Security Blog &#187; Thursday night PCI articles</dc:creator>
		<pubDate>Fri, 14 Aug 2009 04:45:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4979</guid>
		<description>[...] Standards aren&#8217;t security: PCI compliance and Heartland&#8217;s data breach &#8211; A secure network often means a compliant network.&#160; But a compliant network only sometimes means a secure network.&#160; Therefore COMPLIANCE DOES NOT EQUAL SECURITY!&#160; [...]</description>
		<content:encoded><![CDATA[<p>[...] Standards aren&#8217;t security: PCI compliance and Heartland&#8217;s data breach &#8211; A secure network often means a compliant network.&nbsp; But a compliant network only sometimes means a secure network.&nbsp; Therefore COMPLIANCE DOES NOT EQUAL SECURITY!&nbsp; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kilauea</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4913</link>
		<dc:creator>kilauea</dc:creator>
		<pubDate>Thu, 30 Jul 2009 08:40:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4913</guid>
		<description>Your just not getting the budget thing fella&#039;s.

Any company makes x profit of which a small % is allocated to security. Nothing wrong in that, the company has other costs and needs to make a profit (and we are in recession after all).

Pre-PCI, all that small budget would be focussed on the high-risk areas. In this case, the web servers that were hacked. Post-PCI, you have over 200 controls to apply to a wide variety of systems. 

It&#039;s the removal of a risk based approach, allowing orgs to put budget to the high-risk areas year-on-year, that is the biggest failing of PCI. Nobody is chasing security any more, they are all chasing compliance.</description>
		<content:encoded><![CDATA[<p>Your just not getting the budget thing fella&#8217;s.</p>
<p>Any company makes x profit of which a small % is allocated to security. Nothing wrong in that, the company has other costs and needs to make a profit (and we are in recession after all).</p>
<p>Pre-PCI, all that small budget would be focussed on the high-risk areas. In this case, the web servers that were hacked. Post-PCI, you have over 200 controls to apply to a wide variety of systems. </p>
<p>It&#8217;s the removal of a risk based approach, allowing orgs to put budget to the high-risk areas year-on-year, that is the biggest failing of PCI. Nobody is chasing security any more, they are all chasing compliance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rick</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4904</link>
		<dc:creator>Rick</dc:creator>
		<pubDate>Wed, 29 Jul 2009 02:27:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4904</guid>
		<description>Hi

Perhaps the work that Network Solutions undertook to become PCI-DSS compliant resulted in the breech being detected, analysed and remediated in a timely manor that actually reduced the effect of the breech.  Any network can potentially be breached, what PCI brings is detective and preventative controls as well as an incident response plan.  Perhaps if they had not put all the PCI controls in place the breech may have gone undetected for months even years.

One of the controls of PCI-DSS (12.1.2) is that you conduct a threat risk assessment against your CDE (Cardholder Data Environment).  Perhaps today is a good time to take this to your CEO\CTO and ask for time and resource to conduct an assessment.</description>
		<content:encoded><![CDATA[<p>Hi</p>
<p>Perhaps the work that Network Solutions undertook to become PCI-DSS compliant resulted in the breech being detected, analysed and remediated in a timely manor that actually reduced the effect of the breech.  Any network can potentially be breached, what PCI brings is detective and preventative controls as well as an incident response plan.  Perhaps if they had not put all the PCI controls in place the breech may have gone undetected for months even years.</p>
<p>One of the controls of PCI-DSS (12.1.2) is that you conduct a threat risk assessment against your CDE (Cardholder Data Environment).  Perhaps today is a good time to take this to your CEO\CTO and ask for time and resource to conduct an assessment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: NY Computer Security Consulting</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4903</link>
		<dc:creator>NY Computer Security Consulting</dc:creator>
		<pubDate>Tue, 28 Jul 2009 18:49:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4903</guid>
		<description>I think the problem is most larger companies use accountants to determine &quot;risk&quot; as appose to engineers. If the likelihood of a security compromise and the ensuing lawsuits, don&#039;t outweigh the cost of tightening their infrastructure then it isn&#039;t deemed &quot;cost effective&quot;.

When your only goal is the bottom line your core business (or at least what should be the core values of your business) will suffer.</description>
		<content:encoded><![CDATA[<p>I think the problem is most larger companies use accountants to determine &#8220;risk&#8221; as appose to engineers. If the likelihood of a security compromise and the ensuing lawsuits, don&#8217;t outweigh the cost of tightening their infrastructure then it isn&#8217;t deemed &#8220;cost effective&#8221;.</p>
<p>When your only goal is the bottom line your core business (or at least what should be the core values of your business) will suffer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4902</link>
		<dc:creator>Peter</dc:creator>
		<pubDate>Tue, 28 Jul 2009 17:59:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4902</guid>
		<description>I don&#039;t think anyone expects it to be perfect, but too many companies view PCI compliance as the maximum amount of effort required to avoid liability instead of the minimum amount required to do the job properly.

You know a risk analyzer somewhere has done the math based on how much the extra security would cost and how likely an event is and how much the fallout from an event would cost and said it just isn&#039;t worth it to spend more on compliance.  Additional security is also something that is probably not going to result in additional sales, making it that much harder to justify economically.

In tough economic times, it&#039;s easier to say &quot;let&#039;s do the minimum required, roll the dice on the rest and deal with any problems IF they occur, since they probably won&#039;t.&quot;  It&#039;s a bad long-term philosophy, but it usually works quite well in the short term.

In situations where the free market doesn&#039;t force businesses to the right thing you need to legislate it and make the penalties so severe that not complying isn&#039;t a viable option.  You hear stories all the time about business that violate regulations for years, make hundreds of millions of dollars in profits from those activities and then get hit with a $50 million fine.  It might not be right, but from a business perspective, that&#039;s not a bad deal.  If the fine was double your ill-gotten gains, people might think twice about it.  

So if you want strict compliance and better overall PCI security make the fines outrageous, something like $1000 per piece of breached data.  Network Solutions had 573,928 records stolen.  A fine of $573 million makes spending money on better security seem like a good idea instead of an unnecessary expense.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think anyone expects it to be perfect, but too many companies view PCI compliance as the maximum amount of effort required to avoid liability instead of the minimum amount required to do the job properly.</p>
<p>You know a risk analyzer somewhere has done the math based on how much the extra security would cost and how likely an event is and how much the fallout from an event would cost and said it just isn&#8217;t worth it to spend more on compliance.  Additional security is also something that is probably not going to result in additional sales, making it that much harder to justify economically.</p>
<p>In tough economic times, it&#8217;s easier to say &#8220;let&#8217;s do the minimum required, roll the dice on the rest and deal with any problems IF they occur, since they probably won&#8217;t.&#8221;  It&#8217;s a bad long-term philosophy, but it usually works quite well in the short term.</p>
<p>In situations where the free market doesn&#8217;t force businesses to the right thing you need to legislate it and make the penalties so severe that not complying isn&#8217;t a viable option.  You hear stories all the time about business that violate regulations for years, make hundreds of millions of dollars in profits from those activities and then get hit with a $50 million fine.  It might not be right, but from a business perspective, that&#8217;s not a bad deal.  If the fine was double your ill-gotten gains, people might think twice about it.  </p>
<p>So if you want strict compliance and better overall PCI security make the fines outrageous, something like $1000 per piece of breached data.  Network Solutions had 573,928 records stolen.  A fine of $573 million makes spending money on better security seem like a good idea instead of an unnecessary expense.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Lewis</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4901</link>
		<dc:creator>Rob Lewis</dc:creator>
		<pubDate>Tue, 28 Jul 2009 17:37:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4901</guid>
		<description>It&#039;s not much of a standard if there are so many work arounds that any serious attacker can navigate successfully. It then leaves people with a false sense of security, which may be more dangerous than when they had nothing in place. They assume they are &quot;secure&quot; when what they really have is a &quot; little bit more secure&quot;. I think you say this in your own post.</description>
		<content:encoded><![CDATA[<p>It&#8217;s not much of a standard if there are so many work arounds that any serious attacker can navigate successfully. It then leaves people with a false sense of security, which may be more dangerous than when they had nothing in place. They assume they are &#8220;secure&#8221; when what they really have is a &#8221; little bit more secure&#8221;. I think you say this in your own post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Angelo Comazzetto</title>
		<link>http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/comment-page-1/#comment-4900</link>
		<dc:creator>Angelo Comazzetto</dc:creator>
		<pubDate>Tue, 28 Jul 2009 15:46:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2009/07/27/but-network-solutions-was-compliant-werent-they/#comment-4900</guid>
		<description>PCI Compliance is interesting, they wanted to assure that millions of unknowledgeable retailers and shops could get compliant, so they left the actual requirements quite vague and sometimes open to creative interpretations. With 1.2 they got a bit more specific but still it’s easy to do it poorly.
PCI just basically enforces security around the payment card industry.

For example they say you have to physically secure the servers, but they don’t say with what. Lock and Key? Machine Sentry Guns? Gas Chamber? Tie a rope around them?

Since they are indeed general and not terribly specific about many requirements, its very valid to say that even you are fully PCI compliant, it doesn’t mean at all the entire network is anything resembling fully secure, but rather that you knew how to implement a few broad guidelines as they relate to payment processing and data storage.

For example, it doesn’t mean every client workstation not related to the payment card systems is fully locked down, content filtered, IPS’s scanned, etc…since that’s not a requirement for PCI specifically.</description>
		<content:encoded><![CDATA[<p>PCI Compliance is interesting, they wanted to assure that millions of unknowledgeable retailers and shops could get compliant, so they left the actual requirements quite vague and sometimes open to creative interpretations. With 1.2 they got a bit more specific but still it’s easy to do it poorly.<br />
PCI just basically enforces security around the payment card industry.</p>
<p>For example they say you have to physically secure the servers, but they don’t say with what. Lock and Key? Machine Sentry Guns? Gas Chamber? Tie a rope around them?</p>
<p>Since they are indeed general and not terribly specific about many requirements, its very valid to say that even you are fully PCI compliant, it doesn’t mean at all the entire network is anything resembling fully secure, but rather that you knew how to implement a few broad guidelines as they relate to payment processing and data storage.</p>
<p>For example, it doesn’t mean every client workstation not related to the payment card systems is fully locked down, content filtered, IPS’s scanned, etc…since that’s not a requirement for PCI specifically.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

