The NATF Criteria, Part I

CIP-013 compliance is hard to figure out, I’ll freely admit. The main reason for this is quite clear: The standard reads more like an exercise in haiku than a mandatory standard with huge potential fines for violation. There are no more than five sentences in the entire standard, and it may be fewer than that.

In theory, this should be welcome news to people at NERC entities that are tasked with complying with CIP-013. After all, since a NERC entity can only be held for violation of the strict wording of the requirements, and since the three requirements give very little information about what must be done to comply with them (my favorite is R2, which reads in its entirety “Each Responsible Entity shall implement its supply chain cyber security risk management plan(s) specified in Requirement R1”), CIP compliance professionals should be jumping for joy at the idea that they finally can decide for themselves the best way to mitigate BES cyber security risks.

In practice, of course, just the opposite is happening with many people, as I discussed in this post last year. People who are used to the very prescriptive NERC CIP requirements are desperately seeking something…something!...that they can hang their hats on as they develop their CIP-013 plans. Something that tells them what should be in a good plan, and which the auditors are likely to be in agreement with come audit time.

This is why I and many others were happy when the North American Transmission Form put out their spreadsheet “Cyber Security Supply Chain Criteria for Suppliers” last summer. While this isn’t official NERC guidance, it does provide a very good set of questions that a NERC entity can ask of its suppliers (and like everything else in CIP-013, it could be useful for any electric utility anywhere, not just those in North America that happen to be subject to CIP-013) – which is another way of saying that the document identifies a number of risks that can be found at many suppliers.

Since CIP-013 R1.1 requires the entity to “identify and assess” supply chain cyber security risks to the BES, I’m sure some people consider the Criteria to be a complete listing of all the risks that need to be mitigated in R1.1. However, those people are mistaken. There are lots of risks that IMO need to be considered for inclusion in any CIP-013 plan, including some that NATF never intended to address, and some they may have intended to address, but missed.

So I consider the Criteria to be one among a number of documents (NIST 800-161, NIST 800-53, the DoE Cybersecurity Language for Energy Delivery Systems, ISO 27001, NISTIR 7622 and more) that should be scoured for threats, vulnerabilities and mitigations that are applicable to ICS and to CIP-013 in particular. Over the past year of working on CIP-013 with clients, I and my clients have compiled spreadsheets of these - as well as their interrelations; I just recently added the NATF Criteria to them (some were already in my documents, although many Criteria weren’t). I and my clients are constantly adding to, removing, and refining the entries in the spreadsheets (which I share among all of my clients, since there’s nothing in them that’s proprietary to one client).

What do the Criteria do, and what don’t they do?

There is one big trap that the NATF Criteria avoid, for the most part: Like all of the standards, CIP-013 applies to control systems, not systems that are used to store and/or process information. The biggest problem with almost all frameworks of cybersecurity risks (or of cybersecurity risks in general) is that they are focused mostly (or even entirely) on information systems. This means they focus a lot on threats to confidentiality (personal data privacy, web site security, lack of encryption of data at rest, protection of intellectual property, etc.), and very little on threats to availability, which is of course the number one concern with control systems. On the other hand, the NATF Criteria were written by people who understand the paramount importance of availability, so almost all of the Criteria identify risks that should definitely be considered by anyone developing their CIP-013 plan.

However, the Criteria don’t in any way cover the entire set of risks that should be considered – or even a representative sample of all the different types of risks. I don’t think the people who drafted the Criteria ever thought these would be considered to be the entire set, but I know some entities are considering them to be just that. Here’s what the Criteria don’t include:

First and perhaps most importantly, they don’t address any risks that apply to the entity itself. For example, FERC talked a lot in Order 829 about installation risks. FERC issued the order about seven months after the first Ukraine attacks were announced, and they focused on the attacks in the Order – pointing out that if the Ukrainian utilities hadn’t installed their HMIs on the IT network, it would have been much harder for the attacks to have succeeded. FERC wanted the new standard to ensure that the risk assessment that utilities do when starting a procurement always considers risks of insecure installation. And R1.1 specifically includes that word, to indicate installation is one of the areas of risk that must be included in the entity’s supply chain cyber security risk management plan.

And guess what? Installation isn’t a supplier or vendor risk; yet one rarely hears anyone in the NERC community (except for me, since I enjoy being the skunk at the garden party, in case you never noticed) talking about anything but vendor risks in CIP-013 – and I’m sure many if not most CIP compliance professionals would be surprised if you told them that they need to consider risks introduced by their own organization, not just by vendors.

I believe that most NERC entities do installations themselves, but even if they do sometimes have a supplier or vendor do that work, it’s always the utility’s responsibility to make sure it’s done properly, not the vendor’s. I really doubt any NERC entity – or any responsible organization, period – would just wave toward their data center or substation and tell the vendor “Just install the stuff there and don’t bother me with any of the details. I’ll check in with you in a few hours to see how you’re doing.”

And there are a lot of other risks that apply to your organization, not your vendors. For example, does your supply chain department have a policy of always buying products at the lowest possible price, so that when Mr. Kim’s Discount Routers in Pyongyang, North Korea sends them an email offering knock-off Cisco routers at incredibly low prices, they don’t hesitate a minute before placing the order? Probably not, but are there specific guidelines for when cyber risk needs to be considered over price and when it doesn’t (if discount paper clips were being offered, this deal might be worth considering)? This is another example of a risk that applies to your organization, not to your vendor.

But even when we get to true supplier/vendor risks, there are a number of important risks that aren’t listed in the Criteria at all. These include:

1. Risks due to use of open source software;
2. Risks due to third party software that is embedded in the software package that the utility buys (I read recently that 80% of the code in commercial software was really written by third parties. This sounds pretty high, but even if it’s 50%, that’s still a serious issue. What’s even worse is that the developer may not even know what parts of their code are due to third parties – and they almost certainly don’t know which parts of those third parties’ code are due to fourth parties, etc. The Heartbleed vulnerability in OpenSSL was a vivid example of the problem: Many software suppliers had no idea whether their code was vulnerable or not, since so much of it came from third parties);
3. Lack of multi-factor authentication for the vendor’s own remote access system – which, according to DHS’ briefings in the summer of 2018, allowed the Russians to penetrate over 200 vendors to the power industry;
4. Lack of adequate security in a software supplier’s development environment, or in a hardware supplier’s manufacturing environment – including adequate separation of development and IT networks, and lack of multi-factor authentication for access to the development environment; and
5. Inadequate training and other measures to mitigate the risk of ransomware, and measures to prevent any ransomware attack from being automatically spread to your network (including isolation of machines used for remote access to your network).

This is a lot. Do you have to mitigate all of the risks you identify? No. CIP-013 is the first NERC standard (and certainly the first CIP standard, with CIP-014 being a possible exception) in which the NERC entity is explicitly allowed to accept risks. And keep in mind that you probably have the majority of these risks – both those that apply to your vendors and those that apply to you – already mitigated by various policies and procedures that either you or your vendors have implemented.

But you need to try to consider all of the important supply chain risks, so that you can concentrate your resources on mitigating those risks, rather than unimportant ones. Remember, you’re not required to spend any particular amount of resources complying with CIP-013. But you should always aim to mitigate the most possible risk, given the resources you have available.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.