The Cross-Sector Cybersecurity Performance Goals (CPGs) are a new baseline released jointly by CISA, NIST, and the interagency community, with a goal of providing consistency across all critical infrastructure. The primary webpage for these goals gives us a great understanding of what they are (and are not). It is worth delving into those specifics to understand where the CPGs apply, and how they are intended to be used.
A baseline set of cybersecurity practices broadly applicable across critical infrastructure with known risk-reduction value.
A benchmark for critical infrastructure operators to measure and improve their cybersecurity maturity.
A combination of recommended practices for IT and OT owners, including a prioritized set of security practices.
Unique from other control frameworks as they consider not only the practices that address risk to individual entities, but also the aggregate risk to the nation.
The most important take away here is that these goals were selected to address risks to the nation as well as individual entities. This is a big shift from other well-known baseline documents, such as the CIS Benchmarks or the NIST Security Guidance. At the same time, this is not a complete guide, it is a starting point to ensure organizations are all starting on the same footing. CISA spells this out on the same page when they describe what the CPGs are.
Voluntary: The National Security Memorandum does not create new authorities that compel owners and operators to adopt the CPGs or provide any reporting regarding or related to the CPGs to any government agency.
Not Comprehensive: They do not identify all the cybersecurity practices needed to protect national and economic security and public health and safety. They capture a core set of cybersecurity practices with known risk-reduction value broadly applicable across sectors.
Voluntary benchmarks are great, but they don’t necessarily have the same adoption as mandatory certifications. At the same time, CISA immediately calls out that these are not comprehensive practices, and you can see that as soon as you look through the document.
What is included in the CPGs?
Which brings us to the next question, what is included in the CPGs? First, let’s talk about the selection criteria for each CPG (available here):
Significantly and directly reduce the risk or impact caused by commonly observed, cross-sector threats and adversary Tactics, Techniques, and Procedures (TTPs.)
Clear, actionable, and easily definable.
Reasonably straightforward and not cost-prohibitive for even small- and medium-sized entities to successfully implement.
These are great criteria. We’re simplifying to the basics and, as we’ve seen time and time again, a lot of organizations are breached because they forget about the basics. As you dig into the sections the CPGs are split into, and think about the fact that the goal was something straightforward and not cost-prohibitive that isn’t comprehensive, it seems like a decent initial target was selected. Once you start to break these down, you will appreciate the depth the document covers.
The 8 sections of the CGPs
- The CPGs are split into 8 sections:
- Account Security
- Device Security
- Data Security
- Governance and Training
- Vulnerability Management
- Supply Chain / Third Party
- Response and Recovery
Most of these categories are commonplace in various benchmarks, policies, and certifications, and the guidance within them is exactly what you would expect.
Account Security is focused on password policies and MFA. It is nice to see that they did not include a password aging policy, as too many organizations rely on this when it has been pointed out several times over that the policy is no longer applicable in the majority of situations.
Device Security looks at asset management, documented device configuration, a hardware and software approval process, and more. One inclusion that I was glad to see, given I recently spoke about BadUSB attacks, was language to prohibit the connection of unauthorized devices.
Data Security covers logging and encryption, while Governance and Training looks at training and corporate leadership. The most interesting aspect of this was section 4.5, Improving IT and OT Cybersecurity Relationships, which suggests throwing a pizza party or social gathering at least once a year to foster better relationships between those in traditional IT cybersecurity and those in emerging OT cybersecurity. Silos are all-too-common in many industries, and IT and OT cybersecurity truly suffer from this. To my knowledge, it is the first time that this has been called out in any published guidance.
The Vulnerability Management section was larger than I expected it to be, and the breakdown here is fantastic. I’ve spent most of my career in the vulnerability management space and I was really excited to see what they had in here. From references to limiting your external attack surface, to mitigating known vulnerabilities, there’s a lot of great recommendations. Pointing out that security researchers are protected under Safe Harbor rules and recommending the use of a security.txt file based on RFC9116 was a nice touch that you rarely see in this type of guidance.
I was a little disappointed to find that Software Bill of Materials (SBOMs) were not referenced in the Supply Chain / Third Party section. Given that SBOMs are another CISA initiative, it felt like a missed opportunity. They do mention important things, however, like specifying the vendor/supplier cybersecurity requirements, and establishing supply chain incident reporting and vulnerability disclosure. Supply chain incident reporting takes us nicely into section 7, Response and Recovery, which covers incident reporting and response plans, system backups, and a documented network topology. The documented network topology adds a nice touch.
I’ve spoken to way too many organizations that can’t tell me or show me how two devices on opposite ends of their network are connected, and this always concerns me. You should know the paths that your data traverses or, at the very least, be able to find that information.
The CPGs finish off with the Other category, which feels a little hastily thrown together as an afterthought. Network segmentation, detecting relevant threats and TTPs, and email security could have all used additional discussion in the document, especially since email security seems to have multiple bullet points merged together. They are, however, exactly what you would expect to see for an email security baseline – use STARTTL and enable SPF, DKIM, and DMARC.
The CPGs are very detailed and very well documented. The initial packet includes the details I’ve discussed, recommended actions, a worksheet for assessing yourself now and again in a year, and an excel document that provides complete mapping to the NIST Cybersecurity Framework, NIST SP 800-53, ISA 62443, ISO 27001, and more. Overall, this is a great start from CISA and a great baseline for businesses to implement.