PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) is a globally recognized set of security standards designed to protect cardholder data and reduce credit card fraud. It was developed by the Payment Card Industry Security Standards Council (PCI SSC), which was founded by the major credit card brands (Visa, Mastercard, American Express, Discover, and JCB).
What is its purpose?
The primary purpose of PCI DSS is to ensure that all entities that store, process, or transmit credit card information maintain a secure environment. This helps prevent data breaches, protects consumers from identity theft and fraud, and builds trust in the payment ecosystem.
Who does it apply to?
PCI DSS applies to all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). This includes:
Merchants: Any business that accepts credit card payments, regardless of volume.
Processors: Companies that handle the actual processing of payment transactions.
Acquirers: Financial institutions that contract with merchants to accept payment cards.
Issuers: Banks or financial institutions that issue payment cards to consumers.
Service Providers: Any company that provides services that could impact cardholder data security (e.g., hosting providers, payment gateways).
What does it cover?
PCI DSS provides a baseline of technical and operational requirements to protect payment account data. It is built around six control objectives, which are further broken down into 12 detailed requirements:
Six Control Objectives:
Build and maintain a secure network and systems.
Protect cardholder data.
Maintain a vulnerability management program.
Implement strong access control measures.
Regularly monitor and test networks.
Maintain an information security policy.
12 Detailed Requirements (PCI DSS v4.0 is the current version):
Install and maintain network security controls (firewalls) to protect cardholder data. This involves setting up firewalls to create a secure boundary around networks that handle cardholder data and configuring routers securely.
Apply secure configurations to all system components. This means not using vendor-supplied defaults for system passwords and other security parameters. All systems, including servers, network devices, applications, and POS terminals, should be hardened.
Protect stored account data. Minimize cardholder data storage and render all authentication data unreadable if it must be stored. Implement strong encryption, tokenization, or hashing techniques.
Protect cardholder data with strong cryptography during transmission over open, public networks. Ensure that sensitive card details are encrypted across networks (e.g., over the internet).
Protect all systems and networks from malicious software. Use and regularly update antivirus software or programs on all systems commonly affected by malicious software.
Develop and maintain secure systems and software. Ensure all software and systems are patched and updated to protect against new threats. This includes internal and third-party developed software.
Restrict access to system components and cardholder data by business need-to-know. Implement role-based access controls and the principle of least privilege, meaning only individuals who need access to cardholder data for their job functions should have it.
Identify users and authenticate access to system components. Assign a unique ID to each person with computer access and use strong, unique passwords. Multi-factor authentication (MFA) is required for all access into the cardholder data environment.
Restrict physical access to cardholder data. Secure physical access to areas where cardholder data is stored or processed, including paper records and physical devices. Use cameras and access logs to control who can enter these areas.
Log and monitor all access to system components and cardholder data. Implement logging and monitoring of all network and system activities, and regularly review these logs for suspicious activity.
Regularly test the security of systems and networks. Conduct regular internal and external vulnerability scans (at least quarterly) and annual application and network penetration testing to ensure the effectiveness of security measures.
Support information security with organizational policies and programs. Establish and maintain a comprehensive information security policy, conduct regular risk assessments, provide security awareness training for employees, and have an incident response plan.
Compliance Validation:
Organizations subject to PCI DSS must validate their compliance annually, or sometimes quarterly, depending on their transaction volume and processing methods. This can be done through:
Self-Assessment Questionnaire (SAQ): This is a self-evaluation tool for smaller merchants.
Report on Compliance (ROC): For larger entities, this is a formal audit conducted by a Qualified Security Assessor (QSA), an individual or firm certified by the PCI SSC.
Consequences of Non-Compliance:
Failure to comply with PCI DSS can lead to severe penalties, including:
Fines from banks and credit card companies.
Increased transaction fees.
Loss of the ability to process credit card payments.
Damage to reputation and customer trust.
Legal liabilities and lawsuits in the event of a data breach.
PCI DSS is a critical framework for securing payment card data, aiming to minimize the risk of fraud and data breaches across the entire payment industry.
ThreatNG is an all-in-one solution for external attack surface management, digital risk protection, and security ratings, which can significantly help organizations achieve and maintain PCI DSS compliance.
ThreatNG's "External GRC Assessment" capability provides a continuous, outside-in evaluation of an organization's Governance, Risk, and Compliance (GRC) posture. It identifies exposed assets, critical vulnerabilities, and digital risks from the perspective of an unauthenticated attacker, mapping these findings directly to relevant GRC frameworks, including PCI DSS. This enables organizations to proactively uncover and address external security and compliance gaps, thereby strengthening their overall GRC standing.
External Discovery & Continuous Monitoring
ThreatNG performs purely external, unauthenticated discovery, meaning it identifies assets and risks from an attacker's perspective without needing connectors. This is crucial for PCI DSS, as it helps organizations discover unknown or rogue assets that might be storing, processing, or transmitting cardholder data (CHD) and fall within the scope of PCI DSS. ThreatNG monitors an organization's external attack surface, digital risk, and security ratings. This continuous monitoring ensures that new exposures or changes to existing assets that could impact PCI compliance are immediately identified.
Examples of ThreatNG's help:
Identifying rogue applications: ThreatNG can discover applications and login pages that the organization may not have been aware of. If these applications handle CHD, they must be inventoried and secured in accordance with PCI DSS requirements 1.4.2 (inventory), 6.3.1 (secure SDLC), and 6.4.3 (public-facing app protection). ThreatNG's discovery helps ensure all such interfaces are known, protected, and subject to proper security governance.
Detecting exposed developer resources: ThreatNG can identify developer resources and environments that are exposed externally. Suppose these environments are not segmented from production or use real CHD. In that case, it violates PCI DSS requirements 6.4.1 (separation of environments) and 6.4.3 (no production data in test or development environments). ThreatNG's continuous monitoring would flag such exposures, allowing for timely remediation.
ThreatNG performs a variety of external assessments that directly map to PCI DSS requirements:
Web Application Hijack Susceptibility: ThreatNG analyzes the external attack surface of web applications, including domain intelligence, to identify potential entry points for attackers. This directly supports PCI DSS Requirement 6.4.3, which mandates protections for public-facing web applications against attacks like XSS and injection. A missing Content Security Policy (CSP), which ThreatNG can identify, increases the attack surface and is often discovered during vulnerability scans or penetration tests (PCI DSS 11.3.1 and 6.2.3).
Example: If ThreatNG identifies a subdomain missing a Content Security Policy (CSP) header, it directly highlights a weakness in protecting public-facing web applications, as required by PCI DSS 6.4.3. A lack of CSP can facilitate malware injection via XSS, indirectly linking to anti-malware mechanisms (PCI DSS 5.2.2).
Subdomain Takeover Susceptibility: ThreatNG uses external attack surface and digital risk intelligence, including Domain Intelligence, to evaluate a website's susceptibility to subdomain takeover. This includes analyzing the website's subdomains, DNS records, and SSL certificate statuses. Subdomain takeovers are critical for PCI DSS as they relate to asset management (PCI DSS 1.4.2), vulnerability management (PCI DSS 6.2.3), and external penetration testing (PCI DSS 11.3.1).
Example: ThreatNG detecting a subdomain takeover vulnerability means an unmanaged or forgotten asset could be hijacked. This directly impacts PCI DSS 1.4.2 (maintaining inventory) and 11.3.1 (pen testing external interfaces), as hijacked subdomains can be used for phishing or script injection on trusted domains, which falls under 6.4.3 (protecting public-facing web applications).
BEC & Phishing Susceptibility: This is derived from Sentiment and Financials Findings, Domain Intelligence (including DNS Intelligence, Domain Name Permutations, and Web3 Domains that are available and taken; and Email Intelligence that provides email security presence and format prediction), and Dark Web Presence (Compromised Credentials). It directly ties to PCI DSS Requirements 5.4.1 (protecting personnel and systems from phishing attacks) and 12.10.5 (responding to alerts).
Example: ThreatNG identifying "Domain Name Permutations - Taken with Mail Record" indicates a high-confidence phishing infrastructure. This relates to PCI DSS 5.4.1 (protection against phishing) and 12.10.5 (incident response for detection events).
Brand Damage Susceptibility: This is derived from attack surface intelligence, digital risk intelligence, ESG Violations, Sentiment and Financials (Lawsuits, SEC filings, SEC Form 8-Ks, and Negative News), and Domain Intelligence (Domain Name Permutations and Web3 Domains that are available and taken). While not a direct PCI DSS requirement, brand damage can stem from security incidents that violate PCI DSS, which in turn impacts policy, incident response, and risk assessment (PCI DSS 12.3.1, 12.10.1, 12.2.1).
Data Leak Susceptibility: This is derived from external attack surface and digital risk intelligence based on Cloud and SaaS Exposure, Dark Web Presence (Compromised Credentials), Domain Intelligence (DNS Intelligence capabilities which include Domain Name Permutations and Web3 Domains that are available and taken; and Email Intelligence that provides email security presence and format prediction), and Sentiment and Financials (Lawsuits and SEC Form 8-Ks). This aligns with PCI DSS requirements related to data protection (PCI DSS 3.x), access control (PCI DSS 7.x, 8.x), and incident response (PCI DSS 12.10.x).
Example: ThreatNG identifying "Files in Open Cloud Buckets" is a direct violation of PCI DSS controls, such as 3.4.1 (rendering stored PAN unreadable) and 7.2.1 (restricting access based on need-to-know). It also triggers incident response (12.10.5) and requires accurate inventories (12.5.2).
Cyber Risk Exposure: This considers parameters ThreatNG's Domain Intelligence module covers, including certificates, subdomain headers, vulnerabilities, and sensitive ports, to determine cyber risk exposure. Code Secret Exposure is factored into the score as it discovers code repositories and their exposure level and investigates the contents for the presence of sensitive data. This maps to PCI DSS requirements for secure configurations (PCI DSS 2.2.x), strong cryptography (PCI DSS 4.x), and vulnerability management (PCI DSS 6.2.x).
Example: ThreatNG detecting "Invalid Certificates" directly violates PCI DSS 4.2.1 (use strong cryptography) and 4.2.2 (valid certificates). It also indicates poor system configuration (2.2.6) and is a finding for vulnerability scans (11.2.1).
Cloud and SaaS Exposure: ThreatNG evaluates cloud services and Software-as-a-Service (SaaS) solutions. This is crucial for PCI DSS 1.4.2 (inventory of system components) and 12.5.2 (assign responsibility for protection of CHD), as cloud environments need to be appropriately scoped and secured.
ESG Exposure: ThreatNG rates the organization based on the discovered environmental, social, and governance (ESG) violations through its external attack surface and digital risk intelligence findings. It analyzes and highlights areas such as Competition, Consumer, Employment, Environment, Financial, Government Contracting, Healthcare, and Safety-related offenses. While not direct security controls, governance failures can impact access control (PCI DSS 9.3.2), data handling (PCI DSS 6.4.6), and incident response (PCI DSS 12.10.5).
Supply Chain & Third-Party Exposure: This is derived from Domain Intelligence (Enumeration of Vendor Technologies from DNS and Subdomains), Technology Stack, and Cloud and SaaS Exposure. It aligns with PCI DSS 12.8 (managing third-party service providers) and 12.5.2 (maintaining an inventory of technologies in scope).
Breach & Ransomware Susceptibility: This is calculated based on external attack surface and digital risk intelligence, which includes domain intelligence (exposed sensitive ports, exposed private IPs, and known vulnerabilities), dark web presence (compromised credentials and ransomware events and gang activity), and sentiment and financials (SEC Form 8-Ks). This is highly relevant to PCI DSS 12.10.x (incident response), 10.6.1 (monitor and respond to security alerts), and 6.2.2 (apply security patches).
Example: ThreatNG identifying "Ransomware Events" directly links to PCI DSS 12.10.5 (responding to alerts from monitoring and detection systems) and 12.3.1 (maintaining a formal information security policy for ransomware response).
Mobile App Exposure: ThreatNG evaluates how exposed an organization’s mobile apps are through the discovery of them in marketplaces and for the following contents: Access Credentials, Security Credentials, and Platform Specific Identifiers. This directly addresses PCI DSS 3.2 (do not store sensitive authentication data), 3.3 (mask PAN), 3.4 (encrypt sensitive data in storage), and 6.3 (secure application development).
Example: ThreatNG discovering "Mobile Application Exposure Sensitive Information Found" indicates potential violations of PCI DSS 3.2 (not storing sensitive authentication data) and 3.4 (encrypting sensitive data in storage).
ThreatNG provides comprehensive reports including Executive, Technical, Prioritized (High, Medium, Low, and Informational), Security Ratings, Inventory, Ransomware Susceptibility, U.S. SEC Filings, and External GRC Assessment Mappings (e.g., PCI DSS). These reports are invaluable for demonstrating PCI DSS compliance posture to auditors and guiding internal security efforts. The prioritized reports help organizations focus on the most critical risks, aligning with PCI DSS's risk-based approach to security.
ThreatNG's investigation modules provide detailed insights that support PCI DSS compliance:
Domain Intelligence: This module offers a comprehensive overview of an organization's digital presence, encompassing DNS Intelligence (Domain Record Analysis, Domain Name Permutations, and Web3 Domains), Email Intelligence (Security Presence, Format Predictions, and Harvested Emails), WHOIS Intelligence, and Subdomain Intelligence.
Example: "Private IPs Found" in public DNS, discovered via IP Intelligence, directly undermines PCI DSS 1.1.1 (network segmentation controls) and 4.1 (use strong cryptography). ThreatNG's investigation helps identify these exposures.
Example: "Subdomains Missing Strict Transport Security (HSTS) Header" found through Subdomain Intelligence directly impacts PCI DSS 4.2.1.1 (strong cryptography during transmission) and 2.2.6 (secure configurations).
Sensitive Code Exposure: This module discovers public code repositories and uncovers digital risks that include Access Credentials, Security Credentials, Configuration Files, Database Exposures, Application Data Exposures, Activity Records, Communication Platform Configurations, Development Environment Configurations, Security Testing Tools, Cloud Service Configurations, Remote Access Credentials, System Utilities, Personal Data, and User Activity. This directly aligns with PCI DSS requirements 3.2 (do not store sensitive authentication data), 4.1 (use strong cryptography), 6.6 (enforce application layer security), and 7.1 (restrict access to CHD).
Example: "Code Secrets Found" in public GitHub repositories directly violates PCI DSS 3.2 (sensitive data storage) and 4.1 (data transmission security). ThreatNG's ability to investigate code repositories for sensitive data directly helps prevent these violations.
Mobile Application Discovery: ThreatNG identifies mobile apps related to the organization under investigation within marketplaces, examining the contents of these apps and the presence of Access Credentials, Security Credentials, and platform-specific identifiers. This helps enforce PCI DSS requirements for mobile applications, such as 2.3 (not storing sensitive authentication data) and 6.5.4 (addressing vulnerabilities).
Search Engine Exploitation: This module identifies website control files (such as Robots.txt and Security.txt) and assesses the search engine attack surface for potential exposures, including errors, Sensitive Information, Public Passwords, and Vulnerable Files. This helps identify misconfigurations that could lead to data exposure, relevant to PCI DSS 6.5.1 (protect web applications against attacks) and 2.2.6 (secure configurations).
Example: "Errors on Subdomains" identified through Search Engine Exploitation can expose attack vectors like SQL injection and sensitive information, directly relevant to PCI DSS 6.5.1 (protecting web applications) and 6.4.2 (application security controls).
Cloud and SaaS Exposure: ThreatNG identifies Sanctioned, Unsanctioned, and Impersonated Cloud Services, as well as open and exposed cloud buckets on AWS, Microsoft Azure, and Google Cloud Platform, along with all SaaS implementations associated with the organization. This helps ensure that cloud resources processing CHD are securely configured and properly inventoried (PCI DSS 1.4.2, 2.2.x, 7.2.1).
Online Sharing Exposure: This detects the presence of organizational entities on code-sharing platforms such as Pastebin and GitHub Gist. It is critical to prevent sensitive data leakage and align with PCI DSS 3.x requirements.
Sentiment and Financials: This section identifies organizational lawsuits, layoff chatter, SEC Filings of Publicly Traded US Companies, especially their Risk and Oversight Disclosures, SEC Form 8-Ks, and ESG Violations. It indicates potential underlying governance or security issues that could impact PCI DSS compliance.
Example: "Layoff Mentions" can indicate potential issues with access control (PCI DSS 7.1.2, 8.1.1) and personnel security (PCI DSS 12.5.1), as proper access revocation during terminations is critical.
Archived Web Pages: This feature identifies archived content, including API, HTML, and document files, that may contain outdated or sensitive information. It helps identify potential data exposure risks relevant to PCI DSS 3.x (data protection) and 12.1 (information security policy).
Dark Web Presence: ThreatNG identifies organizational mentions, associated ransomware events, and compromised credentials. This directly supports PCI DSS 12.10.x (incident response) and 8.3.1 (MFA for remote access).
Technology Stack: This identifies various technologies used by the organization. This helps maintain an accurate inventory of system components (PCI DSS 1.4.2) and ensure that all technologies are securely configured and patched (PCI DSS 6.2.x).
Example: "Assets with PHP" require diligent security practices due to potential vulnerabilities from outdated code (PCI DSS 6.5.1) and the need for application-layer testing (PCI DSS 6.6).
Intelligence Repositories (DarCache)
ThreatNG's continuously updated intelligence repositories provide vital context for PCI DSS compliance:
Dark Web (DarCache Dark Web): Includes Compromised Credentials (DarCache Rupture) and Ransomware Groups and Activities (DarCache Ransomware). This directly informs PCI DSS requirements related to incident response (12.10), access control (8.3.1), and anti-malware measures (6.1.1).
Vulnerabilities (DarCache Vulnerability): Provides NVD (DarCache NVD), EPSS (DarCache EPSS), KEV (DarCache KEV), and Verified Proof-of-Concept (PoC) Exploits (DarCache eXploit). This directly supports PCI DSS 6.2.3 (identifying and addressing vulnerabilities) and 11.2.1/11.3.1 (conducting vulnerability scans and penetration testing).
Example: The DarCache Vulnerability with KEV data provides "Vulnerabilities that are actively being exploited in the wild", which directly informs PCI DSS 6.2.3 (addressing security vulnerabilities) and 11.6.1 (responding to critical vulnerabilities within one month).
ESG Violations (DarCache ESG): While not a direct security control, governance failures can indirectly impact PCI DSS compliance by affecting overall security posture and risk management (PCI DSS 12.3.1, 12.5.2).
Bug Bounty Programs (DarCache Bug Bounty): Indicates "In Scope and Out of Scope" programs. Bug bounty programs align with PCI DSS 6.3 (develop and maintain secure systems) and 11.3 (test security systems regularly) by encouraging proactive vulnerability discovery.
SEC Form 8-Ks (DarCache 8-K): Security incident filings can highlight gaps in PCI DSS areas like incident response (12.9) and protection of stored CHD (3.4).
Bank Identification Numbers (DarCache BIN): The discovery of BINs helps ensure proper masking (PCI DSS 3.4) and secure transmission (PCI DSS 4.1) of cardholder data.
Mobile Apps (DarCache Mobile): This service identifies whether Access Credentials, Security Credentials, and Platform-Specific Identifiers are present within mobile apps discovered in marketplaces. It reinforces PCI DSS requirements for mobile app security (PCI DSS 3.x, 6.x).
Synergies with Complementary Solutions
ThreatNG's capabilities can be significantly enhanced with complementary solutions, bolstering an organization's PCI DSS compliance efforts.
Security Information and Event Management (SIEM) Systems: ThreatNG's continuous monitoring and alerting on critical security events (e.g., compromised credentials, open ports, data leaks) can feed directly into a SIEM. For instance, when ThreatNG identifies "Compromised Emails", the SIEM can correlate this with login attempts or unusual activity, triggering real-time alerts as required by PCI DSS 10.4.1.1 (alerting on critical security events). This combined visibility allows for more effective log review and incident detection (PCI DSS 10.6.1).
Vulnerability Management (VM) Platforms: ThreatNG's external discovery and assessment of vulnerabilities (e.g., "Critical Severity Vulnerabilities Found" , "Subdomains Missing Content Security Policy" ) can complement an internal VM platform. ThreatNG identifies the internet-facing exposures, and the VM platform can conduct deeper, authenticated scans. The combined insights ensure that external and internal CHD vulnerabilities are addressed, directly supporting PCI DSS 6.2.3 (identify and address vulnerabilities) and 11.2.1/11.3.1 (regular vulnerability scans and penetration testing).
Incident Response (IR) Platforms: ThreatNG's detection of high-risk events, such as "Ransomware Events" or "Dark Web Mentions," can automatically trigger playbooks in an IR platform. This enables swift and coordinated responses to CHD security incidents, aligning with PCI DSS 12.10.1 (implement an incident response plan) and 12.10.5 (respond to alerts). The IR platform can use ThreatNG's findings to quickly assess the scope of a breach and prioritize remediation efforts.
Secure Software Development Lifecycle (SSDLC) Tools: ThreatNG's "Code Secrets Found" capability identifies exposed credentials in public code repositories and provides critical feedback to SSDLC tools. This synergy helps enforce PCI DSS 6.3 (secure development practices) and 6.6 (secure web applications) by ensuring that sensitive data is not embedded in code and that applications are developed securely from the outset. Development teams can then use the SSDLC tools to implement secrets management solutions and improve secure coding practices based on ThreatNG's findings.
Domain Name System (DNS) Security Solutions: ThreatNG's detailed Domain Intelligence, including "Domain Security: DNSSEC" and "Domain Security: WHOIS Privacy" findings, can be integrated with DNS security solutions. If ThreatNG flags missing DNSSEC, the DNS security solution can be used to implement it, thereby strengthening PCI DSS 4.1 (use strong cryptography) and 2.3 (encrypt CHD during transmission) by preventing DNS manipulation that could redirect traffic to malicious sites. Similarly, identifying "Hostmaster Email Present" can be prompted using WHOIS privacy features provided by DNS security solutions to mitigate phishing risks.
