September 7, 2010
Outsourcing PCI is not a silver bullet
I’m always particularly interested in blogs and articles that seek to help and advise clients on how to achieve PCI compliance. More specifically, I’m interested in articles that give advice on how to make achieving PCI compliance “easy”. After reading several articles I’ve noticed two common suggestions: 1) minimize the scope of the assessment by segmenting the cardholder environment from the corporate network; and 2) outsource as many of the services as possible. I’m noticing more and more of my clients outsource security tasks to 3rd party service providers (SP) in the hopes of being able to successfully avoid having to be responsible for certain PCI requirements. Services such as firewall/router management, IDS, hosting facilities, software development, code review, & software testing are just a few services which clients have outsourced. Some clients think they are being extra slick by outsourcing these services to service providers who have achieved PCI compliance.
In theory, outsourcing does allow an organization to bypass having to themselves adhere to certain PCI requirements but it does not necessarily completely absolve the organization from responsibility. Just because an organization outsources services to a SP the organization is still on the hook for ensuring that the SP is maintaining and managing the devices or service according to the requirements outlined in the PCI-DSS. This may require the organization to dictate to the SP how “things should be done”. This will also undoubtedly lead to the SP having to be included and visited as part of the organization’s PCI compliance assessment. As a QSA, I’ve seen including a SP’s environments in my client’s PCI assessment go horribly wrong.
“Well we were smart. We made sure to go with a PCI compliant service provider.” This is better but the organization is still not out of the woods. One of the most common mistakes I see my clients make is ASSUME that the services they purchased/using was 1) part of the SP’s Report on Compliance (ROC) scope & 2) that ALL of the PCI requirements that pertain to that particular service, are being performed. As a QSA when I am performing a PCI assessment on my client and they’ve outsourced let’s say their firewall management to a “PCI compliant” SP, I need to do two things which coincidently are the same two things my client hopefully did before signing that P.O. The first thing I, and any halfway decent QSA, needs to do is validate that the SP’s ROC scope includes that particular service my client is using. I need to confirm that the firewall management service/solution/practices were covered in the SP’s PCI-DSS assessment. After confirming the first part, I then need to perform a little QSA due diligence, or C-Y-A, and ensure that the ROC addressed the appropriate PCI requirements. Again, I’ve seen how a client’s total faith in their SP’s ROC has led to false promises and broken dreams.
Outsourcing services is NOT a silver bullet in becoming PCI compliant. With it come different responsibilities and potential consequences if not done correctly. Organizations need to establish a more robust vendor management process which includes a lot more than a written agreement declaring the service provider “responsible for securing cardholder data.”
August 13, 2010
Motivation…..Many things act as motivators for how one does their job. Job satisfaction, meeting contractual requirements, or achieving compensation goals are a few reasons why people do their jobs to the best of their ability. Over the past 3 weeks I’ve had conversations where the term C.Y.A. (Cover Your A$$) has been uttered. I have heard this from both clients and from within my own organization which when considered in their context created a light bulb moment for me both as a security assessor working with my clients and as an employee working for an organization that offers security assessment services. When CYA is a critical part of doing your job, the amount of overhead one creates for oneself can be disruptive.
During my career doing both infosec and PCI security assessments, I’ve seen many examples of CYA. Usually when interviewing business units I tend to discover that credit card numbers are being written down, emailed internally, and then stored indefinitely. This typically is both a surprise to my point of contact as it is to me. When asked why, the response is always a whispered, “CYA”. For reasons that may be obvious to other assessors, this response has the hairs on the back of my neck standing. After further discussions, further paper trails, and scope creep, I have realized that CYA is no longer an admirable quality, if it ever was one. Because several business units within organizations tend to follow a CYA course of action, the amount of “sensitive” information that is being shared internally as well as being sent off site expands the scope of the assessment dramatically. And with increased scope comes increased effort to control and bring into compliance these various business units.
Now one might write this off as an organizational and procedural problem, but when I hear the term CYA explained to me internally when dealing with clients, again I was struck with a foreboding feeling. In the name of CYA, the amount of time I am required to spend on each client and corresponding paperwork seems absurd. True I am billable for that extra time, but I now have to fit this into a schedule that was already packed with my “regular” duties.
As an assessor CYA is showing itself to make it increasingly more difficult for organizations to adequately protect sensitive information. At the same time, internal CYA is making assessors more skittish in not only how they handle their clients but in what they are requiring of their clients during assessments. CYA has even recently entered my realm of thinking and has spooked me. Spooked me because of the recent unpleasantness I’ve but some clients through…No, I am not perfect…shocking!! With that said, I’m not naïve in thinking CYA is not in the back of everyone’s mind when doing their job, but CYA should never be the driving factor in the day to day operations for either me or my clients.
July 26, 2010
As a major part of becoming and maintaining PCI compliance, organizations are tasked with performing routine/periodic tasks over the course of a year. And during their annual PCI re-validation, the organization is required to provide evidence that these routine tasks have been performed. But what happens when the QSA determines that the organization did not keep up with their homework? How does it affect their PCI compliance?
Short answer….it doesn’t.
Merchants and service providers (SP) are required to perform the following routine tasks which a QSA then needs to validate as having been completed:
- Daily review of audit logs
- Quarterly internal vulnerability scans
- Quarterly external vulnerability scans
- Quarterly scans w/wireless analyzer
- 6 month review of firewall/router rule sets
- Annual risk assessment
- Annual review/update of infosec policies
- Annual internal penetration test
- Annual external penetration test
- Annual security awareness
- Annual incident response test
Of course if this is an organization’s first attempt at compliance, they will be unable to provide a “year’s” worth of evidence that the above has been completed. But, if this is not their first time around the PCI block, then the organization should be able to provide a year’s worth of evidence. However, what happens when a merchant or SP missed a quarterly scan or it’s been over a year and they have yet to conduct IR testing? One might think that they’ve missed their mark to be compliant for that year, and another year needs to go by. But that is not the case. If an organization failed to meet a task, they are simply asked to promise (and mean it this time) in a strongly worded policy/procedure to have it done in the required timeframe next year. As for the current assessment, the organization just needs to get it done and submitted to the QSA for review, even though it is outside of the task window. As long as it’s done sufficiently, the QSA has no choice but to mark it “In Place.”
What’s the point? I’d like to see a QSA that actually tells the organization, “Nope, you missed the annual window. You’ll have another chance to be PCI compliant next year.” I know I am being harsh but where are the consequences for not taking these tasks seriously knowing they can just get it done after the fact? Does a breach have to occur in which the card brands, jumping up and down, pointing their finger proclaiming that “at the time of the breach, the organization was not PCI compliant.” By then it would be too late. I think most of us can agree that the tasks identified are part of a comprehensive infosec security plan; however, I consider this is just another example as to why the PCI standard itself needs to be re-evaluated on how it is being applied.