Achieving PCI Compliance with Log Management

Transcription

1 Achieving PCI Compliance with Log Management

2 TABLE OF CONTENTS Introduction.. Page 3 PCI DSS Requirement Page 3 Log Management and PCI..... Page 4 Data Collection... Page 5 Data Storage.... Page 6 Analyzing the Data... Page 7 SenSage for PCI Compliance..... Page 8 Collecting the Data... Page 9 Storing the Data... Page 9 Analyzing the Data... Page 10 SenSage for PCI and the Total Cost of Ownership Page 13 Achieving PCI Compliance with Log Management 2

3 Introduction Credit card theft and exposure incidents have risen sharply in the last several years, and the pace of these incidents continues to accelerate. The cost of financial fraud associated with these transgressions reaches into the millions of dollars, and the resulting identity theft victimizes millions of people annually. To decide how to protect customer account data when processing credit card transactions, a posse of major credit card companies gathered and issued the Payment Card Industry Data Security Standard ( PCI DSS ). The PCI Standard is comprised of 12 separate standards organized into six different control objectives. Basically, these objectives are to: 1. Build and maintain a secure network 2. Protect cardholder data 3. Manage ongoing vulnerabilities 4. Control access to cardholder data 5. Regularly monitor and test networks, and 6. Maintain an information security policy. In essence, the requirements demand that a number of security controls be implemented. However, simply deploying controls is not sufficient to reach compliance with PCI DSS. These controls must be monitored on a regular basis to ensure their continued effectiveness and to identify any potential threats to the cardholder processing environment. As a matter of fact, tracking and monitoring these security countermeasures is so important to the goal of securing the PCI environment that one of the 12 requirements addresses it directly. This white paper will review what is specifically called for in PCI DSS Requirement 10, explore the technical considerations of the requirement, and consider some different approaches to addressing the requirement. In addition, it will introduce SenSage for PCI Compliance and illustrate that it not only meets and exceeds PCI DSS Requirement 10, but can also effectively address additional PCI DSS requirements. PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 10 states it is not enough to simply put the PCI controls in place and walk away. Rather, these controls must be monitored, and any anomalies investigated. PCI Achieving PCI Compliance with Log Management 3

4 states that logging mechanisms to track user activities are critical. Instating logs in all environments permits thorough tracking and analysis if something does go wrong. In addition, determining the cause of a compromise is made possible by system activity logs. The logs referred to are the audit trails that each IT device in the cardholder processing environment generates to record user, system and network activity. As previously stated, the other 11 Requirements of the PCI Standard mandate the deployment and implementation of many security-related IT controls. Each of these controls, whether intrusion detection systems, networking equipment, operating systems on servers, or even the payment card business application itself, generate logs. Requirement 10 describes in detail how to manage the logs and how to extract the information in them to keep systems safe. While the necessary tracking and monitoring could conceivably be performed by individuals, this option poses a number of problems. The first is the cryptic nature of log records each device has its own log format, organization, and content. Reviewers must be extremely familiar with the log format to understand the content. Even a senior technician has difficulty understanding more than one or two different log formats. The second problem with reviewing these logs manually is the sheer volume of data. Many sources, such as firewalls and servers, can generate millions of individual log entries. Clearly, it is practically impossible for a single human being to adequately review and identify anomalies. This brings us to the final problem in manually reviewing the logs correlating the information. With the increased sophistication of security attacks, rarely does one event, or even one data source for that matter, yield the necessary insight to identify and scope a security incident. Doing so commonly requires multiple sources, which means involving multiple administrator groups to get a full picture of what occurred. It s likely that the PCI Security Standards Council noted these problems as well because they attached the following note to Requirement 10.6 to help. In fact, they went so far as to recommend log harvesting, parsing, and alerting tools to achieve compliance with Requirement Log Management and PCI Log harvesting, parsing and alerting tools are also known as log management, security information management (SIM), security event management (SEM), or some combination of these (SIEM). Since Requirement 10 specifically mentions logs, this paper will refer to them as log management tools. Achieving PCI Compliance with Log Management 4

5 As noted above, manual review of logs is not feasible. Therefore, organizations may wish to invest in a log management tool that automates the collection of these logs from wherever they may reside; stores them in a centralized, secure repository; and provides the required analysis to support the business objective -- in this case, complying with PCI DSS. Log management can greatly assist companies in transforming log data into actionable information. This information can then be used to monitor controls, identify security threats, conduct investigations, satisfy auditors, answer legal requests, and manage security. But just as there are a number of different names for tools like these, there are a number of different ways to provide the basic functions of collection, storage and analysis. Although many vendors use the same messages and product descriptions, there are significant technical differences between the tools. Data Collection There are a number of different ways to collect data. Agent vs. Agentless: Refers to the method used to move the log data from a system component into the repository. While agents can be used to encrypt data before the data is sent for loading, providing a layer of security, agentless solutions are preferable. agentless solutions collect remotely by using industry accepted protocols such as SCP, SFTP or HTTPS to gather the data. They also employ SCP, SFTP and HTTPS also provide a secure method of transporting the data. Parsed vs. Indexed Log Entries: Refers to how the log data is organized for loading and later analysis. Parsed data requires breaks each log entry into distinct pieces of information (fields/columns). Meta data, such as column names, are provided to give relevancy and meaning to the individual pieces of parsed information. Parsing also allows each piece of information to be the axis from which a report, trend or investigation can be generated. Indexed logs: Utilize proprietary algorithms to create internal indexes of what the vendor considers to be the most important data in each log record. Indexing is a general approach applied against specific log sources that contain different pieces of information, so data that is not indexed may not be available for further analysis. Indexed log sources are generally analyzed via Google-like searches rather than formatted reports. Achieving PCI Compliance with Log Management 5

6 Data Storage It is critical to understand data storage. Deciding where data is to be kept and how it will be organized in the repository is crucial. These factors will directly affect how easy or difficult it is to analyze the data once it has been collected and stored. The PCI Standard, coupled with the highly distributed architecture of today s business applications, requires the collection, storage, analysis, and retention of numerous logs from numerous devices up and down the application stack for at least one year. This Herculean effort may well represent one of the largest data management problems an organization will ever face. The following diagram provides an overview of different data sources involved in PCI Compliance. Some log management solutions still store log data in commercial RDBMS solutions (e.g., Oracle, SQL Server, or MySQL). While traditional database solutions are excellent for storing business transaction data, log data is not transactional. Transactions can be updated or deleted within a database, but audit trails should not be. In addition, RDBMS solutions involve expensive licensing and DBA support costs and generally don t scale to the volume and query requirements required by PCI DSS. Online retention of these solutions is generally 30 to 90 days before data must be archived. While this technically meets the PCI requirements, it has operational consequences that are not ideal. Achieving PCI Compliance with Log Management 6

7 Some solutions offer a two-tier approach to storing data. These generally consist of a short-term database where reporting and alerting occur and a long-term log depot where the logs are stored for retention purposes. Again, while this will satisfy the technical requirements of PCI DSS, it is not without a high operational price. Some vendors understand that data management has become one of the biggest challenges for organizations today. These vendors created columnar-based data repositories that stored the log data in a series of compressed flat files but enabled that data to be queried by a single reporting mechanism. These flat file repositories solve the security and operational weaknesses of the RDBMS solutions. More importantly, they give customers a single repository with a single method for extracting data. Further, they organize the data in a way that will scale to handle both volume and retention requirements without the need for archiving. Analyzing the Data Today, almost all log management solutions provide out-of-the-box reports to address PCI DSS monitoring. However, to do more than just generate reports review, track and investigate the information presented in the reports, then consider the following differences in log management approaches. Most of these differences relate to the way data is organized in the repository (parsed vs. indexed), as well as where the data is located (short-term vs. long-term repository). In a nutshell, queries against parsed data return standard formatted reports. This is what 99% of log management solutions provide, for the short-term data, anyway. However, queries against indexed data are akin to Google-like searches that return raw log entries where the matched search criteria are highlighted. These Google-like searches require the user to sift through individual raw log entries to find the relevant ones. Further, they must understand the native format of each log source that is returned in order to obtain the information needed. While this might work for technically-minded users, even they would have trouble manually analyzing and correlating the information. For less technical users, it would be a near impossibility. Another set of solutions stores data in two different repositories include both scenarios: Formatted reports on data contained in the short-term RDBMS Indexed searches on data kept in the log depot To access both devices, a user must import the required timeframe of data from the log depot into the short-term RDBMS and run a formatted report or indexed search across both repositories. This takes time and sometimes requires a separate short-term database to handle the data importing and analysis (so as not to interfere with the standard log loading and Achieving PCI Compliance with Log Management 7

8 reporting) as well as DBA support. Or, a user can sift through the different log entries presented by the indexed search. Another consideration is how often you expect to have to deal with data stored in the long-term log depot. PCI Requirement 10.7 calls for data to remain at least 90 days online and prefers even longer. A recent study conducted by the FBI and Computer Security Institute found that 70% of security incidents involved authorized personnel and that the average insider security incident lasted nine to 18 months. This means that the average insider security incident automatically brings the long-term log depot with its indexed searches into play. What about solutions that archive data on to a storage device? Doesn t this remove the long-term log depot and its indexed searches? Unfortunately, no, it s worse. While many log management solutions will play up their storage partner integration, it is almost always a one-way integration. To perform an investigation involving archived data stored on a network addressable storage device you have to take the following steps: Steps (and Costs) to Query Data Contained in an Archive: Find a spare server (server cost, sysadmin involvement). Create a database instance on the server (DB license cost, DBA involvement). Create the necessary tables on the database (DBA involvement). Take one archived file at a time (DBA involvement) and: o Uncompress archive o Load archive into appropriate tables o Run query against that data (DBA involvement) o Save results to a temporary dataset (DBA involvement) o Repeat for duration of archive investigation (DBA involvement, TIME) What if any of the resulting information spurs additional questions? Must do entire process all over again Must incur all of the costs all over again So what is becoming evident is the more data you can have on-line and available for query the better. And if those queries return exact answers in formatted reports that provide relevance to the information contained on them, then that is preferable to indexed searches. SenSage for PCI Compliance The SenSage for PCI Compliance solution not only meets but exceeds PCI DSS Requirement 10, as well as many of the other PCI DSS requirements. By integrating the collection, storage and analysis functions and designing the solution specifically for log data, SenSage offers a simple and comprehensive way to monitor, analyze and ultimately comply with PCI requirements. Achieving PCI Compliance with Log Management 8

9 Collecting the Data SenSage supports the collection of over 200 commercial products through the use of Log Adapters. A separate Log Adapter for each supported log source understands the log format of that source and contains the parsing mechanism required to split each log entry into its separate pieces of information. Log Adapters exist for all of the security control categories called for by PCI DSS, ranging from the external (e.g., firewalls) through the server layer (e.g., zos, Tandem/Non-Stop, AS400/iSeries) all the way through to the internal (databases and commercial applications like SAP). For a custom data source not supported out-of-the-box, such as a PCI-related business application, a user simply creates a custom Log Adapter with a Regular Expression parsing statement for the data, and then lists the column names the data should be parsed into. SenSage does the rest. SenSage s patented data repository builds all data tables dynamically at load time, allowing for full field-level reporting, analysis and investigations. Not only does the Log Adapter provide the necessary information for SenSage to dynamically construct the data table at load time (eliminating the need for costly DBA services), but it also provides cross-source and cross-vendor reporting with a feature called IntelliSchema. IntelliSchema offers reporting views, similar to traditional RDBMS table views. There is no need for professional services. No need for a DBA. No need for indexed searches. SenSage for PCI Compliance collects the data, parses it for easy analysis, and incorporates the custom data sources not only in the collection process, but in the reporting process as well. Storing the Data SenSage stores its collected log data in a patented data repository. As data management becomes an increasingly large hurdle for organizations to leap, SenSage understands that relational databases are poorly designed for event (log) data. The issues of scale, security and analysis require a new type of database. Therefore, SenSage delivers just that. Based on a columnar design (columns are the stored elements rather than rows), SenSage created a single, centralized data repository designed specifically for log data. Data is compressed and stored in a hierarchical series of folders and flat files on each node s local disk, with a backup copy of each node s data stored on another node for data redundancy and automatic failover. Scaling is provided by adding nodes to the cluster. Security is ensured by eliminating the DBA function (there is no privileged user for SenSage) as well as the ALTER and DELETE functions providing write-once-read-many (WORM) functionality. And, sophisticated analysis is made possible through the use of SQL as the data extraction Achieving PCI Compliance with Log Management 9

10 language, enabling the Oracle-style analysis required by compliance and forensic investigations. PCI DSS demands companies collect, retain and analyze terabytes of audit trail history for at least one year, with a minimum of three months of on-line availability. SenSage s patented data repository ensures organizations a minimum of one year s worth of data online, without archiving. However, SenSage s unique design means that multiple years worth of data can remain online and fully queriable. SenSage s customers have taken advantage of these capabilities and are running deployments that manage three, five or seven years of data -- all on-line. No tiered storage is required. No restoring from archives or compressed media. How much data can realistically be stored in this manner? SenSage hasn t yet reached its limit. With data fully queriable at all times, trending and investigations become questions of intent, rather than of data availability. Analyzing the Data SenSage for PCI Compliance provides three different methods for analyzing the data it collects from an organization s cardholder processing environments: dynamically, historically, and ad-hoc. Dynamically refers to the real-time correlation rules that SenSage uses to identify suspected security breaches. This feature partially addresses PCI Requirement 11.4 that recommends network intrusion detection systems and intrusion prevention systems to alert personnel to suspected compromises. SenSage correlation rules look for attack behavior patterns rather than distinct signatures. This reduces the total number of rules required and enables organizations to catch suspicious activities without having to write specific rules for each variation of an attack. For example, when an attack occurs, the following behaviors can be detected: Some form of reconnaissance (e.g., port scans, network sweeps, logon attempts) An action exploiting a weakness or exposure Actions to cover tracks (e.g., turning off monitoring and logging, killing processes or programs) Ensuring the perpetrator owns the machine so they can gain access again (e.g., creating/compromising an account, outbound connection for root kits) Achieving PCI Compliance with Log Management 10

11 Once a correlation rule fires, users can drill down into a graphical representation of the attack and step through it, event by event, to understand what happened. Users can also initiate an investigation report against historical data directly from the correlated event to begin the process of scoping the exposure and its effects. Compliance with PCI DSS requires not only deploying the mandated security countermeasures, but also frequent reviews of those controls to ensure their continued effectiveness. This is where audit logs come in. As both controls and evidence of controls, event logs detail system and user activity to: Document who is accessing the cardholder data environment Monitor privileged user activity Analyze the logs of the PCI security countermeasures to detect anomalies Understand the scope of those anomalies Comply with PCI Requirement 10.6 to review logs daily Provide auditors with the data and information they seek The SenSage Compliance Analytics package, a series of reports mapped directly against the specific sections of the PCI DSS, provides these capabilities to ensure proper coverage. The final part of data analysis is ad-hoc reporting, or executing out-of-the-box Investigative Reports to create custom reports beyond what is already provided by SenSage. Investigative Reports are a necessary part of a PCI DSS monitoring program. The SenSage for PCI Compliance analytic reports are automatically run on a regular basis and distributed to the appropriate personnel for review and analysis. If a report recipient notices something unusual -- an exception or anomaly -- he must comply with the PCI Audit Procedures for Requirement 10.6 and investigate the exception. SenSage s Investigative Reports for users, machines and IP addresses make this possible. Achieving PCI Compliance with Log Management 11

12 (Figure 1) Figure 1 shows an IP Investigation Report looking for log entries where the IP address of is either the destination IP address or the source IP address. With year s worth of SenSage data always available on-line, there is no need to know where the data is stored. Just choose the time frame and without fail SenSage will return a formatted report (similar to Figure 2) over one day, one year or five years. (Figure 2) Achieving PCI Compliance with Log Management 12

13 And because SenSage uses SQL, the reports are 100% accurate. The same can not be said for indexed searches that return raw log entries to sift through. SenSage provides answers, while other solutions provide possibilities. Further the Investigative Reports are fully customizable. Remove conditions or add new ones. Save changes as a new report, or simply revert back to the original report. Even out-of-the-box reports contain dynamic qualities that will be essential for efficient and effective investigations. SenSage makes custom reporting possible in several ways. First, SenSage exposes the SQL logic so that reports can be changed with ease. SenSage for PCI Compliance comes with a Wizard Report Builder that allows a non-technical user to create sophisticated reports. The user is guided through the four GUI screens and the Wizard generates the appropriate SQL report for them. SenSage for PCI and the Total Cost of Ownership Many organizations believe the initial price tag of a product is the cost of that product. But what they often forget is that once the product is installed, it must be administered and supported. Some organizations fail to take into account all aspects of using the product. Those using long-term log depots don t realize how much time it will take to find the answers they need, or perform investigations involving data that has been archived. With that in mind, here are some things to keep in mind in judging the cost of SenSage for PCI Compliance: SenSage runs on inexpensive, general purpose hardware (approximately $6K/server). SenSage stores data on flat-files, for standard flat-file based easy backups. Data redundancy is built in, so there is no need for additional devices. No RDBMS, so DB licenses or maintenance charges are eliminated. No need for costly DBA resources because: o No indexes to build and maintain o No partitions o No tuning o No replication o No archiving Optimized query capability finds answers in minutes instead of hours or days. 8 billion records are analyzed in 2.5 minutes. 100 billion records representing two years of data are analyzed in 6.8 minutes. Column headings give parsed data relevance for better understanding. No backups or data restores required for long-term historical investigations and forensic analysis since online storage of years of information is possible. Now, consider the consequences of not having data on-line: Achieving PCI Compliance with Log Management 13

14 Average length of security incidents involving insiders is nine to 19 months. Trend analysis requires a long period of data. Extent and scope of security incidents need to be completely identified to ensure proper remediation. Data analysis of archived data is slow, expensive and inefficient. Sophisticated attacks and internal violations can bring a company to its knees, breaking trust with customers and tarnishing reputations. In addition, regulatory compliance requires 100% accuracy. Failing audits is time-consuming and expensive. SenSage s sophisticated solution enables companies to meet regulatory compliance and maintain system availability through granular analysis of privileged user behavior and rapid detection of anomalies across networks, systems, and applications. With SenSage, hundreds of organizations now enjoy peace of mind knowing they are effectively managing vast amounts of data and confronting head-on internal and external threats to data integrity. Corporate Headquarters: SenSage, Inc. 55 Hawthorne Street, Suite 700 San Francisco, CA (415) Achieving PCI Compliance with Log Management 14