{"id":261,"date":"2020-04-07T16:57:17","date_gmt":"2020-04-07T16:57:17","guid":{"rendered":"http:\/\/www.pcidssguide.com\/?p=261"},"modified":"2023-10-09T07:55:12","modified_gmt":"2023-10-09T07:55:12","slug":"pci-dss-requirement-10","status":"publish","type":"post","link":"https:\/\/pcidssguide.com\/pci-dss-requirement-10\/","title":{"rendered":"PCI DSS Requirement 10 Explained"},"content":{"rendered":"\n\n\n\n\n
Logging mechanisms and the ability to track user activity are critical to preventing, detecting or minimizing the impact of data security.<\/p>\n\n\n\n
Keeping logs in all environments allows extensive monitoring, warning and analysis when something goes wrong. Determining the cause of the attack is very difficult without logging the activity of the system.<\/p>\n\n\n\n
See Also: PCI DSS Logging Requirements Explained<\/a><\/strong><\/p>\n\n\n\n The PCI DSS Requirement 10 relates to the monitoring and tracking of individual access to system components, applications, databases, or any other device where cardholder data can be stored, processed or transmitted.<\/p>\n\n\n\n It is essential to have a process or system that connects and associates user access to the system components that are accessed. This system creates audit logs and provides the ability to track suspicious activity back to a specific user.<\/p>\n\n\n\n Creating audit trails for suspicious activities alerts the system administrator, sends data to other monitoring mechanisms and provides a history trail for post-incident tracking.<\/p>\n\n\n\n Logging suspicious events allow an organization to identify and track potentially malicious activities.<\/p>\n\n\n\n Automatic audit trails are required for all system components to reconfigure the following events:<\/p>\n\n\n\n Malicious individuals can obtain information about a user account with access to systems in the cardholder data medium (CDE), or create a new, unauthorized account to access the cardholder data.<\/p>\n\n\n\n A record of all individual access to cardholder data can determine which accounts may have been hacked or misused.<\/p>\n\n\n\n Accounts with elevated privileges, such as the \u201cadministrator\u201d or \u201croot\u201d account, may have a significant impact on the security or operational functionality of the system.<\/p>\n\n\n\n If the activities performed are not logged, any problems arising from an administrative error or privileges given to a specific action and individual cannot be monitored.<\/p>\n\n\n\n Malicious users often try to change audit logs to hide their actions. Access logs allow an organization to track the inconsistencies or the possible tampering of records.<\/p>\n\n\n\n Access to logs that define changes, additions and deletions may help track the steps taken by unauthorized personnel.<\/p>\n\n\n\n Malicious people often run multiple access attempts to reach targeted systems. More than one invalid login attempt may be an indication of an unauthorized user\u2019 brute force\u2019 attack or attempts to guess a password.<\/p>\n\n\n\n It is impossible to identify the accounts that could have been used at the time of the event without knowing who logged in. Also, malicious users may try to change their authentication checks to bypass or emulate a valid account.<\/p>\n\n\n\n It is common practice for malicious users who want to turn off or pause audit logs before carrying out illegal activities and avoid being spotted or spotted later.<\/p>\n\n\n\n Starting, stopping, or stopping audit logs may indicate that the log function is disabled or changed by the user to hide their actions.<\/p>\n\n\n\n Malware often creates or modifies system-level objects on the target system to control a specific function or process on the system.<\/p>\n\n\n\n It will be easier to determine whether such changes are allowed if system-level objects such as database tables or stored procedures are logged when they are created or deleted.<\/p>\n\n\n\n When capturing this information for auditable events, it is possible to quickly identify a potential solution with sufficient detail to know who, when, where, where and how.<\/p>\n\n\n\n Time synchronization technology is used in multiple systems to synchronize the clocks. When clocks are not properly synchronized, it can be challenging to compare log files from different systems and create an exact sequence of events.<\/p>\n\n\n\n See Also: What You Need to Know About NTP Security<\/a><\/strong><\/p>\n\n\n\n Time synchronization and log sources show a consistent time for forensic analysis in the event of a violation. For post-incident forensics teams, the accuracy and consistency of time in all systems and the time of each activity are critical in determining how systems are handled.<\/p>\n\n\n\n An example of time synchronization technology is the Network Time Protocol (NTP).<\/p>\n\n\n\n Critical systems must have an accurate and consistent time. For this;<\/p>\n\n\n\n Time data should be preserved. For this;<\/p>\n\n\n\n Time settings should be taken from industry-accepted time sources. For this;<\/p>\n\n\n\n Usually, malicious people entering the network try to edit or change audit logs to hide their activity. If the audit logs are not adequately maintained, their accuracy and integrity cannot be guaranteed. Therefore, audit logs can be rendered useless as an investigation tool after an investigation.<\/p>\n\n\n\n Only people with a business need should be able to view audit trail files.<\/p>\n\n\n\n Adequate protection of audit logs includes robust access control and the use of physical or network separation to make logs challenging to find and replace.<\/p>\n\n\n\n Backing logs to a central log server or medium that is difficult to modify without losing time provides log protection if the system that creates logs is compromised.<\/p>\n\n\n\n External-facing technology logs such as wireless devices, firewalls, DNS and mail servers will reduce the risk of loss or replacement as they are more secure on the internal network.<\/p>\n\n\n\n Logs can be written directly to related resources or uploaded or copied securely from external systems to the internal system or media.<\/p>\n\n\n\n Monitoring file integrity or change detection systems will check critical files for changes, and report when those changes are made.<\/p>\n\n\n\n Files that do not change regularly are monitored for file integrity monitoring purposes, which means that there is a potential attack attempt when such files are changed.<\/p>\n\n\n\n Newly added data should not cause an alert to prevent the generation of continuous alerts.<\/p>\n\n\n\n Many violations occur days or months before they are detected. Regular daily reviews by staff or automated methods can identify and proactively address unauthorized access to the cardholder\u2019s data environment.<\/p>\n\n\n\n See Also: PCI SIEM Requirements <\/a><\/strong> <\/p>\n\n\n\n The daily review does not have to be manual. Using daily collection, segregation, and alert tools can help streamline the process by identifying the daily events that need to be reviewed.<\/p>\n\n\n\n Checking logs regularly daily will minimize the exposure time for a possible violation.<\/p>\n\n\n\n In addition to security events, logs of critical system components are also required to identify potential problems. Determination of the safety incident may vary for each organization. In such cases, consideration should be given to the type, technology and function of the device. Organizations should also define \u201cnormal\u201d traffic to help identify abnormal behaviour.<\/p>\n\n\n\n The following should be reviewed daily:<\/p>\n\n\n\n Logs for all other system components should be reviewed periodically to identify symptoms of potential problems or attempts to access sensitive systems through less sensitive systems. The annual business risk assessment should determine the frequency of the reviews.<\/p>\n\n\n\n Depending on the organization\u2019s policies and risk management strategy, procedures for periodic review of logs of all other system components, either manually or automated, should be defined.<\/p>\n\n\n\n If the exceptions and anomalies identified during the log review are not investigated, the organization may not be aware of any unauthorized and potentially malicious activity occurring within its network.<\/p>\n\n\n\n The procedures needed to track the exceptions and abnormalities identified in the review process should be defined.<\/p>\n\n\n\n It usually takes some time to understand that an attack has reached its target or that the system has been exposed.<\/p>\n\n\n\n See Also: What are the PCI DSS Log Retention Requirements?<\/a><\/strong><\/p>\n\n\n\n Keeping logs for at least one year allows a sufficient log history of researchers to determine the duration of a potential violation.<\/p>\n\n\n\n An entity can quickly identify and minimize the impact of a data breach by holding a quarterly journal. Storing logs in offline locations may prevent them from being available, and longer time may be required to restore log data, analyze and identify affected systems or data.<\/p>\n\n\n\n The following items should be included in the security policies and procedures regarding audit logs:<\/p>\n\n\n\n This requirement only applies when the assessed organization is a service provider.<\/p>\n\n\n\n Without formal processes to detect and alert critical security checks, failures cannot be seen for long periods. They can give attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.<\/p>\n\n\n\n Certain types of malfunctions may vary depending on the functionality of the device and the technology used. Typical faults are a system that ceases to perform its safety function or does not function as intended. An example of this is a firewall that erases all of its rules or is offline.<\/p>\n\n\n\n Critical security control systems can include:<\/p>\n\n\n\n This requirement only applies when the assessed organization is a service provider.<\/p>\n\n\n\n Attackers can use this time to add malware, take control of the system, or steal data from the enterprise environment if critical security control error alerts do not respond quickly and effectively.<\/p>\n\n\n\n Documented evidence should support the availability of procedures and procedures for responding to security failures. Also, employees should be aware of their responsibilities in the event of a malfunction. Actions and responses to the error should be included in the documented evidence.<\/p>\n\n\n\n Processes to respond to errors in security audits should include:<\/p>\n\n\n\n Staff should be aware of and follow security policies and day-to-day operational procedures to monitor all access to network resources and cardholder data on an ongoing basis.<\/p>\n\n\n\n For detailed information, see the PCI DSS Quick Reference Guide<\/a><\/strong> from the PCI SSC Documentation library.<\/p>\n\n\n\n To review all of the PCI DSS Requirements, you can review our PCI DSS Requirements<\/a><\/strong> and PCI Compliance<\/a><\/strong> articles.<\/p>\n","protected":false},"excerpt":{"rendered":" Logging systems and monitoring user behaviors are important to prevent, identify or mitigate the effect of a data compromise. The availability of logs in all environments makes it possible to monitor, warn and evaluate thoroughly when something goes wrong.<\/p>\n","protected":false},"author":1,"featured_media":351,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[19,32,20],"tags":[54,66,56],"yoast_head":"\nPCI DSS Requirement 10.1: Apply audit trails to associate all access to system components with individual users.<\/strong><\/h2>\n\n\n\n
\n
PCI DSS Requirement 10.2: Apply automatic audit trails for all system components to reproduce events<\/strong><\/h2>\n\n\n\n
\n
PCI DSS Requirement 10.2.1: All individual access to cardholder data<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.2.2: All transactions by root or any person with administrative privileges<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.2.3: Access to all audit log paths<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.2.4: Invalid logical access attempts<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.2.5: Use and modification of identification and authentication mechanisms and all changes, additions or deletions in accounts with root or administrator privileges<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.2.6: Starting, stopping, or pausing audit logs<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.2.7: Creating and deleting system-level objects<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.3 1-6: Record at least the following audit trail entries for all system components under each event<\/strong><\/h2>\n\n\n\n
\n
PCI DSS Requirement 10.4 1-3: Synchronize all critical system clocks and times using time synchronization technology.<\/strong><\/h2>\n\n\n\n
\n
\n
\n
PCI DSS Requirement 10.5: Secure audit trails cannot be altered.<\/strong><\/h2>\n\n\n\n
PCI DSS Requirement 10.5.1: Limit the display of audit trails only to those with business needs.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.5.2: Protect audit trail files from unauthorized changes.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.5.3: Back up audit trail files to a central log server or environment that is difficult to alter.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.5.4: Write logs for external technologies to a secure, central, internal log server or media device.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.5.5: Use file integrity monitoring or change-detection software in logs to ensure that existing log data cannot be changed without generating an alert<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.6: Review logs and security events for all system components to identify abnormalities or suspicious activity.<\/strong><\/h2>\n\n\n\n
PCI DSS Requirement 10.6.1: Review logs of all system components that store, process, or transmit CHD or SAD at least daily<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 10.6.2: Review the logs of all other system components according to organization policies and risk management strategy as determined by the organization\u2019s annual risk assessment.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.6.3: Track exceptions and abnormalities detected during the review process.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 10.7: Retain audit trail history for at least one year and have at least three months of data ready for analysis<\/strong><\/h2>\n\n\n\n
\n
PCI DSS Requirement 10.8: Additional requirement for service providers only: Apply a process for timely detection and reporting of faults in critical security control systems<\/strong><\/h2>\n\n\n\n
\n
Requirement 10.8.1 Additional requirement only for service providers: Respond to faults of critical security controls promptly.<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 10.9: Ensure that security policies and operational procedures are documented, in use, and known to all affected parties to monitor all access to network resources and cardholder data.<\/strong><\/h2>\n\n\n\n