There are two notable changes that may require a fair bit of runway to fully meet the existing requirement to monitor your critical security control systems.

On March 31^st, 2022 PCI DSS v4.0 was released. Today’s post is part of series of pieces we are publishing that explore the changes to the PCI standard and provide insight into what the changes will mean for your organization. All of our posts can be found here.

As we dissect the new PCI DSS v4.0, we find ourselves responding to specific questions from our Clients related to the changes as well as questions about the type of entities to which the requirements apply.  

One requirement that we are talking about frequently is PCI DSS v4.0 requirement 10.7: “Failures of critical security control systems are detected, alerted, and addressed promptly…“.  While this is not a new requirement (previously included in v3.2.1 as Requirement 10.8) there are two notable changes that may require a fair bit of runway to fully resolve:  

• the addition of detecting failures of security controls for automated log review mechanisms and security testing tools, and 
• the expanded scope of the requirement which now applies to ALL entities – not just service providers.  
  
   

The DSS has this requirement listed as a best practice until March 31, 2025. We anticipate this being a challenge, especially for merchants who haven’t had to worry about this before. 

Monitor the Monitoring 

While this requirement centers around the failures of security controls, I like to refer to this as “Monitor the monitoring.”  The failure of a security control is a binary event, and while important to capture and understand, we also have to ensure the quality of the monitoring as a whole and make that a more intentional best practice – thus, “monitor the monitoring.” Ultimately, compliance is a byproduct of good security hygiene, policies and procedures. 

Let’s look more closely at the elements that should be considered as part of the compliance and best practice efforts related to Requirement 10.7.2: 

• First out of the gate is to ensure that the applicable policies, standards, and procedures are assigned and set for review, and align with the business goals of the entity. Often one of the more difficult tasks is gathering an inventory of the applicable assets and services specific to security controls that need to be included as part of the monitoring efforts. We recommend reviewing the inventory list as a whole and updating the overall scoping process to address for completeness and to gain a thorough picture of all related security controls requiring monitoring. You can’t monitor the monitoring if you don’t have a comprehensive enumeration of the environment. 
  
  

Some monitoring considerations include:  

• For any security control related onboarded or decommissioned equipment still online, there needs to be a rock-solid process to ensure these items receive and maintain the appropriate agents installed or are otherwise included in the monitoring efforts. Decommissioned equipment that might still be causing a lot of unnecessary traffic for operations staff should be removed but you might not be aware that it isn't being monitored. It’s great to have a lot of data, but too much can make it impossible to determine what is actionable, and obviously too little can cause the opposite problem where you aren’t being notified of potential issues. Imagine a car without a fuel gauge or check engine light!  
  
  
• Some monitored resources by their very nature will create a steady stream of alerts which can operate as a de facto heartbeat. For other resources that may not populate the SIEM with much telemetry, there should be a regular health check (a la the quarterly reviews in the SP requirement 12.4.2) as well as other automated monitoring tools employed where possible. 
  
  

• Check that agents (SIEM, FIM, AV, HIDS) are not crashing or being inadvertently or surreptitiously disabled. For example, most anti-malware agents have anti-tamper features that should be enabled. 
  
  
• As you review the audit logging and audit log review mechanisms, it is important to keep sight of how critical these functions are post-event for forensics, accounting, and non-repudiation. While perhaps a broad statement, there are many foundational services that need to be solid such as NTP and RBAC to establish integrity and a reliable chain of events that may result in an incident. 
  
  
• Complete File Integrity Monitoring (FIM) baseline reviews. Far too often we see the management of FIM as a “set-it-and-forget-it” affair. There needs to be a regular review of file comparison baselines as there are many opportunities for file changes to occur from upgrades, patching, and development, never mind simply changes to the threat landscape.  We rarely see FIM baselines reviews included as part of the compliance calendar and recommend that FIM baseline reviews are triggered, where appropriate, as part of the change control process. 
  
  
• For cloud-based as well as on-prem services you will want to consider: what if email is down? Or, what if a sending email address supporting an alerting service suddenly changed and was no longer whitelisted and went to junk or clutter or was otherwise not received? Are Global or individual mailbox rules creating problems? The point here is that many of the alerts use email as their conduit so the email alerts should be regularly reviewed. Better still, explore additional notification options so everything is not dependent upon receiving an email. 
  
  
• With so many clients migrating to cloud service providers (CSP’s), there are often SLA’s whereby the initial triage is handled by the entity’s service provider. While that can lead to great efficiencies, it is a good time to remind yourself that you can outsource the workload but never the ultimate responsibility for it. Therefore it is imperative to have a well-defined responsibility matrix with such service providers that would also be subject to annual review. 
  
  
• We have run into this more than once: Security appliances may run a long list of services that are subscription-based. Sometimes all of the licensed services within that appliance do not all expire at the same time. As part of the management of these security appliances, the subscription terms should be included as part of the compliance calendar as well as leveraging any license alerting notifications the appliance or vendor may offer.
  
  

  ProTip: You sure don’t want an auditor being the one to discover that a component of the IDS service has an expired license. (Yes – we have seen that more than once!)

   

• For entities with on-prem or hybrid environments, the monitoring of physical supporting services and telemetry like UPS, HVAC, and fire/life/safety systems is foundational, since a failure here can clearly lead to a security control failure. Many of these types of systems might not be a quick fix either. One of the most public breaches in recent times was a direct result of a supporting service failure. 
  
  
• This might be a bit obvious, but from an access controls perspective, the monitoring systems should be given the same level of access control rigor as the monitored resources. Make sure any 3rd party access (like an outsourced SOC) is regularly reviewed and there aren’t any unprotected break glass accounts in place or default passwords to those accounts still active. Also, we have seen locked down on-prem data centers only to find a legacy and forgotten network KVM system that was unmanaged. 
  
  
• We strongly recommend using network/dataflow diagrams to document security controls. We don’t see enough of these - especially when there are layers of log forwarding and aggregation appliances in an enterprise. It’s good to review these to match the physical layout against the SIEM master console dashboard to keep things in perspective. 
  
  
• For segmentation controls, special consideration should be given to change control detection and alerting for any ACL related hosts. High availability (HA) pairs should also be reviewed in tandem as part of firewall reviews to ensure nothing unexpected happens in the event of a failover. The misconfiguration of a segmentation control could unexpectedly increase the PCI scope and at worse allow unexpected lateral access into the CDE. 
  
  

• Security controls that are unable or otherwise do not lend themselves to be reported into an automated or log monitoring system such as a data center door, locked cabinet, badging system, & video cameras, can be addressed with security awareness and operational oversight. 
  
  
• For the ever-burgeoning internet of things (IoT), special consideration or scrambling might be necessary to include anything needed here that may be categorized as a monitorOR or monitorEE. (I actually know someone with IOT golf clubs!) 

A Special Note to Merchants 

This is a new requirement for merchants. Since merchants may have a smaller AOC audience than an entity assessed as a service provider, it might be natural for a merchant to have a different level of external scrutiny. This should be guarded against to ensure that compliance and monitoring efforts remain robust. Best advice here is to just stick to the script of the DSS requirement which in this case will be the same for both Merchants and Service Providers.

Online is ready to assist you in developing your PCI program, helping unpack what the v4.0 changes will mean for your organization, and then designing a compliance roadmap to get you there. For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0 Resource Center, where we have identified and dissected many of the significant changes and new requirements in the latest release of the PCI Standard.