We recently examined achieving PCI compliance in a public cloud environment. In that article, I gave a high-level overview of the steps you need to perform. In this article, I would like to dive a bit deeper and discuss some of the unique challenges you can run into, and your options for resolving them. As I hinted in the last article, the biggest challenges can revolve around meeting the network specific controls within the PCI DSS framework.
Cloud providers can receive a PCI DSS attestation as a Service Provider. This permits them to offer services to customers that need to process credit cards as part of their business model. It also permits them to offer services to other cloud providers that expect to have an impact on credit card transactions. For example, Amazon maintains an attestation as a PCI DSS Level 1 Service Provider. This means any third party company could build a Software as a Service (SaaS) offering capable of achieving PCI DSS compliance on top of that infrastructure. This is sometimes referred to as “nested vendors.”
One of the required documents a cloud provider must maintain is a Report on Compliance (ROC). This defines the level of responsibility assumed by both the cloud provider and their customers for each PCI DSS control. In some cases, the provider may assume full responsibility (example: data center physical security). In some cases, the vendor may assume no responsibility (example: checking customer code for security vulnerabilities). In others, implementation of the control is considered a shared responsibility (example: vendor supplies a firewall but customer must properly configure it). You need to review the ROC and provide coverage for all controls to which the provider does not accept full responsibility.
Let’s look at an example of a PCI DSS control that can be extremely challenging to put in place if your provider does not accept full responsibility. Figure 1 shows the control requirements included in control 11.4:
The control requires that a Network based Intrusion Detection or Prevention System (NIDS or NIPS) be installed and maintained. While the description does not specify a network or host based system, the bullet items specify that it be installed at the “perimeter” and “at critical points,” which implies a network deployment rather than host based. In a cloud environment, the provider includes networking services. However, they typically do not accept responsibility for this control. This leaves you in a position of having to implement a control within an infrastructure that you do not administer.
One possibility is to attempt to implement a compensating control. This is permitted when there is a legitimate hindrance to implementing the control exactly as described. Since you don’t control the network layer, you could argue that you are technically unable to implement the control as it is described. You could further argue that a compensating control would be to run Snort, or similar NIDS software, on either every host within the provider’s environment or on a dual-homed server acting as a gateway in front of all other servers (assuming the provider supports this type of connectivity). You could then argue that this creates a similar level of security to that which is described by the PCI DSS control.
However, pursuing this path brings its own set of challenges. You are deviating from the control as it is described. Your Qualified Security Assessor (QSA) may or may not agree with your assessment, and thus may or may not consider this control to be in place. You may put a lot of work into implementing a compensating control, only to find out that you need to identify another solution. Further, just because a QSA accepts a compensating control once, does not guarantee they will do so in future assessments. It is entirely possible that a compensating control can get accepted one year but rejected the next. Since the acceptance of a compensating control is a subjective evaluation, final judgment can vary between assessments.
Finally, both of the described possibilities create additional administration challenges. In the case of running Snort on every box, you have to administer the overhead of having Snort running on every system. A centralized infrastructure must be created, and Snort will take processor and disk read/write time from whatever production processes are also running on each system. While running a gateway setup solves many of these challenges, the configuration is not supported by all cloud vendors and even if it is, you can end up with a single point of network failure. So while compensating controls are possible, they should be considered an option of last resort.
A common mistake I hear is that Netflow or IPFIX data cannot be used to meet PCI DSS control 11.4. The assumption is that since this data does not include payload information, it does not qualify. Let’s carefully reread control 11.4 and extract out all listed requirements:
Note that the defined purpose is to alert personnel when a system acts suspiciously and is potentially compromised. A NIDS that analyzes payloads is not going to give you this information. For example let’s assume an attacker launches an inbound injection attack, which is the top listed OWASP vulnerability. Most likely the attack will take place over HTTPS. HTTPS provides data privacy, which will prevent the NIDS from being able to eavesdrop on the session. Thus the attack will go undetected. Further, even if HTTPS is not used and the attack is detected, this does not guarantee that the target system is actually vulnerable. All we know for sure is that someone attempted the attack. Triggering a response when the success of the attack is not confirmed is going to generate a large number of false positive alerts.
So how do we detect suspect compromises? By identifying when the system acts suspiciously. For example, assume we have a publicly accessible Web server. What type of outbound session establishment is required by this system? Here is a common list:
This is a pretty short list. We could easily define a set of rules that ignores all traffic that meets the above-defined criteria. We then trigger an alert whenever an unexpected traffic pattern is detected leaving the system. We could do this with a classic signature based NIDS, or we could do this with IPFIX flow data. We do not need to analyze payloads to detect this type of suspect activity. The benefit of using flow data is that we do not need to deploy an entirely new security system.
We have established that NetFlow or IPFIX data can be used to meet PCI DSS control 11.4. This leads us to our next challenge, which is that as of the time of this writing, no public cloud vendor supports IPFIX. However all is not lost, if you have instances running in Amazon, you can convert their VPC flow logs to IPFIX format.
I’ve written an article called Working With VPC Flow Logs. If you are new to Amazon flow logs, this may be a good place to start. Once you’ve read that, you can move on to Alex Barsamian’s great article on the configuration as well as importing flow logs into Flowtraq. This can help you get up to speed quickly in meeting this control.
Leveraging public clouds that are PCI DSS compliant is a great way to reduce the number of control to which you are responsible. This can create new challenges, as you need to satisfy controls within an infrastructure you do not administer. Combining tools such as Amazon’s flow logs with FlowTraq can help you meet this control quickly and effectively.