Fidelis Cybersecurity
Fidelis Blog


“Operating PCI Compliant Servers on AWS” — Webinar Resources and Q&A

In last week’s Operating PCI Compliant Servers on AWS webinar, Carson Sweet (CloudPassage), Ryan Holland (AWS), and Philip Stehlik (Taulia) discussed what PCI DSS requires and the challenges and opportunities that come with being compliant in the cloud.  The webinar generated a lot of interest and questions, indicating that companies are actively pursuing how to tackle compliance challenges in the cloud.

In case you missed it, you can find a link to the slides here.  We also took the opportunity to address all the great questions asked during the live webinar.

Answered by Ryan Holland (AWS)
Q: Is it accurate to say that VPC may aid in PCI Compliance and segmentation, but is not necessary to maintain PCI Compliance in AWS?
A: I recommend folks to use VPC, due to the isolation and separation it provides. However you can get a completely PCI compliant infrastructure on EC2 without using VPC, we have a number of customers doing that., If I was building a new application stack today, I would use VPC. But if you are currently using EC2 but don’t want to make the migration, you don’t have to.

Q: I’ve recently had my QSA on site to validate our existing environment and I went through the cloud structure options extensively with him. One of the items which he absolutely would not agree to would be to store the encryption keys/keystore systems within the cloud. It is determined to be “outside” of our control and as such not PCI compliant. Can you comment on this?
A: From the standpoint of the auditor’s concern and a security best practice, I would usually recommend to folks that they have a separation of the keys and the data. So keeping your key server outside of where you are operating the data is generally a good security practice.

Q: Is there a document that lists which PCI requirements AWS addresses and which requirements the customer is responsible for?
A: For customers pursuing PCI certification, upon request, AWS will provide a PCI Compliance Package* that includes authoritative compliance documentation from the AWS QSA. This includes the QSA’s Attestation of Compliance document and AWS PCI DSS Controls Responsibility Summary, also published by the QSA, which contains:

  • An Executive Summary, including a business description and the description of the in-scope environment. This content is aligned to that contained in the AWS Report on Compliance.
  • Customer implementation considerations, including implementation details to be considered relevant to a PCI environment.
  • Responsibility of PCI Requirements for a customer’s environment, which is a detailed matrix of PCI DSS controls and the description of responsibility for each individual control
  • The AWS PCI Compliance Package is provided to customers under NDA who request it through their business development contact. If a customer does not know their business development representative, they can contact customer support directly.

*The AWS PCI Compliance Package is provided to customers under NDA who request it through their business development contact. If a customer does not know their business development representative, they can contact customer support directly.

Answered by Carson Sweet (CloudPassage)
Q: How long before the audit does one have to have all this setup?
A: For PCI there really isn’t a minimum time requirement for having all the controls in place. You could hypothetically be audited as soon as you set up your controls, processes, etc. What I do suggest is a pre-audit to help you determine where you need to shore things up prior to your audit of record, and there are a lot of good QSAs that will do this. Guidepoint, for example, is a partner of CloudPassage and they can do this. Have your QSA do a pre-audit, and have them look at where you are and help you understand what needs to be done. Giving yourself the time to tune up before your audit is better than getting blindsided. But in terms of having things up for PCI specifically, there is nothing that says that you have to show 6 months worth of data, for example. If you’re doing a SOC2 that has a particular period associated with it, for example a 6 month look back, you’re required to prove that you’ve had the controls in place for the previous six months. But for PCI, I’ve never seen any such requirement.

Q: Can a SAS 70 Type  II be given as proof for PCI DSS requirement? 
A: No, although it can help. Some QSAs may be able to use previously completed audit work to help support their audit. Two things to keep in mind are that SAS 70 was replaced by SSAE 16 / SOC1 / SOC2 as an auditing standard, and some of these auditing standards are quite arbitrary — you actually define the standard you are auditied against. So for example, you could actually have a SOC2 audit that attests to your PCI compliance. To pass official PCI muster, however, you have to have an actual PCI QSA perform a PCI audit. So the bottom line is no — but it might help.

Q: AWS provides Firewall and Security Groups as well; How is CloudPassage Halo’s Firewall different than it? Does it provide any additional features than AWS Firewall?
A: AWS provides Security Groups by default. Security groups provides non-stateful, inbound filtering. It does not generate audit logs and uses a shared (multi-tenant) policy enforcement point. Halo orchestrates host-based firewalls across cloud servers, which provides inbound and outbound stateful filtering, logging that’s completely under the user’s control and a policy enforcement point that is completely owned by the user. Host based firewalls are also encouraged by AWS.

Q: Does CloudPassage provide any Anti Virus tools or do customers need to manage that?
A: Halo does not provide antivirus tools, although Halo’s File Integrity Monitoring can identify corrupted binaries via cryptographic hashing, preventing unauthorized changes from going undetected.

Q: CloudPassage is a major part of the @awscloud partner ecosystem; is it integrated in the AWS environment?
A: CloudPassage is proud to be part of the AWS partner ecosystem and strive to meet the needs of AWS customers. Halo is also agnostic to cloud platforms, and is therefore not integrated directly into any cloud vendor’s technologies. Halo has been successfully integrated into AWS environments using the Halo REST API, however, for customers who want tighter integration (e.g. automatically spinning up a pristine server using AWS if Halo detects a server integrity failure).

Q: How data encryption is managed via CloudPassage? Which encryption techniques are used?
A: Please see

Q: Do quarantined machines stay in an active state or are they shut down?
A: Quarantined systems stay can in an active state or be shut down. Through a Halo API call, Halo can move the server into a quarantine group which will implement extremely restricted inbound and outbound firewall rules (e.g. preventing data egress, outbound botnet communication, further inbound access). The quarantine group policy can also enforce multi-factor authentication with GhostPorts prior to allowing access to the server, e.g. to restrict access to  investigators. The quarantine group can also be configured with a “data collection” configuration scanning policy set to collect detailed information about the server. This allows for initial examination of the server state in the Halo environment before even needing to log into the quarantined server.

Q: Not sure if you’re familiar with Zabbix, but in terms of weight, is the Halo agent similar?
A: I’m not familiar with Zabbix, but some of the traits that set Halo apart from most of the other available solutions:

  •  The Halo Daemon is very lightweight (less than 6 MB in memory).
  • Highly secure agent, including all data encrypted on disk and in transmission with no key materials in the clear.
  • Processing of data is done on our grid, not on your servers, thus dramatically reducing performance impact.
  • Halo is purpose built for the cloud. Install the daemon on your gold standard master and Halo will detect when clones are created and implement the same protections configured for the master.
  • Halo uses an asynchronous messaging architecture that requires no inbound socket connections for server monitoring or management. This means you do not have to expose your server to additional remote-attack risk for the sake of a management console needing to communicate into agents.

Q: Where does the Halo Grid run at? AWS?
A: CloudPassage operates multiple Halo Grids in multiple cloud environments, including in AWS EC2.

Q: Can you expand on your comment about new PCI requirements being released in a few weeks? The next version of PCI is not scheduled for release until October.
A: What will be released in a few weeks is the PCI cloud SIG guidance on implementing PCI DSS in the cloud (both public and private). It was originally supposed to be released in September 2012, but has been pushed back a number of times. The February release date seems firm based on our work with the PCI organization, but could move again.

Q: What are some common pitfalls overlooked when an organization is moving to PCI-DSS cloud setup?
A: Arguably one of the biggest is employing a QSA firm that has no experience in cloud attestations. You could end up paying them to learn from your environment, and thus have a knowledge curve to deal with. in addition, you will not be able to achieve PCI compliance if your cloud provider cannot do their part. Organizations need to investigate the capabilities and attestations of their cloud service providers to ensure they’re not in for any surprises at audit time.

Q: All API endpoints protected by SSL – can you expand on that point. does this mean that intercommunication between endpoints occurs over SSL?
A: All API communications use HTTPS, so they are protected by SSL or TLS. Further, the communication must use a valid OAuth 2 session. The Halo Daemons also utilize HTTPS/TLS for all communications with the Halo Grid. The Halo Portal can also only be accessed via HTTPS.

Q: When a new server is brought online in AWS how long does it typically take for Halo to setup the security on the new server?
A: Assuming that policies have already been configured, etc. the Halo Daemon immediately implements the last know policies at boot-time, typically before the networking stack has activated. It takes the Halo Daemon between 10 and 60 seconds to retrieve and apply the latest policies from the time that connectivity to the Halo Grid is established.

Q: Can I ask about firewalls and IPS options… How to get similar functions since AWS does not provide logs from security groups.
A: Getting logs from a firewall is one of the reasons for implementing host-based firewalls. With host-based firewalls, you can point logs to anywhere you want to: a syslog server, Splunk, or whatever it is you’re using for SIEM.
Traditional NIDS that operates by reassembling and inspecting network packets is not tenable in the cloud. IPS that relies on NIDS by extension is not easily operable, if operable at all. IPS that uses traffic inspection in a proxy-like model, for example a web-application firewall, can provide effective IPS for the application layer.
For IDS / IPS at the operating system and stack levels, a host-based approach is typically used. Monitoring the server for unusual states, behaviors and/or events using tools like Halo (often combined with SIEM solutions like Splunk or Sumo Logic) are very effective. The Halo API can be used to affect IPS by allowing real-time changes, e.g. firewall rules to block offending external traffic or disabling a system account.

Answered by Philip Stehlik (Taulia)
Q: Does Taulia have a hybrid cloud or is it fully based on AWS?
A: We’re running on AWS in multiple regions.

Thanks again to everyone who participated in the webinar. If you have any questions concerning PCI DSS compliance in the cloud, please email

Stay up to date on all things security

Subscribe to the Threat Geek Blog