SOURCE: LockPath, Inc.

LockPath

March 24, 2015 17:56 ET

Fast Break in Transition -- From PCI DSS 2.0 to 3.0

OVERLAND PARK, KS--(Marketwired - March 24, 2015) - The revision to PCI DSS 3.0 has been a slow train coming, but some companies still haven't caught up despite the January 1, 2015 enforcement deadline. In a survey early last year, 41 percent of respondents were aware of the PCI 3.0 change, but had no plans in place. A surprising 70 percent were still unaware of the deadline.

A report published by Dr. Branden Williams and the Merchant Acquirers' Committee suggested those figures may not be a direct result of ignorance or apathy, but rather misunderstanding on the part of the company. "Many merchants do not fully understand the inner workings of the standard, how it applies to them, and how to ensure their technology partners are properly securing their data," Williams posits.

On the other hand, some organizations just haven't been bit hard enough in the past for lapses in compliance. Williams states that some acquirers and processors don't have much incentive to be proactive on that matter. Some entities, he wrote, "can either absorb the losses or pass them along to merchants instead of proactively working to address the issue."

To make sure that your organization keeps up to code, we've assembled a checklist to help ensure the change process goes smoothly.

-Make penetration testing a requirement before it's no longer just a best practice. (11.3)
Enforcement of this particular tenet doesn't occur until June 20, but it's not exactly a college term paper. If your organization hasn't started taking the steps to create a reliable in-house pen testing program or contracted third party services, stop procrastinating now and get it done.

-Separate the Card Data Environment from the rest of the enterprise. (11.3.4)
This aspect of data security was overlooked and ostensibly became one of the contributing factors to the Target breach last year. Therefore, this requirement will likely be the first thing SAQs look for. Essentially, the CDE should be treated like a biohazard quarantine zone.

-Establish and maintain an inventory of relevant system components. (2.4)
This new requirement affects essentially all software and hardware that touches customer card data, including physical and digital network hosts and devices as well as customized enterprise software and home-baked applications. Not only do organizations need documentation on all of these assets, but they also need to classify each one by function to ease the strain on reporting and auditing. We suspect this requirement will be the most labor-intensive when one considers the implications of registering and classifying virtualized systems and worldwide data center locations across a large enterprise.

-Classify vendor relationships by requirement responsibility. (12.8.5 & 12.9)
Third-party security assessment will be a heavily scrutinized area of compliance this year due to a recent string of massive vendor-related security breaches. Auditors will be looking for concise division, classification and sign-off of security responsibility between organizations and their third-party vendors to identify indemnity in the event of a breach. The interesting part in this process is going to be determining which vendors can see eye-to-eye with your organization's security philosophy.

-Identify and monitor malware threats on non-typical systems. (5.1.2)
If your organization has an older mainframe or Unix assets on the network that aren't being scanned regularly for malware, you'd better be ready to do that. The idea here is to prevent any kind of attack that would exploit older systems as a backdoor to more sensitive data on the network.

-Limit capability to modify or change the operation of antivirus software. (5.3)
This requires explicit authorization from management is needed to modify the schedules of security scanners. Disabling them completely should be a time-limited exception. This is a significant change from the second iteration of the standard, which only required that antivirus was present, current, scheduled and had the ability to generate logs for findings. In theory, the new change should be easy to implement, but might require some advanced configuration.

-Restrict access to physical servers and point-of-sales systems by employee role. (9.9)
Our last tip is more directed toward smaller operations that house their enterprise server in the same closet in which you'd find trashbags and cleaning chemicals or haven't had nearly a strong enough mindshare for security in the past. Stringent methods of physical security for business servers should already be implemented in any larger organizations, but auditors will now also be looking for point-of-sale systems that match up correctly to individually identifiable employees on periodic inspection.

About LockPath
LockPath is a market leader in corporate governance, risk management, regulatory compliance (GRC) and information security (InfoSec) software. The company's flexible, scalable and fully integrated suite of applications is used by organizations to automate business processes, reduce enterprise risk and demonstrate regulatory compliance to achieve audit-ready status. LockPath serves a client base of global organizations ranging from small and midsize companies to Fortune 10 enterprises in more than 15 industries. The company is headquartered in Overland Park, Kansas.