PCI archives - IT Compliance Advisor

IT Compliance Advisor:

PCI

May 27 2009   4:51PM GMT

Zero liability limits legal recourse for PCI data breach violations



Posted by: Scot Petersen
PCI, compliance, Heartland, Hannaford, data breach, credit card, podcast

The recent dismissal of lawsuits against retailer Hannaford raises questions about what recourse consumers have if they are victims of a credit card data breach.

In this Compliance Advisor podcast, PCI expert and ecommerce writer Evan Schuman, of Storefrontbacktalk.com discusses the “zero-liability domino effect” that protects the retailers in the case of a data breach.

Meanwhile, Heartland Payment Systems is continuing to fight back against its data breach, and recently announced an aggressive transaction encryption plan, though it still may not prevent thefts of internal data.

 
icon for podpress  Zero liability limits legal recourse for PCI data breach violations [12:06m]: Play Now | Play in Popup | Download

May 6 2009   4:32PM GMT

Red Flags Rule delay reveals troubling pattern developing



Posted by: Scot Petersen
Red Flag Rule, FTC, PCI, MA data protection law, data protection, data leakage

May 1 passed without the raising of the Red Flags: The Federal Trade Commission announced a delay in the enforcement of the Red Flags Rule, which requires companies to come up with programs to detect and respond to financial data breaches or identity theft.

Last week, the FTC said it will delay enforcement until Aug. 1, “to give creditors and financial institutions more time to develop and implement written identity theft prevention programs.”

This is the second enforcement delay of a major data protection law. Massachusetts extended enforcement of its 201 CMR 17.00 law until Jan. 1, from the original enforcement date of May 2009, also to give constituents more time to get into compliance.

Security expert and SearchCompliance.com contributor Paul Roberts of The 451 Group sees a pattern developing, which he relayed in an email:

I think the decision to delay Red Flag Rule enforcement is yet more evidence that the public sector has a lot to learn about formulating and then implementing data privacy regulations. What’s so interesting is how closely the FTC’s Red Flag Rule headache parallels Massachusetts regulators’ headaches trying to implement their “toughest in the nation” data privacy laws.

“The lesson in both cases is that regulators need to put down the sledgehammer when writing these new rules and spend more time refining their scope and soliciting input from the private sector so that they understand the practical impact of new requirements on businesses, nonprofits and individuals. Practically: Some kind of phased-in approach to enforcement would seem to make sense. And, as with the PCI regulations, it might be smarter to have an iterative process to writing these kinds of regulations, rather than trying to fix a complex problem (data theft, data privacy) in one fell swoop. So you might start with small-bore regulations that have teeth, but are focused on clear problems and easy to implement, then expand and refine them over time, as conditions change.

Seems like smart advice. Perhaps security, compliance and risk managers from corporate America should start calling for a change of strategy from federal and state lawmakers. But on the other hand, he’s also right about the fact that the “public sector has a lot to learn about formulating and then implementing data privacy regulations.” As we have also pointed out, many compliance, security and risk managers are finding themselves out of the loop, creating a major disconnect between the new laws and the efforts many companies are putting forth to get into compliance.


Mar 26 2009   6:57PM GMT

Know your PCI DSS requirements



Posted by: Scot Petersen
PCI, PCI DSS, Heartland, compliance, e-commerce, retail, credit cards, QSA, Heartland Payment Systems, Qualified Security Assessor

IT Knowledge Exchange blogger Charles Denyer has some sound advice for merchants or service providers who are wondering if they are in compliance with the PCI DSS requirements.

A key question that needs to be addressed before implementing PCI is first figuring out how your operation is categorized under Visa’s compliance validation guidelines, either as a merchant or a service provider. Then determine which levels of compliance you are required to meet for that category. These levels range from filling out self-compliance reports up to having to submit to an annual on-site review by a Qualified Security Assessor (QSA).

Such questions are important now in the aftermath of data breaches at Heartland Payment Systems Inc. and RBS WorldPay in recent months. In a strange turn, Heartland officials have gone on the offensive in response to Visa’s statement that it had removed Heartland and RBS from its list of PCI-compliant vendors. The removal prompted some competitors to use the incidents to steal customers away, alleged Heartland CEO Robert Carr, who issued a statement threatening legal action if the misinformation campaign continues.

Visa then clarified its statement regarding the removal, saying that despite the delisting, Heartland was still able to process transactions, which may have caused even more confusion. Evan Schuman has a good take on the situation in “Heartland Taking Names And Kicking POS, With Visa’s Help.”

Gartner has come to the rescue somewhat, issuing a statement earlier this week with recommendations for merchants using Heartland or RBS WorldPay:

* Merchants and other card-accepting enterprises using Heartland or RBS WorldPay services: Take no action, because the processors will likely be recertified soon.
* Visa and other card brands: Clarify PCI DSS enforcement policy from this point on and publicly disseminate enforcement policies and ongoing clarifications and refinements to these policies. Strengthen U.S. payment system security by instituting measures (for example, end-to-end card data encryption and stronger cardholder authentication) that go beyond PCI DSS requirements.
* All parties that handle cardholder data: Focus on maintaining continuous cardholder data security, rather than on achieving PCI-compliant status.

Reblog this post [with Zemanta]

For more coverage on PCI:

Podcast: PCI officials on data breaches, PCI DSS

Third QSA firm placed in remediation by PCI SSC

PCI Council issues priority tool for compliance


Mar 23 2009   7:13PM GMT

Cloud compliance: Will PCI be applied to cloud computing by the FTC?



Posted by: Alexander Howard
Google, Amazon.com, Cloud computing, Hewlett-Packard, Sun Microsystems, Payment card industry, IBM, PCI, cloud compliance, cloud security, SaaS

The hype around cloud computing may have subsided, but the issues around adapting and adopting the underlying model are as hot as ever. The enterprise IT headline of the week in The Wall Street Journal was, after all, that IBM is in talks to buy Sun Microsystems. Why? GigaOm thinks IBM wants to bolster its cloud computing arsenal

Major questions for enterprise adoption remain, however, particularly around the issues of security and compliance. When I attended “An Evening in the Clouds” at last year’s Enterprise 2.0 Conference, where Amazon.com, Google and Salesforce.com offered complete cloud computing environments, these paired challenges were cited by a California state CIO as major barriers to governmental adoption. The advantages posed by accessing the computing power and storage capacity offered in the cloud have simply not outweighed the risks posed by exposing sensitive data by moving it outside of encrypted internal networks.

The issue of compliance and cloud computing is of critical importance for organizations large and small, public or private, nonprofit or for-profit. As Lamont Wood notes in his excellent article for Computerworld on cloud compliance, “the user organization is responsible for figuring out who is doing what to its data and requiring assurances about the data staying in compliance.”

As Wood writes, there are specific issues raised by the usual suspects: SAS 70, Payment Card Industry Data Security Standards (PCI DSS) and the Health Insurance Portability and Accountability Act. For instance, Chris Day, senior VP at Terremark Worldwide Inc., noted in the article:

“PCI responsibilities of a cloud provider include firewalls, intrusion detection, disaster recovery, physical controls and appropriate segmentation of staff duties. Servers handling PCI data should be in a separate room with solid walls and a monitored door, rather than being placed in the main floor of the data center with the other servers.”

Moving personally identifiable information (PII) that an organization has assumed responsibility for protecting to a third party also requires a degree of trust that many governmental entities have been understandably hesitant to make. Or, in some cases, will never make. As Scott McClellan, VP and chief technologist of scalable computing at HP, said to Stacy Higgenbotham during an interview for GigaOm: “Solving security is a trust issue that can be surmounted, but the legal issues around location cannot be. There are also items, such as corporate data for financial results during a quiet period, that aren’t going to leave the enterprise walls.” CIOs, CTOs and CCOs tasked with SOX compliance will likely find that reality familiar.

In the wake of comments by Vivek Kundra, the new U.S. CIO, federal adoption of cloud computing and Software as a Service (SaaS) is likely about to increase. Consider what David Linthicum writes at the Intelligent Enterprise: “It’s clear that new White House appointee Vivek Kundra is part of a ‘new generation of CIOs’ that consider cloud computing as a viable architectural option.” Just read what Kundra told The Wall Street Journal last year:

“I’m all about the cloud computing notion. … I look at my lifestyle, and I want access to information wherever I am. … I am killing projects that don’t investigate Software as a Service first.”

The nation’s first CIO is going to face some stiff criticism in both private and public enterprises. I’m not worried about Kundra’s ability to weather such critiques — he handled the federal sting on his D.C. offices with grace, after all — but there are valid questions about whether certain data sets and institutions should ever be integrated into a cloud computing model.

Perhaps prompted by Kundra’s evangelism, Google’s lobbying or pervasive cloud security concerns, the FTC met this past week to discuss securing personal data in the global economy. The discussion was timely. (Although, as of today, there was no webcast posted for the session.)

As reported by Computerworld UK, Google is getting slammed for the security of its cloud services. According to Jeremy Kirk, “the Electronic Privacy Information Centre is calling on the U.S. Federal Trade Commission to investigate whether Google is making deceptive claims over the security of data stored in cloud-computing services such as Gmail and Google Docs.”

That’s precisely the issue that Chuck Goolsbee focused on when he shared his considerable skepticism about whether cloud computing providers can meet regulatory compliance requirements like PCI DSS in “Don’t buy cloud computing hype: Business model will evaporate.” If there isn’t an effective regulatory standard, framework and guidance from the appropriate regulatory bodies on security, compliance issues will derail enterprise adoption.

FTC guidance on cloud compliance or official recognition by the PCI Security Standards Council may be forthcoming later this year. Given the visibility, adoption and interest in cloud computing in the enterprise, cloud compliance under PCI or something like it seems likely. Michael Dahn addressed the issue late last year inCloud computing security and PCI,” relating the controversy to earlier discussions around compliance and virtualization. He reiterates a common mantra I’ve heard this month: “Regulatory compliance and PCI are NOT technology issues, but risk management issues.”

One potential way that enterprises can adopt cloud computing and still remain compliant may be to use multiple clouds: an external cloud and an internal cloud or private cloud. In fact, at least one Gartner analyst thinks private cloud networks are the future of corporate IT. As Higgenbotham reported in her excellent article on the cloud and the enterprise at GigaOm:

“HP and companies such as Elastra, Sun Microsystems and IBM are pitching highly virtualized and automated environments that mimic the agility of the public clouds. However, all of the people at enterprise-oriented companies I’ve spoken with believe that their customers should start turning over some computing tasks to external clouds, be they infrastructure providers like those offered by Amazon, Rackspace’s new CloudServers business, Sun’s planned cloud or platforms such as Microsoft’s Azure.

Many believe enterprise customers will source their computing to multiple clouds, both to avoid vendor lock-in and because some clouds will be optimized for certain types of computing tasks. That’s why tools to manage multiple clouds will be important. RightScale, Aptana, Sun and others are all trying to help manage multiple clouds.

And once an enterprise sends out data to external clouds, they will need to find ways to manage, secure and  actually deliver this data from inside the corporation to a cloud. Some providers, like Rackspace and Voxel, are banking on customers using their hosting and cloud products as a way to keep the data inside the same company (and maybe data center). [Werner Vogels, CTO of Amazong's Web Services] says Amazon uses VPNs with enterprise clients, while startups such as Aspera are creating private highways to deliver data between clouds.”

In a throwback to a classic IT conundrum, this paradigm of multiple clouds and multiple cloud providers is complicated by interoperability issues. As Rich Miller writes at Data Center Knowledge, cloud interoperability is a hot topic at the moment as a result of the posed multiple cloud model and the diversity of infrastructure and standards presented by Google, Amazon, Microsoft and other cloud computing providers. As Craig Balding of Cloud Security told Wall Street & Technology, “Amazon and Google are walled gardens. You can’t take an app from Google and bring it over to Amazon because they’re architected differently.”

In the cited article, “Adoption of Cloud Computing Hindered by Security and Operations Concerns,” Penny Crossmon reported significant compliance issues rest in the ability of cloud computing providers to meet audit requirements. As she writes, “the biggest hurdle for cloud computing on Wall Street right now — especially among large firms — is a lack of visibility into cloud providers’ operations and security.” Balding suggested that nondisclosure agreements may provide a means for cloud computing providers to share more detailed information about where data is being handled, how, by whom and how it is being protected — all crucial under many compliance regulations. Amazon Web Services released a cloud security white paper to try to address the visibility issue but leaves key details like access to log files or access for digital forensic investigations related to e-discovery unanswered.

One project to keep an eye on is Eucalyptus, an open source system that enables organizations to create private clouds that will be interoperable with multiple cloud computing platforms. As Simon Wardley recently blogged on Radar O’Reilly, “Karmic Koalas love Eucalyptus.” This cryptic title refers to the fact that Mark Shuttleworth recently announced that the next release of Ubuntu 9.10 is code-named Karmic Koala. The project won’t address the thorny issues of compliance requirements but, given the ambition of Canonical (the company that sponsors and supports Ubuntu) to “provide our users with the ability to build their own clouds whilst promoting standards for the cloud computing space,” it may drive the industry towards the adoption of PCI or other frameworks.

For more commentary and perspectives on compliance in the cloud, review the following articles and blog posts:

Reblog this post [with Zemanta]

Technorati Profile