<?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: PCI Council And Passwords: Do As We Say, Not As We Do</title>
	<atom:link href="http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/feed/" rel="self" type="application/rss+xml" />
	<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/</link>
	<description>Techniques, Tools and Tirades about Retail Technology and E-Commerce</description>
	<lastBuildDate>Sun, 20 May 2012 01:49:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: James</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67742</link>
		<dc:creator>James</dc:creator>
		<pubDate>Tue, 02 Mar 2010 23:57:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67742</guid>
		<description>Irrelevant...no credit card, no PCI, no DSS.</description>
		<content:encoded><![CDATA[<p>Irrelevant&#8230;no credit card, no PCI, no DSS.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave CISA/M/SP</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67488</link>
		<dc:creator>Dave CISA/M/SP</dc:creator>
		<pubDate>Fri, 26 Feb 2010 15:54:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67488</guid>
		<description>The word version of this document only exists so that self-assessors preparing a ROC have a document into which they can enter their data. It&#039;s a tool provided for convenience. It&#039;s not the PCI equivalent of NIST&#039;s meter bar, an item that it is essential it be kept inviolate in a tightly controlled environment to maintain the integrity of the standard. 

Let’s ask the Security Question: What was the RISK here? If a user chooses to hack the password and alter the document, they&#039;re not hurting anyone but themselves. No forensic investigator s going to go by their altered document nor is it likely to stand up in front of a jury.  Mom always said, “If you’re fooling yourself, you&#039;re fooling the biggest fool of all”. IMHO the Council made a risk-based decision and chose to secure the document at a level they deemed appropriate. PCI DSS was never in play, either as a standard or a best practice.

I am advocating focus on REAL issues that matter to this community: lowering the cost and complexity of PCI by treating it as the business problem it is, identifying cost-effective steps for making PCI more accessible to small businesses (who represent the majority of compromises), identifying the impact of compliance-enabling technologies, or the explaining the advantages of getting to validated hardware and software to lower risk.</description>
		<content:encoded><![CDATA[<p>The word version of this document only exists so that self-assessors preparing a ROC have a document into which they can enter their data. It&#8217;s a tool provided for convenience. It&#8217;s not the PCI equivalent of NIST&#8217;s meter bar, an item that it is essential it be kept inviolate in a tightly controlled environment to maintain the integrity of the standard. </p>
<p>Let’s ask the Security Question: What was the RISK here? If a user chooses to hack the password and alter the document, they&#8217;re not hurting anyone but themselves. No forensic investigator s going to go by their altered document nor is it likely to stand up in front of a jury.  Mom always said, “If you’re fooling yourself, you&#8217;re fooling the biggest fool of all”. IMHO the Council made a risk-based decision and chose to secure the document at a level they deemed appropriate. PCI DSS was never in play, either as a standard or a best practice.</p>
<p>I am advocating focus on REAL issues that matter to this community: lowering the cost and complexity of PCI by treating it as the business problem it is, identifying cost-effective steps for making PCI more accessible to small businesses (who represent the majority of compromises), identifying the impact of compliance-enabling technologies, or the explaining the advantages of getting to validated hardware and software to lower risk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Schuman</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67447</link>
		<dc:creator>Evan Schuman</dc:creator>
		<pubDate>Fri, 26 Feb 2010 00:54:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67447</guid>
		<description>Editor&#039;s Note: The story does not suggest that PCI should apply to anything beyond payment. But it does acknowledge the reality--a reality that is not a bad thing, actually--that many businesses do use the best practices included in the standard as guidance for a wide range of security practices. The irony we noted was that the PCI Council opted to not be among them.</description>
		<content:encoded><![CDATA[<p>Editor&#8217;s Note: The story does not suggest that PCI should apply to anything beyond payment. But it does acknowledge the reality&#8211;a reality that is not a bad thing, actually&#8211;that many businesses do use the best practices included in the standard as guidance for a wide range of security practices. The irony we noted was that the PCI Council opted to not be among them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Haag</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67428</link>
		<dc:creator>Richard Haag</dc:creator>
		<pubDate>Thu, 25 Feb 2010 21:00:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67428</guid>
		<description>@Carsten - you are forgetting the &quot;Transmit&quot; portion of scope which likely applies to you.  

In general QSA&#039;s have know how to unlock this document for a very long time(Insert Object --&gt; Select file).  I am not sure why they choose to lock it in the first place, but they have been doing this for years. 

I do not think it is a fair statement to suggest that the council is following bad password practices for something as meaningless as protecting the integrity(vs confidentiality) of a document.  There is a big difference in terms of value(and risk) in using weak passwords on a POS system and using a weak password to protect a document.

Now if someone were to hack into their portal and execute a successful SQLinjecton attack, that would be ironic.</description>
		<content:encoded><![CDATA[<p>@Carsten &#8211; you are forgetting the &#8220;Transmit&#8221; portion of scope which likely applies to you.  </p>
<p>In general QSA&#8217;s have know how to unlock this document for a very long time(Insert Object &#8211;&gt; Select file).  I am not sure why they choose to lock it in the first place, but they have been doing this for years. </p>
<p>I do not think it is a fair statement to suggest that the council is following bad password practices for something as meaningless as protecting the integrity(vs confidentiality) of a document.  There is a big difference in terms of value(and risk) in using weak passwords on a POS system and using a weak password to protect a document.</p>
<p>Now if someone were to hack into their portal and execute a successful SQLinjecton attack, that would be ironic.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carsten</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67411</link>
		<dc:creator>Carsten</dc:creator>
		<pubDate>Thu, 25 Feb 2010 18:26:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67411</guid>
		<description>Harry Maggiore, can i get this in writing ?
&gt;Given they do not collect store or transmit card &gt;holder data, they are not subject to the specification.

i have proven to my QSA that we do not collect any card holder data within our system except for the last four digits... and i am still required to implement all 12 PCI requirements throuhout the whole IT landscape and infrastructure.
Yes, we are a retailer, and yes, we do a lot of credit card business... but we do not store card holer information other than the ccPAN masked, with only the last 4 digits visible. But that doesn&#039;t seem to be enough to be PCI compliant ?

the irony in the PCI council though, as mentioned in the article... very enjoyable. :-)
Carsten</description>
		<content:encoded><![CDATA[<p>Harry Maggiore, can i get this in writing ?<br />
&gt;Given they do not collect store or transmit card &gt;holder data, they are not subject to the specification.</p>
<p>i have proven to my QSA that we do not collect any card holder data within our system except for the last four digits&#8230; and i am still required to implement all 12 PCI requirements throuhout the whole IT landscape and infrastructure.<br />
Yes, we are a retailer, and yes, we do a lot of credit card business&#8230; but we do not store card holer information other than the ccPAN masked, with only the last 4 digits visible. But that doesn&#8217;t seem to be enough to be PCI compliant ?</p>
<p>the irony in the PCI council though, as mentioned in the article&#8230; very enjoyable. :-)<br />
Carsten</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frank</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67390</link>
		<dc:creator>Frank</dc:creator>
		<pubDate>Thu, 25 Feb 2010 15:31:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67390</guid>
		<description>As an ex IT auditor (you never really become an ex auditor) I have several comments on this particular non issue.  First of all I feel that the document should be one that the PCIDSS has in their possession with their own security.  I really don&#039;t see the purpose or the reason to password protect the document.  If a level whatever credit card processor wants to make changes to the document and they compare the original with the one submitted this would in my view be fraud and subject to some very serious fines.

In another light I see this as one of the better standards as it does require companies and Government agencies to become better at security.  To me it&#039;s like the intro class to IT security for the dummies of management who have no clue how to spell security.

As far as the audits are concerned.  I hope not to be disappointed. But we&#039;re being audited by KPMG for PCI compliance. This is like Auditor appreciation week as we&#039;ve decorated the office with all things for the auditor.  The sign in sheet we put up at the computer room door with badges the Friday before the auditors come in. Management here thinks auditors are just stupid. And personally if these young wet behind the ears auditors buy off on all these fake decorations I have lost all faith in audit.

It appears they are asking some pretty interesting questions which indicate a lot of follow up to what I see as dead ends. Which I hope they address.

The problem to me is that in the past when auditors draft their findings they usually get fired. Then two years later we get a few more new kids come in with their check lists.  I really hope these &#039;kids&#039; are good at what they do, else management will celebrate how well they can pull the wool over the eyes of children.</description>
		<content:encoded><![CDATA[<p>As an ex IT auditor (you never really become an ex auditor) I have several comments on this particular non issue.  First of all I feel that the document should be one that the PCIDSS has in their possession with their own security.  I really don&#8217;t see the purpose or the reason to password protect the document.  If a level whatever credit card processor wants to make changes to the document and they compare the original with the one submitted this would in my view be fraud and subject to some very serious fines.</p>
<p>In another light I see this as one of the better standards as it does require companies and Government agencies to become better at security.  To me it&#8217;s like the intro class to IT security for the dummies of management who have no clue how to spell security.</p>
<p>As far as the audits are concerned.  I hope not to be disappointed. But we&#8217;re being audited by KPMG for PCI compliance. This is like Auditor appreciation week as we&#8217;ve decorated the office with all things for the auditor.  The sign in sheet we put up at the computer room door with badges the Friday before the auditors come in. Management here thinks auditors are just stupid. And personally if these young wet behind the ears auditors buy off on all these fake decorations I have lost all faith in audit.</p>
<p>It appears they are asking some pretty interesting questions which indicate a lot of follow up to what I see as dead ends. Which I hope they address.</p>
<p>The problem to me is that in the past when auditors draft their findings they usually get fired. Then two years later we get a few more new kids come in with their check lists.  I really hope these &#8216;kids&#8217; are good at what they do, else management will celebrate how well they can pull the wool over the eyes of children.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave CISA/M/SP</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67389</link>
		<dc:creator>Dave CISA/M/SP</dc:creator>
		<pubDate>Thu, 25 Feb 2010 15:09:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67389</guid>
		<description>PCI applies to the storage, processing and transmission of cardholder data, and nowhere else. Provided there is no cardholder data in a given segment, that environment can be placed out of scope for PCI. This article seems to further assume that not only is the Council storing cardholder data, but they haven&#039;t segmented their network to take the zone where this article is stored out of scope.  

The idea of a standard implies uniform application. There is no expectation that we deploy PCI across zones that are out of scope. Ergo there should be no expectation the Council do otherwise. There is enough expense, confusion, difficulty, concern, criticism, and mud-slinging in this environment already. Neither increasing the scope, cost, and complexity of PCI to areas out of scope, nor expecting the Council to act differently than those its standards govern, advances the cause of Information Security in general or cardholder data security in particular.</description>
		<content:encoded><![CDATA[<p>PCI applies to the storage, processing and transmission of cardholder data, and nowhere else. Provided there is no cardholder data in a given segment, that environment can be placed out of scope for PCI. This article seems to further assume that not only is the Council storing cardholder data, but they haven&#8217;t segmented their network to take the zone where this article is stored out of scope.  </p>
<p>The idea of a standard implies uniform application. There is no expectation that we deploy PCI across zones that are out of scope. Ergo there should be no expectation the Council do otherwise. There is enough expense, confusion, difficulty, concern, criticism, and mud-slinging in this environment already. Neither increasing the scope, cost, and complexity of PCI to areas out of scope, nor expecting the Council to act differently than those its standards govern, advances the cause of Information Security in general or cardholder data security in particular.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert L Santuci Jr.</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67383</link>
		<dc:creator>Robert L Santuci Jr.</dc:creator>
		<pubDate>Thu, 25 Feb 2010 14:30:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67383</guid>
		<description>At least it appears that they&#039;ve removed the spot for credit card information from their fax forms.</description>
		<content:encoded><![CDATA[<p>At least it appears that they&#8217;ve removed the spot for credit card information from their fax forms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bill bittner</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67382</link>
		<dc:creator>bill bittner</dc:creator>
		<pubDate>Thu, 25 Feb 2010 14:24:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67382</guid>
		<description>One of my pet peaves with passwords is the 90 day rule.  That, more than anything else I would imagine, is the reason you find passwords written on the back of postit notes attached to monitors.</description>
		<content:encoded><![CDATA[<p>One of my pet peaves with passwords is the 90 day rule.  That, more than anything else I would imagine, is the reason you find passwords written on the back of postit notes attached to monitors.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A reader</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67376</link>
		<dc:creator>A reader</dc:creator>
		<pubDate>Thu, 25 Feb 2010 13:03:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67376</guid>
		<description>Irony?

From the association that was created to inflict tissue-paper security protocols on the rest of the world, and whose mandate is to punish organizations that don&#039;t build a proper steel safe to guard their used tissues?

Their foundations were built on irony.  Why are you so surprised?</description>
		<content:encoded><![CDATA[<p>Irony?</p>
<p>From the association that was created to inflict tissue-paper security protocols on the rest of the world, and whose mandate is to punish organizations that don&#8217;t build a proper steel safe to guard their used tissues?</p>
<p>Their foundations were built on irony.  Why are you so surprised?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Schuman</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67374</link>
		<dc:creator>Evan Schuman</dc:creator>
		<pubDate>Thu, 25 Feb 2010 12:45:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67374</guid>
		<description>True, but that&#039;s not the point. If they have chosen to password protect a file, it&#039;s interesting that they didn&#039;t adhere to their own recommendations. Compliance is not the issue. As we--and tons of others--have noted, PCI is not just for payment. Officially, of course, it is, but the guidance, guidelines and best practices contained in PCI is a good tool for anyone to use when needing to protect any kind of data. Lots of companies are using their suggestions to secure CRM data and many other kinds of information. The irony here is that the PCI Council didn&#039;t opt to use its own advice.</description>
		<content:encoded><![CDATA[<p>True, but that&#8217;s not the point. If they have chosen to password protect a file, it&#8217;s interesting that they didn&#8217;t adhere to their own recommendations. Compliance is not the issue. As we&#8211;and tons of others&#8211;have noted, PCI is not just for payment. Officially, of course, it is, but the guidance, guidelines and best practices contained in PCI is a good tool for anyone to use when needing to protect any kind of data. Lots of companies are using their suggestions to secure CRM data and many other kinds of information. The irony here is that the PCI Council didn&#8217;t opt to use its own advice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harry Maggiore</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67373</link>
		<dc:creator>Harry Maggiore</dc:creator>
		<pubDate>Thu, 25 Feb 2010 12:37:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67373</guid>
		<description>Given they do not collect store or transmit card holder data, they are not subject to the specification.</description>
		<content:encoded><![CDATA[<p>Given they do not collect store or transmit card holder data, they are not subject to the specification.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Schuman</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67332</link>
		<dc:creator>Evan Schuman</dc:creator>
		<pubDate>Wed, 24 Feb 2010 20:13:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67332</guid>
		<description>Not necessarily. PDFs today can be edited quite easily, unless they have password-protection activated, in which case you&#039;re back to the same issue again. Besides, the council DOES offer these documents as PDFs already.</description>
		<content:encoded><![CDATA[<p>Not necessarily. PDFs today can be edited quite easily, unless they have password-protection activated, in which case you&#8217;re back to the same issue again. Besides, the council DOES offer these documents as PDFs already.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Preston</title>
		<link>http://storefrontbacktalk.com/securityfraud/pci-council-and-passwords-do-as-we-say-not-as-we-do/comment-page-1/#comment-67328</link>
		<dc:creator>Preston</dc:creator>
		<pubDate>Wed, 24 Feb 2010 20:02:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4842#comment-67328</guid>
		<description>If they don&#039;t want the document changed, they should save it as a PDF and be done with it.</description>
		<content:encoded><![CDATA[<p>If they don&#8217;t want the document changed, they should save it as a PDF and be done with it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

