TrustedSec - Making EDR Work for PCI

The Endpoint Detection & Response (EDR) and Advanced Threat Protection (ATP) marketplace is abuzz with products that blur the lines of personal firewall, host-based intrusion detection system (IDS) and intrusion prevention system (IPS), anti-virus, system logging, and file integrity monitoring (FIM). These solutions are centrally managed from your web browser and include advanced dashboards for both summarizing and detailing all covered hosts. They are much more powerful and easier to manage than what existed only a few years ago. Seriously, if you have not looked at EDR, what are you waiting for?

The appeal is obvious, as this is a chance to improve the overall security posture while managing fewer software titles, vendors, and agents.

As a QSA, I am seeing an explosion of requests from my compliance clients to cover these many needs (firewall, IDS/IPS, anti-virus, logging, and FIM) with a single product (FireEye, CrowdStrike, EndGame, and many others!). Companies are looking to both reduce their overall software costs and spend less on the resources needed to support them.

All the Things

As anyone who has gone through the Payment Card Industry (PCI) compliance knows, the process requires a multitude of controls to provide a layered protection strategy. This includes firewalls, IDS/IPS, anti-malware, logging, monitoring, and more. In general, these tools were created for a single purpose and now are being grown into consolidated tooling sets.

However, most of these tools still do not meet complete coverage of what is needed. These products often meet some, but not all, audit log requirements, and they perform some, but not all, requirements for FIM. These products generally excel at strong firewall, anti-virus, IPS, and ATP, though there are far too many offerings to sum them all up.

Some products are more transparent about these limitations than others by offering a matrix for related PCI controls with a detailed description of what they 1) completely support, 2) support with limits, or 3) do not support. This is useful to then know what responsibilities remain for you to support. This exercise of examining coverage by third-party service providers is also your responsibility at least annually via PCI-DSS requirement 12.8.5.

PCI-DSS version 4

PCI can be challenging in its specific framing of controls that pre-date modern EDR/ATP solutions. In the current version 3.2.1, the areas of firewall, IDS/IPS, anti-virus, logging, and FIM are described in terms that pre-date modern EDR/ATP solutions. Additionally, the reporting in 4.0 may go beyond today’s narrowly written controls and instead provide options for coverage to the intent of the controls. This would potentially allow good security to also be compliant, even when the standard is outpaced by industry developments. This will certainly be used to show how an advanced EDR/ATP provides significant coverage to the intent of controls.

With PCI-DSS version 4 not being implemented until Q2 of 2021, we are left wondering what to do for PCI compliance until then.

Not the Obvious

“Aye, there’s the rub.” How does one approach PCI compliance when the choice to consolidate to new EDR/ATP software is, in other respects, a no brainer?

You are not reading this to learn of the obvious solutions. For instance, if your proposed software, let’s say FireEye or CrowdStrike, covers all but FIM, then continue with your existing FIM. While keeping a blend of a few products (instead of just one (1) EDR) provides savings over keeping five (5) old products, we know that business pressures are often more complex than simply seeking ROI. Many of us are facing the challenge of doing the most with the least (a step up in difficulty from simply doing more with less), and this is only complicated by strained budgets and the complexities of enterprise license agreements for bundled software. No single blog can help you with all those unique situations.

The Unlikely Solution

Let’s go back to the challenge of narrowly written controls in PCI v3.2.1 and consider the use of a compensating control. Compensating controls should normally be avoided, as their use requires a legitimate technical or business constraint. They are not an ‘easy button,’ as you cannot cite compliance to another required control as your compensating control.

Additionally, ‘Identified Risk’ is a section of every compensating control, and the control must demonstrate how it mitigates the risk. There are many reasons to not pursue a compensating control. Still, with compelling business drivers, a compensating control may be the key to modernizing while maintaining compliance.

Compensating Control for 11.5 FIM

Take FIM as an example control. Multiple EDR products log changes to all files, and all of those changes are reportable almost immediately to a central browser-based management console. As great as that sounds, this falls short of ‘…to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons,’ as per PCI requirement 11.5.

Why does it fall short? Because if all changes are reported, then effectively none of them are. A method to recognize the file changes that need investigation must be demonstrated. 11.5 continues with, ‘…verify that all alerts are investigated and resolved.’ The ability of EDR solutions to selectively alert on only critical file changes varies widely, and this ability is generally lacking.

An alternative is to have EDR logs collected by your Security Information and Event Management (SIEM) and then automate/correlate them to highlight only the critical ones. Another alternative is to manually augment the Security Operations Center (SOC) so that some dedicated time is regularly devoted to finding issues. While this is not a security best practice, PCI only requires the file comparison to be performed weekly! This is a very low bar from which to operate. Automated or manual, the investigation and resolution of unwanted file changes needs to be demonstrated.

Make sure to design the alerting and investigation solution to be operationalized for compliance. Demonstrating compliance may involve support from:

• EDR/SIEM agent configurations from hosts
• EDR/SIEM views of file change logs/alerts
• Service agreement with SOC
• Alert reviews (emails, tickets, etc.)
• Investigations (emails, tickets, etc.)

EDR solutions can, with some support, be used to replace yesterday’s standalone products in a PCI-compliant fashion.

The post Making EDR Work for PCI appeared first on TrustedSec.

from TrustedSec https://www.trustedsec.com/blog/making-edr-work-for-pci/