Note: The product mentioned in this blog, AlienVault USM for AWS, is no longer being sold. Learn more here.
In my previous blog I discussed the difficulties using Intrusion detection (IDS) in AWS to gain visibility. Often the drive for AWS intrusion detection is to meet the requirements of regulatory compliance - in particular PCI Requirement 11.4. The question becomes, now that I have an environment which is finally elastically scalable and is operating at an efficiency I never thought possible, do I really need to re-introduce a static point of failure just to become PCI compliant? Well, unfortunately there is no hard and fast answer, the truth of PCI compliance is that the QSA you are working with has a lot of latitude in their judgment. Without implementing intrusion detection you must qualify as having a compensating control. The requirements of a compensating control are as follows:
- Meet the intent and rigor of the original PCI DSS requirement.
- Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Navigating PCI DSS for the intent of each PCI DSS requirement.)
- Be “above and beyond” other PCI DSS requirements.
- Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement
As discussed in the previous blog post there is alack of scalable options to introduce IDS into AWS. This combined with the ability that AWS affords to consistently monitor the critical services running in our card holder environment we can certainly make a case for a compensating control. Appendix C is supplied in the PCI DSS “Requirements and Security Assessment Procedures v3.0” to make the case for a compensating control.
Requirement Number: 11.4 - Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.
| Information Required | Explanation | |
|---|---|---|
| 1. Constraints | List constraints precluding compliance with the original requirement. | AWS EC2 does not provide a mechanism for consistent access to all network traffic. It is not possible to implement network level monitoring without impacting the operation of the environment. |
| 2. Objective | Define the objective of the original control; identify the objective met by the compensating control. | Network intrusion detection is designed to detect known behaviors of malware and hacker tools. |
| 3. Identified Risk | Identify any additional risk posed by the lack of the original control. | Failure to integrate and analyze data from a publicly expose service would provide an unmonitored point of attack. |
| 4. Definition of Compensating Controls | Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any. | Analysis of the log data from all publicly exposed services provides the ability to monitor attacks, combined with the analysis of the OS-level logs detection of malware persistence and command and control techniques are possible. The ability to automate this log collection through the deployment automation and configuration management tools used provided by AWS make it possible to validate that all publicly exposed services are being monitored. In addition, the ability to monitor the management plane of the AWS environment provides a cross-check of the exposed services by providing the ability to assess the network configuration of the running instances. This provides a double layer of validation for monitoring exposed services and OS-level log analysis. |
| 5. Validation of Compensating Controls | Define how the compensating controls were validated and tested. | Validate the collection of log data from OS-level and publicly facing services from all running instances. Validate the automated configuration of log collection for new instances. |
| 6. Maintenance | Define process and controls in place to maintain compensating controls. | The deployment of new instances includes the automated configuration of log collection for the operating system and publicly facing services. |
Summary
We no longer have to rely on a system that requires direct access to low-level network traffic as a prerequisite for complete network visibility to easily cover our bases. We can take a cloud native approach to security monitoring in AWS and satisfy rigorous compliance requirements like PCI DSS. This means we are now relying on the management plane and the data provided by the API to gain universal visibility without major effort, we can also leverage the same automation that makes elastic scalability possible to hook into the very systems and applications we desperately need to monitor in order to get deep visibility into every corner of our environment. Welcome to the new norm!
