.png)
X
X
X
.png)
PCI-DSS is one of the most ubiquitous security standards in the world today, a must-have for any organization that handles customer payment card information or other sensitive data. Ever since the world’s five largest payment card brands came together to formulate the standard in 2004, PCI-DSS has been the de facto compliance requirement for vendors accepting electronic card payments.
Twenty years on, PCI-DSS version 4.0 currently defines the full scope covered by the standard, ranging from network security and cryptography, to access control and monitoring.
In this guide, we’re breaking down the 12 requirements of PCI-DSS as specified by the Payment Card Industry Security Standards Council. We’ll understand in detail what each step expects of your organization, and how you can go about fulfilling each requirement.
Network security controls cover everything from firewalls to access management systems — basically, controlling the flow of traffic between environments of varying security levels or trust. For example, the cardholder data environment needs to be one of the most highly protected parts of your network, since that’s where your customers’ most sensitive data is stored.
Any user or device who requests access to this data would have to be carefully evaluated and monitored. This requires you to implement policies that define how traffic goes in and out of your system, and which users or devices have access to specific resources.
Let’s understand the steps you need to take to meet all the requirements for strong network security.
Once you’ve identified what configurations you’re going to use, it’s time to enforce these security controls across your network. Define which protocols and ports are permitted for use, firewalls, routers, access controls lists, and any other requirements. Any changes to the configurations need to be formally approved by the person responsible for that part of the network.
This one should be obvious: as the most important and sensitive data in the network, your customer’s payment card data needs to be the most well-secured part of the system. That means all inbound and outbound traffic to and from the CDE should be restricted by default, only allowing traffic that’s strictly necessary.
This step ensures that a malicious user can’t hitch a ride onto a secure and trusted network by way of an untrusted or third party network connected. This also extends to any computing devices, including company or employee-owned devices, that connect to both the untrusted network and the cardholder data environment.
This section is pretty straightforward. Most vendors of software services will offer certain default security parameters, like passwords, access control measures, etc. However, these are merely placeholders and aren’t meant to be used in an operational setting.
Additionally, unused or unnecessary services, protocols, daemons, and functions should be disabled or removed. Any component that doesn’t serve a purpose only increases the attack surface of your network, creating unmonitored pathways into your system for attackers to exploit.
Track and document all the various passwords and security parameters across your system, ensuring all the vendor-supplied defaults are changed. Ideally, any sensitive secrets and access tokens should also be rotated out every week or month.
Like in the previous section, all of these activities should be documented and verified regularly, and you should assign relevant team members to keep track of security controls and handle approvals for any changes.
This should one of the cornerstones of your security program, as it holds the key to your organization getting successfully compliant with PCI-DSS. Customers’ account data, including their personal identifiable information (PII) and payment card data, is what all the attackers are after.
Your team’s data security program should include an arsenal of techniques, ranging from encryption, truncation, masking, and hashing. But it goes beyond that: simply following simple best practices—like not storing user data unless necessary—can go a long way in reducing not only the risk to your network, but the effort required to secure everything.
The single best way to securely store customers’ data is to not store it at all. User data often doesn’t need to be stored long-term, and should ideally be securely deleted as soon as it’s not being used by the system.
This extends to sensitive authentication data (card verification codes, PINs, etc.) which should not be stored after the authorization process is complete.
You should set up formal processes and retention policies that define details like the length of the data retention period, a secure deletion process, and periodic verification that no unused data is being stored in your network.
This step is crucial to ensuring the safety of cardholder data. The PAN is the most important piece of information on a payment card, so every measure must be taken to securely store it.
There are four approaches recommended for this:
If your organization is using encryption to secure the PAN, you need to define procedures on protecting cryptographic keys through access control and secure storage.
At this step, you also need to ensure that the PAN is always masked when displayed, and can only show the last four digits of the number.
It’s not enough just to secure cardholder data at rest, because information is often at most risk when being transmitted over an open network. There are lots of ways for malicious actors to intercept data in transit, exploiting vulnerabilities in legacy encryption methods or misconfigured wireless networks.
Payment card information must be secured before transmission over untrusted networks using strong cryptography and well-defined security protocols.
Here are some best practices you can follow when setting up encryption for sensitive data:
Malware is one of the most common ways attackers infiltrate and take control of networks and system components. It can often be as simple as a privileged employee clicking on a malicious link in a phishing email, causing a malware to be executed on their system.
Identify a powerful antivirus or anti-malware solution that suits your needs and deploy it across your network. This will ensure that all manner of viruses, Trojans, spyware and ransomware are either removed or blocked from your systems.
Regularly monitor your antivirus solution and configure it to automatically update so you don’t fall behind on crucial security features.
Instead of relying on your antivirus to be the main line of defense, why not stop these attacks at the source? Invest in anti-spoofing controls for your organization’s domain and email system, such as DMARC, SPF, and DKIM.
This way, phishing emails will be blocked straight away, without ever reaching the inboxes of your team members.
As an additional measure, you can train your staff on how to spot phishing emails, and double-check communications that seem suspicious.
There’s no such thing as an ‘unhackable’ software — it’s up to organizations to constantly work towards being one step ahead of attackers by implementing more robust security measures and fixing exploits on a regular basis.
That’s why it’s important for your company to apply software patches to cover weaknesses in your system, and if your team develops custom software in-house, vulnerabilities can be avoided by applying software lifecycle processes and secure coding techniques.
If your team is building in-house applications, these need to developed with consideration to secure coding practices. You can employ automation to speed up detection of vulnerabilities, and set up processes to prevent the same bugs from resurfacing from one build to the next.
But your average developer doesn’t just have these skills to start with — they need to be taught. Training is one of the best investments for your team, because developers with hands-on knowledge of secure coding techniques are far more valuable to your business.
A product team with security skills will be able to release software faster, at higher quality, and much more securely than one without. With AppSecEngineer’s suite of developer-focused courses and challenges, you’ll be able to see noticeable results in just 3 months.
Check out AppSecEngineer’s suite of hands-on courses specifically made for PCI-DSS certification and start upskilling your team today.
Any application accessible to the public is bound to be a target for malicious actors. You need to implement a system of constantly reviewing your applications via manual or automated assessment methods (preferably both).
The vulnerabilities found should then be aggregated and correlated based on their severity, and systematically fixed by your product team. Implementing these security activities into your SDLC ensures you’re releasing secure software without slowing down development.
AppSecEngineer offers a whole collection of hands-on courses and labs in DevSecOps, where your team can learn to automate security scans, build CI/CD pipelines, and embed security into every stage of development.
The principle of least privilege dictates that a user should only be given the minimum permissions they need to perform their activities. In essence, all access should only be provided on a need-to-know basis.
To that end, applying a deny-by-default setting and using allow lists for granting permissions can eliminate a significant portion of risk.
But for more complex environments, it’s far more beneficial to use role-based access control (RBAC) to manage access to resources, since this allows you to give out permissions based on a user’s job functions.
For example, a user might need to access specific data, but only to view it. They can be assigned a role that only grants them permissions to read that data, but not modify or delete it.
RBAC allows you to manage a much larger number of users and groups, simply by assigning roles with pre-applied permissions. This can be configured with sophisticated authentication systems (SSO, tokens, etc.) for an even more robust security system.
Assuming you’ve fulfilled Requirement 7 and have set up access control policies across your users, there’s a new problem now: how do you identify each user? More importantly, how do you ensure a user isn’t really an attacker in disguise?
Authentication is the answer. Implement a system that uses unique IDs or accounts to establish the authenticity of every user or process. These accounts have to be validated by the system using some form of authentication: passwords, tokens, certificates, etc.
While all this might seem obvious, implementing it in the real world isn’t quite so easy.
We like to joke about how ridiculous password requirements have got: “Your password must contain an uppercase letter, a number, a haiku, a gang sign, a hieroglyph, and the blood of a virgin.”
But there’s a reason for that. The longer and more complex your password is, the harder it is for attackers to guess or use brute-force methods. You should also ideally make passwords expire after some time, forcing users to periodically change their passwords.
As an additional measure, lock accounts after a set number of failed login attempts to prevent brute-force attacks.
MFA is an industry standard today for a reason: it offers a second line of defence, making it much harder for an attacker to bypass both security measures. Even if they manage to steal your password, they likely won’t be able to manipulate or access your secondary authentication mechanism.
But MFA system itself can be misused or bypassed if not properly configured. No user should be capable of bypassing MFA, even administrative users, and access should only be granted if all the authentication factors properly succeed.
Accessing cardholder data over a network is one thing, but what about physical access? This might seem like an unlikely scenario, but if any part of your physical infrastructure it could result in your online systems breaking, or worse, a complete breach of customer data.
To start, heavily restrict physical access to systems in the cardholder data environment, like computer rooms, data centers, and offices. Monitor them with security cameras, use card or key controls to open locked doors, and maintain visitor logs to sensitive areas.
Additionally, ensure that all physical media containing cardholder data, whether it’s hard drives, disks, etc., are securely stored, accessed, distributed, and destroyed. That last part is important, because if you dispose of an old drive without properly wiping or destroying it, skilled hackers could find a way to retrieve the data.
Logging and monitoring is a cornerstone of a robust security program, not only because it can allow you to examine suspicious patterns and activities in your network, but you can configure it to detect and alert you about an attack, minimizing the damage an attacker can do.
Once you enable audit logs for all your system components, you essentially have a constant stream of data available for forensic analysis of events, allowing you to observe suspicious patterns and detect malicious activity even before it harms your environment.
An audit log history for at least 12 months should be available for analysis, and these logs should be protected from destruction or unauthorized modification.
If any important security controls fail, the monitoring system should be configured to immediately detect the failure, and report it as a critical event. This will allow your team members to quickly respond to the incident, shutting down any ongoing cyberattacks and preventing further damage to the system.
The audit logs should then be examined to determine the cause of failure, and the problem should be rectified.
Even the most secure network doesn’t remain that way forever, so it’s important to be aware of what’s going on under the hood. If you’re developing custom software, you’ll also have to take that into account in your security assessments.
Vulnerability scans need to be conducted at least every three months, which should tell you how the security of your systems is evolving over time.
Vulnerabilities should be prioritized based on how much of a risk they pose to the network: those of a high or critical level of severity of should be resolved as quickly as possible. A rescan should verify that these vulnerabilities are mitigated and don’t reappear.
If your team develops custom software, vulnerability scans would have to be performed much more often. Static analysis (SAST) scans can be automated to run before each build, and dynamic testing should be performed to identify runtime vulnerabilities.
Learn how you can train your team in SAST, DAST, and SCA automation with AppSecEngineer’s hands-on labs.
While security scans can be fast and often support automation, penetration testing is a slow, methodical process mostly performed manually. Pentesting is crucial to providing a much deeper insight into your network’s security posture, and finding deep-seated issues within your system.
Pentesting should be performed at least once a year, and the results from the testing process should be used to systematically resolve the issues found.
To wrap it all up, your organization should implement comprehensive information security policies that govern how data is kept secure across the network. All the relevant members of your team as well as vendors and business partners must be made aware of the policies, and measures taken to enforce them consistently.
Upon completing a risk analysis on your system, you should have identified the assets that need protection, and the threats that could potentially arise and their impact. This should directly inform a formal plan on managing risk and responding to incidents.
PCI-DSS compliance isn’t a one-time deal, it’s an ongoing process that needs to be updated and refreshed annually. You’d need to assign specific team members to be accountable for activities related to PCI-DSS compliance, and perform periodic reviews.
There should also be a process to document the scope of PCI-DSS, and take an inventory of all the system components that fall within that scope.
With how vast and complex the PCI-DSS landscape is, your organization can't move forward without skills in security. Teams that invest in learning not only see an uptick in productivity and speed of delivery, but are able to get compliant with PCI-DSS with greater ease.
AppSecEngineer allows everyone on your product team, from developers to security engineers to architects, to build secure software that prioritizes the safety of customer data.
Make PCI-DSS compliance a breeze with dedicated learning journeys on AppSecEngineer. These are courses, labs, and challenges handpicked to give your team the skills to meet all the requirements with minimal effort.
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.
.svg)
.svg)
Contact Support
help@appsecengineer.com
1603 Capitol Avenue,
Suite 413A #2898,
Cheyenne, Wyoming 82001,
United States
.svg)
Contact Support
help@appsecengineer.com
68 Circular Road, #02-01, 049422, Singapore
.png)
.png)
.png)
.png)
