<?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: New PCI Phone Rules: A Number Spoken Is Just As Risky As One Typed</title>
	<atom:link href="http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/feed/" rel="self" type="application/rss+xml" />
	<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/</link>
	<description>Techniques, Tools and Tirades about Retail Technology and E-Commerce</description>
	<lastBuildDate>Wed, 08 Feb 2012 16:02: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: Emma Jenkins</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-179039</link>
		<dc:creator>Emma Jenkins</dc:creator>
		<pubDate>Thu, 30 Jun 2011 15:59:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-179039</guid>
		<description>Oh, and http://storefrontbacktalk.com/securityfraud/new-pci-call-center-recording-advice-make-sad-go-away/ is the great article about it :-)

Emma.</description>
		<content:encoded><![CDATA[<p>Oh, and <a href="http://storefrontbacktalk.com/securityfraud/new-pci-call-center-recording-advice-make-sad-go-away/" rel="nofollow">http://storefrontbacktalk.com/securityfraud/new-pci-call-center-recording-advice-make-sad-go-away/</a> is the great article about it :-)</p>
<p>Emma.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Emma Jenkins</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-179038</link>
		<dc:creator>Emma Jenkins</dc:creator>
		<pubDate>Thu, 30 Jun 2011 15:57:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-179038</guid>
		<description>Just pointing out that there is a more up-to-date guidance document from the PCI SSC about call recording and compliance here: https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf

Emma.</description>
		<content:encoded><![CDATA[<p>Just pointing out that there is a more up-to-date guidance document from the PCI SSC about call recording and compliance here: <a href="https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf" rel="nofollow">https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf</a></p>
<p>Emma.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Man</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-66986</link>
		<dc:creator>Jeff Man</dc:creator>
		<pubDate>Thu, 18 Feb 2010 21:48:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-66986</guid>
		<description>As a QSA, I&#039;ve been telling call center clients to protect their recordings for at least five years. Now I have &quot;proof&quot; that recordings are in scope - and that sensitive authentication data simply should not be recorded. 

@Martin - I&#039;d check back with TrustWave in light of this latest clarification. MP3 and WAV are digital formats - so this clarification FAQ definitely applies.</description>
		<content:encoded><![CDATA[<p>As a QSA, I&#8217;ve been telling call center clients to protect their recordings for at least five years. Now I have &#8220;proof&#8221; that recordings are in scope &#8211; and that sensitive authentication data simply should not be recorded. </p>
<p>@Martin &#8211; I&#8217;d check back with TrustWave in light of this latest clarification. MP3 and WAV are digital formats &#8211; so this clarification FAQ definitely applies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Schuman</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-66899</link>
		<dc:creator>Evan Schuman</dc:creator>
		<pubDate>Thu, 18 Feb 2010 14:49:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-66899</guid>
		<description>That&#039;s what the current clarification now says. But the phrase &quot;in any way&quot; is not one you want to have to defend if your QSA chooses to push it.</description>
		<content:encoded><![CDATA[<p>That&#8217;s what the current clarification now says. But the phrase &#8220;in any way&#8221; is not one you want to have to defend if your QSA chooses to push it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-66897</link>
		<dc:creator>Martin</dc:creator>
		<pubDate>Thu, 18 Feb 2010 14:43:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-66897</guid>
		<description>Go to the source, this is a misinterpretation of the original FAQ. You can use MP3 o WAV if you can&#039;t query in any way the data. (Trustwave checked this in our call center).</description>
		<content:encoded><![CDATA[<p>Go to the source, this is a misinterpretation of the original FAQ. You can use MP3 o WAV if you can&#8217;t query in any way the data. (Trustwave checked this in our call center).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Walt Conway</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-64736</link>
		<dc:creator>Walt Conway</dc:creator>
		<pubDate>Tue, 02 Feb 2010 16:25:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-64736</guid>
		<description>@Joe,
My guess is Reg E call centers will be issuing banks, so they may not be subject to PCI as such.  Also, the Council&#039;s guidance said only to remove the offending security codes - you can keep the rest and protect it per PCI.  

@Steve,
I agree with your points.  At least from my end, I don&#039;t know what it will cost to purge the codes from existing records.  But what I find interesting is your statement that there isn&#039;t any process to search the records which flies in the face of the Council&#039;s position that such applications existed.   BTW, what are the &quot;storage requirements of 3 years&quot;?  I know banks have to retain financial transaction history, but merchants?</description>
		<content:encoded><![CDATA[<p>@Joe,<br />
My guess is Reg E call centers will be issuing banks, so they may not be subject to PCI as such.  Also, the Council&#8217;s guidance said only to remove the offending security codes &#8211; you can keep the rest and protect it per PCI.  </p>
<p>@Steve,<br />
I agree with your points.  At least from my end, I don&#8217;t know what it will cost to purge the codes from existing records.  But what I find interesting is your statement that there isn&#8217;t any process to search the records which flies in the face of the Council&#8217;s position that such applications existed.   BTW, what are the &#8220;storage requirements of 3 years&#8221;?  I know banks have to retain financial transaction history, but merchants?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve French</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-64735</link>
		<dc:creator>Steve French</dc:creator>
		<pubDate>Tue, 02 Feb 2010 16:07:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-64735</guid>
		<description>For a company to purge old recordings may well breach FSA compliance relating to tampering with recordings.  Also, with call centres blanket recording 10,000+ calls per day with an original storage requirement of 3 years, (now 6 months),  the process of even finding the calls with the sensitive data boggle the mind.  I don&#039;t know of any process capable of searching the millions of encrypted compressed digital audio files for calls that contain sensitive data, and then copy the recording anew without the sensitive data to maintain compliance with FSA and the companies own recording keeping needs.  It seems PCI have made the ruling without considering its members.</description>
		<content:encoded><![CDATA[<p>For a company to purge old recordings may well breach FSA compliance relating to tampering with recordings.  Also, with call centres blanket recording 10,000+ calls per day with an original storage requirement of 3 years, (now 6 months),  the process of even finding the calls with the sensitive data boggle the mind.  I don&#8217;t know of any process capable of searching the millions of encrypted compressed digital audio files for calls that contain sensitive data, and then copy the recording anew without the sensitive data to maintain compliance with FSA and the companies own recording keeping needs.  It seems PCI have made the ruling without considering its members.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-64734</link>
		<dc:creator>Joe</dc:creator>
		<pubDate>Tue, 02 Feb 2010 15:40:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-64734</guid>
		<description>So how does this work with Regulation E in call centers, where the call is required to be recorded and archived for 2 years when a caller is agreeing to use of a debit card?</description>
		<content:encoded><![CDATA[<p>So how does this work with Regulation E in call centers, where the call is required to be recorded and archived for 2 years when a caller is agreeing to use of a debit card?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave CISA/M/SP</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-64434</link>
		<dc:creator>Dave CISA/M/SP</dc:creator>
		<pubDate>Fri, 29 Jan 2010 17:35:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-64434</guid>
		<description>This is scary and potentially quite expensive - implementation costs aside. This would seem to put merchants with verifcation values stored on digital audio in the position of storing prohibited data. Prohibited data retention enforcement fines can be much (many times) higher than PCI DSS non-compliance fines. 

This one has the potential to be very &quot;disruptive&quot;</description>
		<content:encoded><![CDATA[<p>This is scary and potentially quite expensive &#8211; implementation costs aside. This would seem to put merchants with verifcation values stored on digital audio in the position of storing prohibited data. Prohibited data retention enforcement fines can be much (many times) higher than PCI DSS non-compliance fines. </p>
<p>This one has the potential to be very &#8220;disruptive&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Walt Conway</title>
		<link>http://storefrontbacktalk.com/securityfraud/new-pci-phone-rules-a-number-spoken-is-just-as-risky-as-one-typed/comment-page-1/#comment-64410</link>
		<dc:creator>Walt Conway</dc:creator>
		<pubDate>Thu, 28 Jan 2010 23:47:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.storefrontbacktalk.com/?p=4673#comment-64410</guid>
		<description>Call center recordings have been in scope for PCI for at least a year or two.  The previous guidance from the PCI Council stated that if the data were digital, they had to be protected according to PCI DSS.  If your recordings included the security codes (CVV2, CVC2, etc.) you got a kind of free pass so long as the recordings were protected and weren’t searchable.  What changed with the January 22 revision to the FAQ (as you point out) is you can no longer store the security codes – ever – and if you store them digitally you have to scrub them out.   All the Council said was that call centers are now subject to the same requirement 3.2 as everybody else.  

To me, the revised FAQ is an example of the Council’s efforts to reflect current attack vectors and available technology.  I can’t say I’ve ever seen a credible account of a data breach resulting from call center recordings.  I’ve heard anecdotal, second-hand reports, but I classify them as urban myths.  I guess the Council knows something I don’t.  But I do know there are vendors with call recording apps that can interrupt the recording and not record sensitive data.  My take is the Council is simply reflecting this fact and bringing call centers into line with the DSS. 

Merchants with existing recordings will need to purge the CVV2/CVC2 data.  In some cases, the recordings age off after a period, so it may not be a big issue or at least it can be a self-correcting one.  I know one merchant who is looking at ceasing call recording until they can install an updated system.  In the meantime, if you record the PANs, the PCI Council says you have to protect the recordings per PCI - nothing new there.  What they added last Friday was that if you record the sensitive security codes you are going to have to stop, and then you need to find a reasonable way to purge them from your old recordings.</description>
		<content:encoded><![CDATA[<p>Call center recordings have been in scope for PCI for at least a year or two.  The previous guidance from the PCI Council stated that if the data were digital, they had to be protected according to PCI DSS.  If your recordings included the security codes (CVV2, CVC2, etc.) you got a kind of free pass so long as the recordings were protected and weren’t searchable.  What changed with the January 22 revision to the FAQ (as you point out) is you can no longer store the security codes – ever – and if you store them digitally you have to scrub them out.   All the Council said was that call centers are now subject to the same requirement 3.2 as everybody else.  </p>
<p>To me, the revised FAQ is an example of the Council’s efforts to reflect current attack vectors and available technology.  I can’t say I’ve ever seen a credible account of a data breach resulting from call center recordings.  I’ve heard anecdotal, second-hand reports, but I classify them as urban myths.  I guess the Council knows something I don’t.  But I do know there are vendors with call recording apps that can interrupt the recording and not record sensitive data.  My take is the Council is simply reflecting this fact and bringing call centers into line with the DSS. </p>
<p>Merchants with existing recordings will need to purge the CVV2/CVC2 data.  In some cases, the recordings age off after a period, so it may not be a big issue or at least it can be a self-correcting one.  I know one merchant who is looking at ceasing call recording until they can install an updated system.  In the meantime, if you record the PANs, the PCI Council says you have to protect the recordings per PCI &#8211; nothing new there.  What they added last Friday was that if you record the sensitive security codes you are going to have to stop, and then you need to find a reasonable way to purge them from your old recordings.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

