As you noticed during our discussion around the updates to requirement 1 (and if you didn’t go read that blog post), the content is pretty dry, but I try to present it in a way that is at least easy to consume and use. That won’t change throughout the rest of the requirements, not even requirement 2 – the “common sense” requirement (as I like to call it.) The reason I refer to it in that way is simple – If you just do things based on what just makes sense, you have achieved most of the needs for compliance in this one. If you want to hear my thoughts on that, feel free to reach out directly for a conversation on the topic.
Overall Thoughts
As we discussed in our PCI discussion there is a major shift on ownership of the PCI program. If you don’t dig too deeply it feels like the only motivation is to just shine a light on PCI and prevent it from being forgotten in the overall security stance of the company, and I admit I do think that is part of it. I also think that the council is motivated by making sure the process owners are acknowledged within the organization, so they have the internal credibility and awareness of their position to act in a way that helps them be almost as agile as the threat landscape they are facing. In IT security the defenders are mostly in a reactive mode, giving an edge to the attackers, so the shorter the reaction window is the less the impact. Requirement 2 is designed around the idea that we reduce risk and increase the window allowed for reaction from the start, or introduction of items to the environment to begin with. With that focus in the overhaul of Requirement 2, the updates will provide clarification on how the environmental elements are expanded and managed during the introduction period.
What’s New for Req 2 in v4
The only net new item in version 4 for requirement 2 is the new 2.1.2, which states “Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.” If the previous sentence feels like I just took the same sentence from the post on requirement 1 and changed the 1 to a 2, good job remembering what we discussed in the previous blog post. You truly might be my biggest fan!
Changes to the existing controls
As in our previous post dedicated to a specific section of the DSS, I am going to bullet them out for you and give a (very) brief note on them.
- 2 (in general) – Clarification/Guidance – Updated principal requirement title to reflect that the focus is on secure configurations in general, and not just on vendor-supplied defaults.
- 2.1 – Clarification/Guidance – Now will be 2.2.2 where the SSC wants to clarify the intent is to understand whether vendor default accounts are in use and to manage them accordingly.
- 2.2.1 – Clarification/Guidance – Updated as 2.2.3, adds details to the intent of the requirement for managing primary functions that require different security levels.
- 2.2.2 – Structure/format – Combined with 2.2.5, to now be 2.2.4 as a combination of what the council feels to be “similar topics”
- 2.2.3 – Clarification/Guidance – Renumbered to 2.2.5 and added details on the intent of the requirement is if any insecure services, protocols, or daemons are present.
- 2.1.1 – Clarification/Guidance – Split into two separate controls (2.3.1 / 2.3.2) to provide focus on different aspects of assessment on wireless vendor default settings.
- 2.4 – Structure/Format – Removed from requirement 2 and now part of requirement 12 (12.5.1)
- 2.6 – Structure/Format – Removed from RoC/SAQ assessments. The council felt it was covered under other areas and no longer needed to be a standalone part of the assessment process.
Conclusion
Well, this week we had less to talk about, due to the nature and length of requirement 2 in general. Don’t let the limited number of requirements in this section of the DSS lull you into a sense of complacency. Reduction of risk through removing it prior to its introduction of your environment is an important step for all. The reason I refer to requirement 2 as the “common sense” requirement, yes even when talking to my clients, is because you must be pretty naïve and brand new to the IT world to think that putting devices on the network without going through some hardening process. As with most, if not all, items in the PCI Digital Security Standards, if it is included – someone wasn’t doing it.
When reading through the bulleted list you may have noticed that I didn’t go too deep into the changes and kept it as a high-level description on the type of change more than the actual change. In order to not publish a book weekly I am choosing to provide some general information, so you know how to frame the conversation with your internal subject matter experts and/or your third-party experts. I don’t want to provide detailed specifics without knowing your environment. Even leaning in that direction would be irresponsible of me, in my opinion.
As always, if you have additional questions or feel the need to discuss payment card security (or data privacy or any other IT security/risk/privacy topic) feel free to reach out to us to continue the conversation. If you already have a trusted consultant, good for you on finding someone that you can rely on for counsel. Either way, make sure you are having conversations to build a better understanding of the changes happening that will have an impact on your organization.