<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: PCI Compliance in 60 days?</title>
	<link>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/</link>
	<description>Security News</description>
	<pubDate>Fri, 12 Mar 2010 03:00:01 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Mike Ghodoosian</title>
		<link>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-4955</link>
		<pubDate>Sat, 29 Sep 2007 22:08:13 +0000</pubDate>
		<guid>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-4955</guid>
					<description>I read your comments on the preparation of PCI solutions in healthcare. I am interested to hook up with a reputable group of consultants for bringing turnkey solutions in less than 60 days to a few of our clients NOW. 

I could also use a white paper or two on the details. Can you help or give me some advice?

Thanks,

Mike Ghodoosian, URC</description>
		<content:encoded><![CDATA[<p>I read your comments on the preparation of PCI solutions in healthcare. I am interested to hook up with a reputable group of consultants for bringing turnkey solutions in less than 60 days to a few of our clients NOW. </p>
<p>I could also use a white paper or two on the details. Can you help or give me some advice?</p>
<p>Thanks,</p>
<p>Mike Ghodoosian, URC
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Cary Sholer</title>
		<link>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-4308</link>
		<pubDate>Wed, 29 Aug 2007 22:51:30 +0000</pubDate>
		<guid>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-4308</guid>
					<description>Allen and Martin, I agree with both of you. Implementing any solution in less than 60 days requires advanced planning, standard procedures, and a very high functioning team with lots of experience. Implementing a security and compliance solution also requires more standards, e.g. a security policy template, well thought our support processes, and job descriptions parced out to maintain separation of duties. 

While all of this sounds simple enough, to implement a security and compliance solution in 60 days can be done and I have done it. Yet, we had most of the prework done before we acquired the vendor solution. We also had strong executive sponsorship and support of the CTO to help us overcome obstacles in IT. The seven P's that I learned early in my career make all of the difference on these types of projects: Prior Proper Planning Prevents Piss Poor Performance. The best teams with enough prior proper planning can implement almost anything in 60 days. 
Regards,
Cary</description>
		<content:encoded><![CDATA[<p>Allen and Martin, I agree with both of you. Implementing any solution in less than 60 days requires advanced planning, standard procedures, and a very high functioning team with lots of experience. Implementing a security and compliance solution also requires more standards, e.g. a security policy template, well thought our support processes, and job descriptions parced out to maintain separation of duties. </p>
<p>While all of this sounds simple enough, to implement a security and compliance solution in 60 days can be done and I have done it. Yet, we had most of the prework done before we acquired the vendor solution. We also had strong executive sponsorship and support of the CTO to help us overcome obstacles in IT. The seven P's that I learned early in my career make all of the difference on these types of projects: Prior Proper Planning Prevents Piss Poor Performance. The best teams with enough prior proper planning can implement almost anything in 60 days.<br />
Regards,<br />
Cary
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Martin Hack</title>
		<link>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-3898</link>
		<pubDate>Fri, 10 Aug 2007 03:40:02 +0000</pubDate>
		<guid>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-3898</guid>
					<description>I'm not sure whether everything has to be in place *before* you hire a vendor. For example, most of the vendor specific documentation won't be possible to produce after it's been deployed and aligned for a given customer environment, 

The underlying issue here is that there are companies that look at PCI as, "oh it's just another audit we've got to pass", and then there are organizations who simply want to have a great security posture. Two observations here, the first group are usually the guys who always operate out of a tactical, "that's good enough" catch-up mode, the second group are the ones who have a much more strategic approach to security. Nothing that's in the current PCI DSS spec should be a surprise to anyone who deals with security, all of the requirements make security AND business sense and one could argue that companies should have been following them even without a standard and the threatening of fines. 

So I would suggest that if you approach every new security requirement from a tactical point of view you are already screwed. At the same time organizations could start and use a "60 days to compliance" at least as a framework that gets them out of the tactical and into a anticipatory mode for security.  For a disciplined organization - yes they are out there - chances are they are already there and if there are a couple of things they have to update to pass an audit, they should be able to do it in 60 days.</description>
		<content:encoded><![CDATA[<p>I'm not sure whether everything has to be in place *before* you hire a vendor. For example, most of the vendor specific documentation won't be possible to produce after it's been deployed and aligned for a given customer environment, </p>
<p>The underlying issue here is that there are companies that look at PCI as, "oh it's just another audit we've got to pass", and then there are organizations who simply want to have a great security posture. Two observations here, the first group are usually the guys who always operate out of a tactical, "that's good enough" catch-up mode, the second group are the ones who have a much more strategic approach to security. Nothing that's in the current PCI DSS spec should be a surprise to anyone who deals with security, all of the requirements make security AND business sense and one could argue that companies should have been following them even without a standard and the threatening of fines. </p>
<p>So I would suggest that if you approach every new security requirement from a tactical point of view you are already screwed. At the same time organizations could start and use a "60 days to compliance" at least as a framework that gets them out of the tactical and into a anticipatory mode for security.  For a disciplined organization - yes they are out there - chances are they are already there and if there are a couple of things they have to update to pass an audit, they should be able to do it in 60 days.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: netsecurity</title>
		<link>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-3894</link>
		<pubDate>Thu, 09 Aug 2007 19:29:37 +0000</pubDate>
		<guid>http://hackreport.net/2007/08/08/pci-compliance-in-60-days/#comment-3894</guid>
					<description>I don't think it is realistic to count on 60 days as a time frame for PCI compliance in the vast majority of enterprises.

Yes, it is possible when there is a new, single application that is being brought up for the first time, but in a complex environment it may well take 60 days just to map what is the current topology and the data flows. Without the precursor information in place and validated, putting boxes that handle encryption and encryption key management in the data center won't really create compliance.

If I were a vendor of a hardware or software package dealing with one or more of the twelve PCI standards I’d have a few questions I’d ask the buyer before signing a contract:

1. Have the executive team proven they support the project by making sure their enterprise is in alignment with the objectives?

2. Has the enterprise provided the funds to accomplish the required precursor work?

3. Are policies, procedures, and documentation current?

4. Are their people within the enterprise who own keeping policies, procedures, and documentation current?

There are a number of other questions that would need to be asked and answered affirmatively, but the few above will give you the flavor of the type of questions they would be.

The other part of this type of situation is that no one vendor handles all twelve aspects of PCI-DSS. As with other things, the weakest link is the one that will be exploited. The vendor for the one part may well be compromised by any failure in the remediation of the other parts such as firewall configuration, proper isolation via network sub-netting, data in flight, data leaving the network via e-mail or other protocols, and on and on, need to be addressed. 

You could put a very large team on the project to make it move faster. While a large team can do a lot, there is always a certain shakedown period for the team to be able to work effectively together. The larger the team, the longer this trust building process will take. Then, too, there is the trust building required between the vendor’s or consultant’s team and the staff of the enterprise.

Even a team that has worked together on other projects and has been tested under fire with real world problems, and is in alignment with the enterprise, won’t have a chance unless you have all the policies, documentation and organizational drive and buy-in in place *before* you hire the vendor.

It is this groundwork that is missing in my experience and often the organization is not willing to pay for and keep current all this. To me, this is the most critical part of meeting any compliance or regulatory requirement, and while this is my area of expertise, I think you will find most people experienced in IT will agree.

That said, it is possible to meet PCI standards in a SMB environment, but I wouldn't count on it. The lack of complete and current documentation of the topology and the data flows is often worse than the very sad state of affairs at larger enterprises.

If I were the buyer I'd be very skeptical and want written, actionable guarantees before signing a contract.

I’d be very interested in hearing other viewpoints on this subject.

Allen Schaaf, CISSP, CEH, CHFI</description>
		<content:encoded><![CDATA[<p>I don't think it is realistic to count on 60 days as a time frame for PCI compliance in the vast majority of enterprises.</p>
<p>Yes, it is possible when there is a new, single application that is being brought up for the first time, but in a complex environment it may well take 60 days just to map what is the current topology and the data flows. Without the precursor information in place and validated, putting boxes that handle encryption and encryption key management in the data center won't really create compliance.</p>
<p>If I were a vendor of a hardware or software package dealing with one or more of the twelve PCI standards I’d have a few questions I’d ask the buyer before signing a contract:</p>
<p>1. Have the executive team proven they support the project by making sure their enterprise is in alignment with the objectives?</p>
<p>2. Has the enterprise provided the funds to accomplish the required precursor work?</p>
<p>3. Are policies, procedures, and documentation current?</p>
<p>4. Are their people within the enterprise who own keeping policies, procedures, and documentation current?</p>
<p>There are a number of other questions that would need to be asked and answered affirmatively, but the few above will give you the flavor of the type of questions they would be.</p>
<p>The other part of this type of situation is that no one vendor handles all twelve aspects of PCI-DSS. As with other things, the weakest link is the one that will be exploited. The vendor for the one part may well be compromised by any failure in the remediation of the other parts such as firewall configuration, proper isolation via network sub-netting, data in flight, data leaving the network via e-mail or other protocols, and on and on, need to be addressed. </p>
<p>You could put a very large team on the project to make it move faster. While a large team can do a lot, there is always a certain shakedown period for the team to be able to work effectively together. The larger the team, the longer this trust building process will take. Then, too, there is the trust building required between the vendor’s or consultant’s team and the staff of the enterprise.</p>
<p>Even a team that has worked together on other projects and has been tested under fire with real world problems, and is in alignment with the enterprise, won’t have a chance unless you have all the policies, documentation and organizational drive and buy-in in place *before* you hire the vendor.</p>
<p>It is this groundwork that is missing in my experience and often the organization is not willing to pay for and keep current all this. To me, this is the most critical part of meeting any compliance or regulatory requirement, and while this is my area of expertise, I think you will find most people experienced in IT will agree.</p>
<p>That said, it is possible to meet PCI standards in a SMB environment, but I wouldn't count on it. The lack of complete and current documentation of the topology and the data flows is often worse than the very sad state of affairs at larger enterprises.</p>
<p>If I were the buyer I'd be very skeptical and want written, actionable guarantees before signing a contract.</p>
<p>I’d be very interested in hearing other viewpoints on this subject.</p>
<p>Allen Schaaf, CISSP, CEH, CHFI
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
