Data Leak Test
DLP Validation and Testing

 

Your public IP address is: 35.173.57.84; more info

Updated Feb 14, 2020

 

SSL is: off ; more info

Mega Test

POST Test

GET Test

Upload Test

Email Test

Industry Info

Session Info

About DLT

 

What is PCI DSS?

PCI DSS - Payment Card Industry Data Security Standard, Version 3.0 as of November 2013 is the latest regulation set forth by the PCI SSC (Security Standards Council) [pcisecuritystandards.org]. PCI requirements apply to any entity that touches Credit Card Data.

The intent of PCI is to provide guidelines to companies that process credit card transactions.

There are 12 PCI Requirements and Assessment Procedures for PCI v3. The official 112 page regulation can be found here: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

 

    Below are the PCI requirements and where Data Security applies*

 

PCI Regulation Overview

 

 

Who does the PCI regulation apply to?

  • PCI requirements apply to any entity that touches Credit Card Data.
  • Organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected by the third party per the applicable PCI DSS requirements.
  • Security services such as authentication servers
  • Virtual systems (servers, computers, network components)
  • Network components (firewalls, switches, routes, wireless access points, etc)
  • Servers
  • Applications
  • Any other component or devices located within or connected to the CDE

    A good Data Security solution will integrate and work with all of the above.

 

What Data does PCI apply to?

  • Primary Account Number -Can be stored *must be encrypted
  • Cardholder Name -Can be stored
  • Expiration Date -Can be stored
  • Service Code -Cannot store
  • Magnetic Track Data -Cannot store
  • CAV2/CVC2/CVV2/CID -Cannot store
  • PINs/PIN Blocks -Cannot store

    A good Data Security solution should be able to detect account numbers, magnetic track data, security codes , and PINs.

 

Yearly assessment requirements

  • Identify Cardholder Data Flow -many unknown data flows can be discovered with a good Data Security tool
  • Identify and Document the existence of Cardholder Data -Data Security tools should be able to detect and report on the existence of PCI data
  • Maintain Documentation of how the PCI DSS scope was determined. (Scope = Cardholder data flow and storage)
  • Network Segmentation/ isolation of the CDE environment is recommended but not required. If there is no segmentation then the entire network is considered part of the CDE -a good Data Security too will be able to help keep cardholder data from entering the non CDE network
  • Outsourced service providers are required to undergo an annual onsite assessment

Recommended Best Practices as listed in the regulation

  1. Monitor Security Controls -firewalls, IDS/IPS, Antivirus, file integrity, access controls
  2. Detecting failures in security controls are detected and responded to in a timely manner
  3. Review changes to the environment -new or changed systems and configs
  4. Formal Review of Org Changes -impact to PCI DSS due to changes in Org Structure changes like mergers & acquisitions
  5. Periodic reviews of practices and procedures -audit logs, vulnerability scan reports, firewall reviews, etc.
  6. Annually review hardware and software technologies for security compliance

    A good Data Security solution will perform numbers 2 and 5.

 

 

In Greater detail;

    PCI DSS Requirements that apply to Data Security solutions

 

Requirement 1; Install and maintain a firewall configuration to protect cardholder data

Requirement

Testing Procedure

How Data Security Can Help

1.13 Current diagram that shows all cardholder data flows across the system and networks Examine data flow diagram and interview personnel to verify the diagram shows all data flows and is kept current Use Network or Endpoint Data Protection to uncover and validate data use & business processes

Requirement 2; Do not use vendor-supplied defaults for system passwords and other security parameters

Requirement 3; Protect stored cardholder data

3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes that include at least the following for all cardholder data (CHD) storage:
  • Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements.
  • Process for secure deletion of data when no longer needed
  • Specific retention requirements for cardholder data
  • Quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention
3.1a Examine the data retention and disposal policies, procedures, and processes to verify they include at least the following:
  • Legal, regulatory, and business requirements for data retention including
  • Specific requirements for retention of cardholder data for (for example, cardholder data needs to be held for X period for Y business reasons)
  • Secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.
  • Coverage for all storage of cardholder data
  • A quarterly process for identifying and securely deleting stored card holder data that exceeds defined retention requirements

3.1b Interview personnel to identify that

  • All location of stored cardholder data are included in the data retention and disposal process
  • Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data
  • The quarterly automatic or manual process is performed for all locations of cardholder data

3.1c For a sample of system components that store cardholder data:

  • Examine files and system records to verify that the data stored does not exceed the requirements defined in the  data retention policy
  • Observer the deletion mechanism to verify data is deleted securely

 

A Data Security Data at Rest (DAR) crawler can be used to find Cardholder data and either move, change permissions, encrypt, or secure delete.
3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

  • There is a business justification and

  • The data is stored securely.

Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

 

3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.

3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured

3.2.c For all other  entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization

3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable.

 

 

Data Security tools can find Authentication Data if it is being stored (DAR, or Data at Rest). Most products can watch and block web transactions (Data in Motion) as well as control how the data is used at the Endpoint (DIU, or Data in Use)

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:

  • The cardholder’s name

  • Primary account number (PAN)

  • Expiration date

  • Service code

To minimize risk, store only these data elements as needed for business.

 

3.2.1 For a sample of system components, examine data sources including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored after authorization:

  • Incoming transaction data

  • All logs (for example, transaction, history, debugging, error)

  • History files

  • Trace files

  • Several database schemas

  • Database contents

 

Data Security tools can find Track Data if it is being stored (DAR, or Data at Rest). Most products can watch and block web transactions (Data in Motion) as well as control how the data is used at the Endpoint (DIU, or Data in Use)

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.

 

3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, AV2 data) is not stored after authorization:  

  • Incoming transaction data 

  • All logs (for example, transaction, history, debugging, error) 

  • History files 

  • Trace files 

  • Several database schemas 

  • Database contents

 

Data Security tools can find verification codes, account numbers and PINs if they are being stored (DAR, or Data at Rest). Most products can watch and block web transactions (Data in Motion) as well as control how the data is used at the Endpoint (DIU, or Data in Use)

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block

 

3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization:

  • Incoming transaction data

  • All logs (for example, transaction, history, debugging, error)

  • History files

  • Trace files

  • Several database schemas

  • Database contents

 

Data Security tools can find verification codes, account numbers and PINs if they are being stored (DAR, or Data at Rest). Most products can watch and block web transactions (Data in Motion) as well as control how the data is used at the Endpoint (DIU, or Data in Use)

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

  • One-way hashes based on strong cryptography, (hash must be of the entire PAN)

  • Truncation (hashing cannot be used to replace the truncated segment of

  • PAN)

  • Index tokens and pads (pads must be securely stored)

  • Strong cryptography with associated key-management processes and procedures

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN

 

 

3.4.a Examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the following methods:

  • One-way hashes based on strong cryptography,

  • Truncation

  • Index tokens and pads, with the pads being securely stored

  • Strong cryptography, with associated key-management processes and procedures

3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text)

3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is rendered unreadable.

3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs.

 

 

3.4.1 If disk encryption is used (rather than file-or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials).

Decryption keys must not be associated with user accounts.

 

3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).

3.4.1.b Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls)

3.4.1.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored

Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method

 

 

 

Requirement 4; Encrypt transmission of cardholder data across open, public networks

4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

  • Only trusted keys and certificates are accepted.

  • The protocol in use only supports secure versions or configurations.

  • The encryption strength is appropriate for the encryption methodology in use

Examples of open, public networks include but are not limited to:

  • The Internet

  • Wireless technologies, including 802.11 and Bluetooth

  • Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)

  • General Packet Radio Service (GPRS).

  • Satellite communications

 

4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified:

  • Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.

  • Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a security control for authentication or transmission.

 

 

4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

 

4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies

4.2.b Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies

 

 

4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

 

4.3 Examine documentation interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:

  • Documented,

  • In use, and

  • Known to all affected parties

 

 

 

Requirement 5; Protect all systems against malware and regularly update antivirus software

Requirement 6; Develop and maintain secure systems and applications

6.5.4 Insecure communications

6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications

 

Requirement 7; Restrict access to cardholder data by business need to know

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access

 

7.1 Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows:

  • Defining access needs and privilege assignments for each role

  • Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities

  • Assignment of access based on individual personnel’s job classification and function

  • Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved

 

 

7.1.3 Assign access based on individual personnel’s job classification and function

 

7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function

 

 

7.2 Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

This access control system must include the following

7.2.1 Coverage of all system components

7.2.2 Assignment of privileges to individuals based on job classification and function

7.2.3 Default “deny-all” setting

 

7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows

7.2.1 Confirm that access control systems are in place on all system components.

7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function

7.2.3 Confirm that the access control systems have a default “deny-all” setting.

 

 

 

Requirement 8; Identify and authenticate access to system components

8.1.3 Immediately revoke access for any terminated users

 

8.1.3.a Select a sample of users terminated in the past six months, and review current user access lists—for both local and remote access—to verify that their IDs have been deactivated or removed from the access lists

8.1.3.b Verify all physical authentication methods—such as, smart cards, tokens, etc.—have been returned or deactivated

 

 

8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

  • All user access to, user queries of, and user actions on databases are through programmatic methods.

  • Only database administrators have the ability to directly access or query databases

  • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes)

 

8.7.a Review database and application configuration settings and verify that all users are authenticated prior to access

8.7.b Examine database and application configuration settings to verify that all user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures)

8.7.c Examine database access control settings and database application configuration settings to verify that user direct access to or queries of databases are restricted to database administrators.

8.7.d Examine database access control settings, database application configuration settings, and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes)

 

 

Requirement 9; Restrict physical access to cardholder data

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

10.1 Implement audit trails to link all access to system components to each individual user.

 

10.1 Verify, through observation and interviewing the system administrator, that:

  • Audit trails are enabled and active for system components

  • Access to system components is linked to individual users

 

 

10.2 Implement automated audit trails for all system components to reconstruct the following events

 

10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following

 

 

10.2.1 All individual user accesses to cardholder data

 

10.2.1 Verify all individual access to cardholder data is logged.

 

 

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

 

10.3 Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following:

10.3.1 Verify user identification is included in log entries

10.3.2  Verify type of event is included in log entries

10.3.3 Verify date and time stamp is included in log entries

10.3.4 Verify success or failure indication is included in log entries

10.3.5 Verify origination of event is included in log entries

10.3.6 Verify identity or name of affected data, system component, or resources is included in log entries

 

 

10.6.1 Review the following at least daily

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, or that could impact the security of 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.)

 

10.6.1.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools:

  • All security events

  • Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of 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.)

10.6.1.b Observe processes and interview personnel to verify that the following are reviewed at least daily:

  • All security events

  • Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of 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.)

 

 

10.8 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

 

10.8 Examine documentation interview personnel to verify 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

 

 

 

Requirement 11; Regularly test security systems and process

Requirement 12; Maintain a policy that addresses information security for all personnel

 

12.5.5 Monitor and control all access to data

 

12.5.5 Verify that responsibility for monitoring and controlling all access to data is formally assigned.

 

 

12.6 Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

 

12.6.a Review the security awareness program to verify it provides awareness to all personnel about the importance of cardholder data security.

 

 

 

 

 

 

 

*Content pulled directly from the PCI_DSS_V3.pdf from pcisecuritystandards.org