The News from RF

I have a confession to make: Even though Reliability First Corporation (RFC) changed their name to ReliabilityFirst (RF) a couple years ago (perhaps more than that), I have continued to refer to them as RFC in my posts. This was a grievous sin, and I have decided to come clean on it in front of all the world. I will refer to them simply as RF from now on.

On October 1 and 2, 2015 I attended RF’s CIP v5 Workshop outside of Cleveland. As with the other two RF CIP v5 workshops I’ve attended (one remotely), I found this an excellent event. Below are some of the interesting things I learned (you can find all of the presentations here). I want to spend some time describing in depth one important discussion that occurred during the meeting, but I’ll address that in a separate post.

The points below may be helpful to you, regardless of your region. However, as I say very regularly now, for any questions regarding the CIP v5 requirements or enforcement, you need to address them directly with your region. Your mileage may vary.

Low Impact Update (Mike Ketchens and Scott Pelfrey)

Mike and Scott gave a good presentation on Lows. In a question, I pointed out that, since a Low impact asset is defined as one “with Low impact BCS”, this implies that an asset that isn’t High or Medium impact - but that doesn’t have any cyber assets at all - won’t be Low impact either. It will simply be “no impact” and will be out of scope for CIP v5. I asked if this was RF’s understanding; the answer was yes.

I followed up this question by asking whether, if there are cyber assets in an otherwise Low impact asset and the entity wants to go through the exercise of demonstrating there are no BES Cyber Systems among those cyber assets, this asset would also end up being “no impact” and out of scope for v5. The answer to that was also yes.

Of course, if you are claiming “no impact” assets, you need to be prepared to prove they are so in an audit.

2016 CIP Monitoring Plan (Ray Sefchik)

RF will not require an annual self-assessment for CIP next year, as they normally do. This is because the self-assessment is usually done in Q1. Since CIP v5 won’t come into effect until Q2, it doesn’t make sense to have entities assess their compliance in Q1. That assessment would presumably cover v3 compliance, and that won’t be relevant after 4/1/16. The attendees were quite happy to hear this. My guess is the other regions may adopt this policy as well, but be sure to check before you take this off your calendar.

CIP v5 RSAWs (Lew Folkerth)

Lew has been very active in the ERO program to develop the v5 RSAWs, and provided some great insights on the new RSAWs (for the ten CIP standards you’ll be audited on, three v5 and seven v6). You can find these by going here, and then picking out the CIP standards with “-5.1”, “-5”, “-6” and “-2” in front of them (no one can accuse NERC of spending unnecessary resources making it easy to find things on their web site. I’ve often said I know of only one surefire way to protect Critical Infrastructure Information: post it on the NERC site. Al Quaeda will never find it there!).

These were some of Lew’s more interesting points (interesting for me, that is. If you don’t find these interesting, get your own blog).

• The RSAWs are now organized down to the Requirement Part. This will allow auditing of compliance with a particular part, rather than the entire requirement.
• The Compliance Narrative is the most important part of the RSAW. It’s there so the entity can tell what they did to comply, and why. Lew suggested a narrative of 1-2 pages was appropriate for each Requirement Part. You might look at this and this post for some guidance from Lew on what might be required in the narrative - if the requirement in question is ambiguous or depends on a missing definition.
• NERC and RF are interested in outcomes, not documentation of what the entity did to comply. The example Lew provided was the case where a patch won’t install and the entity needs to take another action to mitigate the threat – close a firewall port, put in an IDS signature, etc. The outcome being measured will be whether or not the threat was mitigated; what is done to mitigate it is less important.[i]
• Lew pointed out that there are a number of “implicit requirements” in CIP v5. These are things that the entity needs to do to be in compliance, which are not specifically identified in the actual Requirements. Lew gave the example of the implicit requirement to “verify the identification of any associated PCAs” (this requirement never appears in v5, but the entity obviously needs to identify PCAs). RF isn’t just looking for a list of the PCAs, but wants to know how the entity verified that every Cyber Asset in the ESP had been identified. Another example is identification of EACMS and PACS. The entity is never explicitly required to identify these, but they obviously have to do so to be in compliance - and they need to be able to show that they haven't missed any EACMS or PACS systems.
• Of course, you can’t find out about these implicit requirements by reading the RSAWs, since they only deal with the explicitly-stated requirements. A questioner asked Lew if RF would publish a list of the implicit requirements. Lew said he’d look into doing that. I certainly hope he does – it is greatly needed (and not just in RF).

CIP-005 Audit Approach (Bob Yates)

The highlight of this presentation for me was when Bob said that no PVs will be issued for “improper” identification of BCS as having or not having External Routable Connectivity (ERC). Of course, given the huge amount of controversy over what ERC means (and for a great example, see my last post. When I first wrote the post, I reported what two auditors were saying about ERC, but I had to rewrite that section two days later, before I published it. This was because both of the auditors had refined their positions as we discussed the subject in emails. I’m sure I could do posts on ERC from now ‘til Doomsday and I still wouldn't exhaust that subject) and the lack of any definitive guidance from NERC on the issue, it’s hard to see how they could have any other policy. All the same, it’s good to hear RF at least explicitly acknowledge this – and it sounds like this may be the case ERO-wide; as usual, consult with your Regional Entity. I am sure the same policy will apply to CIP-002 R1 as well, since the ambiguities in that requirement are even more intractable than those in ERC.

A questioner asked whether an entity needs network diagrams to document ESPs. Bob’s answer was that they are not required, but they are probably the best way to communicate what the ESP covers to the audit team. In other words, the audit team won’t appreciate it if they’re not given diagrams, but have to rely on some verbal description of the ESP.

CIP-007 Audit Approach (Todd Thompson)

Todd Thompson addressed the monster requirement, CIP-007. After Todd’s presentation, a questioner asked if an entity must upgrade their firmware if the upgrade will assist with compliance – for example, it will enable longer passwords – given that firmware upgrades can sometimes lead to unanticipated issues. Todd answered that the entity needs to test to make sure the upgrade won’t cause a problem. If it does, they don’t need to apply the upgrade, but they do need to document why they couldn’t apply it.

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

---

[i] An emphasis on outcomes, not the process by which they were achieved, sounds wonderful and is a big hot button for NERC – mainly because in theory it should reduce the documentation requirements. However, as the previous bullet point alludes (and as I’ve discussed in many blog posts, including the two linked in that bullet point), the many ambiguities in CIP v5 require a lot of documentation just to show why the entity chose the approach it did for that particular requirement. In fact, the amount of documentation required for CIP v5 will be at least several times – and perhaps much more than that – what was required by v3. My own guess is CIP v5, if done right, requires somewhere between 5 and 25 times the documentation required for v3; and this isn’t even considering that most entities have more systems in scope than under v3, which will of course lead to the need for even more documentation.