Compliance & Legislation | Managed Security Services

September 24, 2019

Any organisation, no matter the size, that is required to comply with the Payment Card Industry Data Security Standard (PCI DSS) needs to implement a comprehensive ICT security capability to ensure they pass their annual review. The PCI standard contains auditing and monitoring requirements that ask entities to collects logs and raise alerts when they are under attack from cyber adversaries. Let’s explore this requirement and look at how your managed security service can help your customers achieve PCI DSS compliance without the need to redesign their network architecture or systems infrastructure.

Monitoring and PCI DSS compliance

Most security programmes follow the age-old design methodology known as ‘defence in depth’, whereby they implement a combination of security controls covering all aspects of the defensive lifecycle: preventive, detective and corrective controls. The ‘defence in depth’ concept originates from stronghold designs and ancient castles, where a stong perimeter comprising several countermeasures, from the moat to the portcullis, keep adversaries at bay. ICT architects still think this way, and, indeed, perimeter security remains a requirement, so this approach remains valid. However, we also need to consider that cyber adversaries are smart and patient and are continually scanning for ways to bypass security controls.

This is where you have an opportunity to offer security monitoring systems to customers that directly report on system activity, allowing them to detect attackers either on the outside of the network, or operating within the perimeter.

As an MSSP you can quickly detect these kinds of activities and mobilise an incident response team that minimses the harm that non-compliance (or cyber-attack) has on customers, given the target for attacking PCI-bound organisations is often to steal customer financial data. The potential damage from a successful cyber-attack can be catastrophic, so you have an instant value proposition that demonstrates better threat detection and response to reduce risk and limit financial exposure.

Understanding Logging, Monitoring and Alerting Requirements

Every organisation generates security events, since operating systems, network devices and applications all do this by default. In many cases, if an attack occurs, a specialist forensics team is called to identify what happened. The team combs through the evidence stored in a myriad of logs, which are often spread across many systems, piecing together what happened onto a timeline.

Most organisations, whether they realise it or not, already have all the data they need to detect cyber attacks before the intruder has a chance to complete their attack. Think about it this way, if the investigation team is able to discover all of information they need to piece together what happened, then the systems were already recording the activities as the attack took place. These activities are what your team can monitor for and at certain stages of any given chain of events, it becomes evident an attack is underway, so the incident response process can begin.

You should work with your customers to determine how they monitor, analyse and alert on attacks as are they are happening, so the incident response team (could be yours or the customer’s) has a chance of stopping the intruder.

Yet there is one major issue most security teams are left with that needs to be addressed; there is no common language across systems, and logging doesn’t have a standard structure or format so it’s very hard to dig through those logs and piece everything together. New MSSPs in particular will have a variety of logs from different sources that make correlation across systems very difficult: some logs are in text files; some are only accessible through APIs; while some are stored databases. The complexity of scanning disparate logs evolves to become an impossible task for MSSPs so a toolset is required to help you collect and normalise this data.

Build a SOC

The best approach to monitoring customer systems is to move your security analysts into a security operations centre (SOC), dedicated to collecting and analysing logs and responding to cyber-attacks. A SOC doesn’t have to be a special facility with massive screens or glamorous theatrics (as you might have seen on television), rather it’s a place where the security team works together to coordinate monitoring and alerting across the customer base.

Tools are fundamental to the running of a SOC since this normalisation of logs across hundreds (or thousands) of sources is necessary, along with the ability to detect patterns of attack in real-time. The toolset, known as a Security Information and Event Management (SIEM) system, does all the hard work, freeing up your analyst time to triage alerts and follow investigative leads, rather than spending time correlating events manually across disparate systems. So lets look at this in the context of monitoring for customers who need to be PCI compliant.

What to Monitor?

The Huntsman Security team is often asked what should be monitored to fulfil PCI DSS compliance obligations; should we collect logs from every system, or restrict it to the systems on which we store or process customer or credit card information? We respond to this question with an analogy: when a jewel thief breaks into a bank to steal diamonds, they leave traces of the theft throughout the bank’s facility, not just on the safety deposit box where the jewels were stored. ICT systems are the same. If you can detect the attacker as they come through the door, or slip in through an open window, then you can prevent them getting to their end goal. You can adopt this analogy when talking to PCI customers, since a monitoring solution using SIEM allows them to monitor and correlate information along the entire attack path, thus being able to identify attacks before they get close to the end objective (credit card information).

The earlier you detect cyber-attacks, the more significant the reduction in overall harm to your customers. Together with your customer, you can use threat modelling to determine how attackers would reach their objectives within the context of the customer’s systems, looking at each technology and application through the eyes of the hacker. Using this approach, you can help the PCI customer prioritise the collection of logs, and tailor notifications based on the risks associated with each of those systems identifying indicators of compromise.

MSSP value proposition: helping maintain PCI DSS compliance

Next generation SIEM products have specialist collectors developed to interface with hundreds of different kinds of ICT systems, so the hard work in collecting and normalising the data is already done for you.

Once the data is ingested into the SIEM and made available to analysts, the rules pertaining to each event and their relation to other events can be programmed into the platform to alert on patterns of attack. This activity forms the basis of how you would work with PCI customers.  There are, however, two specific aspects of detection and response that you can explain to a customer, since both assist in PCI DSS compliance, but more importantly they help detect and prevent security breaches that simple log analysis cannot. The first is based on gaining an understanding of user behaviour. Next generation SIEM technology can build a baseline of what regular operations look like then alert when something unusual happens. Second, is reporting, the SIEM can report the PCI customer’s compliance status on a dashboard that immediately shows issues in real-time.

Next generation SIEM technology provides essential aspects of fulfilling PCI DSS compliance obligations – something that you, as an MSSP, can use to show the value of your SOC service.

MSP Guide to Building Cyber Security Services


Related Cybersecurity Content


Read by directors, executives, and security professionals globally, operating in the most complex of security environments.