Wednesday, April 6, 2016

What Products are Compliant with NERC CIP?

I have heard there are a few vendors that say their products are “NERC CIP Certified”. Of course, I find this assertion to be amusing, since there are obviously no product certifications issued by NERC or any party authorized by them. I have heard more often that vendors refer to their products as “NERC CIP Compliant”. This is equally mistaken, but requires a little more discussion.

To be succinct, there is no way a product can be compliant or not with NERC CIP. If you think about the requirements in CIP v5 that have anything to do with cyber assets directly, they are mainly the requirements in CIP-007, but also those in CIP-005, CIP-009, CIP-010 and (perhaps) CIP-011. None of these requirements mandate that products should have particular features. Rather, they all say that the entity should do something involving their BES Cyber Systems – restrict ports and services, protect against malware, implement logging and alerting, control access, etc. None of these are product features.

But can it be said that some vendors’ products will make it easier to comply with a particular requirement than other vendors’ products, because of the features they offer? Strictly speaking, no. The CIP requirements all take care not to be seen as mandating that the entity needs to buy products with particular features, or replace products that don’t have those features. For example, if a particular cyber asset can’t do logging, CIP-007 R4 doesn’t require the entity to replace it with one that does; the words “per device capability” in R4.1 (as well as in other requirements) make that clear.

However, there is one way in which some requirements do nudge entities toward purchasing products with certain desired features, and that is Technical Feasibility Exceptions. While TFE’s are specifically designed to allow entities to continue using products that don’t have particular security features, the fact that a product would require one or more TFEs (which require a lot of work) should be enough to make an entity think twice about purchasing it – and maybe encourage them to move it up on their list of devices to be replaced, if they already own it.

For example, CIP-007 R5.1 says that BCS (and PCAs, etc) should have “a method to enforce authentication of interactive user access, where technically feasible.” This means you can still keep using that 20-year-old RTU that doesn’t allow for authentication, but you’ll pay the price for this by having to go through the trouble of submitting and maintaining TFEs. So if a vendor wants to say that their product will help you comply with CIP-007 R5.1 because it supports authentication, I guess I won’t object to that (although I’m not sure what products don’t support authentication nowadays).

But this is a long way from saying a product is “CIP compliant”. 

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.


  1. I wish I could laminate this and hand it to every sales person and RFP customer I run into. We always argue that we may have ways to assist you with compliance, but absolutely zero technology will make you compliant. Anyone that tells you otherwise is either lying or clueless and probably a combination of the two.

  2. Thanks, Dave. I would tend to the clueless explanation, but that may be overly generous.