The Payment Card Industry Data Security Standard version 3.2 (PCI DSS v3.2) is a proprietary information security standard that was created to reduce credit card fraud by stipulating a series of controls regulating the use of information systems that handle cardholder data (CHD) and sensitive account data (SAD). PCI DSS compliance is not an optional standard. As stated, all entities who process, store, or transmit CHD and/or SAD must comply with the standard, or they can be fined and refused access to the card brand’s payment systems.
The PCI DSS standard is comprised of six “control objectives” with twelve “requirements” that comprise the detail of the standard. The fifth control objective to “Regularly monitor and test networks” contains a requirement, number 10, to “Track and monitor all access to network resources and cardholder data”. It is incumbent upon the entity, in order to be compliant with PCI DSS, to select and implement a particular technical approach to satisfying this requirement.
The traditional approach to comply with Requirement 10, has been to use an internal network systems logging resource, typically part of an internal security infrastructure, which can receive the (syslog) streams of event data, originating from key components in the system. These key components, typically servers, network devices, firewalls, intruder detection/prevention systems, etc., have been previously configured to generate streams of event information which may be monitored (for active alerts and alarms) and recorded (for subsequent inquiry). It is desirable for the information in this stream to contain sufficient details from the systems and devices, to create an “audit trail” of critical and ordinary events to satisfy the sub-requirements of Requirement 10, which call for specific user and system events to be tracked.
Although low-level event information, such as what is contained in a thorough (and properly configured) audit trail, does encompass enough detail to potentially satisfy the after-the-fact analysis of virtually everything the system may have done, the sub-requirements for daily review (10.6.1) and for post-review follow-up (10.6.3), make this requirement very hard to satisfy when manual methods are used by the customer. It is typical that raw event data is generated at a prodigious rate, often accumulating many megabytes per hour. For these reasons, most logging systems process the event data to correlate, summarize, and scan for critical (alerting and alarming) patterns of activity. Requirement 10.6.1 (daily review of all security events and logs) is usually met by the combination of correlation, summarization and then scanning for bona-fide security events – events that have usually been “confirmed” by automatic processing of two or (often many) more security events from the audit trail. Systems that historically perform this type of logging and analysis are collectively known as Security Incident and Event Monitoring (SIEM) systems. But with the increasing numbers of workloads moving to the cloud, and the explosive growth in the volume, variety, and velocity of data being generated, a new category is emerging to address, referred to as Advanced Security Analytics. It has been a long-standing tradition that systems were selected from SIEM vendors, but now more often from newer, cloud-native Security Analytics vendors entering the marketplace, who craft specific software and sell them to PCI DSS entities who deploy them internally, alongside their CHD processing infrastructure in their data centers.
Sumo Logic provides an innovative Software as a Service (SaaS) solution to the traditional SIEM mission by using the Amazon Web Services (AWS) public cloud infrastructure to deliver a comprehensive solution for logging, analysis, and monitoring requirements used by PCI DSS and other regulations (HIPAA, FedRAMP®, Sarbanes Oxley, CJIS, FISMA, etc.). This SaaS-based offering (referred to as Sumo Logic, or “the service,” in this document) is provided to subscribers as a monthly service, with pricing based upon logging volume and retention period.
The key challenge with the security incident and monitoring mission is to make sense of all the data. By converting unmanageable data into information, and cleverly drawing working insights from the deluge of log data, intelligence can be extracted from the security analytics systems enabling the actuality of Requirement 10, to “Track and monitor all access to network resources and cardholder data.” Sumo Logic purports to be such a tool.
In this document, we [Coalfire] present an “auditor’s perspective” on Sumo Logic’s approach to the fulfillment of Requirement 10, and state our opinion of the product’s applicability to satisfy the specifics of each sub- requirement of the PCI DSS, and further declare whether we believe it is suitable, in whole or in part, to assist in securing cardholder data and secure account data.
