Read Time:5 Minute, 9 Second
This is the first of a series of consultant-written blogs around PCI DSS.
Many organizations have multiple IAM schemes that they forget about when it comes to a robust compliance framework such as PCI DSS.
There are, at minimum, two schemes that need to be reviewed, but consider if you have more from this potential, and probably incomplete, list:
Cloud service master account management AWS (Amazon Web Services), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Architecture (OCA),
Name Service Registrars (E.g., GoDaddy, Network Solutions)
DNS service (E.g., Akamai, CloudFront)
Certificate providers (E.g., Entrust, DigiCert)
IaaS (Infrastructure as a Service) and SaaS (Software as a Service)) accounts (E.g.: Digital Realty, Equinix, Splunk, USM Anywhere (USMA), Rapid7)
Servers and networking gear administrative account management (Firewalls, routers, VPN, WAF, load balancer, DDoS prevention, SIEM, database, Wi-Fi)
Internal user account management, (Active Directory, LDAP or equivalent, and third parties who may act as staff augmentation or maintenance and repair services, API accesses)
Consumer account management (often self-managed in a separate database using a different set of encryption, tools and privileges or capabilities, from staff logins).
PCI DSS v4.0 expands the requirement to all system, automated access, credentialed testing, and API interfaces, so those need to be considered too.
Bottom line, in whatever fashion someone or something validates their authorization to use the device, service, or application, that authorization must be mapped to the role and privileges afforded to that actor. The goal being to ensure that each is provisioned with the least-privilege needed to be able to complete its or their intended function(s) and can be held accountable for their actions.
As many of the devices as possible should be integrated into a common schema, since having multiple devices with local only admin accounts is a recipe for disaster.
If privilege escalation is possible from within an already-authenticated account, the mechanism by which that occurs must be thoroughly documented and monitored (logged) too.
PCI DSS Requirement 7 asks the assessor to review the roles and access privileges and groupings that individuals could be assigned to, and that those individuals are specifically authorized to have those access rights and roles. This covers both physical and logical access.
Requirement 9 asks specifically about business-based need and authorization for visitors gaining physical access to any sensitive areas. Frequent visitors such as janitors and HVAC maintenance must be remembered when writing policy and procedures and when conferring access rights for physical access.
Requirement 8 then asks the assessor to put together the roles, privileges, and assignments with actual current staff members, and to validate that the privileges those staff currently have, were authorized, and match the authorized privileges. This is one of the few for-ever requirements of PCI DSS, so if paperwork conferring and authorizing access for any individuals or automation has been lost, it must be re-created to show authorization of the current access rights and privileges.
PCI DSS v4.0 requires much more scrutiny of APIs – which are a growing aspect of application programming. The design engineers need to ensure that APIs and automated processes are given, or acquire, their own specific, unique, authorization credentials, and the interface has session control characteristics that are well-planned, documented, and managed using the same schema created for Requirement 7. Cross-session data pollution and/or capture must be prevented. If the API is distributed as a commercial off-the-shelf (COTS) product, it cannot have default credentials programmed in, but the installation process must ask for, or create and store appropriately, strong credentials for management and use.
Requirements 1 and 6 both impact role and privilege assignments also, where separation of duties between development and production in both networking and code deployment is becoming blurred in today’s DevSecOps and agile world. However, PCI’s standard remains strict and requires such separations, challenging very small operations. The intent is that no one person (or login ID) should have end-to-end control of anything, and no-one should be reviewing or QA’ing and authorizing their own work. This might mean a small organization needs to contract one or more reviewers1 if there’s one person doing development, and the other doing deployment.
Even in larger organizations where developers sometimes need access to live production environments to diagnose specific failures, they must not be using the same login ID as they use for development. Organizations could choose asmith as the developer role and andys as the administrative login ID for the same person, to ensure privilege escalations are deliberately bounded and easily trackable (per requirement 10). Also, no-one should ever be using elevated privileges to perform their day-to-day job; elevations should always be used for point tasks and dropped as soon as they are no longer needed.
Next, third parties allowed into your cardholder data environment (CDE) – for maintenance purposes for instance – must always be specifically authorized to be there (physically or logically) and monitored while they are there. Most SIEM tools these days monitor everything indiscriminately, but PCI also says their access must be cut off as soon as it is no longer needed.
That might mean time-bounding their logical access, and it does mean escorting them while they are present. Staff must also be empowered and encouraged to challenge people with no badge, or no escort, and to escort them out of any sensitive area until their escort can be reunited with them. If your staff has access to customer premises where PCI-sensitive data is present, (either physically or logically) they must conduct themselves in like manner.
PCI DSS v4.0 also adds a requirement that any normally automated process that can be used interactively (e.g. for debugging) must log any of the interactive usage that occurs, with the appropriate individual’s attribution.
Lastly, PCI DSS 4.0 adds credentialed testing using high access privileges for requirement 11 (although not necessarily administrative privilege), which requires those credentials to be designed into the overall requirement 7 schema and subjected to the requirement 8 restrictions and constraints.
1Reviewers are secure-code reviewers and security-trained functional QA staff.
