Month 2. Domain 2: Locking The Door
The Summary: What are we actually doing?
Now that our fences are built, we must address the entry points. In the chronicles of Castle CDE, Domain 2 is the art of securing the openings. It is not enough to have high walls if the locks on the main gates are the ones that came from the factory – locks that every common thief has a master key for.
Requirement 2 is fundamentally about ensuring that every system component is hardened against unauthorized access by removing “vendor defaults”. In our medieval keep, this means:
- Proper Locks on Every Door: We replace the standard, easily picked locks (default passwords and settings) with custom, high-security ironwork unique to our fortress.
- Bars on the Windows: We don’t just secure the doors; we ensure that every secondary entry point – the “windows” of our digital environment – is reinforced so that even a persistent intruder cannot squeeze through.
- Protecting Sewage Pipes and Engineering: A castle can be breached through its most overlooked conduits. In modern terms, this means hardening the underlying “engineering” of your systems – disabling unnecessary services, scripts, and protocols that potentially could provide a hidden path inside.
The objective is to create a configuration standard where only the necessary “gates” are open, and every single one is secured by a lock that only your trusted sentries can operate. And also to make proper standards or blueprints so that your blacksmith would know how to prepare new locks to be fitter if one needs to be replaced.
As we often encounter in our field notes, a single forgotten “engineering pipe” (a default VLAN on your hypervisor, an unpatched service or default account) is all an enemy spy needs to bypass your most expensive walls.
An enemy spy doesn’t care how beautiful or fancy your locks are
if they can just crawl through the plumbing.
Three Common Pitfalls (Which We Often Encounter)
1. The Sentry’s Blind Spot: Forgetting the Foundation
Often, a lord mostly focuses all his coins and effort on reinforcing the doors of the high tower (the virtual machine) while leaving the stairs and the foundation (the hypervisor and underlying infrastructure) completely unguarded. We frequently find long-life credentials or default settings on hypervisors, and default VLANs on virtual networks that hosted machines share. A spy doesn’t need to pick the lock on the tower door if they can simply walk through the basement and then climb up through the window.
2. The Shared Well: Technology Stack Vulnerabilities
In a cloud keep, the same mistakes are made with shared resources. If a resource is not an immediate part of the CDE but is shared between CDE and non-CDE systems, it must be hardened as if it is part of the crown jewels.
- Containerized Environments: If you use containers, ensure your images are hardened or use pre-hardened versions. Harden your container orchestration tool as well.
- Infrastructure as Code: If you use GitHub for your CloudFormation templates, harden it – it is the blueprint to your castle.
- Bottom of the Stack: Always go to the very bottom of your technology stack; a crack at the bottom can bring down the entire spire.
3. The Rusted Hardware: Vulnerable Firmware
The ironwork of your portcullis and the mechanisms of your drawbridge (network devices, HSMs, etc.) are still “software” at heart. While you may have little control over how they were forged, they can still have critical weaknesses. An enemy spy looks for rust in these mechanisms to jam your defenses. You must keep a vigilant eye on critical vulnerabilities and act fast to patch or mitigate them before they are exploited.
Sometimes you might need to bring heavy machinery to protect outdated mechanism, i.e. use compensating or customised controls.
Assessment Tips & Tricks
- Self-Assess First: Assess your own environment before the QSA’s visit to identify and fix obvious gaps. Use CIS Benchmarks and vendor hardening guides as a baseline. Please note that not every CIS Benchmark or vendor recommendation is relevant to PCI DSS (e.g. PCI DSS is very little about availability and DoS).
- Take AI help (but be careful) to automate self-audit process (e.g. go to Google AI studio and ask to write a simple application that will use available CIS Benchmarks and vendor hardening guide to create a checklist for a given component, OS, database, etc.)
- Don’t Panic: Identified gaps are indicators of weak high-level security controls rather than personal faults. Improve these together with your assessor; the QSA is here to help and very often may bring practical knowledge.
- Daily Ops Over Compliance: Remember, hardening once is not enough. Monitor vulnerability databases and scan your components (we will talk about that in July and November), but also make a habit to check very basic settings (like outdated passwords for powerful accounts, shared dirs full of secrets, test data, test cron jobs/scripts, hardcoded credentials, Kerberos golden tickets that live forever – you know better than me).
Typical Evidence Required
| PCI DSS Requirement | Evidence Required | Tryggr’s Comment |
| 2.1.1 | Secure configuration policies and procedures | Sometimes, best procedure is not a long forgotten document but an actual Ansible or Puppet script |
| 2.1.2 | Role and responsibility definitions | These can be part of job descriptions, your scope definition, or high-level policies. |
| 2.2.1 | Configuration standards for all classes of system components in scope | The requirement states “…all system components” and “…all known security vulnerabilities”. I am a bit sceptical about that. Obviously, I would expect a different approach to critical CDE components and secondary, “connected-to” systems. The main question is still “what happens if this vulnerability is exploited – is my cardholder data at risk?” |
| 2.2.2 | Evidence of not using vendor defaults on sampled system components | If you don’t find a “default username/password” for your modern equipment or cloud service, that does not mean you are out of scope of this requirement. Think of your, let’s say, friend or subcontractor who set up your startup’s environment when it just started – aren’t those credentials still the same? |
| 2.2.3, 2.2.4 | List of running services of sampled system components | Take extra attention to 2.2.3.c – if you run virtual machines, make sure that machines with different security profiles are indeed isolated – including virtual network level. |
| 2.2.5 | Evidence of hardening insecure protocols, if any | HTTP/HTTPS is a good example. I know you enforce TLS 1.2/1.3 – but are there any weak ciphers supported? Are there any HTTP methods enabled that you don’t need – like TRACE? |
| 2.2.6 | System security parameters from sampled system components | Some assessors use manual checks, others like to automate evidence collection using various scripts and tools like ScoutSuite for clouds, PingCastle for AD etc. |
| 2.2.7 | Evidence of non-console administrative access protection | TLS 1.2/1.3 is one of the options. Use SSLLabs free tool to check whether your TLS handshake is ok, your certificates are trusted, and there are no weak ciphers in use. |
| 2.3.1 | Evidence of secure wireless settings | This is becoming a rare bird, especially in cloud environment, and it’s mostly marked n/a. |
Need assistance?
If you need any help while preparing for your assessment or would like to have quick call about PCI DSS, 3DS, PIN Security, P2PE or DORA compliance, please feel free to reach out to us at Trausta. We’re
always here to ensure a smooth and secure compliance process.
Next Month: Domain 3 – Hiding what needs to be hidden.
