Skip to main content

PCI DSS - Checklist




Requirement 1: Build and Maintain a Secure Network

This can be divided into two parts:


  1. Create a secure network
  2. Document your network

Following steps should help you to achieve this:


  • Identify your Card Holder Environment (CDE):
    If you are hosting your CDE on-premise then your local network is usually the CDE. It is preferable to have some demarcation for your CDE. This is usually achieved by means of a firewall.
  • Secure your CDE: Most firewalls work on a whitelist model i.e. only the services that are explicitly allowed to pass are allowed, the rest are blocked.
  • Firewall process document : You should document the list of services that are allowed across the firewall. This should consist of the IP addresses, ports and applications (in case of Next-generation firewalls) that have been allowed on the firewall. Not only the IP addresses, you should be able to map these IP addresses with the servers hosting your card related applications.


Requirement 2 : Do Not Use Vendor Supplied Defaults

This is, in fact, another step towards ensuring that we build a secure network (requirement 1)
In general:

  • Change the vendor supplied passwords.. For eg. most of the vendors have their usernames as admin/admin, default/default or some other permutations of root, firewall name etc. This should be changed.
  • Most of the devices have a super admin / root account which has the highest privileges. Create another account, assign those privileges and disable the generic admin / root account.
  • Enable management access using strong cryptography. Use technologies such as SSH for CLI based management, SSL/TLS (HTTPS) for web-based management access.


Requirement 3 : Protect Cardholder Data

  • Never store payment card data on personal hard drives, USBs etc.
  • Don't store any cardholder data in the first place. If you must, then do it only for the time period it is needed
  • It is recommended to offload the task of processing payments to a payment processor like PayPal. The commission charged by the processor is usually much less compared to the efforts and the resources spent on processing the payments yourself, apart from the implementation of PCI compliance costs.


Requirement 4 : Encrypt Transmission of Cardholder Data

  • SSL / TLS is the go to technology when the aim is to encrypt and secure sensitive data. HTTPS which is considered to be the secure protocol for web communication is built in conjunction with SSL / TLS.
  • SSL is known to have issues. TLS v1.1 and higher are mandatory for PCI compliance
  • There is a marked effect on SEO rankings for SSL / TLS enabled (secure) sites. Most search engines rank secure sites higher than their non-secure peers.


Requirement 5: Maintain a Vulnerability Management Program

  • Protect all systems against malware and regularly updated antivirus programs
  • Deploy antivirus solutions on all systems
  • Simply deploying antivirus on systems is not sufficient. There should be valid patch management policy in place to ensure that latest signatures are applied to your systems.


Requirement 6: Develop and maintain secure systems and applications

  • Ensure that the website and other components of CDE are protected from known vulnerabilities.
  • If you have a vulnerable CMS, extension, plugin or theme, fix it prior to exposing it to internet
  • If it is not possible to do the same, setup a compensating control


Requirement 7: Restrict Access to Cardholder Data by Business Need to Know

  • This follows from the CISSP concepts of "Principle of least privilege" and "Need to know"
  • Prepare an access control matrix to define the users who should have what level of access and ensure that the access is only provided as per their needs to perform specific functions.
  • Security policies and operational procedures for restricting access to cardholder data should be documented


Requirement 8: Identify and authenticate access to system components

  • Ensure that unique set of identification (username) credentials are provided to each person who has access to the cardholder data.
  • It is preferable to have a strong password policy in place for authentication. (Note that identification and authentication are two separate entities. A "username" provides a proof of identification while a password / pin / biometric method provides proof of authentication.
  • Most of the platforms today provide for Multi-Factor Authentication (MFA). Leverage it to further strengthen the security
  • The idea behind all this is to ensure that there is adequate accountability among the users (having access to the cardholder data) should there be a security incident. It also ensures non-repudiation


Requirement 9: Implement Strong Access Control Measures

  • There must be physical access restrictions to cardholder data, such that only the authorized personnel are able to access the data which they have a "need to know" for. Physicall access restrictions apply to the devices (storing, processing or transmitting the data), data itself, and hardcopies if any.
  • Data Retention Policy : Retain the cardholder data only for the time it is required for business or legal reasons. Purge the data if it is no longer required.
  • This is one of the requirements for GDPR, as well. More about that later.


Requirement 10: Track and Monitor all access to Network Resources and Cardholder data

This is one of the most important requirements for PCI compliance

  • It clearly states that you MUST have a mechanism to have audit trails and the ability to review logs should there be a compromise / data breach.
  • This implies, you should be able to determine "who, what, where and when" accessed the (cardholder) data processing environments.
  • Failure to have the audit trails and logs would make it difficult to pinpoint the breach timeline or identify the responsible party.
  • Monitoring also implies you should have a mechanism that verifies the files on a website, SSL certificates, DNS settings etc. if they have been tampered with by an unauthorized user.


Requirement 11 : Regularly Test Security Systems and Processes

  • Run vulnerability scans after periodic intervals or major changes
  • Authorized penetration testing for web applications should be carried out
  • Detection and prevention techniques to safeguard against hackers should be in place


Requirement 12 : Maintain an Information Security Policy

  • Establish, document, maintain and follow an Infosec policy. This is a broad function and we will discuss in detail in subsequent blog posts
  • Risk Assessment process should be well-defined with the right skilled personnel selected to perform the assessments
  • The policies should clearly make sure there is no gap in the policies and the personnel's understanding of it. The personnel should understand their individual responsibilities and the criticality of the actions they undertake.





Labels:

Comments

Post a Comment

Popular posts from this blog

Checkpoint - Exporting Objects in CSV format

Be it a Network Operations Manager, Security Architect or a Security Auditor, the people up the hierarchy always harangue the Security Engineers to compile the list of firewall objects or rules or policies or the traffic statistics and so on.. This can turn out to be quite hectic especially if there are no built in features to systematically provide the output in a "layman-readable" format. Come, Checkpoint's "Object Explorer..."  which not only provides the output in the "layman-readable" format, but also provides in-built filtering mechanisms, thereby ensuring that the Security Engineer doesn't have to rely on Google for building his scarce Microsoft Excel data filtering skills. The following screenshots will show how easy it is, with Checkpoint R80.10 to generate the firewall configuration inventory. On the SmartConsole Unified Portal, navigate to Menu >> Open Object Explorer... Select the Categories you wish to see in your output: Click o
Post a Comment
Read more

MITRE ATT&CK - Kerberos Vulnerabilities and Security

From the previous post, the summary of Kerberos authentication process is as below: For the initial authentication, the user’s client machine sends a request to the KDC  Authentication Service (AS) . The request includes details like the user’s username, and the date and time. All information except the username is encrypted using the hash of the user’s password. The KDC AS uses the username to look up its copy of the user’s password hash and uses it to decrypt the rest of the request. If the decryption is successful, that means the client used the correct password hash and the user has successfully authenticated. Once the user is authenticated, the KDC AS sends the user’s client a  ticket granting ticket   (TGT) . The TGT includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). Importantly, before sending the TGT, the KDC encrypts it using the password hash for a special account, the  KRBTGT account.  That password hash is s
5 comments
Read more

Tejas Jain - GCP Constraints & Random Facts

1.  Google Cloud Interconnect Security Cloud Interconnect does not encrypt the connection between your on-premises network and Google's network. Cloud VPN cannot be used with Dedicated Interconnect For additional security, use application-level encryption or your own VPN 2. While using Cloud CDN, the default time-to-live (TTL) for content caching is 3600 seconds = 60 mins 3. Cloud NAT sends only the translation logs and error logs to Cloud Logging service. 4. GCP Dedicated Interconnect - On Premises network device requirements:     10-Gbps circuits, single mode fiber or 100-Gbps circuits, single mode fiber     IPv4 link local addressing     LACP, even if you are using single circuit     EBGP-4 with multi-hop     802.1Q VLANs 5. While using Cloud VPN, the recommended MTU to be configured on the peer VPN  gateway = 1460 bytes 6. Each instance must have at least one network interface. The maximum number of network instances per instance is 8, depending on the instance's machine
1 comment
Read more