guidance_for_requirements_10_and_11_-_regularly_monitor_and_test_networks [Control]

GUIDANCE FOR REQUIREMENTS 10 AND 11: REGULARLY MONITOR AND TEST NETWORKS

Requirement 10: Track and monitor all access to network resources and cardholder data

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.

Requirement		Guidance
10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.		It is critical to have a process or system that links user access to system components accessed, and in particular, for those users with administrative privileges. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user. Post-incident forensic teams heavily depend on these logs to initiate the investigation.
10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.1 All individual user accesses to cardholder data 10.2.2 All actions taken by any individual with root or administrative privileges 10.2.3 Access to all audit trails 10.2.4 Invalid logical access attempts 10.2.5 Use of identification and authentication mechanisms 10.2.6 Initialization of the audit logs 10.2.7 Creation and deletion of system-level objects.		Malicious individuals on the network will often perform multiple access attempts on targeted systems. Generating audit trails of suspect activities alerts the system administrator, sends data to other monitoring mechanisms (like intrusion detection systems), and provides a history trail for post-incident follow-up.
10.3 Record at least the following audit trail entries for all system components for each event: 10.3.1 User identification 10.3.2 Type of event 10.3.3 Date and time 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		By recording these entries for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, where, and how. 10.3.1 Built into the payment application; no configuration needed. 10.3.2 Built into the payment application; no configuration needed. 10.3.3 Built into the payment application; no configuration needed. 10.3.4 Built into the payment application; no configuration needed. 10.3.5 Is this the computer name? If so, built in. 10.3.6 Built into the payment application; no configuration needed. Disabling of the logs should not be done and will result in non-compliance with PCI DSS.
10.4 Synchronize all critical system clocks and times.		If a malicious individual has entered the network, they will often attempt to change the time stamps of their actions within the audit logs to prevent detection of their activity. For post-incident forensics teams, the time of each activity is critical in determining how the systems were compromised. A malicious individual may also try to directly change the clock on a time server, if access restrictions are not appropriate, to restate the time to before the malicious individual was in the network.
10.5 Secure audit trails so they cannot be altered		Often a malicious individual who has entered the network will attempt to edit the audit logs in order to hide their activity. Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise.
10.5.1 Limit viewing of audit trails to those with a job related need. 10.5.2 Protect audit trail files from unauthorized modifications. 10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. 10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.		Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only) and use of internal segregation (to make the logs harder to find and modify). By writing logs from external facing technologies such as wireless, firewalls, DNS, and mail servers, the risk of those logs being lost or altered is lowered, as they are more secure within the internal network.
10.5.5 Use file-integrity monitoring and 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).		File-integrity monitoring systems check for changes to critical files, and notify when such changes are noted. For file-integrity monitoring purposes, an entity usually monitors files that don't regularly change, but when changed indicate a possible compromise. For log files (which do change frequently) what should be monitored are, for example, when a log file is deleted, suddenly grows or shrinks significantly, and any other indicators that a malicious individual has tampered with a log file. There are both off-the-shelf and open source tools available for file-integrity monitoring.
10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6.		Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach. The log-review process does not have to be manual. Especially for those entities with a large number of servers, consider use of log harvesting, parsing, and alerting tools.
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 back-up).		Retaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing back-up tapes off-site may result in longer time frames to restore data, perform analysis, and identify impacted systems or data.

Requirement 11: Regularly test security systems and processes
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

Requirement		Guidance
11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identity all wireless devices in use.		Implementation and/or exploitation of wireless technology within a network is one of the most common paths for malicious users to gain access to the network and cardholder data. If a wireless device or network is installed without a company's knowledge, it can allow an attacker to easily and “invisibly” enter the network. In addition to wireless analyzers, port scanners, and other network tools that detect wireless devices can be used. Due to the ease with which a wireless access point can be attached to a network, the difficulty in detecting their presence, and the increased risk presented by unauthorized wireless devices, these scans must be performed even when a policy exists prohibiting the use of wireless technology. An organization should have, as part of its incident response plan, documented procedures to follow in the event an unauthorized wireless access point is detected. A wireless IDS/IPS should be configured to automatically generate an alert, but the plan must also document response procedures if an unauthorized device is detected during a manual wireless scan.
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by the company's internal staff.		A vulnerability scan is an automated tool run against external and internal network devices and servers, designed to expose potential vulnerabilities and identify ports in networks that could be found and exploited by malicious individuals. Once these weaknesses are identified, the entity corrects them, and repeats the scan to verify the vulnerabilities have been corrected. At the time of an entity's initial PCI DSS assessment, it is possible that four quarterly scans have not yet been performed. If the most recent scan result meets the criteria for a passing scan, and there are policies and procedures in place for future quarterly scans, the intent of this requirement is met. It is not necessary to delay an “in place” assessment for this requirement due to a lack of four scans if these conditions are satisfied.
11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following: 11.3.1 Network-layer penetration tests 11.3.2 Application-layer penetration tests.		Network and application penetration tests are different from vulnerability scans in that penetration tests are more manual, attempt to actually exploit some of the vulnerabilities identified in scans, and include techniques used by malicious individuals to take advantage of weak security systems or processes. Before applications, network devices, and systems are released into production, they should be hardened and secured using security best practices (per Requirement 2.2). Vulnerability scans and penetration tests will expose any remaining vulnerabilities that could later be found and exploited by an attacker.
11.4 Use intrusion detection systems, and/or intrusion prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up-to-date.		These tools compare the traffic coming into the network with known “signatures” of thousands of compromise types (hacker tools, Trojans and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection via these tools, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these tools should be monitored, so that the attempted intrusions can be stopped. There are thousands of compromise types, with more being discovered on a daily basis. Stale versions of these systems will not have current “signatures” and will not identify new vulnerabilities that could lead to an undetected breach. Vendors of these products provide frequent, often daily, updates.
11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files, and configure the software to perform critical file comparisons at least weekly. Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is the merchant or service provider).		File-integrity monitoring (FIM) systems check for changes to critical files, and notify when such changes are detected. There are both off-the-shelf and open source tools available for file integrity monitoring. If not implemented properly and the output of the FIM monitored, a malicious individual could alter configuration file contents, operating system programs, or application executables. Such unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.

You could leave a comment if you were logged in.