The ultimate goal of the PCI DSS is to lower financial losses due to fraud across the card payment world. How does it go about this? The six PCI DSS objectives work together to lower risks across your card processing operations. When followed correctly they make it harder for unauthorized people to get their hands on card numbers and other sensitive information.
There are a lot of different ways in which card data is handled. Simply requiring people to safeguard it would hardly result in a consistent approach. To make any information security program more manageable, we try to identify its objectives. Each objective then becomes a more manageable unit of work.
In the case of PCI DSS, there are six (6) high level objectives the PCI SSC have identified. Each of these has one or more requirements supporting it, and each requirement has many items to assess. Normally during an assessment we focus on those individual line items. But that risks losing the big picture. Stepping back and looking at the six objectives gives us a chance to consider what PCI DSS is really about.
Contents
PCI DSS Structure
Within PCI DSS, there are six high level objectives. Each has different numbers of items to assess, however all objectives all considered equally important. Each objective has to be in place for you to be considered compliant with the standard.
Like most security controls, the objectives are designed to operate together. You need to recognize this part: the tightest firewall configuration can’t guarantee the safety of cardholder data if you have no HR background checks or vendor due diligence in place.
In that regard, the PCI DSS is very useful in that it tells you the minimum set of areas for you to be concerned about. You should plan on going beyond PCI DSS requirements, but it’s a solid baseline. Most Information Security standards require management to do a risk assessment to identify the set of risks and vulnerabilities to their business. PCI DSS also requires this, but it starts off with a defined set of areas to focus on and controls to implement.
You can easily nitpick individual items within the PCI DSS testing procedures, and argue they’re not current best practice. A good example is the change in password guidance from NIST regarding frequency of password changes. PCI DSS has not yet caught up with this. But in general, the high level objectives are sound.
So what are they?
The Six PCI DSS Objectives
The Six high level objectives for PCI DSS are layed out in the following table.
| PCI DSS Objective |
|---|
| Build and Maintain a Secure Network and Systems |
| Protect Cardholder Data |
| Maintain a Vulnerability Management Program |
| Implement Strong Access Control Measures |
| Regularly Monitor and Test Networks |
| Maintain an Information Security Policy |
Let’s consider each of these in depth.
Build and Maintain a Secure Network and Systems
Unless your interaction with PCI DSS is limited to hosting a payment terminal managed by an acquirer, you’re going to be doing some basic level of system integration. This might be as simple as having a network switch, a firewall connecting to your ISP, and a few terminals. The moment you have multiple devices interacting, you need to think:
- how are they interacting
- how do I keep that secure
This is why there’s an objective to build and design secure systems. Unfortunately it’s not just for megacorps with 100K endpoint devices.
Protect Cardholder Data
The whole of PCI DSS is about protecting cardholder data. So why this specific objective? This one is much more focussed, as you can see when you drill into the requirements. In this case, you’re being asked to protect cardholder data both:
- wherever it is stored
- whenever it is sent over a network
In both cases, encryption is essential to meeting this requirement. That is encryption done properly, with the right key management in place to safeguard the data wherever it’s stored or sent.
Maintain a Vulnerability Management Program
All non-trivial systems have vulnerabilities. A system with no known vulnerabilities is just that – a system nobody has found vulnerabilities for, yet. Since vulnerabilities are constantly being found in existing software, you need to establish ways of handling them. This requires:
- having access to sources of information on vulnerabilities as they’re found
- having procedures in place to react to these
- prioritizing in advance which systems should be updated first when issues are found
All of these form part of a comprehensive vulnerability management program.
Implement Strong Access Control Measures
There’s no use in having the best security controls at the network layer, but then allowing everyone to set a silly password like ‘password1’ (it’s secure because there’s a number!). You need to control who has access to your systems by looking at this problem from different angles:
- a limited set of people should have access to systems with cardholder data
- their level of access should be limited by business need to know
- their access should be strongly authenticated so they can’t be impersonated
- their access should be time-limited to contain any accidental exposure
Be aware: these requirements only apply to business users of your system. PCI DSS has prescriptive requirements for these, but it doesn’t create the same requirements for consumers. You can decide how to manage those based on your business needs and risk tolerance.
Regularly Monitor and Test Networks
Once you’ve built your well designed system and controlled access to it, you need to know what it’s doing. There are multiple reasons you might want to track what’s going on with your production environment:
- get early warning of system issues developing before they become catastrophic
- deter insider fraud as people should know they will be caught if they get up to no good
- provide an audit trail should the worst happen and you get breached
It’s not enough to just be recording and alerting on the events being generated by your systems. You need to regularly test these controls to make sure they’re actually operating. Silence could mean everything is OK, or it could mean your monitoring isn’t working. Testing can tell you the difference.
Maintain an Information Security Policy
In the context of GRC, a Policy document is a management statement of how things should be done. Whether this requires cardholder data to be encrypted, or that background checks be performed before hiring someone, a requirement is created for an operational department to act in a specific way.
Many of the items in the PCI DSS require that a policy exists to mandate a specific outcome. The Information Security Policy is where these are documented and communicated to employees, contractors, and service providers. Because of this, policies can’t just be written and filed away. Everyone subject to the Information Security Policy must review it periodically and acknowledge that they have done so.
