Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 400 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
PCI Compliance Every Day – Requirement 7
As mentioned in our primer blog post for this series (PCI Compliance Every Day), with the release of PCI Data Security Standard (DSS) v3.2, the PCI Security Standards Council (SSC) introduced the concept of business as usual (BAU). BAU is meant to embed those relevant PCI DSS requirements into the business operations of organizations.
This post focuses on PCI DSS requirement seven; restricting access to cardholder data and in-scope system components based on the “need to know” and/or the principle of “least privilege.” “Need to know” as defined in the PCI DSS is “when access rights are granted to only the least amount of data and privileges needed to perform a job.”
While “need to know” is sometimes viewed as synonymous with “least privilege,” the exact terminology of each are still debated – to a degree. The intent of both, however, is to limit access rights (authentication and authorization) only to those which are absolutely necessary for a specific role – as defined by the organization. For the purposes of this post, users should only be able to access data, systems and execute functions absolutely necessary for their job role.
The sub-heading for requirement seven in the PCI DSS states:
“To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.”
PCI DSS requirement seven focuses on defining job classifications and functions, assigning system roles based on those classifications and functions, approving and validating the access levels assigned, and ensuring any access outside of those parameters default to a “deny all” configuration.
It’s important to understand section seven requirements do not apply solely to individuals (reminder – that’s both internal staff and third parties), but also to applications and their related service accounts, which often possess broad or privileged access and use non-expiring credentials.
The BAU frequencies we’ll primarily focus on in this post are “as needed” and “annual,” although other frequencies and conditions may be referenced to provide additional context (e.g. significant changes). This post also illustrates the cross-over between these two frequencies as they pertain to procedures for creating and managing access rights, which organizations should define for themselves based on the size and/or complexity of the environment.
The frequency of “as-needed” can be viewed a few different ways and can cover an array of activities (and crosses over to support the PCI DSS’ notorious “significant change” term). The “as needed” frequency should be defined by an organization’s risk assessment, but should occur at least annually since the controls must be assessed annually. Organizations should be prepared to account for the items in the list below when deploying new systems and applications, implementing changes in organizational structure (e.g. data owner shifts), or building new business processes interacting with PCI cardholder data (CHD) and sensitive authentication data (SAD) in new ways. Organizations also should ensure these activities include third-party relationships where access roles could be defined for on premise (e.g. remote connections in) and off-premise (e.g. cloud, private VPN). On an “as-needed” basis, organizations should perform the following access control tasks to support a BAU model:
During an organization’s annual PCI assessment, compliance with requirements in section seven will be validated by the assessor, but samples and evidence will reach back in time over the previous year to demonstrate compliance with these requirements were sustained and continue to be in place. Also remember that a designation of “annual” means that this is the minimum allowed and that your risk assessment may dictate that some or all of these controls may have to be tested/assessed more often. As mentioned earlier, performing these activities on a recurring basis and collecting the right evidence along the way will ease the assessment process.
How often organizations feel compliance with these requirements should be validated internally is largely dependent on the size and complexity of the environment as well as driven by the results of the organization’s risk assessment. As a reminder, that internal validation must coincide with the frequency and evidence expectations of the PCI DSS in order to be leveraged for annual assessments. Implementing a process to review access controls (authentication and authorization) for all in-scope system components and PCI data on a quarterly or even monthly basis may be more appropriate for some. The decision to adjust frequencies and perform internal validation checks should take both risk and cost into account and any internal BAU program should collect [proper] evidence along the way as it could be used in an annual assessment when assessors deliver their sample sets. Modeling and executing this the right way can reduce risks inherent with access control and ease the assessment process.
The activities outlined in this post also will help organizations identify and correct, or altogether avoid, permission creep and inappropriately assigned access rights. Permission/entitlement creep can be defined as a condition where a user retains access rights assigned in a previous role, project or other activity where entitlements were changed or added and often takes place when personnel change roles within the same organization.
Implementing access review processes to focus on what the account can authenticate to, and what rights the account has after authentication, can help identify other challenges with access control. Some examples include identifying where default accounts may still exist and be active (PCI DSS requirement 2.1), where shared or generic accounts are being used (PCI DSS requirement 8.5) and if any unused or unneeded accounts still exist (PCI DSS requirements 8.1.4, 8.1.5). Watch for our future posts covering those PCI DSS requirement sections to learn more.
September 19, 2017
Optiv works with your organization to optimize its investment in RSA Archer.
Let us know what you need, and we will have an Optiv professional contact you shortly.