The NERC Critical Infrastructure Protection standards are the most effective tools for securing the electrical supply today. If you think that's a controversial statement, let me explain why I make it. Cybersecurity in the context of the electrical supply is synonymous with reliability. The cyber-risks to electric utilities are ultimately risks to their ability to deliver a constant, clean supply of electricity to everyone who needs it. With this in mind, we can ask what tools, including people, process and technology, are making the most material difference in the cybersecurity of the electrical supply. The only regulation that makes a material difference is NERC CIP. While it applies narrowly to registered entities in North America, there currently are no competing standards outside the region that could be more effective. NERC CIP is the only game in town, so to speak. That solitary status makes NERC CIP not only the most effective tool but also the least effective by having no competition.
What NERC CIP Gets Right
I'm a fan of NERC CIP. While I'm about to pick on the standard in some specific ways, I'll start by saying that it has some things going for it. It requires some of the most well-established cybersecurity best practices, like inventorying the environment (CIP-002) and establishing configuration baselines for assets and monitoring for changes (CIP-010 R1), and centralized log management (CIP-007 R4). There's more, but the point here is that NERC CIP isn't a disaster and we look to improve it because it's worth improving.
What NERC CIP Gets … Less Right (CIP-010 R3)
CIP-010 R3 addresses the subject of vulnerability assessments, requiring:
- A paper vulnerability assessment every 15 months
- An active scan in a test environment every 35 months, where technically feasible
- Scans of new cyber assets before deployment, unless it's a replacement of the same asset already deployed
In other words, it's very likely that the assets directly responsible for the reliability of your electricity are being scanned for vulnerabilities less often than you might lease a car. Actually, that's not entirely true. The requirements don't include scanning actual production assets, so the actual assets on which reliability depends on are never scanned. We are, simply, leaving these assets at risk by not scanning them for vulnerabilities on a more frequent basis. Vulnerability scanning is a core best practice for Information Security. When 85 percent of breaches (Verizon DBIR) start with a known, published vulnerability, there's plenty of evidence to suggest that finding and patching vulnerabilities results in material risk reduction. If you believe that ICS devices don't have just as many vulnerabilities as every other software or hardware asset out there, then you should spend a little time looking at the evidence. These devices are in the same shape as every other technology out there with regards to vulnerabilities, yet we're treating them substantially differently.
It's Not Really That Easy
The reality is that for all the simple rhetoric about how we should be running vulnerability scans on ICS devices, it's not as simple as just turning on the scanners and having at it. IT and OT are not the same thing, and there are very valid reasons that we've ended up with the level of caution we have today. The two primary reasons are related to each other, in fact. Device Interactions Very simply, no one wants to scan ICS/SCADA devices with vulnerability scanners because they tend to cause outages. There's a kind of Pavlovian response here. We're habituated to associate outages with vulnerability scanning anywhere near a control network. This response isn't unprecedented. The situation with ICS systems is akin to how scanning was perceived in the early 2000s by IT, and it's largely changed in that arena. The change has come in part from improvements in vulnerability scanning itself, from a greater understanding of the risks involved in leaving systems vulnerable, and from more resilient IT. Lack of Vulnerability Research The chief change in the vulnerability scanning technology itself came from an explosion of vulnerability research, which is a commodity sorely lacking from the ICS/SCADA world today. While there's an easy to understand causal relationship between vulnerability research and published vulnerabilities, there's a less obvious connection between the research and the actual scanning. As vulnerabilities are discovered and reported to system vendors, those vendors not only patch the specific vulnerabilities found but also learn to avoid them in the future and make improvements to security and stability in more general ways. As researchers learn more about categories of systems, they provide a similar feedback loop into the scanning technology itself, resulting in more effective, accurate and safe scanning techniques. In essence, we're at the beginning of both of these feedback loops in the ICS space.
Changing the Course
The single best way to improve this process is to promote and fund vulnerability research into ICS and SCADA systems. In altering a cycle, the hardest part is often determining where in that cycle to intervene. I'm suggesting that funding vulnerability research is the best way to influence the dual cycles around vulnerability scanning frequency and patched vulnerabilities. Here's an illustrative image:
By funding research, we'll drive vendors to build more product-safe scanning techniques. If you're in OT and your first reaction is to scoff at this idea, that's totally understandable. I would only say that while it may not be realistic to scan OT environments now, the best way to guarantee that it's never realistic is to not admit the possibility at all. At the same time, vulnerability research ends up alerting vendors to produce patches. In other words, funding vulnerability research has two benefits. If you're a consumer of any system that gets deployed in an ICS environment, you should ask your vendors how they test for vulnerabilities in their own products. Don't simply accept a rote marketing answer either. Ask about frequency and depth of testing. Ask about how they accept vulnerability reports from other sources and whether they have an SLA around response and patches. If you're a vendor in the ICS space, ask yourself these questions before a customer surprises you. If you'd like to know about how Tripwire vulnerability management works in sensitive environments, let us know.
