<?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: How Banks and Merchants manage their risk with PCI DSS</title>
	<atom:link href="http://chaordicmind.com/blog/2009/06/22/how-banks-and-merchants-manage-their-risk-with-pci-dss/feed/" rel="self" type="application/rss+xml" />
	<link>http://chaordicmind.com/blog/2009/06/22/how-banks-and-merchants-manage-their-risk-with-pci-dss/</link>
	<description>Mixing childlike wonder with adultlike understanding</description>
	<lastBuildDate>Wed, 14 Jul 2010 23:42:41 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=abc</generator>
	<item>
		<title>By: PCI punk</title>
		<link>http://chaordicmind.com/blog/2009/06/22/how-banks-and-merchants-manage-their-risk-with-pci-dss/comment-page-1/#comment-71</link>
		<dc:creator>PCI punk</dc:creator>
		<pubDate>Sat, 27 Jun 2009 02:45:00 +0000</pubDate>
		<guid isPermaLink="false">http://chaordicmind.com/blog/?p=58#comment-71</guid>
		<description>Attack vector based security risk management makes lots of sense. The problem is that many QSAs come from the &quot;corporate&quot; big5 auditor school and do not have the required skills or mindset of a potential attacker to perform the analysis or work required.

I have seen many reports by QSAPs who did the previous year&#039;s assessment - where basic web application security flaws, such as XSS, was not adequately checked. This was mainly due to QSAP lack of web application security experience and skills.

The PCI Council needs to revise the minimum QSA experience and skills plus how this is verified. Right now many QSAs with not enough experience can easily pass the training and exam the PCI Council offers.

Another sad thing is that things seem to be geting worse than better. There are companies in the market that now offer &quot;PCI lite&quot; pen-tests, which are basically glorified automated scans. These have little or no attack vector based analysis to drive the testing scope and methodology.

Same goes for QSAs that do not spend enough time to define the proper scope across technology, processes and job roles. Assessments are rushed through and the requirements are not verified adequately to save time and cost.  

If the PCI Council does not make the required changes, the whole PCI DSS program will soon become a joke with QSAs performing fast &quot;tick in the box&quot; assessments and non-serious companies performing fully automated vulnerability scans sold as a &quot;pen-test&quot;.

Do not get me started on the internal pen-tests, which are most of the time even more of a joke based on what most security companies are doing today, some of which are QSAs.

Most good QSAs I have spoken to who have both good business and technical security skills, have become more cynical to the whole PCI DSS scheme, the more they have been working on assessments.

Unless there are major changes and revisions done, there is only one way things will go in the future. It is not looking good right now ...</description>
		<content:encoded><![CDATA[<p>Attack vector based security risk management makes lots of sense. The problem is that many QSAs come from the &#8220;corporate&#8221; big5 auditor school and do not have the required skills or mindset of a potential attacker to perform the analysis or work required.</p>
<p>I have seen many reports by QSAPs who did the previous year&#8217;s assessment &#8211; where basic web application security flaws, such as XSS, was not adequately checked. This was mainly due to QSAP lack of web application security experience and skills.</p>
<p>The PCI Council needs to revise the minimum QSA experience and skills plus how this is verified. Right now many QSAs with not enough experience can easily pass the training and exam the PCI Council offers.</p>
<p>Another sad thing is that things seem to be geting worse than better. There are companies in the market that now offer &#8220;PCI lite&#8221; pen-tests, which are basically glorified automated scans. These have little or no attack vector based analysis to drive the testing scope and methodology.</p>
<p>Same goes for QSAs that do not spend enough time to define the proper scope across technology, processes and job roles. Assessments are rushed through and the requirements are not verified adequately to save time and cost.  </p>
<p>If the PCI Council does not make the required changes, the whole PCI DSS program will soon become a joke with QSAs performing fast &#8220;tick in the box&#8221; assessments and non-serious companies performing fully automated vulnerability scans sold as a &#8220;pen-test&#8221;.</p>
<p>Do not get me started on the internal pen-tests, which are most of the time even more of a joke based on what most security companies are doing today, some of which are QSAs.</p>
<p>Most good QSAs I have spoken to who have both good business and technical security skills, have become more cynical to the whole PCI DSS scheme, the more they have been working on assessments.</p>
<p>Unless there are major changes and revisions done, there is only one way things will go in the future. It is not looking good right now &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://chaordicmind.com/blog/2009/06/22/how-banks-and-merchants-manage-their-risk-with-pci-dss/comment-page-1/#comment-61</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Tue, 23 Jun 2009 06:48:02 +0000</pubDate>
		<guid isPermaLink="false">http://chaordicmind.com/blog/?p=58#comment-61</guid>
		<description>Dominic, yes, I&#039;m sure the banks and even card brands see many more attacks than does the individual merchant, but if you review the Verizon DBIR report (and others that cover the payments industry) we need only focus on a few factors.  

We know that insecurities in partner or 3rd party connections account for 32% of data breaches. Do we spend 32% of our money on evaluating third party security?  Do we even cover it more than PCI DSS Requirement 12.8?

I do like the PCI DSS but I think implementers need a data flow diagram (DFD) that walks them through the various business processes and what their options are for securing them.  If we pair that with known risk and threat vectors (that have remained rather static over the years) we have a much better model for maximizing the usage of the PCI DSS and other scope reduction methods.</description>
		<content:encoded><![CDATA[<p>Dominic, yes, I&#8217;m sure the banks and even card brands see many more attacks than does the individual merchant, but if you review the Verizon DBIR report (and others that cover the payments industry) we need only focus on a few factors.  </p>
<p>We know that insecurities in partner or 3rd party connections account for 32% of data breaches. Do we spend 32% of our money on evaluating third party security?  Do we even cover it more than PCI DSS Requirement 12.8?</p>
<p>I do like the PCI DSS but I think implementers need a data flow diagram (DFD) that walks them through the various business processes and what their options are for securing them.  If we pair that with known risk and threat vectors (that have remained rather static over the years) we have a much better model for maximizing the usage of the PCI DSS and other scope reduction methods.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dominic White</title>
		<link>http://chaordicmind.com/blog/2009/06/22/how-banks-and-merchants-manage-their-risk-with-pci-dss/comment-page-1/#comment-59</link>
		<dc:creator>Dominic White</dc:creator>
		<pubDate>Tue, 23 Jun 2009 06:37:56 +0000</pubDate>
		<guid isPermaLink="false">http://chaordicmind.com/blog/?p=58#comment-59</guid>
		<description>Interesting idea, if it were any other industry I would say you were wrong because the time effort and limited insight into attacks often results in rather poor efforts. But the CC industry has a nice centralised repository, allowing them to detect attacks even if the issuing bank or merchant don&#039;t know about it (the card numbers in a breach all belong to X). I&#039;m fairly sure that more breaches are detected by the payment brands than by their merchants (can you confirm this?). They should use their unique position and ability to analyse these attacks to provide a standard which prioritises based on attack vector, although this should be an additional weighting added to the prioritised approach.</description>
		<content:encoded><![CDATA[<p>Interesting idea, if it were any other industry I would say you were wrong because the time effort and limited insight into attacks often results in rather poor efforts. But the CC industry has a nice centralised repository, allowing them to detect attacks even if the issuing bank or merchant don&#8217;t know about it (the card numbers in a breach all belong to X). I&#8217;m fairly sure that more breaches are detected by the payment brands than by their merchants (can you confirm this?). They should use their unique position and ability to analyse these attacks to provide a standard which prioritises based on attack vector, although this should be an additional weighting added to the prioritised approach.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.439 seconds -->
