Home » Cybersecurity » Identity & Access » PCI for SMB: Requirement 7 & 8 – Implement Strong Access Control Measures

PCI for SMB: Requirement 7 & 8 – Implement Strong Access Control Measures

This is the fifth post in a series of articles on understanding the Payment Card Industry Data Security Standard – PCI DSS. We are halfway there! In the previous articles about PCI, we covered the following:

• Requirement 1: Build and Maintain a Secure Network – Install and maintain a firewall configuration to protect cardholder data.
• Requirement 2: Build and Maintain a Secure Network – Do not use vendor-supplied defaults for system passwords or other security parameters.
• Requirement 3 & 4: Secure Cardholder Data
• Requirement 5 & 6: Maintain a Vulnerability Management Program

As we move into the next section on how to Implement Strong Access Control Measures, we will talk about Requirements 7 and 8 together. I will set aside Requirement 9 for the next installment so we can dive into that with more detail. Let’s get started!

PCI Requirement 7

Restrict access to cardholder data by business need to know

This is a fairly straightforward principle to abide by. The idea is to ensure you establish a “deny all” philosophy as your default. It is a practice we preach here at Sucuri and it will be a good security-first mindset you can establish as part of your business culture. Specifically, the requirement mandates this mindset for:

1 – Systems Components

For those that are confused by this broad term, it basically refers to:

• Virtual components – virtual routers/switches & virtual desktops/applications, for example.
• Network components – firewalls, switches, routers, network appliances, other security appliances.
• Servers – web, application, database, mail, proxy, (DNS) servers.
• Applications – purchased & custom, including internal and Internet-connected applications.

2 – Access Control Systems

This is exactly what it refers to; any system you have set up designed to prevent & restrict access.

Your security policy should reflect this philosophy and also ensure that whoever is accessing any system containing cardholder data, is authorized to do so and for legitimate purposes.

If you are interested in learning more about security policy, I will be talking about it in our next webinar: Simple Steps To Secure Your Online Store.

PCI Requirement 8

Identify and authenticate access to system components

These are actually requirements that we know intuitively but are still good to review with the team on an ongoing basis; especially as you bring on more to your team.

For example, if you look at requirements 8.1, 8.2, 8.3 and 8.5, you will realize these are standards we are reminded to abide by all the time now in 2018. But enabling 2FA and strong passwords are often easier to preach than practice.

Here are some examples that will help in complying with this requirement based on what’s written in the PCI DSS:

Action A:

Assign all users a unique ID & do not use group, shared, or generic IDs

Good examples:

• Employee 1: v.sant001
• Employee 2: j.doe001
• Employee 3: j.doe002

Action B:

Employ at least one of the following methods to authenticate all users:

• Something you know, such as a password
• Something you have, such as a device
• Something you are, such as a biometric

Good examples:

• LastPass for complex management
• Smartphone for Google Authenticator
• Fingerprint verification

Action C:

Passwords/phrases must meet the following:

• Require a minimum length of at least seven characters (I personally use 16!)
• Contain both numeric & alphabetic characters.
• The passwords/phrases must have complexity.

Good examples:

Here is an example of this using a LastPass-generated password:

M9XmNVuqJoBrBTSL

How to Account for Requirement 8.2 & 8.4

Here are some other ways to consider Requirement 8.2 & 8.4 across your stack.

• Review the existing framework of your origin server to see how it authenticates the username/password combination (something you know).
• Review the existing configuration of your origin server to confirm how it is authenticating your SSH keys (something you have).
• Observe authorized personnel using multi-step/multi-factor authentication to confirm the settings are working as expected.
• Require acknowledgment of all password resets based on your mandated frequency (60 days, 90 days, etc.).
• Setup email campaigns for reminders with guidelines of how to identify and authenticate access to system components.

Any Other Suggestions?

I would also include thorough examples (like some that I listed in the above table) as part of your documented procedures & policies to reduce any confusion about the expectation you’re setting.

This is especially important because Foregenix recently uncovered that:

“…the number and intensity of brute force attacks – such as those which targeted the UK and Scottish Parliaments last year – has increased dramatically over the first half of 2018.”

Foregenix CEO Andrew Henwood also comments:

“There’s little reason to believe the trend will be reversed. The difficulty in catching the cyber criminals, the ease with which they can launch attacks and weak cyber defences especially in growth areas like the Internet of Things means brute force attacks are a long-term issue. Organisations need to take action to safeguard valuable data. Following straightforward security procedures can avert a serious incident that could have a devastating impact on a business.”

In other words: Take care of your business, figuratively and literally!