PCI Journey

Your Path to PCI DSS compliance

Software & Tools for PCI DSS Compliance

The PCI Data Security Standard itself has multiple requirements where you basically have no choice but to use specific types of tool in order to meet the requirement. Using well chosen tools can streamline your PCI DSS compliance process. So what’s a well chosen tool? Everyone is going to have their own ideas and approach for tool selection.

Contents

Considerations for tool selection

An overarching consideration is going to be whether you have the capabilities within your organization to deploy and maintain the tool. If you have large, established IT Operations and IT Security departments, that’s going to maximize your available options when it comes time to select new tools. With in-house capabilities, deploying open source tools that require significant customization and integration becomes feasible. You effectively build your own tool suite from open source components.

At the other end of the spectrum, you may have no real in-house capabilities in this space. Unless you want to invest heavily in this area, you’re going to be driven towards the managed services options. These can either be cloud-based solutions following the IaaS or SaaS models. Here, you configure your systems to talk to the remote service, and can make some configuration changes via the web interface and tools. But you’re spared the infrastructure configuration. Or, perhaps you go down the MSSP (Managed Security Service Provider) route, which is where you pay a company to operate a set of security services on your behalf. That company will then likely handle the choice of tools to be used, perhaps offering you a menu of options at different price points.

Any new tool you introduce into your environment is going to require some investment in learning to get the most out of it. From this, there are a couple of additional things to keep in mind. One, what do existing team members have experience with? If there’s a tool commonly used in the industry that everyone knows, but you’re not currently using, it might be best to pick that one if it’s viable. Two, tools that fill more than one role can be particularly valuable. A good example of this is OSSEC, which can do both File Integrity Monitoring (FIM), act as an agent to enable centralized logging, and also provide Rootkit Detection capabilities.

Personally, I’ve found that it’s always worth doing an evaluation of at least two different tools for any particular requirement, even if you think there is an obvious ‘winner’ going in to the process. It wouldn’t be the first time I’ve come away disappointed with the software I was going to use, and ultimately ended up selecting a different solution.

Open Source Issues

In general, Open Source Software (OSS) is one of the most important and significant developments of the last 30 years in the software industry. However, you need to take some care with open source tools when dealing with PCI compliance.

First, if you are considering open source tools, it’s important to understand how the open source license really operates. There can be various constraints put on open source tools that make them less than ideal for operating a commercial business:

  • The license may be more restrictive than you thing. An example is anything licensed under the AGPL. Software licensed with the AGPL has its source code freely available to be reviewed and even modified. However, if you use the AGPL software to operate a commercial service, then you’re forced to make a choice: use the free (as in beer) AGPL version, and also give away the source code of anything you link with the AGPL software; or purchase a commercial license for the software. In the payments space, a well known example of this is the jPOS ISO 8583 message parser.
  • It’s becoming common for software vendors to distribute “core” versions of their software, including source code, under fairly free open source licenses. However, they keep many of their higher value features out of the open source version, requiring you to purchase a commercial version. Or, they provide all the features, but don’t offer tools to upgrade from one open source version to the next, keeping those commercial-only. You need to watch out for these ‘gotchas’ before getting too dependent on this software.

Second, for any software that will handle PCI cardholder data, you need to understand where support and security updates will come from. This is particularly important for open source software, where you may not have any commercial relationship with a support provider, and the author of the software may simply stop releasing updates. If the tool or software is critical to ongoing operations, have contingency plans in place.

For more discussion of the issues surrounding open source, read my article on choosing open source software.

Document Production

Being PCI compliant means you’re going to be maintaining a substantial body of documentation. These are going to break down into the following areas:

  • Policies
  • Procedures
  • Configuration Standards

Supporting these, you may have diagrams showing anything from flow charts to physical network diagrams illustrating segmentation controls.

There are many ways of producing this documentation, so many that I won’t discuss specific documentation tools. Just remember that anything you have to write needs to be in a form that you can use effectively day-to-day, and can also be easily provided as evidence for the QSA during your audit. Because the business should use approved versions of these documents, some kind of publishing capability to keep drafts separate from approved documents is also strongly recommended.

So you could use a Wiki and print the document to PDF from your browser. Or you could maintain the document in Markdown, and generate a pretty formatted PDF for the QSA using one of many tools. Other people use Word documents, and these days they can be generated with Microsoft Word itself, LibreOffice, or one of the cloud office suites.

Unless you have some specific requirements, document production is no longer an area where you must spend money on tools to get decent results.

Drawing Diagrams

In addition to diagrams being useful for understanding your own business, PCI DSS version 3.2.1 has specific requirements for you to maintain diagrams:

  • 1.1.2 – Current diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks
  • 1.1.3 – Current diagram that shows all cardholder data flows across systems and networks

There was a time when the go-to tool for business diagrams was Microsoft Visio. It’s still a great tool because of its versatility, but it’s also a somewhat expensive tool, and it only works on Microsoft Windows. As a result, it no longer has the same dominance it once held.

One alternative approach that I see a lot of business people using is drawing their diagrams in Microsoft PowerPoint, and then embedding them in whatever document they need. I’m sure this trend is being driven by familiarity with a tool already installed on your work laptop, but I don’t personally like this approach. PowerPoint’s drawing capabilities are somewhat limited – it’s not a full-fledged technical drawing tool. It works great, until you run out of steam. Then you need to convert your diagram to use a dedicated too.

Some alternatives are listed below:

  • draw.io is a free, web-based tool that only depends on a modern browser to run. You can use it on Windows PCs, Macs, Linux, and even Chromebooks. Some people will worry that being web-based, they can access your data. However, the Terms and Conditions make it very clear that the actual diagram is only stored on your computer, and any cloud services you save it to. Diagrams are never uploaded to the draw.io servers. This is a surprisingly good tool for basic network diagram tasks.
  • OmniGraffle is a commercial app for Macs and iOS devices only. It’s been really popular with Mac-based developers, and I’ve received a number of graffle files over the years that I’ve had to get converted into images just so I could view them. If you’re heavily invested in macOS as your desktop platform, and have users familiar with OmniGraffle, then I think it’s a great choice to use. But if you’re not already using it, I’m not sure I see the value in starting out with it versus one of the web-based multiplatform alternatives.
  • Lucidchart is a commercial web-based tool that only depends on a modern browser to run. It offers a more comprehensive set of functionality than draw.io, for those who find the free tool to be too restrictive. Lucidchart also offers the ability to import from a range of formats including Visio, OmniGraffle, and draw.io. If you’re going through a consolidation and rationalization exercise, it may be a good tool for pulling legacy diagrams into a common location and format.

IT Operations

To successfully operate a PCI DSS-compliant production environment, you need more tools than just those listed below. In particular, you’ll want some kind of infrastructure monitoring solution in place to do things like service alive checks, response times, and more general resource utilization alerting and trending.

However, those tools are highly recommended for any production environment, and are not specific to PCI compliance. The tools listed in this section are those mandated by the PCI DSS requirements, and where not all environments are likely to have existing solutions deployed. These are the tools of security operations, as well as IT operations.

File Integrity Monitoring

Multiple sections of the current version of the PCI DSS (3.2.1) require that you deploy a File Integrity Monitoring (FIM) platform. The purpose of a FIM platform is to detect unauthorized changes to files – in practice this can mean it alerts you as changes to files are detected, which must then be investigated to determine whether the change was actually authorized.

The sections of PCI DSS explicitly referencing file-integrity monitoring, or FIM, are:

  • 10.5.5 – Use file-integrity monitoring … software on logs to ensure that existing log data cannot be changed without generating alerts
  • 10.8 – (service providers only) Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of … FIM
  • 11.5 – Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly

It’s hard to see how any of these could be marked N/A, other than perhaps 10.8 if you’re not a service provider. So in practice all PCI DSS-compliant environments should have a FIM platform deployed and active. A range of FIM solutions now exist:

  • OSSEC is a free open source FIM, HIDS, and log monitoring platform which is available for both Linux and Windows. As such, it’s listed in multiple sections of this guide, and is somewhat of a one-stop shop for various PCI DSS requirements. OSSEC’s deployment model uses a centralized management server, and an agent running on each server in the environment. The management server handles environment wide configuration management using XML files pushed out the clients, and acts as a log event receiver. Agents run on each server in the environment, running FIM on demand and on a schedule.
  • Wazuh is an open source fork of OSSEC, created to allow the addition of many new features and technology updates (e.g. AES encryption). In addition to the core features of OSSEC, Wazuh has the option to use SHA256 checksums for its FIM module. It also has a number of scalability improvements for managing large numbers of hosts, such as multi-threading in the server process, TCP for manager-agent communications as well as the older UDP protocol. It also uses the modern AES encryption which can be hardware accelerated on recent CPUs, instead of the less secure legacy Blowfish algorithm.

Host Intrusion Detection

The current version of the PCI DSS (3.2.1) does not have any explicit requirements for HIDS (Host-based Intrusion Detection Systems). However, the following get honorable mentions here because they meet multiple other PCI requirements, and offer some HIDS capabilities as well.

  • OSSEC is a free open source FIM, HIDS, and log monitoring platform which is available for both Linux and Windows. As such, it’s listed in multiple sections of this guide, and is somewhat of a one-stop shop for various PCI DSS requirements. OSSEC’s deployment model uses a centralized management server, and an agent running on each server in the environment. The management server handles environment wide configuration management using XML files pushed out the clients, and acts as a log event receiver. Agents run on each server in the environment, running the Rootkit-detection HIDS component on a schedule. By default this is once every two hours, but it can be tuned for your local requirements.
  • Wazuh is an open source fork of OSSEC, created to allow the addition of many new features and technology updates. In addition to releasing the software under an open source license, they offer a managed cloud-based server component as Wazuh Cloud.

Network Intrusion Detection

Section 11.4 of the current version of the PCI DSS (3.2.1) explicitly requires that you “Use intrusion-detection systems 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.” As such, you basically can’t be PCI compliant without having some kind of network IDS (Intrusion Detection System) or IPS (Intrusion Prevention System) deployed.

In some cases you may effectively be able to get this using existing technologies. Requirement 1 of PCI requires that you operate a firewall; many firewalls have an optional IDS/IPS capability available. If you have such a firewall, enabling the IDS/IPS is often the way to go. If you are planning on doing this, carefully understand your current firewall resource utilization (particularly CPU %), and the likely impact of enabling the IDS/IPS feature. Doing additional inspection of all network traffic flows will add load to your firewall, and you don’t want to do this on a box that’s near the limit already.

If you want to deploy an IDS/IPS that’s decoupled from your firewalls, multiple software solutions exist.

  • Snort is a free open source network IDS and IPS platform which is available for Linux and the BSD’s, but not Windows. It was the original widely adopted open source IDS platform, however for a while it stagnated due to the original code not being multithreaded and so not able to make use of multiple CPU cores. Snort 3 is the latest version and is finally multithreaded, but as of this writing in early 2020, it’s still in beta. That makes Snort hard to recommend for environments with high traffic volume at this time.
  • Suricata is a free open source network IDS and IPS platform which has broad OS support, being available for Linux, the BSD’s, macOS, and Windows. Being architected significantly more recently than Snort, Suricata is designed from the ground up to be fully multithreaded, allowing it to take full advantage of modern multi-core CPUs. In addition to its own rule engine which uses the Lua scripting language, Suricata is also able to work with Snort rules. This makes the migration path from Snort more straightforward than it otherwise would be.

Network Device Change Monitoring

Section 1.2.2 of the current version of PCI DSS (3.2.1) creates a couple of requirements around managing the configuration of network devices:

  • 1.2.2: Secure and synchronize router configuration files
  • 1.2.2.b: Examine router configurations to verify they are synchronized – for example, the running (or active) configuration matches the start-up configuration (used when machines are booted).

It’s possible to meet this requirement without any dedicated tools, through manually backing up the configuration after every change, and recording status output showing that the saved configuration is newer than the running one. However, this is error prone both in terms of having confidence that what is saved actually matches the live config, and also requiring discipline to do correctly. Most people choose to use some kind of tool to automate the process.

Some free and inexpensive options are:

  • RANCID (Really Awesome New Cisco confIg Differ) is a free open source network device configuration backup tool that runs on Linux and macOS. It has been around for many years, and lots of people in the industry have experience working with it. For a long time, it only supported backing up the configuration to CVS repositories, while the development world was moving on to git. This seems to have caused some people to move over to using Oxidized as their free solution, but now RANCID supports git too it’s no longer a differentiator.
  • Oxidized is a free open source network device configuration backup tool that runs on Linux. It is significantly newer than RANCID, and has supported git as the configuration repository for longer. Oxidized has something of a reputation for being challenging to configure; that may not be well deserved at this point given the number of quick start guides out there. It has an integration with LibreNMS allowing device configuration data to be displayed within the LibreNMS interface, so if you’re already a LibreNMS shop then Oxidized is going to be a good option.
  • Kiwi CatTools is a relatively inexpensive commercial network device configuration backup tool for Windows. It’s been around for a while, and was acquired by SolarWinds in 2009 and maintained ever since. Functionality is somewhat limited, presumably to avoid competing with SolarWinds’ more expensive offerings. However if all you’re looking for is backup/restore, and change detection functionality, and you want a native Windows solution, it’s a good bet.
  • Unimus is a relatively inexpensive commercial network device configuration backup tool which runs on Linux and Windows. Currently they offer the first 5 devices free, and then each additional device is $4.50 U.S. per year. For small installations, that is likely very compelling given the complexity of using the open source RANCID or Oxidized.

Log Monitoring & Management

One thread running through the PCI DSS is the need to be able to create audit trails for what’s happening on systems that are in scope, and alert if certain events occur. Multiple requirements support this, including:

  • 5.2: Ensure that all anti-virus mechanisms are maintained as follows: Generate audit logs which are retained per PCI DSS Requirement 10.7
  • 10.2: Implement automated audit trails for all system components to reconstruct the following events: …
  • 10.3: Record at least the following audit trail entries for all system components for each event: …
  • 10.5: Secure audit trails so they cannot be altered.
  • 10.6: Review logs and security events for all system components to identify anomalies or suspicious activity. Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.
  • 10.7: Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis
  • 12.11: SP Only Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes: Daily log reviews, …

With the requirements both to alert on certain events, and retain audit trails for significant amounts of time, log management tools are important for PCI DSS compliance. In fact, the PCI SSC consider log monitoring to be so important, they have actually published a separate 43-page guidance document on this one topic!

Some options for centralizing log management and alerting are:

  • OSSEC is a free open source FIM, HIDS, and log monitoring platform which is available for both Linux and Windows. As such, it’s listed in multiple sections of this guide, and is somewhat of a one-stop shop for various PCI DSS requirements. OSSEC’s deployment model uses a centralized management server, and an agent running on each server in the environment. The management server handles environment wide configuration management, and acts as a log event receiver. OSSEC can also parse logs from a variety of network devices in addition to its own agents, and triggers can be created to send alerts based on receiving certain log messages.
  • Wazuh is an open source fork of OSSEC, created to allow the addition of many new features and technology updates (e.g. AES encryption). In addition to the core features of OSSEC, for log monitoring it adds cloud integration with AWS Cloudtrail and Cloudwatch, and Microsoft Azure, and adds the ability to decode JSON-format messages natively. It can now handle much larger individual log messages.
  • ELK is not one product, but a service powered by the combination of three separate open source tools: Elasticsearch, Logstash, and Kibana. The combination of these tools provide a stack that can ingest logs and store them (Logstash), search the stored logs (Elasticsearch), and visualize the results (Kibana). You can use these tools to deploy your own log management solution, or various companies including Elastic and Amazon AWS provided hosted, managed implementations ready to go.
  • Splunk is a commercial log management tool available both to host on-premise, and also as a cloud service. For a number of years, Splunk was the undisputed king of the log analytics world before its success brought increased competition. Splunk is a very powerful solution, but it has a reputation as one of the more expensive options available. I’ve consulted at multiple organizations where there was an active project to minimize the log volume being sent to Splunk, purely to avoid having to purchase additional licenses.

In addition, there are now a number of cloud-based log management services to consider.

A word of caution: there are a number of cloud-based solutions out there for log management. It seems to be common for these to quote pricing for 30 days of retention, and in some cases to not even offer higher retention levels on their ‘standard’ plans. PCI DSS mandates at least 90 days worth of retention in an easily accessible format, and a year in cold storage, so those default 30 days of retention just don’t meet the requirements.