PCI compliance is undergoing change. PCI v3.0 introduced one of the most radical changes called “Business as Usual”. Business as Usual requires organizations to be in a continuous state of compliance. No longer is PCI compliant aspirational. It’s now necessary to be compliant 24/7/365. In order to handle this there needs to be a shift in strategies, policies and procedures. And equally important in corporate culture.
Our goal is to provide insight into how to achieve a state of continuous compliance, resulting in a less disruptive PCI compliance audit with a higher probability of success. The webinar program will address the following:
The challenges of implementing strategies, policies and procedures to support Business as Usual
Business as Usual’s impact on IT.
How network monitoring and file transfer solutions map to many of the new PCI procedures
We hope you can join us next Tuesday, September 15 (ed. Webinar is now available on demand). I’ll post another blog shortly after the event to provide insight into what was addressed.
You might say that the entire point of a Managed File Transfer (MFT) system is to do exactly that: provide centralized management and control. For example, let’s say that your company is subject to the Payment Card Industry Data Security Standard (PCI DSS). Requirement 4 of PCI DSS is to “encrypt transmission of cardholder data and sensitive information across public networks,” such as the Internet. Let’s also say that you frequently need to transmit cardholder data to partner companies, such as vendors who will be fulfilling requests.
One option is to simply allow someone within your company to email that information, or to have an automated process do so. You’ll need to ensure that everyone remembers to encrypt those emails — you did remember to get digital certificates for everyone, correct? — every single time. If someone forgets, you’ve created the potential for a data breach, and it’s not going to look very good for your company on the evening news.
Another option is to automate the file transfer using an MFT solution. That solution can be centrally configured to always apply PGP‐based encryption to the file, to always require an FTP‐over‐SSL connection with the vendors’ FTP servers, and to always require 256‐bit AES encryption. You don’t have to remember those details beyond the initial configuration — it’s
centrally configured. Even if your users need to manually transfer something ad‐hoc — perhaps an additional emergency order during the Christmas rush — your MFT solution will “know the rules” and act accordingly. Your users’ lives become easier, your data stays protected, and everyone sleeps more soundly at night. This central control is often referred to as policy-based configuration because it’s typically configured in one spot and enforced — not just applied — to your entire MFT infrastructure, regardless of how many physical servers and clients you are running.
What’s the difference between enforced and applied? Making a configuration change is applying it. That doesn’t, of course, stop someone else from coming along behind you and applying a new configuration. The idea with policies is that they’re configured sort of on their own, and that they’re protected by a unique set of permissions that govern who can modify them—they’re not just wide‐open to the day‐to‐day administrators who maintain your servers. In many cases, a review/approve workflow may have to be followed to make a change to a policy. Once set, the policies are continually applied to manageable elements such as MFT client software and MFT servers. A server administrator can’t just re-configure a server, because the policy prevents it. The MFT solution ensures that your entire MFT infrastructure stays properly configured all the time.
– From The Tips and Tricks Guide to Managed File Transfer by Don Jones
To read more, check out the full eBook or stay tuned for more file transfer tips and tricks!
I just returned from the PCI Security Standards Council . It was great to spend a couple of days talking tech and trends with other security experts.
The hottest trend this year in the payment security industry is “tokenization”. This technology lifts credit card numbers from sets of data and replaces them with unique one-way tokens (e.g., “234cew23”) in the data instead. The original credit card numbers are stored in a “secure token vault” and may only be retrieved by authorized people and processes who present another set of credentials (preferably two-factor credentials).
The reason businesses find tokenization compelling is because PCI requirements state that data sets with credit card numbers must be treated with more care than data sets without that information (e.g., just your name, expiration date, etc.). The higher degree of care often translates into full encryption, good key management, regular key rotation and a host of other security controls. All these extra controls cost money, so if businesses can ratchet down the sensitivity of their data with tokenization, they can enjoy cost savings by not having to implement (or audit) other security controls.
Anyone buying in at this stage would be an early adopter: the Council has not yet endorsed the use of this technology. However, the Council has formed a working group to come up with specific guidance (e.g., are hashes OK, if so, which ones, are unique IDs OK, etc.), so some level of future acceptance seems likely. So far the working group has only provided a definition of the technology (essentially, the one I provided above). However, a draft recommendation from the Council with specifics is expected around the new year.