Migrating your PCI DSS infrastructure to AWS

Over the past number of years, clients have asked us to support and validate migration plans moving existing PCI DSS compliant infrastructures to cloud hosting providers. In fact, we’ve seen the number of these requests increasing from smaller to enterprise Advantio clients and want to share our insights on the migration process with you.

All leading cloud hosting players today are becoming more and more focused on providing security facilities to their customers. AWS ensures those customers who are subject to security standards such as PCI DSS end up with minimum impact as they migrate their in-house and secure facilities to cloud hosting. Today, maintaining security is part of their top priorities. This is good news for security professionals. We would probably not hesitate to include cloud hosting as a secure alternative to protect data confidentiality and comply with security standards, would you agree?

In this article, I want to dive into the typical cloud hosting migration journey of a PCI DSS compliant infrastructure. And, will share my perspective as a security consultant, technology partner and CTO of Advantio. Amazon Web Services (AWS) will be the example use case as it tends to be the preferred choice of our clients (feel free to contact us if you’d like to discuss another option).

Before we kick off, let’s define feasibility in this context. Cloud hosting of PCI DSS compliant infrastructures might not be applicable to complex facilities, providing core and critical services such as acquiring or issuing for large financial institutions, and in general where complex computing technologies are used. The cost of migrating these type of environments won’t justify the effort yet. Instead, this article applies to web services infrastructures such as e-commerce, payment gateways and so on.

Shared PCI DSS Responsibilities

Exploring the reasons behind moving from an in-house hosting solution to a service like AWS is not the purpose of this particular article. However, I do want to highlight the importance of knowing your PCI DSS responsibilities that will remain applicable to your company even after outsourcing to a service such as AWS. This is important to avoid any surprises during a compliance audit.

AWS does a very good job of respecting their PCI DSS duties. They offer a pretty clear responsibilities matrix where every single requirement of the standard is analyzed from both the perspective of the consumer and AWS perspective as a hosting provider.

No migration project should start without careful consideration of such a responsibilities matrix. It will allow you to enhance your impact analysis report. Further, as you start off, it’s also a good time to engage your QSA to get all the support you need for a smooth migration.

Phase 1 -The Diagrams

It might sound basic, but the first thing we ask our clients at the start of an AWS migration project is to show us the network diagrams based on their future AWS based infrastructures.

More often than not, we are show pre-existing diagrams such as those analyzed during the latest audit and applicable to in-house hosted networks.

The reason we ask for the future view is that the migration process is actually an outstanding opportunity to improve the network. In addition, you might discover structural constraints that would trigger unattended changes to the network design; changes which might ultimately even impact the data flow and its confidentiality as well as integrity. So you see, designing a network diagram of the future vision, will show of the AWS network layer will have to function to include any change or improvement that would create a benefit compared to your current solution.

In the diagram, you should consider the scalability, backup processes and the management of the infrastructure among other things.

Added bonus: The person responsible for the implementation of the migration project will definitely approve of a clear vision!

Your data flows should be analyzed next, and consequently, any data flow diagram should be evaluated to make sure no customization, refactoring or extra-effort is needed due to the upcoming migration.

This first phase is something that should be applied to any newly created infrastructures designed directly in the cloud going forward. 

Phase 2 - Security Policies

It is paramount to ensure there are clear structures in terms of the design and configuration of basic AWS services that support security functions are in place.

Core services such as the IAM, the VPC and its embedded sub-services, and ultimately Security Groups are features that will determine many aspects of the future quality of an AWS infrastructure.

Analyzing each individual best practice goes beyond the scope of this article, however, we feel it is mandatory to highlight the importance of educating your team via the comprehensive set of official documentation and make sure best actions are taken towards security, auditing, scalability and maintenance.

The aforementioned services will most likely constitute the backbone of your identity management and authorization, your segmentation and firewalling, and the fundament on which any security auditor will pay careful attention to.

Depending on the approved secure designs, policies and the definition of an implementation and scalability plan, the next step is to exclude or limit any need for refactoring or redesigning which might have an impact on operations and runtime. 

Phase 3 - Scalability and Data Redundancy

AWS has definitely put a lot of effort into in making sure customers benefit from out-of-the-box features that support scalability of common web architectures (mainly horizontal). And, to provide features that facilitate availability and data redundancy.

This phase can definitely overlap with discussions concerning the nature of the business logic and applications hosting technologies as these are factors that might trigger specific decisions concerning scalability and data redundancy. AWS offers stable options for automatic horizontal scalability (thanks to the OpsWork and/or the Cloud Formation automation) and to address data redundancy matters as well (i.e. via RDS multi-zoning or S3 versioning). Understanding the exact nature of the software layer and the desired provisioning would typically allow us to suggest for a secure and stable approach.

Many of our customers are concerned about applying strategies that would rely on AWS services rather than merely replicate processes and workflows long established within their businesses. This is a natural concern as proven technologies are replaced by new alternatives.

While we have often found ourselves advocating reliance on AWS features when it comes to scalability and availability, we do recommend two steps first. The first is to ensure each business case is analyzed individually. Secondly, to carefully split the need for scalability from the one for data and services availability. Behind these terms, we generally find a plethora of individual matters and technologies. Each with a different set of security and quality requirements. The right move forward depends on each individual case, staff experience, know-how and desire.

Phase 4 - Data Migration

In this article, we have left out the so-called software layer from operating systems to supporting software and application deployment. We feel there are no specific best practices or recommendations that fit with this blog post. Key is however to assess, whether the migration and continuity strategy would work and would securely protect the confidential assets of consumers. This should happen once a staging or even a production environment is ready for usage on AWS.

During this phase, we recommend ensuring that AWS papers on the subject are processed first. Then, you should engage with your security consultant to ensure that the process won’t affect your existing compliance and consequently the security of the data being migrated.

This aspect is strictly dependent on each individual business case. Often, migrations are not even necessary or not planned.

Phase 5 - Security Monitoring and Operations

The AWS PCI compliance package carefully depicts the provider's responsibility and the customers', in terms of security monitoring, maintenance and governance. While physical security and a few other aspects will be inherited from the AWS compliant status, the majority of the activities will remain your responsibility.

Your obligations will still include:

• performing firewall reviews
• recurring security testing
• patching
• threat management and monitoring. 

This holds true on all applicable assets and AWS services which are not already covered by the PCI DSS compliance provider itself. For example, patching of RDS databases or AWS Load Balancers.

Some of our customers would tend to port their existing SIEM and monitoring technologies within their newly created AWS infrastructures. However, this might result in mistakes and over complications of the objectives. Our role at Advantio then is to advise customers to rethink their toolsets and make sure the best actions are taken when it comes to hosting within AWS. While the entire stack (or almost) of the technological SIEM could be implemented by using available AWS services, we recognize the importance of relying on trusted vendors or proven solutions. When the scope is reduced to logging, events collections, traffic analysis and data correlation and alerting, we can advise on solid solutions from low budget to expansive, sometimes more invasive alternatives. The recommendation would depend on the use case at hand and factors including budget and business needs.

We have observed a perfectly reliable and functioning monitoring platform being created on top of the new unified AWS events collection client, and the monitoring services already in the AWS portfolio. Based on the frequency of the topic surfacing during our conversation, Intrusion Detection should also be mentioned. The legit abstraction forced by the AWS virtualization creates a constraint for our capacity to intercept and analyse network traffic at lower levels of inbound and outbound. Network Intrusion Detection or Prevention Systems will always be a subject of discussion with your QSA. They are the ultimate judge of your compliance and their opinion might differ from others, especially in an area where the council uses its famous and somehow exciting ambiguity (i.e. the good old NIDS vs HIDS topic). Long story short, today, a mixture of AWS features and third-party tools, from open source to commercials licenses, are absolutely able to allow your organization to retain the high level of monitoring it is used to, in terms of intrusion detection and more.

Phase 6 - Security Testing

A testing platform on AWS should be no different from any other security analysis. From a PCI DSS perspective, and particularly section 11 requirements concerning vulnerability assessments and penetration testing, it is important to mention the need of extending testing exercises to the configuration and secure usage of the various AWS services.

Vulnerability assessments, either those on public-facing assets via your ASV provider or the internal scans will not be affected by the AWS hosting. However, penetration testing, and in particular segmentation tests, should include some knowledge from the tester about the AWS infrastructure in order to better support customers. Core services like IAM, VPC and Security Groups, even if provided with solid documentation from the vendor, are often part of our security reviews, and suggested to customers as threat vectors that might compromise confidentiality and integrity properties.

PCI DSS Section 11 requires the execution of recurring Segmentation Checks to ensure the integrity of the compliance program scope is preserved and security requirements are met. Combining the outcome of a direct analysis of the VPC configuration and the Security Groups can absolutely benefit the ultimate analysis if combined with the technical testing activities performed by your knowledgeable personnel or your ethical hacking provider. A thorough and recurring review of the settings of your AWS console would ensure the adherence of network diagrams and potentially also fulfil PCI DSS Section 1 requirement concerning firewalls and routers reviews.

AWS additionally requires the registration of testing requests. This is to ensure that testing exercises won’t trigger the transparent security monitoring of the underlining hosting infrastructure provided by the AWS itself.

Conclusions

Over the years, we experienced the market becoming more and more relaxed and prone to migrating to a cloud facility. This can be attributed to the evolution of such platforms. When working with our clients, we take the migration process once step further. We analyze the lifecycle of the PCI DSS infrastructure in the cloud and support customers through our internal knowledge.

Today, PCI DSS in AWS is a common practice. Out-of-the-box services are provided which support security professionals and increase security postures and monitoring.

Our final piece of advice is to always consult with your security partner and your technology partners. They will ensure the impact of the migration is minimized from monitoring to maintenance and operations. The decisions you take together on designing the cloud infrastructure will then be easy to scale, monitor and audit. If you would like to advance your business with a trusted security partner, get in touch with us.