PCI DSS Requirement 12.3.9 mandates that you allow the “Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use”.  What does this mean in practice?

Background from PCI DSS

The standard intentionally draws a distinction here between employees and vendors/business partners, creating different requirements for each category of remote access user.  The idea is that you would normally allow system administrators and other employees who need ad hoc access to cardholder systems to connect on an as needed basis.  Allowing this same unrestricted access privilege to vendors and business partners exposes your network to an unacceptable level of vulnerability (at least in the eyes of PCI DSS).

Implementing Requirement 12.3.9

We’ve seen two main ways that organizations meet this requirement.  The first is fairly straightforward – enabling and disabling accounts for only those periods of time that the third party requires access to your network.  The standard doesn’t specify the length of the time window you can open access, but the phrase “immediate deactivation after use” makes it clear that you should be allowing access on a connection-by-connection basis.

The second, more creative approach, is to make innovative use of two-factor authentication, as one organization did.  This group uses keyfob-based authentication for two-factor control.  Normally, keyfobs are issued to individual employees, who may then use them to access the network when needed.  In the case of vendors and business partners, the keyfobs are instead kept at the 24-hour NOC.  Here’s how that works:

  1. Vendors who need access must call the NOC and authenticate using a verbal protocol.
  2. The NOC consults vendor-specific instructions to determine whether additional approval is required.
  3. If additional steps, such as contacting the employee who maintains the vendor relationship, are required by the vendor-specific instructions, the NOC staffer who receives the calls follows those steps.
  4. The NOC operator accesses the keyfob for the vendor’s account and provides the vendor with the code on the fob.
  5. The vendor accesses the network using that one-time password.

The beauty of this approach is that access is automatically deprovisioned as soon as the vendor connects.  The one-time password from the keyfob is no longer valid and the requirement is met!

No matter what approach you choose, remember to implement an audit trail!  QSAs will be looking for evidence that you’re following the process that you’ve designed.  This can be as simple as a paper log in the NOC where you record vendor access requests.

What If That’s Not Feasible?

Cases can arise where 24/7 access by a vendor or business partner is required to meet your business requirements.  If that’s true in your environment, the answer is to identify a compensating control and have it approved by your acquiring bank.  Some examples of compensating controls that you may wish to consider include:

  • Background screening of vendor/partner employees identical to that used for your own employees
  • Real-time notification to administrators when vendor/partner accounts are used.
  • Placing the vendor/partner in a network subnet that strictly limits their access.

When you design your controls, it’s helpful to remember the intent of the rule: providing an added safeguard for accounts that have an inherently higher risk.  If you design with this principle in mind, you’ll be on a great path!