Requirement 7: Restrict Access To Data

Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. 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.

Requirement 7: Restrict Access To Data

7.1 Processes And Mechanisms For Restricting Access To System Components And Cardholder Data By Business Need To Now Are Defined And Understood

7.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

7.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

7.2 Access To System Components And Data Is Appropriately Defined And Assigned

7.2.1 An access control model is defined and includes granting access as follows: • Appropriate access depending on the entity’s business and access needs • Access to system components and data resources that is based on users’ job classification and functions • The least privileges required (for example, user, administrator) to perform a job function

A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing mission-critical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions.

In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals.

7.2.2 Access is assigned to users, including privileged users, based on: • Job classification and function • Least privileges necessary to perform job responsibilities

Access rights are granted to a user by assignment to one or several functions. Access is assigned depending on the specific user functions and with the minimum scope required for the job.

When assigning privileged access, 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.

Once needs are defined for user functions, it is easy to grant individuals access according to their job classification and function by using the already-created roles.

Entities may wish to consider use of Privileged Access Management (PAM), which is a method to grant access to privileged accounts only when those privileges are required, immediately revoking that access once they are no longer needed.

7.2.3 Required privileges are approved by authorized personnel

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.

7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: • At least once every six months • To ensure user accounts and access remain appropriate based on job function • Any inappropriate access is addressed • Management acknowledges that access remains appropriate

When a user transfers into a new role or a new department, typically the privileges and access associated with their former role are no longer required. Continued access to privileges or functions that are no longer required may introduce the risk of misuse or errors. Therefore, when responsibilities change, processes that revalidate access help to ensure user access is appropriate for the user’s new responsibilities.

Entities can consider implementing a regular, repeatable process for conducting reviews of access rights, and assigning “data owners” that are responsible for managing and monitoring access to data related to their job function and that also ensure user access remains current and appropriate. As an example, a direct manager could review team access monthly, while the senior manager reviews their groups’ access quarterly, both making updates to access as needed. The intent of these best practices is to support and facilitate conducting the reviews at least once every 6 months.

7.2.5 All application and system accounts and related access privileges are assigned and managed as follows: • Based on the least privileges necessary for the operability of the system or application • Access is limited to the systems, applications, or processes that specifically require their use

Entities may want to consider establishing a baseline when setting up these application and system accounts including the following as applicable to the organization:

Making sure that the account is not a member of a privileged group such as domain administrators, local administrators, or root.

Restricting which computers the account can be used on.

Restricting hours of use.

Removing any additional settings like VPN access and remote access.

7.2.5.1 All access by application and system accounts and related access privileges are reviewed as follows: • Periodically (at the frequency defined in the entity’s targeted risk analysis) • The application/system access remains appropriate for the function being performed • Any inappropriate access is addressed • Management acknowledges that access remains appropriate

Regular review of access rights helps to detect excessive access rights remaining after system functions change, or other application or system modifications occur. If excessive rights are not removed when no longer needed, they may be used by malicious users for unauthorized access.

7.2.6 All user access to query repositories of stored cardholder data is restricted as follows: • Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges • Only the responsible administrator(s) can directly access or query repositories of stored CHD

Typical user actions include moving, copying, and deleting data. Also consider the scope of privilege needed when granting access. For example, access can be granted to specific objects such as data elements, files, tables, indexes, views, and stored routines. Granting access to repositories of cardholder data should follow the same process as all other granted access, meaning that it is based on roles, with only the privileges assigned to each user that are needed to perform their job functions.

7.3 Access To System Components And Data Is Managed Via An Access Control System(s)

7.3.1 An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components

Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges.

7.3.2 The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function

Restricting privileged access with an access control system reduces the opportunity for errors in the assignment of permissions to individuals, applications, and systems.

7.3.3 The access control system(s) is set to “deny all” by default

It is important to check the default configuration of access control systems because some are set by default to “allow all,” thereby permitting access unless/until a rule is written to specifically deny it.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 7.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirements 7.2 And 7.3

The requirement is very specific. The access should be granted based on the least privileges necessary to perform job responsibilities. Also, all the information should be available on a need-to-know basis. In our example, we “deny all” access to dz-win10 and then grant specific permissions as needed. Restrict access to the physical server, then to the virtualization software, then to dz-win10 and its applications.