What you need to know about PCI 4.0: Requirements 10, 11 and 12

As we continue our review of the 12 Requirements of PCI DSS version 4.0, one has to stop and consider, is it possible to have a favorite section of a standard? After all, most guidance documents, as well as regulations are seen as tedious distractions from the importance of getting the job done. However, depending on a person’s position and function in an organization, it is possible to “geek out” on some of the information in these official papers.

In the case of the new PCI DSS, it is clear from my previous articles, that the language was very carefully considered.  As we continue with the final Requirement sections, one can see that the Standard has something to contemplate for all levels of an organization.

An Appealing View for the C-Suite

Requirements 10 through 12 should pique the interest of any C-Level executive. They are presented under two separate headings:

Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 11: Test Security of Systems and Networks Regularly

Maintain an Information Security Policy

Requirement 12: Support Information Security with Organizational Policies and Programs

My justification for viewing these three Requirements as having supreme interest for the C-Suite is because they are more directed towards organizational structure and process. Viewing these from the perspective of a system administrator, or somebody that has to deal with these specific security controls and systems, these are much less interesting.

Requirement 10 starts with the same theme that runs throughout the entire Standard.  That is, that “Roles and responsibilities for performing activities . . . are documented, assigned, and understood.” There is nothing strange or unusual about that. However, this is the section that talks about the fact that an organization should collect logs and do something with those. In another example of altered terminology, as has been evident in this Standard, the phrase “audit trail” has been changed to “audit log”. This reflects the accepted terminology these days. It doesn’t represent a change in scope or anything like that. The intent is still for having logging turned on. The logs need to be collected and there has to be a clear indication of who will be looking at, as well as who will act upon them.

The part of Requirement 10, and specifically section 1.4.1, that is interesting is that automated mechanisms are supposed to be used to perform audit log reviews. The purpose behind this, as described in the new version is that:

“Manual log reviews are difficult to perform, even for one or two systems, due to the amount of log data that is generated. However, using log harvesting, parsing, and alerting tools, centralized log management systems, event log analyzers, and security information and event management (SIEM) solutions can help facilitate the process by identifying log events that need to be reviewed.”

The Security Standards Council is fully recognizing that it’s just not possible for a human to go through millions of log entries and come up with any reasonable salient analysis that that could be useful. In this section, they’re starting to advocate that automation is not only required, but that there must also be processes and procedures, and defined roles and responsibilities assigned to go in and do something about those alerts. This is considered a best practice until 2025.  This signals that the Council is sensitive to how difficult it can be to adjust the automation to the correct level to achieve the right amount of notification.  After all, alerting on every insignificant event will result in millions of alerts, which defeats the purpose.

One Person’s “Prompt” May Be Another Person’s “Late”

Another evolving requirement that remains a best practice until 2025 is that all entities are to detect, alert, and promptly address failures of critical security control systems. The word “promptly” is very much up for interpretation. One person might think “promptly” means an hour, and another might think it’s a week. The applicability of that term is going to depend on the organization. This is a stark example of how this section of the new PCI DSS is going to be decided at the executive level.  A definition of such a nebulous term has to be decided at a higher level of organizational accountability.  In the broader scheme of corporate responsibility, this definition will emerge in conjunction with the core concept of business risk, or operational risk.

From a technical perspective, not much has changed in this Requirement.  The organization has been collecting logs before, as required in the prior version of the Standard, and they are expected to continue that behavior. Now, they have to do a little more work to make sure automated review is taking place, and that there is action taken upon it according to the organization’s definition of a word.

Test Those Assumptions

It is one thing to set up all of the controls, but testing them is the best method of validating their efficacy, and Requirement 11 focuses exactly on that element.  However, it is more involved than the previous version, for example, the Requirement now calls for authenticated vulnerability scanning.  It’s no longer good enough to hire an external firm to do an external penetration test of the organization from the outside while giving them no access.  This method – formerly known as “black box” testing – is no longer acceptable in the new Standard.

Version 3.2.1 required internal testing, however, it stipulated that “The penetration testing should focus on the segmentation controls, both from outside the entity’s network and from inside the network but outside of the Cardholder Data Environment (CDE) . . .” Contrarily, the applicability notes of section 11.4.1 in version 4.0 very luminously state:

“Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks.” (I have added the bold font to emphasize the differences.)

This is definitely a scope change in terms of what organizations will be doing in order achieve compliance. The types of activities are probably exactly the same, but the scope and the granular level of detail to which they perform those activities will change. This is another example of a requirement that requires attention from the highest levels of the organization. When you think about it, few things can chill an executive’s blood more quickly than telling them that “some people are going to try to break into our production network, and we are going to pay them to do it.”

The good news about the penetration testing requirement is that the findings of a test can be remediated based on a company’s business risk, rather than the severity of the finding. It recognizes that a particular vulnerability might be more severe than another finding, but just because it’s exploitable and has a higher vulnerability score doesn’t mean that for your implementation, it poses more business risk. This is very helpful, as many organizations have not fully understood the rationale behind vulnerability scanning. The Security Standards Council is offering some much-needed guidance to put the right security mindset in place. Yes, it’s a compliance requirement, but the purpose of being compliant is to be secure. And so they’re really trying to change that mindset.

Everyone is Invited to the PCI party

Requirement 12 involves collaboration from all departments in an organization. It focuses on the effective management of the organization.  The name of the Requirement is pretty simple; support information security with organizational policies and programs”. The PCI DSS aspect of this is pretty straightforward. It’s saying that you need to define people, processes, roles, and responsibilities within your organization to do everything to be secure. However, one noticeable change is that Requirement 12.2 from PCI 3.2.1 was removed.  That was the requirement indicated the need for an organizational risk assessment. In version 4.0, that is not acceptable anymore. Instead of doing an organizational risk assessment, a company must conduct specific risk analysis.

This requires a deep dive into the business risk profile.  A general approach is no longer adequate.  For example, instead of presenting an overall tapestry of the business’ risk-based approach, there needs to be a set of “formally identified, managed, and evaluated” risks to the CDE.  This means that there must be carefully considered scenarios with detailed remediation plans.  This is going to be unique to every organization. The first step in accomplishing this goal is just understanding what your business is. A lot of organizations struggle to provide that level of documentation.

Imagine if an auditor came in tomorrow and requested the documentation where all of the business’ operations occur, and which control systems are in place to cover those, as well as the processes that are defined to review those security controls for each facet of the environment. Many organizations would fail that test because they don’t have a clear map of all of those things. They don’t have those processes defined for each different segment of their business and how all the systems interact. Requirement 12.3.1 and 12.3.2 are really advocating that business risk needs to be a driver.  This doesn’t mean a company needs to bring in a new team, but they should take some people that they have in their environment and team that thinks about business risk and routinely works on these topics.

Of course, detailed plans of an organization’s risk scenarios could be seen as a roadmap for an attacker, so the careful stewardship of the risk analysis documentation is of critical importance.

The importance of personnel screening is also carried over from version 3.2.1.  When viewed in the context of detailed risk analysis documentation, the importance of trustworthy personnel is even more important than before.

Requirement 12 also gives businesses a lot of flexibility in the implementation of the Standard. In general, a requirement may direct a particular control, but it also offers a more general way to achieve it. However, the customized approach must be implemented in a secure way. So, it might give you a very specific control or a very general guideline.  That sentiment runs throughout all of PCI 4.0, and what’s being dictated by 12.3.2 is that if an organization used the more general, customized approach, there must be a risk analysis for how that actually meets the requirements of PCI.

Requirement 12 also adds new components to the list of items that require review, including cryptographic protocols, ciphers, hardware, and software that is in use in the organization. A routine review compels the organization to justify why a current practice is best from a security standpoint. This section advocates for being a more specific about how an organization applies all of the people and processes, rather than just technical controls.  This is a full-spectrum organizational activity.

Keep The Purpose in Focus

Remember, the primary goal of PCI DSS is to promote a security mindset across organizations that process cardholder data.  This is not conducted in the silo of the security team. There is something for all members of an organization to consider.  Of course, a short series could never cover every part of this standard, and it is best to read the Standard, as well as the comparative document that shows the main changes between version 3.2.1 and the updated version.

In the next part of this series, zero trust, and the importance of configuration management will be examined.

more about PCI 4.0

What you need to know about PCI 4.0: Requirements 1, 2, 3 and 4.

What you need to know about PCI 4.0: Requirements 5, 6, 7, 8 and 9

To learn more about PCI DSS v4.0, follow the five steps in this executive guide to ensure you are leading your organization down the correct path for complete PCI v4.0 adherence in the necessary timeframe. Using this checklist will help you avoid audit fines and keep your organization’s name out of data breach headlines at the same time.

Click here to learn more: https://www.tripwire.com/solutions/compliance-solutions/pci-dss-compliance/essential-pci-dss-40-transition-checklist