Risk // Compliance
9/26/2011
03:22 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

QSAs Share What Drives Improved PCI Practices

As organizations shift attitudes and overcome misconceptions, PCI compliance and security improve

After looking under the covers at so many different kinds of organizations, Payment Card Industry (PCI) Qualified Security Assessors (QSAs) get to see the full range of the good, the bad, and the ugly of PCI compliance and security regimes. According to many QSAs, avoiding PCI struggles, poor security, and flagged yearly assessments are often more about the right attitudes from management than about the IT security practices themselves. QSAs say the organizations that come at PCI positively reap the most benefits. In other words, approach PCI in earnest, and best practices will follow.

"I've been involved in PCI assessments and security before the Data Security Standards were in place, so I've kind of seen the whole evolution," says Chris Novak, a QSA and managing principal for Verizon Business. "And one of the things I've really seen is that organizations who have really looked at it in a positive way -- seen it as a way to get better at security -- they do a better job a compliance."

While organizations should certainly respect the penalties and ramifications of noncompliance with PCI, management needs to remember why the standard exists in the first place. Security is the name of the game, but often senior leadership loses sight of that and looks at compliance as a challenge rather than an opportunity to improve protection.

"I think that what a lot of folks miss is that the key point of compliance is not to find everybody that's not compliant and penalize them," Novak says. "The idea is to drive people toward becoming compliant so they secure their infrastructure."

According to Andrew Jamieson, a QSA for Witham Laboratories, the compliance issue that he sees organizations trip over time and time again during his assessments is poor documentation of security policies. The organization generally might be doing OK with many of its day-to-day IT practices, but because of a lack of management engagement, the policy documentation that drives long-term compliance and overall security success is nonexistent.

"It's because compliance isn't driven down from management. The problem is that when people first read through PCI, it sounds like an IT security problem," he says. "So they kick it to the IT department, but IT is not necessarily in a position to provide the policy-level documentation that's required."

Even when management does become engaged in PCI, it is with the wrong outlook, Jamieson says. Many times senior leaders view PCI compliance as a one-off project. The problem is that passing an assessment might prove point-in-time compliance, but that one-time push is not going to keep breaches at bay if the organization doesn't support it long-term.

"A lot of people we work with on PCI DSS run it as a project. In other words, 'We're not compliant, let's get compliant. Formulate a budget and have a team run it as a project.' Once they get compliant, then management loses interest in funding anything else," he says. "At that point, it's much harder to maintain the practices to keep PCI compliance and security going."

That project mentality is one of the fastest ways to ensure the money poured into the initial effort will be wasted. When it comes time to face a QSA assessment in subsequent years, future project teams end up having to reinvent the wheel all over again.

"As a QSA, we come in once a year, and I think that companies shouldn't see that as the time they should be compliant," Jamieson says. "We recommend people keep a spreadsheet or database of the systems they have, the policies, configurations, patch states, and logging done on them -- that's basically the audit right there. If you keep up to date throughout the year, the audit becomes a really painless process. I'm not going to say it's easy, but it's easier done throughout the year than in a single point in time."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web