Yes, I understand the importance of Requirement 7. Restrict access to cardholder data by business need to know.
Increasingly, my respect grows for peers that communicate in plain English. Why? Because I understand how well you must understand material to [1] discuss it vs. [2] discuss it plainly.
Several years ago I was listening to a public radio tribute for a great Nobel prize-winning physicist. He had recently passed away, and his mark on society wasn't just his great research. It was his ability to plainly explain complex concepts in a way that people understood, and in a way that excited people. Creative passion. Made people want to understand and know even more. He made physics accessible to the average person.
Like many of you, I'm asked to understand a wide variety of topics. That means that I'm often coming back to topics that I've worked with before, and noticing new things.
As an example, requirement 1.1.5 is nicely done:
Now here's an example of much-needed simplification with respect to roles. The extended original version is fine if you work with this every day. But if you don't, I believe it's incredibly important to keep it simple. I think it would be a fun exercise to see how short and direct you could make the PCI-DSS.
Plain English version:
Increasingly, my respect grows for peers that communicate in plain English. Why? Because I understand how well you must understand material to [1] discuss it vs. [2] discuss it plainly.
Several years ago I was listening to a public radio tribute for a great Nobel prize-winning physicist. He had recently passed away, and his mark on society wasn't just his great research. It was his ability to plainly explain complex concepts in a way that people understood, and in a way that excited people. Creative passion. Made people want to understand and know even more. He made physics accessible to the average person.
Like many of you, I'm asked to understand a wide variety of topics. That means that I'm often coming back to topics that I've worked with before, and noticing new things.
As an example, requirement 1.1.5 is nicely done:
- Requirement 1.1.5
- Description of groups, roles, and responsibilities for management of network components
- Testing Procedure
- 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.
- 1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.
- Guidance
- This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components, and that those assigned to manage components are aware of their responsibilities. If roles and responsibilities are not formally assigned, devices could be left unmanaged.
- Plain English: Validate everything is managed.… No device left behind…
- Plain English: 7.1.1 – Validate privileges following least privilege rule are documented.
- Plain English: 7.1.2 – Validate privileges are appropriate with management.
- plain English: 7.1.3 – Validate process exists whereby users are correctly assigned.
- Plain English: 7.1.4 – Validate access approvals are documented.
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
|
7.1 Examine written policy for access control,
and verify that the policy
incorporates 7.1.1 through 7.1.4 as follows:
· Defining access needs and privilege assignments for each role
·
Restriction of access to privileged user IDs to least privileges necessary to perform
job responsibilities
·
Assignment of access based on individual personnel’s job classification and function
·
Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.
|
The more people who have access to cardholder data, the more risk there
is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through
inexperience or malice.
|
7.1.1
Define access needs for each role, including:
·
System components and data resources that each role needs to access for their job function
·
Level of privilege required (for example, user, administrator, etc.) for accessing resources.
|
7.1.1
Select a sample
of roles and verify access needs for each role are defined
and include:
·
System components and data resources that each role needs to access for their job function
·
Identification of privilege necessary for each role to perform their
job function.
|
In order to limit
access to cardholder data to only those
individuals who need such access, first it is necessary to define
access needs for each role (for example,
system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks.
Once roles and corresponding access needs are defined, individuals can be granted access accordingly.
|
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform
job responsibilities.
|
7.1.2.a
Interview personnel responsible for assigning access to verify
that access to privileged user IDs is:
·
Assigned only to roles that specifically require such privileged access
·
Restricted to least privileges necessary to perform
job responsibilities.
|
When assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their
job (the “least privileges”). For example,
the database administrator or backup administrator should not be assigned the same privileges as the overall
systems administrator.
|
7.1.2.b
Select a sample of user IDs with privileged access and interview responsible management personnel to verify
that privileges assigned are:
· Necessary for that individual’s job function
·
Restricted to least privileges necessary to perform
job responsibilities.
|
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings.
Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access
to a user ID.
|
|
7.1.3 Assign access based on individual personnel’s job classification and function.
|
7.1.3 Select a sample
of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function.
|
Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it is easy to grant
individuals access according to their
job classification and function by using the already-created roles.
|
7.1.4 Require documented approval by authorized parties specifying required privileges.
|
7.1.4
Select a sample
of user IDs and compare with documented approvals to verify
that:
· Documented approval exists for the assigned privileges
· The approval was by authorized parties
·
That specified privileges match the roles assigned to the individual.
|
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.
|
