PCI DSS compliance with Infrastructure as Code

17 Sep

Have you ever thought about what is the most boring part of your job? If you are like me, that would be talking to auditors. It is hard to imagine more mundane task than proving PCI DSS compliance. The work is highly manual, very hard to automate. Yet, the result is not tangible. It’s not a new shiny feature, your infrastructure is just being secure.

It is important aspect of our job though. Indeed, data breaches are not fun. A good chunk of data recovery cases I had to deal with were caused by hackers dropping database and asking for ransom. There was a customer who happened to have network traffic monitoring on the databases server. The hacker claimed they copied the database. The network activity graph didn’t support their claims though. There was no any increase on outgoing traffic. They just dropped the database. Sad story. Remember Garmin was down for a week? There were rumors they did pay eventually. We won’t know for sure what was going on. But let me assure you – that wasn’t fun. We need to keep our databases secure to not pay our hard earned money to doctors to recover from stress.

One common solution to stay secure is to follow guidelines developed by smart people based on common sense and lessons learnt in the past. That’s why various certifications exist. In this post I’ll be talking about PCI compliance. It’s rather a colloquial phrase, formally it’s called Payment Card Industry Data Security Standard. Or PCI DSS – we hate being formal, don’t we?

What makes audits boring

Why did I chose to talk about PCI DSS out of many other certifications? Mainly, for two reasons.

First, PCI DSS as well as everything else is based on common sense and best practices. Sure, all certifications vary in their applications, their requirements. But in essence their core is same.

Second reason is because PCI DSS is the most needed. A company needs to comply with PCI DSS if they take credit card payments online.

Now, as I elaborated on one part of the post title what’s a deal with Infrastructure as code? With it, I’ll show how security and compliance audits can suck less.

Let’s reflect for a moment why audits are so mundane? In one sentence, PCI DSS requirements tell how you should organize your infrastructure, how you should organize processes around this infrastructure. If PCI compliance isn’t incorporated in the infrastructure by design it will be hard to prove to auditors you’re compliant. A typical situation goes like this. Auditors ask why this user was created. Well, you created it manually and JIRA ticket existence is orthogonal to a process of creating the user. And so, the JIRA ticket is often either forgotten or created post factum. It’s a soft part of the process, not technically enforced. See where I’m going?

The audits usually require lots of manual work. Let’s take same example with a user account. You need to show that when the user was created, there was business justification, it was approved etc. There is no other than manual way to create a report like that. How can it be not manual if the process relies on a human following paper instructions? There is no way to automate that.

Where to find solution

What’s a solution if it exists? I believe it does and assumes the compliance should be by design and with Infrastructure as Code it becomes much easier task.

To prove it I picked some requirements from PCI DSS and outlined what and how can be done to comply with the requirement. Let’s go.

PCI DSS Requirements

1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations.

If the firewall/router configuration exists in code, there is a formal process in form of code review to make changes to it. An initiator of the change justifies the change in a commit message. You can technically require the commit message to include a JIRA ticket. Another person, or team reviews and approves the change. The change is deployed without human intervention because you have CI/CD, don’t you?

1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.

1.1.3 Current diagram that shows all cardholder data flows across systems and networks.

Since networks, environments, connections exist in form of Terraform modules, there are tools to generate the requested diagrams automatically, keep them current, publish – all without human involvement.

1.1.4.a Examine the firewall configuration standards and verify that they include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

Easy to do – the firewall configuration is a module that implements all requirements. The module versioned and is reused, so you can be sure no firewall is missed. Also you can be sure the actual configuration corresponds to the code because there are alerts that go off if a terraform apply check shows the configuration hasn’t converged.

1.1.5 Description of groups, roles, and responsibilities for management of network components

That comes for free as most of cloud resources support tags, names, descriptions. Custom linters can be incorporated in the code review process.

1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

With a code review process together with CI/CD it comes for free.

1.1.7 Requirement to review firewall and router rule sets at least every six months

I have several ideas in mind. A tag on a rule with date of the last review with a CI check.

1.2.2 Secure and synchronize router configuration files.

A well established CI/CD workflow make it trivial to comply.

1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

Tools like Terraform Sentinel make things like Policy as Code possible.

2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).

If the provisioning is a part of automated process, this becomes as automatically compliant.

The list of requirements goes on and majority of them are either come for free with Infrastructure as Code or can be automated.

Conclusion

There is a few takeaways from this post.

Infrastructure as Code greatly simplifies the task of running secure and compliant databases.

With Infrastructure as Code a lot of necessary reports, views, processes can be automated.

And last, but not least, Infrastructure as Code makes our job fun.