Free Log Management and PCI DSS 3.0

Robust, reliable and scalable Log Management requires a huge effort from all companies trying to achieve and maintain PCI DSS compliance. PCI DSS v3 mandates the following requirements for all devices located in the Cardholder Data Environment:

10.1 Implement audit trails to link all access to system components to each individual user.
10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data
10.2.2 All actions taken by any individual with root or administrative privileges
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2 5 Use of and changes to identification and authentication mechanisms?including but not limited to creation of new accounts and elevation of privileges?and all changes, additions, or deletions to accounts with root or administrative privileges
10.2.6 Initialization, stopping, or pausing of the audit logs
10.2.7 Creation and deletion of system- level objects
10.3 Record at least the following audit trail entries for all system components for each event:
10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource.
10.5 Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a job-related need.
10.5.2 Protect audit trail files from unauthorized modifications.
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.
10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).
10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.
10.6.1 Review the following at least daily:
-All security events
-Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD
-Logs of all critical system components
-Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
10.6.2 Review logs of all other system components periodically based on the organization?s policies and risk management strategy, as determined by the organization?s annual risk assessment.
10.6.3 Follow up exceptions and anomalies identified during the review process.
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).


There are plenty outstanding commercial tools out there to fulfill the above list, such as Splunk, GFI Monitor or Tripwire. However, many companies do not have budget to spend thousand of pounds on commercial tools.

Recently, I stumbled across a very promising tool called – graylog2. It is an Open Source project, which I tested thoroughly. Its been running in my test lab for over 4 weeks without any glitches and I can definitely recommend it. It has potential to fulfill all relevant PCI DSS v3 requirements and will give any sysadmin a great amount of information for troubleshooting, etc.


I installed graylog2 without any problems on minimal version of CentOS release 6.5 (Final).

Download and install:

Graylog2 Server

Open up your browser and go to http://localhost:9000. At this point you should see:

2014-02-24 14_03_49-Graylog2 - Welcome to Graylog2 - Sign in






Configure Inputs. I settled on the standard Syslog Port UDP 514. graylog2 supports multiple other input formats:

2014-02-24 14_10_04-Graylog2 - Inputs of node






Point your clients to the graylog2 server and start reviewing logs:

2014-02-24 14_05_02-Graylog2 - Search results






graylog2 can certainly fulfill all PCI DSS v3 requirements and do more. It is one of those rare tools, which allows sysadmins truly see what is happening in their networks.

Main benefits:

  • easy configuration,
  • it supports multiple inputs – collect logs from Windows/*nix, Firewalls, Switches, IDS, FIMs, etc. in one place,
  • it is scalable; it can be configured in multi-node mode with full replication and load balancing,
  • it supports strong authentication with multiple users (PCI DSS Req. 7 and 8),
  • it supports various plugins,
  • it is FREE!

Jake Eliasz

Jake is a Chartered Lead Security Consultant with over 15 years' experience in Information Technology. Jake has performed many consultative engagements for retail, banking and government sectors in the EMEA region. Jake is currently focused on designing security controls, PCI DSS, PA DSS, ethical hacking and security risk/compliance. Prior to working for NCC Group, Jake worked as a Lead Security Consultant - QSA (Ambersail), Security Specialist (CreditCall) and Security Analyst (Symantec), where he was designing, implementing and managing various security controls for large, distributed networks. Jake has graduated from the University of Plymouth with the MSc degree in Information Security.


  1. Our security manager has concerns that greylog would not be able to detect If someone logged in and deleted/modified logs. Can Greylag identify who and what was modified log entries? Are there access controls that prevent manipulation of data once the data is acquired by the Greylog server?

Leave a Reply

Your email address will not be published. Required fields are marked *