What NERC CIP Gets RightI'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
It's Not Really That EasyThe 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 CourseThe 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: