We are seeing a lot of trends where organisations are moving to the cloud. If you haven’t moved to the cloud, you’ve probably been asked about it by at least one person in your organisation. The biggest players that we see in the cloud space are:

  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Google Cloud (GCP)

We’ve seen most people have moved to either AWS or Azure, but we are starting to see people make more use of GCP as well. In this article we will try to be be cloud-agnostic. Whatever cloud-service you decide to investigate and/or use will each have it’s own services, solutions, and approach to compliance. Our focus here is on how you approach a cloud migration with PCI in mind no matter what stage you are at.

Before You Migrate

Just like any significant change, you need to take steps to understand what your risk is. The only way that you can understand your risk fully is to start by performing due diligence and understanding exactly where the potential may be for certain risks.

Do Your Due Diligence

When we talk about due diligence for a potential cloud move, there are lots of things that need to be considered. Some of these include:

  • What compliance does the cloud provider have? Do they meet regulatory and contractual regimes that you have to comply with in all the countries you operate in?
  • What rights do you have as a customer over controlling your data?
  • Who has access to your data?
  • What happens to your data when you delete it?
  • Does the cloud service offer native versions of the security controls you need or will you need to implement additional security controls?
  • What obligations do they have to notify you of a breach or potential breach?
  • How easy (or difficult) is it to move platforms?
  • What items would be your responsibility and which would be the cloud providers?

The list above is not meant to be exhaustive. What it should do is make you start thinking about what your potential risks might be that are associated with bringing another service provider into the scope of your PCI environment. If you don’t do your due diligence, you may find yourself in a situation where your cloud provider is not compliant and suddenly there is a significant increase in costs, probably not budgeted. While that’s extremely unlikely with one of the big three cloud providers, they are not the only providers out there.

Understand Your Risks

Once you’ve done your due diligence, you’re in a much better place to be able to understand your risks. Incomplete due diligence can lead to an inaccurate or incomplete understanding of the risks leaving you with gaps that you may not know about until it is too late.

As part of any significant change, you need to be doing a risk assessment. Migrating from a physical infrastructure to the cloud is considered a significant change to your environment. So significant, that it is the kind of change that will, once ready, be required to be re-assessed. We will talk about that later.

While your risks will differ based on your organisation and even your cloud provider, some risks will be common regardless. When identifying risks, ensure that you are including not only technical risks, but people and process risks as well.

  • Those logs that you previously sent to your SIEM, where do those go now, and are they still in a format that you can review? Or will you need a different tool?
  • The documentation you have that relates very clearly to your old systems, what happens if it doesn’t get re-written? How and who will rewrite it?
  • What happens if your cloud provider stops offering their services?
  • What happens if your cloud provider no longer provides PCI compliant services?
  • What happens if auto-scaling isn’t configured properly and you get a spike of traffic leading to a similarly enormous bill?
  • What happens if that old bespoke piece of software you’re using can’t be deployed in the cloud?

Once again, the list isn’t meant to be exhaustive. But you should be looking at the ways that changing to the cloud could add not only what new risks you might add, but how the cloud migration might change your current risks. It may be that migrating to the cloud removes the risk of a data centre that was not PCI compliant and therefore had to be included in your scope. It may be that using a cloud service they offer a log pre-processing service which suddenly makes it much easier to understand when an event is a threat, improving your ability to detect incidents.

When reviewing a migration to the cloud, you should absolutely look at ways that it may also decrease existing risks in your current risk assessment though additional controls that may not have otherwise been available to you.

Draft Your Architecture

Once you’ve done your due diligence and understood the potential risks, you’re probably in a place to make a decision about the cloud-solution that you will use and you can finally get to the part you wanted to get to all along. Playing with the shiny new toys that cloud services offer so that you can figure out which of those things you want (and need) to include in your new architecture.

When considering what your architecture might look like, it’s a good idea to run it by a QSA earlier rather than later so any key items for compliance which may have been forgotten or left out can be identified, saving you time later. Confide can perform architecture reviews to help customers ensure that their cloud migrations will meet their PCI requirements.

Make sure that when you are drafting your architecture design documents, you consider services that may be available from your cloud provider which are PaaS or SaaS offerings which may be able to decrease your overall compliance burden (as long as they are within the scope of your cloud provider’s Attestation of Compliance or AoC).

For example, Azure offers a Bastion Service that lets you implement a jump host with multi-factor authentication for all direct server access. Once you’ve configured it, you can use it with Azure AD and enforce multi-factor authentication. As it is PaaS (Platform as a Service), you do not have any access to the underlying operating system.

Compare this to setting up your own bastion host, being responsible for the patching, for application updates, internal and external vulnerability scans, penetration testing, server build and configuration standards, hardening, potentially antivirus software and server logging to list the key ones. The list goes on because a bastion host is a critical security control within your environment, providing access and segmentation to your environment.

While of course you could migrate your environment like for like, and recreate everything that currently exists in your data centre, you may find that some of the managed services can make PCI compliance easier. So make sure to consider these when designing what your new environment will look like.

Ready to Migrate? What Do Do During Your Migration

So, you’ve decided to migrate, you’ve had your architecture reviewed by a QSA, but that doesn’t mean that everything is ready to go and you’ll immediately be PCI compliant.

Document Everything

As you start building and deploying your environment, make sure that you are documenting everything. A move to a cloud environment is a significant change (remember Requirement 6.4.6), so you’ll need to make sure that you are documenting as you go. As you deploy the environment, remember to consider things like:

  • Do I need to run a vulnerability scan?
  • Do I need to organise a penetration test?
  • What documentation do I need to create or update?
  • What PCI requirements do I need to implement as part of the deployment?

By recording each of these things as part of the change and keeping the evidence with it, you make it even easier to show your QSA how you made sure that each change

As you add (and remove) users and roles to the solution, make sure that you are documenting this as part of your changes. Make sure you document their privileges and understand who should have access once the system goes live. You may find that a different team of people needed access to build the solution and that the team is much different or smaller for maintaining it. So as part of your process, make sure that you’ve only got the right people with the right access.

Test Early, Test Often, Test When You’re Done

You’re always remembering to test things as you implement them, right? No, not just that they work, but that they are secure.

One of the things that you need to do for PCI is to make sure that you do vulnerability scans and penetration tests as part of your significant change. Not every change will require a penetration test, nor will every change require a vulnerability scan. But any time there is a change to networking, your first step should be to run a vulnerability scan (internal or external depending on what type of networking change). Do these scans as often as you need to, and re-scan until any vulnerabilities have been fixed. Keep the results with the change ticket.

You might decide to do penetration testing at different points in your deployment. Great! Just make sure that you book in a final penetration test once you’re ready to go live. You want to make sure that you’re testing the environment in as close a state as possible to what you will actually be using.

Double Check Your Solution

Before getting a QSA in to do the assessment of your new environment, we recommend doing some internal spot checks of your environment against key requirements to make sure you have addressed everything. This includes checking that your documentation has been updated and reflects the new environment, as well as making sure the environment is production ready. This will save you from too many surprises during the assessment.

If possible, build spot checks in early and include them as part of your key milestones. It’s much easier to check things piece by piece rather than all at once, but it’s better to do it once than not at all. It will also help you understand how you will need to explain your implementation of the solution when you are talking about it with your QSA.

Done and Deployed? What To Do After Your Migration

That’s it, you’re done, right? Not quite.

Document Your Decommissioning

Before your assessment, you will want to finalise your decommissioning of your old environment. If your old environment hasn’t been decommissioned, it will have to be included in your scope until it is.

Decommissioning, much like adding new systems is a significant change. You need to make sure they are removed from your security tools, make sure their firewall rules are removed, remove them from your inventory and your diagrams. There’s still a few things that need to be done and documented before you are ready for your assessment.

Review Your Documentation (One More Time!)

Make sure that all of your change tickets are easily identifiable and contain the information that they need to. Make sure that all of your diagrams have been updated to reflect your new environment. Basically, just do a once over to make sure you are in a place where you are ready to be re-assessed.

Schedule Your Re-Assessment

We know that figuring out exactly when you will be done is difficult. There are bumps along the way and nothing ever goes as planned. So figuring out when to schedule your re-assessment is key. Your systems should be production ready. This means that everything has been deployed, everything has been tested, and the only thing left to do is to make sure that it is PCI compliant.

If you assess too early, you run the risk of an extended assessment while we wait for your systems to be production ready. If you assess too late, you run the risk of a security breach due to an incorrectly configured security control. The important thing is to keep your QSA in the loop. Engage with them early, and take steps to keep them up to date as key milestones are achieved. This gives you the assurance you need that your QSA will be able to advise you on when you are ready for your assessment and you can worry less about not being able to fit into the schedule once you’re ready.

How Can Confide Help

Confide understands that a cloud migration is a process and PCI is just one part of it. We’re here for you throughout your PCI journey whatever part of it you’re at. Confide has staff who specialise in cloud security who can advise you and assess your environment. Contact us to find out how we can help you take advantage of cloud offerings.