Contact us
PCI-GO
  • Dashboards
  • PCI eBook
  • Library
  • Blog

PCI 4.0 - Impact on Requirement 10

7/12/2023

0 Comments

 

Overview

The impact of the new PCI 4.0 on the former 3.2.1 requirement 10 is in the form of: Reformulation, Clarification, Change/amendments, Merges
Picture
Terminology:
  • The term "firewall" is replaced by "Network Security controls"
  • The term "Antivirus" is replaced by "Antimalware solution"
  • The term "network resources" is replaced by "System components"

New controls: 3 new controls
4.0 - 10.1.2 Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. 
4.0 - 10.7.2 The requirement to detect detected, alerted, and addressed promptly failures of critical security control systems that was only applicable to service providers in 3.2.1 is now generalized as a separated requirement. 
4.0 - 10.7.3 The list of actions to be included into the response plan of failures of any critical security controls systems is now generalized to non-service providers as well as service-providers

Amended:

4.0 - 10.6.2  Provides additional information regarding the usage of central time servers 
  • One or more designated time servers are in use. 
  • Only the designated central time server(s)receives time from external sources. 
  • Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC). 
  • Where there is more than one designated time server, the time servers peer with one another to keep accurate time. 
  • Internal systems receive time information only from designated central time server(s). 
4.0 - 10.6.3 Clarify how PCIco expects Time synchronization to be protected 
  • Access to time data is restricted to only personnel with a business need and changes to time settings on critical systems are logged, monitored, and reviewed. 
4.0 - 10.2.1.2 Requires to logs any interactive use of application or system accounts as part of actions taken by any individual with administrative access.

Removed: The following controls are removed for clarity and structure
3.2.1 - 10.2 Implement automated audit trails for all system components to reconstruct the following events: 
3.2.1 - 10.5 Secure audit trails so they cannot be altered. 
3.2.1 - 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. 

Moved: NA

Get your PCI 4.0 COMPLIANCE DASHBOARD TOOL . Fully aligned with PCI DSS V4.0. It includes the defined approach requirements, the customized approach, applicability notes, purpose, good practices & further information, definition, example and defined testing procedures and prioritization approach. It also provides templates to register your compensating controls, controls met with remediations but also to register your customized Controls, the outcome of the customized approach risk assessments and the risk assessments for the definition of frequency periods as well as to register execution of vulnerability scans and penetration tests

Detailed analysis

Title:
3.2.1 - Track and monitor all access to network resources and cardholder data 
4.0 - Log and Monitor All Access to System Components and Cardholder Data 

3.2.1 - 10.1 Implement audit trails to link all access to system components to each individual user.  
Change: Reformulation

4.0 - 10.2.1 Audit logs are enabled and active for all system components and cardholder data. ​

3.2.1 - 10.2 Implement automated audit trails for all system components to reconstruct the following events: 
Change: REMOVED
​
4.0 - None

​3.2.1 - 10.2.1 All individual user accesses to cardholder data 
Change: Reformulation

4.0 - 10.2.1.1 Audit logs capture all individual user access to cardholder data. 

3.2.1 - 10.2.2 All actions taken by any individual with root or administrative privileges 
Change: Reformulation + Amendement

4.0 - 10.2.1.2 Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. ​

​3.2.1 - 10.2.3 Access to all audit trails 
Change: Reformulation

4.0 - 10.2.1.3 Audit logs capture all access to audit logs. 

​3.2.1 - 10.2.4 Invalid logical access attempts 
Change: Reformulation

4.0 - 10.2.1.4 Audit logs capture all invalid logical access attempts. 

3.2.1- 10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges 
Change: Reformulation

4.0 - 10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to: 
  • Creation of new accounts. 
  • Elevation of privileges. 
  • All changes, additions, or deletions to accounts with administrative access. 

3.2.1 - 10.2.6 Initialization, stopping, or pausing of the audit logs 
Change: Reformulation

4.0 - 10.2.1.6 Audit logs capture the following: 
  • All initialization of new audit logs, and 
  • All starting, stopping, or pausing of the existing audit logs. 

​3.2.1 - 10.2.7 Creation and deletion of system- level objects 
Change: Reformulation

4.0 - 10.2.1.7 Audit logs capture all creation and deletion of system-level objects. 

3.2.1 - 10.3 Record at least the following audit trail entries for all system components for each event
3.2.1 - 10.3.1 User identification 
3.2.1 - 10.3.2 Type of event 
3.2.1 - 10.3.3 Date and time 
3.2.1 - 10.3.4 Success or failure indication 
10.3.5 Origination of event 
10.3.6 Identity or name of affected data, system component, or resource 
Change: Reformulation + Merge

4.0 - 10.2.2 Audit logs record the following details for each auditable event: 
  • User identification. 
  • Type of event. 
  • Date and time. 
  • Success and failure indication. 
  • Origination of event. 
  • Identity or name of affected data, system component, resource, or service (for example, name and protocol). 

​3.2.1 - 10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. 
Change: Reformulation

4.0 - 10.6.1 System clocks and time are synchronized using time-synchronization technology. 

3.2.1 - 10.4.2 Time data is protected. 
Change: Reformulation + amendement
​
4.0 - 10.6.3 Time synchronization settings and data are protected as follows: 
  • Access to time data is restricted to only personnel with a business need. 
  • Any changes to time settings on critical systems are logged, monitored, and reviewed. 

3.2.1 - 10.4.1 Critical systems have the correct and consistent time. 
3.2.1 - 10.4.3 Time settings are received from industry-accepted time sources. 
Change: Merge + Reformulation + Amendement

4.0 - 10.6.2 Systems are configured to the correct and consistent time as follows: 
  • One or more designated time servers are in use. 
  • Only the designated central time server(s)receives time from external sources. 
  • Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC). 
  • The designated time server(s) accept time updates only from specific industry-accepted external sources. 
  • Where there is more than one designated time server, the time servers peer with one another to keep accurate time. 
  • Internal systems receive time information only from designated central time server(s). ​

3.2.1 - 10.5 Secure audit trails so they cannot be altered. 
Change: REMOVED
​
4.0 - None

​3.2.1 - 10.5.1 Limit viewing of audit trails to those with a job-related need. 
Change: Reformulation

4.0 - 10.3.1 Read access to audit logs files is limited to those with a job-related need. 

3.2.1 - 10.5.2 Protect audit trail files from unauthorized modifications. 
Change: Reformulation + Clarification

4.0 - 10.3.2 Audit log files are protected to prevent modifications by individuals.

​3.2.1 - 10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. 
3.2.1 - 10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device. 
Change: Reformulation + Merge

4.0 -  10.3.3 Audit log files, including those for external- facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify. 

​3.2.1 - 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 
Change: Reformulation

4.0 - 10.3.4 File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts. 

​3.2.1 - 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. 
Change: Removed

4.0 - None

3.2.1 - 10.6.1 Review the following at least daily: 
  • All security events 
  • Logs of all system components that store, process, or transmit CHD and/or SAD 
  • Logs of all critical system components 
  • Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.). 
Change: Reformulation

4.0 - 10.4.1 The following audit logs are reviewed at least once daily: 
  • All security events. 
  • Logs of all system components that store, process, or transmit CHD and/or SAD. 
  • Logs of all critical system components. 
  • Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers). 

​3.2.1 - 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment. 
Change: Reformulation + Clarification (target risk analysis) 

4.0 - 10.4.2 Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically. 
4.0 - 10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

​3.2.1 - 10.6.3 Follow up exceptions and anomalies identified during the review process. 
Change: Reformulation

4.0 - 10.4.3 Exceptions and anomalies identified during the review process are addressed. 

​3.2.1 - 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup). 
Change: Reformulation

4.0 - 10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. 

3.2.1 - 10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: 
  • Firewalls 
  • IDS/IPS 
  • FIM 
  • Anti-virus 
  • Physical access controls 
  • Logical access controls 
  • Audit logging mechanisms 
  • Segmentation controls (if used) 
Change: Reformulation + Clarification

4.0 - 10.7.1 Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: 
  • Network security controls. 
  • IDS/IPS. 
  • FIM. 
  • Anti-malware solutions. 
  • Physical access controls. 
  • Logical access controls. 
  • Audit logging mechanisms. 
  • Segmentation controls (if used). 

3.2.1 - 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include: 
  • Restoring security functions 
  • Identifying and documenting the duration (date and time start to end) of the security failure 
  • Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause 
  • Identifying and addressing any security issues that arose during the failure 
  • Performing a risk assessment to determine whether further actions are required as a result of the security failure 
  • Implementing controls to prevent cause of failure from reoccurring 
  • Resuming monitoring of security controls 
Change: Reformulation + Clarification

4.0 - 10.7.3 Failures of any critical security controls systems are responded to promptly, including but not limited to: 
  • Restoring security functions. 
  • Identifying and documenting the duration (date and time from start to end) of the security failure. 
  • Identifying and documenting the cause(s) of failure and documenting required remediation. 
  • Identifying and addressing any security issues that arose during the failure. 
  • Determining whether further actions are required as a result of the security failure. 
  • Implementing controls to prevent the cause of failure from reoccurring. 
  • Resuming monitoring of security controls.

3.2.1 - 10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties. 
Change: Reformulation

4.0 - 10.1.1 All security policies and operational procedures that are identified in Requirement 10 are: 
• Documented. 
  • Kept up to date. 
  • In use. 
  • Known to all affected parties

4.0 10.1.1 All security policies and operational procedures that are identified in Requirement 10 are: 
• Documented. 
  • Kept up to date. 
  • In use. 
  • Known to all affected parties. 

​3.2.1 - NONE
Change: NEW

4.0 - 10.1.2 Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. 

3.2.1: None
Change: NEW
​
10.4.1.1 Automated mechanisms are used to perform audit log reviews. 

3.2.1 - NONE
Change: NEW
​
4.0 - 10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: 
  • Network security controls. 
  • IDS/IPS. 
  • Change-detection mechanisms. 
  • Anti-malware solutions. 
  • Physical access controls. 
  • Logical access controls. 
  • Audit logging mechanisms. 
  • Segmentation controls (if used). 
  • Audit log review mechanisms. 
  • Automated security testing tools (if used).

GO TO REQUIREMENT 9
0 Comments



Leave a Reply.

    Archives

    March 2023
    February 2023
    April 2020
    July 2019
    February 2019
    January 2019
    August 2018
    May 2018
    February 2018
    January 2018
    December 2017
    October 2017
    July 2017
    June 2017
    April 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    February 2016
    January 2016
    October 2015
    August 2015
    January 2015
    July 2014

    RSS Feed

Provided by DGOZONE SPRL.
Proudly powered by Weebly