Home    Regulatory Compliance    PCI DSS Compliance

Overview

PCI DSS is a set of security guidelines established by major credit card firms to safeguard customer information data and guarantee safe online payments. It also applies to organizations that manage, process, or save payment card data. Achieving PCI DSS compliance is essential to secure sensitive cardholder information, uphold customer trust, and avoid expensive penalties.

For more information, refer to the PCI DSS guide.

Netsurion Managed XDR for PCI DSS Compliance 

Netsurion Managed XDR combines SIEM, log management, proactive threat hunting, and guided incident response to effectively meet the requirements outlined in PCI DSS compliance. With comprehensive monitoring, analysis, and reporting capabilities organizations can identify and manage their assets, establish access controls, protect resources, and respond promptly to incidents.

Businesses may simplify PCI DSS compliance procedures, lower payment card data risk, improve overall security posture, and preserve operational effectiveness by utilizing Netsurion Managed XDR.

Using Netsurion Managed XDR to meet PCI DSS Requirements 

Requirement 1: Install and maintain network security controls

1.1.2 – Roles and responsibilities for performing the activities in Requirement 1 are documented, assigned, and understood.

Netsurion Open XDR supports 1.1.2.a by providing details of allowed or denied, secure or insecure network protocols and ports within the organizational network infrastructure via investigations and reports.

1.2.2 – All changes to the network connections and configurations of NSCs are approved and managed in accordance with the change control process defined in Requirement 6.5.1.

Netsurion Open XDR supports 1.2.2.c by providing details of firewall and router configuration or policy changes via investigations, and reports.

1.2.5 – All services, protocols, and ports allowed are identified, approved, and have a defined business need.

1.2.6 – Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.

Netsurion Open XDR supports testing procedures 1.2.5.b and 1.2.6.b by providing details of allowed or denied network protocols and ports within the organizational network infrastructure.

1.2.8 – Configuration files for NSCs are:

  • Secured from unauthorized access.
  • Kept consistent with active network configurations.

Netsurion Open XDR supports 1.2.8 by providing alarms on firewall synchronization critical or error conditions and by providing details of firewall synchronization conditions via investigations and reports.

1.3.1 – Inbound traffic to the CDE is restricted as follows:

  • To the only necessary traffic.
  • All other traffic is specifically denied.

1.3.2 – Outbound traffic from the CDE is restricted as follows:

  • To the only necessary traffic.
  • All other traffic is specifically denied.

Netsurion Open XDR supports 1.3.1.b and 1.3.2.b by providing details of allowed or denied inbound or outbound network traffic to the cardholder data environment via investigations and reports. This will allow verifying that inbound and outbound traffic are being restricted or allowed.

1.3.3 – NSCs are installed between all the wireless networks and CDE, regardless of whether the wireless network is a CDE, such that:

  • All wireless traffic from wireless networks into the CDE is denied by default.
  • Only wireless traffic with an authorized business purpose is allowed into the CDE.

Netsurion Open XDR supports 1.3.3 by providing details of allowed or denied network traffic that is inbound or outbound between the external Internet environment and cardholder data environment via investigations and reports.

1.4.2 – Inbound traffic from untrusted networks to trusted networks is restricted to:

  • Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
  • Stateful responses to communications initiated by system components in a trusted network.
  • All other traffic is denied.

Netsurion Open XDR supports 1.4.2 by providing details of allowed or denied network protocols or ports between the DMZ environment and the organization’s internal network environment via investigations and reports.

Netsurion Open XDR can detect and alert on allowed or denied network traffic between the external Internet environment and the organization’s internal network environment via investigations and reports.

1.5.1 – Security controls are implemented on any computing devices, including the organization and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows:

  • Specific configuration settings are defined to prevent threats from being introduced into the entity’s network.
  • Security controls are actively running.
  • Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period.

Netsurion Open XDR supports 1.5.1 by providing alarms on host firewall critical or error conditions and by providing details of host firewall conditions via investigations and reports.

Requirement 2: Apply secure configuration to all system components.

2.2.2 – Vendor default accounts are managed as follows:

  • If the vendor default account(s) is used, the default password will be changed as per requirement 8.3.6.
  • If the vendor default account(s) is not used, the account will be removed or disabled.

Netsurion Open XDR supports 2.2.2 by providing alarms and details of known vendor default account authentication failures or successes via investigations and reports.

2.2.1 – Configuration standards are developed, implemented, and maintained to:

  • Cover all the system components.
  • Address all the known security vulnerabilities.
  • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
  • Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
  • Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.

2.2.7 – All non-console administrative access is encrypted using strong cryptography.

Netsurion Open XDR supports 2.2.1 and 2.2.7 by providing details of insecure network protocols or ports that are allowed or denied within the organizational network infrastructure and insecure processes starting or stopping via investigations and reports.

Requirement 3: Protect stored account data

3.6.1 – Procedures are defined and implemented to protect cryptographic keys used to protect the stored account data against disclosure and misuse that include:

  • Access to keys is restricted to the fewest number of custodians necessary.
  • Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
  • Key-encrypting keys are stored separately from the data-encrypting keys.
  • Keys are stored securely in the fewest possible locations and forms.

Netsurion Open XDR supports 3.6.1 by providing details of key integrity activity via investigations and reports on Netsurion Open XDR’s change audit agent. Netsurion Open XDR’s change audit can be configured to monitor key file or directory activities, deletions, modifications, and permission changes. The change audit capability is completely automated; the agent can be configured to scan for files/directory changes on a schedule and can automatically detect file integrity activity in real time.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks.

4.2.1 – Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

  • Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This is a best practice until its effective date. Refer the applicability notes below for further details.
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
  • The encryption strength is appropriate for the encryption methodology in use.

Netsurion Open XDR supports 4.2.1 by providing details of insecure network protocols or ports that are allowed or denied within the organizational network infrastructure and insecure processes that are starting or stopping via investigations and reports. Netsurion Open XDR is capable of alarming in conditions where a system observes unencrypted information is passed when the encrypted traffic is expected.

Requirement 5: Protect all systems and networks from malicious software

5.2.1 – An anti-malware solution(s) is deployed on all the system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that conclude the system components are not at risk from malware.

Netsurion Open XDR supports 5.2.1 by verifying that the service is running on the systems commonly affected by malware and detecting or alerting the changes to the service.

5.3.1 – The anti-malware solution(s) is kept current via automatic updates.

Netsurion Open XDR supports 5.3.1.b by providing alarms on antivirus critical or error conditions and provides detailed information on malware and antivirus detection via investigations and reports. Detection for installed new signatures is also supported.

5.3.2 – The anti-malware solution(s):

  • Performs periodic scans and active or real-time scans.
  • Performs continuous behavioral analysis of systems or processes.

Netsurion Open XDR supports 5.3.2.c by providing visibility to antivirus signature updates and scanning activities, successes and failures via alarms, investigations, and reports.

Netsurion Open XDR’s centralized log collection, management, and archival functionality directly supports PCI-DSS control requirement 5.3.2 by automating the process of collecting and retaining the antivirus software audit trails. Netsurion Open XDR creates archive files of all the collected antivirus log entries which are organized in a directory structure daily, making it easy to store, backup, and destroy log archives based on retention policy.

Requirement 6: Develop and maintain secure systems and software

6.2.4 – Software development professionals establish and apply software engineering techniques or other approaches to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software. These methods may include, but are not limited to, the following:

  • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
  • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
  • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
  • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
  • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
  • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.

Netsurion Open XDR supports 6.2.4 by providing alarms and investigation details on all detected vulnerabilities.

6.3.3 – All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

  • Critical or high-security patches/updates (identified according to the risk ranking process in requirement 6.3.1) are installed within one month of release.
  • All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (For example, within three months of release).

Netsurion Open XDR supports 6.3.3.a by providing alarms on software update critical or error conditions and by providing details on software update conditions via investigations and reports. Netsurion Open XDR can support 6.3.3.b by running reports and showing that specific patches are deployed within one month.

6.4.1 – For public-facing web applications, new threats, and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:

  • At least once in every 12 months and after significant changes.
  • By an entity that specializes in application security.
  • Including, at a minimum, all the common software attacks in Requirement 6.2.4.
  • All vulnerabilities are ranked following the requirement 6.3.1.
  • All vulnerabilities are corrected.
  • The application is re-evaluated after the corrections.

OR

Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:

  • Installed in front of public-facing web applications to detect and prevent web-based attacks.
  • Actively running and up to date as applicable.
  • Generating audit logs.
  • Configured to either block web-based attacks or generate an alert that is immediately investigated.

Netsurion Open XDR supports 6.4.1 by providing alarms and investigation details on the detected vulnerabilities.

Netsurion Open XDR can address either solution by working in conjunction with web exploit systems, such as Intrusion Detection Systems, Web Application Firewalls, Stateful Inspection Firewalls, Web Servers, and other log sources to analyze the detected potential abuses as well as provide a way to investigate suspected breaches.

6.5.3 – Pre-production environments are separated from the production environments and the separation is enforced with access controls.

Netsurion Open XDR supports 6.5.3.c by providing details on allowed or denied network protocols or ports between the test network environment and all other internal production network environments via investigations and reports.

6.5.4 – Roles and functions are separated from the production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.

Netsurion Open XDR supports 6.5.4.c by providing details on allowed or denied network traffic between the test network environment and all other internal network environments via investigations and reports.

6.5.6 – Test data and test accounts are removed from system components before the system goes into production.

Netsurion Open XDR supports 6.5.6.a by providing an intelligence system for logs to be sent to rules that can be created to provide proper alarming, reporting, and enhancement to the abilities of any custom application to be used in the cardholder data environment.

Requirement 7: Restrict access to system components and cardholder data by business need to know

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 are based on users’ job classification and functions.
  • The least privileges required (For example: User, Administrator) to perform a job function.

7.2.2 Access is assigned to users, including privileged users, based on:

  • Job classification and function.
  • The least privileges necessary to perform job responsibilities.

Netsurion Open XDR supports 7.2.1 and 7.2.2 by providing details on privileged access, host authentication, and application access via investigations and reports. Access to cardholder data can be monitored by the custodian(s) of the data in real time by collecting access control system data. Account creation, privilege assignment and revocation, and object access can be validated using Netsurion Open XDR.

Requirement 8: Identify users and authenticate access to system components

8.2.1 – All the users are assigned a unique ID before access to system components or cardholder data is allowed.

8.2.2 – Group, Shared, Generic accounts, or other shared authentication credentials are only used when necessary, on an exception basis, and are managed as follows:

  • Account use is prevented unless needed for an exceptional circumstance.
  • Use is limited to the time needed for the exceptional circumstance.
  • Business justification for use is documented.
  • Use is explicitly approved by the management.
  • Individual user identity is confirmed before access to an account is granted.
  • Every action taken is attributable to an individual user

8.2.3 – Additional requirement for service providers only: Service providers with remote access to customer premises (for example, support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

Netsurion Open XDR supports 8.2.1.b, 8.2.2.b, and 8.2.3 by providing alarms on database accounts granting access or revocation and details on account management, account granting or revocation, and authentication activity via investigations and reports. Netsurion Open XDR also provides details on vendor account management and authentication activity via investigations and reports.

8.2.4 – Addition, deletion, and modification of User IDs, authentication factors, and other identifier objects are managed as follows:

  • Authorized with the appropriate approval.
  • Implemented with only the privileges specified on the documented approval.

8.2.5 – Access for terminated users is immediately revoked.

8.2.6 – Inactive user accounts are removed or disabled within 90 days of inactivity.

8.2.7 – Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:

  • Enabled only during the period needed and disabled when not in use.
  • Use is monitored for unexpected activity.

8.3.4 – Invalid authentication attempts are limited by:

  • Locking out the User ID after 10 unsuccessful attempts.
  • Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.

Netsurion Open XDR supports 8.2 and 8.3 by providing details on account management activities such as account creation, account deletion, and account modification via reports. Account creation can be monitored through reporting and investigations of logs about the creation and modification of accounts.

Requirement 9: Restrict physical access to cardholder data

9.2.4 – Access to consoles in sensitive areas is restricted via locking when not in use.

Netsurion Open XDR provides alarms, investigations, and reports to support PCI-DSS control requirement 9.2.4. Netsurion Open XDR supports 9.2.4 by providing alarms for physical access failures and details on other physical access activity via investigations and reports.

Requirement 10: Log and monitor all access to system components and cardholder data

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

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.

10.2.1.3 – Audit logs capture all access to audit logs.

10.2.1.4 – Audit logs capture all invalid logical access attempts.

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.

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.

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

Netsurion Open XDR supports 10.2 by providing the core function of centralized log collection, management, and archival. Netsurion Open XDR provides alarms on authentication failures from default, disabled, terminated, privileged accounts, object disposal failures, and audit log initializations.

Netsurion Open XDR provides details of user access failures or successes to audit log files, cardholder data files, system-level objects, and applications via investigations and reports.

Netsurion Open XDR provides details of privileged account management such as creation, deletion, modification, authentication failures, and successes, granting or revoking of access, privilege escalation, and failures or successes to access files, objects, and applications via investigations and reports. Netsurion Open XDR also provides details on the creation and deletion of system-level objects and audit log initializations via investigations and reports.

10.2.2 Audit logs record the following details for each auditable event:10.3.2 – Type of event.

  • User identification.
  • Type of event.
  • Date and time.
  • Success and failure indication.
  • Origination of event.
  • Identity or name of the affected data, system component, resource, or service (for example, name and protocol).

Netsurion Open XDR supports 10.2.2 by parsing the account and login information, assigning each log event a specific classification type, specifying a centralized time stamp, extracting success or failure information, identifying the host, IP, application, login originating each event, identifying affected data, components, resources, and other details useful for forensic investigation of the audit logs.

Netsurion Open XDR supports 10.2.2 by independently synchronizing the timestamps of all the collected log entries, ensuring that all log data is time-stamped to a standard time regardless of the time zone and clock settings of the log source.

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

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

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.

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

Netsurion Open XDR supports 10.3 by using discretionary access controls which restricts the viewing of audit logs to individuals based on their role and Need-To-Know. Netsurion Open XDR protects audit trails from unauthorized modification by immediately archiving, hashing, and storing collected logs in a secure central repository. Netsurion Open XDR includes an integrated change audit which can ensure that the collection infrastructure is not tampered with.

Netsurion Open XDR servers utilize access controls at the operating system and application level to ensure log data cannot be modified or deleted. Alerts are customizable to prevent or allow alarms on a case-by-case basis, including not causing an alert with new data being added. Netsurion Open XDR securely collects logs from the entire IT infrastructure including external-facing technologies for storage on an internal LAN Network where a Netsurion Open XDR resides.

10.4.1 – The following audit logs are reviewed at least once daily:

  • All security events.
  • Logs of all the system components that store, process, or transmit CHD and/or SAD.
  • Logs of all the critical system components.
  • Logs of all the servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), and authentication servers).

10.4.2 – Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically.

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

Netsurion Open XDR supports 10.4.1 by supplying a one-stop repository from where to review log data across the entire IT infrastructure. Reports can be generated and distributed automatically daily which provides an audit trail of who did what within Netsurion Open XDR and proof of log data review.

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

Netsurion Open XDR supports 10.5.1 by automating the process of retaining audit trails. Netsurion Open XDR creates archive files of all the collected log entries which are organized in a directory structure by day making it easy to store, backup, and destroy log archives based on retention policy.

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

Netsurion Open XDR supports 10.6.1 by independently synchronizing the timestamps of all collected log entries, ensuring that all log data is time-stamped to a standard time regardless of the time zone and clock settings of the logging hosts.

Requirement 11: Test the security of systems and networks regularly

11.1 – Implement processes to test the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points every quarter.

Netsurion Open XDR supports 11.1.d by providing alarms on the detection of rouge access points and also by providing details of the detected rogue access points via investigations and reports.

11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

Netsurion Open XDR provides alarms, investigations, and reports to support PCI-DSS control requirement 11.4. Collecting logs from network and host-based IDS/ IPS systems, its risk-based prioritization, and alerting reduce the time and cost associated with monitoring and responding to IDS/IPS alerts. Netsurion Open XDR provides built-in alarms that can alert on IDS/IPS detected events such as attacks, compromises, denial of services, malware, reconnaissance activity, suspicious activity, and IDS/IPS signature update failures. Netsurion Open XDR provides details about these critical IDS/IPS events via investigations and reports.

11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:

  • To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.
  • To perform critical file comparisons at least once weekly

Netsurion Open XDR supports 11.5.2.b by providing details of key integrity activity via investigations and reports on Netsurion Open XDR’s Change Audit Agent. Netsurion Open XDR’s Change Audit can be configured to monitor key file or directory activity, deletions, modification, and permission changes. The file integrity capability is completely automated, the agent can be configured to either scan for files or directory changes and can automatically detect file integrity activity in real-time.