Anyone that handles payment card data is affected, so most of us have heard of the Payment Card Industry Data Security Standard (PCI-DSS). It establishes key expectations for protecting cardholder data, whether you’re handling a transaction or keeping details in storage.
When you think of PCI, you probably think of your go-to defensive measures. You’ll have carefully considered the role of your firewall, your anti-virus, and any intrusion prevention systems and made sure they meet the required standard.
However, with the rise in insider threats, protecting your network at the edge is just one part of effective security. So, as you’d expect, PCI compliance also covers the way you should handle accounts, and privileged passwords – both how they are used and how auditable that is.
How are accounts and privileged passwords used?
Requirement 7.1.2 of PCI DSS states that you must ‘Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities’.
That means equipping users with a login that is appropriate to the task at hand – not an all-encompassing root that gives them more power than they need.
Fundamentally, you’d achieve this by managing a large number of logins, each with their own level of access to a system or the wider network. However, it is important to consider the impact of every account – the additional administrative burden that every login represents.
Meanwhile, your root-level accounts are a cause for concern. The blanket access they offer is just too widespread to be ‘least privilege’ for most roles.
However, it’s possible to enforce least privilege on root admin accounts. SSH Command whitelisting limits the commands that are available to an admin, effectively stripping unnecessary privileges away from the login. This is an effective way to make root accounts more granular and tailored to job responsibilities.
Are your privileged accounts really auditable?
Requirement 10.2.2 of PCI DSS states you must ‘Implement automated audit trails for all system components to reconstruct all actions taken by any individual with root or administrative privileges’.
In short, you need to know who is using a privileged account at a given moment, and what they are doing with it.
The problem is how we really use our passwords. In an ideal world, every account would only be used by a single admin. In practice, those privileged accounts are routinely shared by several people in a team. That’s the way of working that makes sense. That’s how we really get things done.
In that context, accountability is quite simply impossible. While you can see which login is being used, there’s just no way to verify who is using it.
Thycotic Secret Server gives you a centralised, secure repository where your passwords can be stored. When a user needs access, they retrieve the password from this encrypted vault. As a result, you can generate a full audit trail for your passwords, and effectively link them to individuals.
Meeting your PCI obligations with Thycotic
In essence, PCI compliance depends on your ability to:
- Give your users the least privileges for the task they need to carry out
- Maintain full visibility over how accounts are used, even if they are shared between different team members
Thycotic offers an entire suite of tools to help you meet these obligations quickly and easily, including:
- Thycotic Secret Server to make access to shared privileged passwords fully auditable
- Thycotic Privilege Manager for UNIX to limit the commands that a root login can execute
- Thycotic Password Reset Server to lessen the administrative burden of resetting passwords – and allow you to enforce your policies with confidence