Thursday, May 24, 2018

An Auditor Disagrees with me, and makes some good Points about Justification



In my last post, I discussed an issue that a friend of mine had brought to my attention recently: the fact that NERC may be expecting entities with Low impact assets to show that all electronic access permissions in place (i.e. firewall rule entries) at Low assets were “justified”, rather than simply “necessary”, as required in the wording for CIP-003-7. I quoted from an email by Mike Johnson, who pointed out that there really is a difference between the two words (I had opined in the post that there wasn’t much of a difference). I accepted his argument.

However, I then went on to say that this didn’t really matter, because of a six-word phrase in the requirement: “as determined by the Responsible Entity”. Whatever the meaning of “necessary” in the requirement (i.e. whether or not it is the same as “justified”), it shouldn’t matter (or so I reasoned), because in the end it was up to the entity to determine what is necessary. I recommended that NERC entities still take the conservative approach and assume they have to justify all access permissions, but I also pointed out that if this would be a huge burden, you might want to talk to your friendly local NERC Regional Entity and ask them what they thought of this.

However, the next day I received an email from an auditor who has appeared many times in the august pages of this blog, although of course never by name. He had the nerve to disagree with me, on both points no less! Regarding the first point, he said (of course, basing his argument on pure logic, not anything having to do with CIP in particular):

“If the access is truly necessary, then it is justified.  Note the phrase in the definition of “justified” that states “marked by a good or legitimate reason.”  If the access is needed or essential (elements of the definition of “necessary’), then it is marked by a good or legitimate reason.  If there is no good or legitimate reason, then the access is not necessary.”

I really can’t argue with that. Regarding the second point, he said:

“Where the “as determined by the Responsible Entity” idea falls apart is in the case where the access is really not necessary, as per the definition.  A common example is where the Responsible Entity configures access for convenience (e.g., it is easier to grant access to everything in the ESP rather than the three hosts that actually need such access permitted).  Under administrative law, there is a concept of reasonableness.  Access deemed necessary by the entity but for which the entity cannot demonstrate the essential need is not reasonable.  We have seen this type of access and we have written PVs that have been later upheld by Enforcement (Note from Tom: He is talking here about CIP-007 R1, which also includes the proviso that the entity determines what is “needed”, not the auditor – although the auditor did point out separately that this requirement, which applies to High and Medium BES Cyber Systems, necessarily requires a higher bar than does CIP-003-7, which only applies to Lows).  Your idea that this is not a big problem because the auditor can only expect to see that you have documentation is invalid.”

In a subsequent email, the auditor elaborated on this statement in the following quote. He also provided some good general advice for preparing for audits:

“What I am saying is that if the entity cannot make a good case for why the permitted access is necessary (i.e., some sort of reasonable justification), then it has not met the Requirement.  Please understand that the auditors are looking for obvious concerns and are unlikely to get down into the weeds on a line-by-line basis.  We just do not have the time to perform that level of scrutiny, even with the automated tools we use.  But we do expect the entity to know why the rule is present, what the rule allows, and why that permitted access is necessary.  If all we see is documentation describing what the port is used for (to use 1433 – MS SQL in your example) and not why port 1433 needs to be permitted to everything in the ESP, the auditor is going to investigate further.  If we see Class C, Class B, Class A, or, heaven forbid, “IP any any” in a rule, we are going to investigate.  It does not mean we will automatically find non-compliance, but we will not simply accept the broad access as being “necessary” on the entity’s word without further discussion.  If we see port 80 permitted from the WSUS server into the ESP, we are going to investigate (this one is a bit [OK, a lot] harder for the entity to justify given the way the WSUS server works).  Don’t just point to the Microsoft or other vendor documentation that lists all of the ports that the software uses in some fashion.  Demonstrate that you know how the port is used by the software.  If, for example, you permit every port listed in the Microsoft documentation for Active Directory, you will permit 98% of all available ports, turning your firewall into, and this is a direct quote from the Microsoft documentation, Swiss Cheese.  Sadly, something we see all too often are rules that are left over from previous configurations that are no longer needed.  This is a basis housekeeping (cyber hygiene) issue.  Entities are good are taking the necessary coordination and steps to get a rule put in, but not so good coordinating when the rule is no longer needed.  We see way too much stovepipe operations where one functional group owns the servers and another functional group owns the access control devices – and they don’t regularly talk with each other.”

  
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. And if you’re a vendor to the power industry, TALLC can help you in various ways, including developing marketing materials, delivering webinars, etc. To discuss this, you can email me at the same address or call me at 312-515-8996.            
               


Sunday, May 20, 2018

The Difference between “Justified” and “Necessary”



At the end of this recent post on the difference between the electronic access control requirements in CIP-003-7 and CIP-003-6, I recounted a concern that a friend of mine had raised, regarding the difference between the words “necessary” and “justified”. To refresh your memory, the electronic access control “requirement” in CIP-003-7 begins with: “Permit only necessary inbound and outbound electronic access as determined by the Responsible Entity…”

The friend had pointed out to me that FERC had noted, in their Order 843 approving CIP-003-7, that “NERC also clarifies (Tom’s note: FERC is referring to NERC’s petition to FERC requesting approval of CIP-003-7) that responsible entities will be required to ‘document the [business or operational] necessity of its inbound and outbound electronic access permissions and provide justification of the need for such access.’” (my emphasis). Since the requirement says “necessary”, not “justified”, he was concerned that NERC had inadvertently made compliance with the new requirement – which of course applies to all Low impact assets – much harder, because justifying something is quite different from merely saying it’s necessary.

Although I didn’t say it in the post, I wondered if there really was a difference between “necessary” and “justified”. As I often do, I was having an email conversation with Mike Johnson and asked him if he thought there was a difference. He said (and I’m paraphrasing his email a little):

“Doing a lookup of the two words, you can get:

Necessary – required to be done, achieved, or present; needed, essential

Justified – having, done for, or marked by a good or legitimate reason

Based on the above they are different.

What I have heard from the Regions I follow (WECC, SPP, TRE, RF) that provide good guidance is that “necessary” communications (ports and services) need to have some type of justification.  You cannot just say they are needed, without knowing why.  For the why, I have seen and recommend you provide the following:

Technical justification – This is the easier one, since you just have to point out that it is required by the technical setup of the communications.  Say for SQL this can be ports 156, 1360, and 1433 over TCP and/or UDP, to name a few.  You have no idea who you are communicating with, just that the communications channel is open.

Operational justification – This one is more difficult, since you need to know who you are communicating with and why.  This should be another computer system or systems, and the application on those systems.  Let’s take the example of port 1433, which is for MS-SQL. You would need to know the systems your MS-SQL is communicating with, what applications on that system(s) is using the MS-SQL database, and what is the purpose of the usage.  One example could be a SCADA HMI workstation that is communicating with a SCADA server over 1433.  The SCADA server could be housing the database for the telemetry of a generation station; the HMI workstation is using 1433 to get the current telemetry to display and act on the database data.  The “operational” justification for the communication could be something like:

MS-SQL communications between SCADA HMI workstations and SCADA database servers is used to acquire real-time telemetry data from the servers for operator console displays and processing based on SCADA HMI programming.

The above indicates what is being communicated technically and why it is required to verify it is “necessary”.”

So I’m satisfied that there is a difference between the two words; in other words, if the regional auditors are going to tell NERC entities they need to justify access permissions, not just show they are necessary, the entities should push back and ask where in the standard the word “justify” appears (of course, the answer to that question is “nowhere”).

On the other hand, I still doubt that this will be a big problem, because of the last part of the CIP-003-7 requirement that I quoted in the first paragraph: “as determined by the Responsible Entity…”  This certainly seems to indicate that an auditor can’t argue with you about whether or not opening a particular port is necessary (or justified) – all they can legitimately do is make sure you have a documented reason.

On the other other hand, I’ve heard that some at NERC were questioning whether this phrase can even be included in a standard, since in theory the auditors are the ones who are supposed to make that sort of decision, not the entity.

I’ll stop here, because I’m out of hands. This is, of course, a very typical CIP compliance question: There is no straightforward answer. Given that, you would be prudent to take the more conservative interpretation – which in this case means assuming you have to provide justification for access permissions, not just assert they are necessary. But if that course is too difficult or burdensome, then you might want to contact your region and ask the question they’ve heard many times before: “I have a friend at a utility down the street from mine, who was wondering….”


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. And if you’re a vendor to the power industry, TALLC can help you in various ways, including developing marketing materials, delivering webinars, etc. To discuss this, you can email me at the same address or call me at 312-515-8996.            
               


Wednesday, May 16, 2018

Indegy - here's the link!

Jayson Roysdon pointed out to me that, in my last post regarding Indegy (which has already drawn a lot of hits!), the link to Indegy's web site at the beginning didn't work. I'm sitting in a foreign airport and am having trouble posting the actual link, but if the above doesn't work, you can find it by going to indegy.com

I also recommend downloading the power industry brochure linked at the end of the post!

A Company you should Look at



One of the clients of Tom Alrich LLC is a company called Indegy. I already mentioned them in a previous post and said I thought you should look at what they have to offer. Now I’m going to provide more information about them, since I honestly believe they have a unique technology that will make your generating stations and substations not only more secure but safer. Full disclosure: I developed this post while being retained by Indegy.

A little background on Indegy. They’re an Israeli startup (with their US headquarters in New York) that received major funding from several US VCs, as well as one of the founders of CheckPoint and an early investor in Palo-Alto Networks. Indegy was founded by three veterans of the elite cyber security units of the Israeli Defense Forces. Their mission is “to bring visibility and control to critical infrastructure and ICS networks.”

They accomplish this by doing two things that no other ICS cyber security vendor does:

1.       Look deeply into the “control plane” of controllers (such as PLCs) to track and notify on changes to their configuration, firmware and control logic. This “meta-language”, over which the engineering maintenance lifecycle of controllers is done, is proprietary to each manufacturer. It varies not just per control vendor, but often per model / product series. Thanks to Indegy’s ability to granularly parse the engineering station commands, they top the usual anomaly detection techniques that other players in this space offer by using a deterministic, policy-based detection approach.
2.       Safely communicate with the control devices using the vendors’ native communication protocols. This allows Indegy to get much more data about the control devices, in order to increase the user’s visibility into their asset inventory. Furthermore, Indegy uses this data to periodically verify the integrity of the devices, by making sure their configurations and code version don’t change from day to day.

Altogether, Indegy can do a lot to secure industrial networks that frankly nobody else can. For example:

·         Indegy fully logs all ICS activities, including controller engineering activities like logic updates, configuration changes, firmware uploads/downloads, and of course anomalous changes made to set points.
·         While PLCs, RTUs and DCS don’t have inherent access control capability, Indegy allows the user to set policies on who has access, when they can have access and what they’re allowed to do. If an unauthorized person tries to access a controller, you will receive an alert.
·         Indegy regularly – the interval is user-configurable – queries each controller and downloads its configuration and code. It compares this with the previous day’s file, notes any changes, and alerts you with information on those changes; this allows you to catch suspicious changes and investigate or reverse them. Conventional anomaly detection solutions can’t do this.
·         Indegy identifies and alerts on malicious code activities on the control network, including malware propagation, abnormal communications, network attacks on controllers and direct attacks via connected compromised laptops.
·         Indegy identifies and logs any remote access to ICS assets. Furthermore, Indegy alerts in real time if the access is new, unauthorized or both – and provides detailed information on the connection. This functionality enables security staff to detect perimeter breaches and ensure system safety. Note this applies to both interactive and “machine-to-machine” remote access.
·         If someone makes a change to a PLC directly, using a serial cable or USB device, Indegy will identify the changes and raise an alert.
·         Indegy maintains a continuously-updated list of the version numbers of all software and firmware installed on your PLCs and compares this regularly against a list of known vulnerabilities (NVD / ICS-CERT data). Indegy notifies you whenever a new vulnerability appears that applies to a software or firmware version installed on one of your devices.
·         Indegy alerts on changes spotted in the asset inventory – new devices that are being connected, as well as devices that disappear from the network.
·         Indegy alerts on anomalous write commands made to SCADA tags, including any that are outside of an acceptable range.

I know some of you have been thinking about how Indegy can help you comply with NERC CIP, and the answer is “a lot”. Indegy has a good Security Guide that discusses benefits both for power industry cyber security in general and for CIP compliance in particular. You can download the document by going here.




Sunday, May 13, 2018

Question: What’s the Difference between CIP-003-7 and CIP-003-6?



Answer: 1

OK, OK. This would have been much better for my annual April Fool’s post (which I missed this year, for the first time in five years). In fact, that answer could have been the whole post!

But let’s ask the question more specifically: What is the difference between the Low impact electronic access control requirement in CIP-003-7 - the standard that was just approved by FERC and will come into effect on January 1, 2020 - and the same requirement in CIP-003-6, which was going to come into effect on September 1, 2018 but now sleeps with the fishes?

I must confess that I have heedlessly enslaved untold billions of electrons in discussing this topic in a number of posts – none more prolifically than in this post from early November 2016, right before the second (and final) ballot approving CIP-003-7 – yet I have never once set out to address this topic in a single post, despite always saying that the answer to the question is very simple (which it is). So now I will remedy that omission. However, I’ve decided the best way to describe the difference is to discuss the history of how the two versions were developed. In addition to doing that, I will discuss at the end of this post what might be a serious interpretation question – for which as of the moment there might not be a good answer.

When FERC approved the CIP version 5 standards in November 2013, they ordered four changes. One of those changes was to add some meat to the Low impact requirements. In v5, the only requirement for Lows was CIP-003 R2, which required entities with Low impact assets to have four policies, including one for electronic access control. But nothing was said about the content of those policies or any steps to implement them; FERC decided there needed to be substantive requirements in each of the four areas, not just policies. All of these changes were drafted by a new SDT and became CIP v6

The CIP v6 standards were approved by FERC in January 2016. The v5 requirement for owners of Low impact assets to have four policies was moved from CIP-003 R2 to R1, where it was combined with the policy requirement for High and Medium impact BES Cyber Systems. R2 was now rewritten as a plan-based requirement[i], calling out Attachment 1 to provide details on what needed to be in the plan(s).

Section 3 of CIP-003-6 Attachment 1 specified that, when a Low impact asset had LERC - Low impact external routable connectivity, as defined in the NERC Glossary at the time - then the NERC entity owning the asset had to “implement a LEAP to permit only necessary inbound and outbound bi-directional routable protocol access”. Of course, LEAP stood for Low impact electronic access point, which was also defined in the NERC glossary. The compliance date for this requirement was September 1, 2018.

However, when FERC approved CIP v6 in January 2016 in Order 822, they ordered that NERC make three further changes to the standards. First, they ordered NERC to develop a standard to protect communications between Control Centers (now being balloted as CIP-012). Second, they wanted there to be a requirement to protect Transient Electronic Devices and Removable Media used at Low impact assets (this new requirement was balloted and approved at the same time as the revised electronic access control requirement, and is included in CIP-003-7 as Section 5 of Attachment 1 of R2[ii]).

Finally, FERC ordered NERC to clarify the meaning of the word “direct” in the definition of LERC­­, which read “Direct user-initiated interactive access or a direct device-to-device connection to a low impact BES Cyber System(s) from a Cyber Asset outside the asset containing those low impact BES Cyber System(s) via a bidirectional routable protocol connection.” FERC was concerned that some entities would interpret the word to mean that simple protocol conversion breaks “direct” access and thus exempts such cases from the requirement, since the definition of LERC isn’t met.[iii]

As usual, the changes FERC ordered couldn’t be incorporated into the standards they had just approved – CIP v6 – but needed to be in new versions of the standards. So NERC convened a new standards drafting team in the spring of 2016 called the CIP Modifications SDT. They were tasked with drafting not just the three changes FERC had ordered, but others as well (of course, the team continues working today, and shows no sign of winding up any time soon).  However, the first task they took up was addressing FERC’s concern about “direct”, since FERC had set a one-year deadline to return a revised requirement or definition for them to approve.

I attended the meeting in June 2016 in which the SDT took up this question, and wrote about it in this post. I should first point out that I was very skeptical, in my post on Order 822, that any NERC drafting team would ever be able to come up with an acceptable dictionary-style definition of “direct”. I was thinking the only workable way to “define” LERC was to provide a set of use cases for when there is and isn’t LERC; but I didn’t see how a NERC definition could legally consist of just a set of use cases.

However,  I was very pleasantly surprised when the team decided at their June 2016 meeting to do a complete end run around the word “direct”, by a) eliminating the definition of LERC altogether and incorporating a much broader and objectively-verifiable definition in the requirement itself; b) making the requirement a completely objectives-based one; and c) developing use cases in the form of ten “concept diagrams” – but actually designated as Reference Models 1-10 - showing ways in which the requirement could be complied with (these are found starting on page 36 of the Guidelines and Technical Basis section at the end of CIP-003-7. I want to point out that the SDT clearly stated on page 35 that “This is not an exhaustive list of applicable concepts”).

In the new requirement – which is of course the CIP-003-7 requirement approved by FERC a few weeks ago - the entity has to take appropriate steps to mitigate the threat posed by the presence of any external routable connectivity at a Low impact asset. The goal is to achieve the objective of the requirement, not to use a particular means to do so (of course, in the v6 version, the requirement prescribed the means to address the threat posed by LERC, which was a LEAP. In every case where there is LERC, the entity had to implement a LEAP). In my opinion, all CIP requirements should be written in this way.

What is the practical difference between the “v6” and “v7” versions of the requirement? The only difference in practice is that the NERC entity now has more options on how they can mitigate the risk posed by external routable connectivity crossing the boundary of a Low impact asset. They have at least ten options, corresponding to the ten concept diagrams, but the entity is now explicitly allowed to come up with another solution as well, as long as they can convince an auditor that it is an equally effective one.

Most importantly, the entity can still use a firewall (although the term LEAP was also discontinued) to comply with the requirement (this solution corresponds to Reference Model 2). They now have to describe it differently in their documentation, but they don’t have to do anything different in their deployment. Yet despite this new freedom, there was a storm of opposition to the revised requirement, and it was voted down decisively in the first ballot in 2016. The SDT made some minor tweaks and the new requirement passed on the second ballot. I attributed (and continue to attribute) the fierce opposition to the fact that a) people simply didn’t understand what the SDT had done, and b) the NERC community in general was profoundly suspicious of new CIP standards with any possible ambiguity – and therefore room for auditor judgement – at all, after the long, exhausting experience with implementing CIP v5 despite the many ambiguities in those standards, and with NERC providing guidance of various types, almost all of which was ultimately withdrawn. I doubt the new requirement would even have passed on the second ballot, were it not for the fact that the looming FERC deadline meant the NERC Board would have to draft and approve their own requirement, if the requirement didn’t pass on the second ballot; there would simply be no time for further balloting.

This is how we got where we are today. I suspect most NERC entities with Low impact assets will simply deploy a firewall in order to comply with this requirement. In fact, I would think almost all Low impact assets that have external routable connectivity would already have a firewall. So everything is rosy and I can conclude this post, right?

No, not yet. It turns out the hard part of complying with this requirement isn’t coming into compliance in the first place, but maintaining compliance thereafter. To understand this, you need to look at the wording in the CIP-003-7 requirement:

Section 3. Electronic Access Controls: For each asset containing low impact BES Cyber System(s) identified pursuant to CIP-002, the Responsible Entity shall implement electronic access controls to:
3.1 Permit only necessary inbound and outbound electronic access as determined by the Responsible Entity for any communications that are:
i. between a low impact BES Cyber System(s) and a Cyber Asset(s) outside the asset containing low impact BES Cyber System(s); 
ii. using a routable protocol when entering or leaving the asset containing the low impact BES Cyber System(s); and
iii. not used for time-sensitive protection or control functions between intelligent electronic devices (e.g., communications using protocol IEC TR61850-90-5 R-GOOSE).

I first want to point out that, even though this is worded very differently from the CIP-003-6 requirement, there is in fact no substantive change, except for the addition of the phrase that I have italicized in the sentence beginning with “Permit only necessary inbound and outbound electronic access…” Very similar wording – without the italicized phrase – was found in the v6 requirement: “permit only necessary inbound and outbound bi-directional routable protocol access…” The italicized phrase was put in the v7 requirement to preclude an auditor from saying that the entity had improperly either permitted or not permitted some access; the entity itself has final judgement on such questions.

But the fact that this wording didn’t change much between the two versions shouldn’t be allowed to obscure the fact that there is a fairly significant “requirement” buried in it: an entity with Low impact assets needs to document why particular firewall rules were implemented in the first place, as well as why any changes are “necessary”; and they need to do this for each of their Low impact assets. The auditor can’t second-guess why they made any changes, but the reason why any change was necessary will need to be documented. This is made clear in Section 3.1 of Attachment 2 of CIP-003-7, which provides examples of acceptable evidence.

However, a very knowledgeable friend of mine pointed out to me that in Order 843, FERC states (on page 28): “NERC also clarifies that responsible entities will be required to ‘document the [business or operational] necessity of its inbound and outbound electronic access permissions and provide justification of the need for such access.’” (my emphasis) They are quoting from NERC’s petition to FERC requesting that they approve CIP-003-7.

My friend points out that the word “justified” is nowhere in CIP-003-7; this was evidently an embellishment added by NERC to get FERC to feel comfortable with the new version. My friend was concerned because, as he put it, “There’s a big difference between “necessary” and “justified” when it comes to an audit!” I will admit that this does sound like a serious issue, but I don’t have enough knowledge to say whether this is a problem or not.

So the question is whether NERC may have inadvertently added a new implicit requirement to CIP-003-7 Attachment 1 Section 3.1: the requirement that the entity “justify” every rule implemented in a firewall at a Low impact asset, not just document why it was necessary. It seems to me that the words “as determined by the Responsible Entity” preclude this from being a problem, since the only justification the entity needs to show is that they determined a rule was needed. But I can see that this could be a big issue, simply because of the huge number of Low impact assets that are out there.

If you want to comment on this, either leave a comment below or email me at tom@tomalrich.com. If warranted, I’ll write another post on this issue. You have been warned.

  
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. And if you’re a vendor to the power industry, TALLC can help you in various ways, including developing marketing materials, delivering webinars, etc. To discuss this, you can email me at the same address or call me at 312-515-8996.            

[i] CIP-003-7 R2 was one of two plan-based requirements in CIP v6, the other being CIP-010 R4. These were the first two plan-based CIP requirements, which as you may know I now see as the wave of the future for all of CIP (see this post).

[ii] I must say I find it unfortunate that the CIP v6 SDT took it upon themselves to put what were actually parts of requirement CIP-003 R2, and put them into an appendix. This requires a lot of circumlocution whenever you try to refer to these requirement parts; more seriously, it leads to confusion about whether Attachment 1 is actually “guidance”, not part of the actual requirement. However, it is every bit as much a part of the requirement as if the contents of Attachment 1 had been included directly in R2. I certainly hope this won’t become a trend in the future.

[iii] FERC’s fear was rooted in the seemingly endless discussions in 2014 and 2015 about what “breaks” external routable connectivity for Medium and High impact BES Cyber Systems (I wrote about this in a series of posts, the first one being here and the last one here). The problem with those discussions, from FERC’s point of view, was that FERC no longer had any leverage, since they had already approved CIP v5 and the ERC definition. They were determined not to let this ambiguity continue if they approved the LERC definition as it stood at the time they approved v6. Indeed, I’ve been told by at least one auditor that the new treatment of Low impact external routable connectivity in CIP-003-7 has set the tone for the interpretation of ERC itself by the auditors, even though there has obviously been no official wording change or official interpretation of the definition of ERC).

Monday, May 7, 2018

About that CIP-013 Compliance Date….



In January, FERC issued their NOPR saying they intend to approve CIP-013. In my post at the time, I guessed that FERC would issue their Order approving the standard (and of course CIP-005-6 and CIP-010-3) in May, although it could still be a couple of months before this happens. In any case, I believe that the compliance date for CIP-013 will be either January 1 or April 1, 2020.[i]

However, in my post on the NOPR I said it looked like the date would be July 1 or October 1, 2019. I was basing this on FERC’s announcement in the NOPR that they were considering shortening the implementation period from 18 months (the period shown in the CIP-013 Implementation Plan, which was of course approved with the standards themselves) to 12.

However, I now consider it highly unlikely that FERC will order the implementation period be shortened. This is for four reasons:

  1. Of all the comments from NERC entities on CIP-013 that I read, all said the period shouldn’t be shortened. The reasons came down to pretty much just one: There is a huge amount of work that needs to be done to put in place a CIP-013 compliance program, especially at a large entity.
  2. I agree with that reason, and want to add two of my own. As I said in this post, the fact that CIP-013 is a completely plan-based standard (meaning it simply requires the entity to develop and implement a Supply Chain Cyber Security Risk Management Plan, with little or no guidance as to what should be included) means that literally everything depends on what you decide to put – and not put – in your plan. For this reason, before you start implementing the plan, you should ask your Region to review it[ii]. But if you wait until say two months before the compliance date, your Region may tell you to get in line and you’ll have to wait six months or so – they’ll most likely have a crush of other plans to review. So you’ll have to implement the plan without your Region’s input, since of course you have to have the whole plan implemented by the compliance date, not just drawn up.
  3. Here’s my second reason: I realize that you may be shocked – shocked! – to hear this[iii], but there is actually a fair amount of uncertainty regarding what CIP-013 means. I point to NERC’s recent webinar on CIP-013, where the entire webinar focused on R1.2, with no mention of how to comply with R1.1 at all. See this post (I have since received indications that NERC does indeed intend to enforce the whole standard, as mentioned in this post).
  4. But the last reason should be the clincher: If FERC orders the CIP-013 implementation period to be shortened by six months, it will at most result in an implementation date that is at most three months before the date that would result if they simply approve CIP-013 with the current Implementation Plan. That is because FERC can’t simply shorten the implementation period. They would have to approve CIP-013 but at the same time order NERC to develop a new Implementation Plan with a 12-month period. NERC would then have to develop a Standards Authorization Request and get it approved in a ballot; appoint a new drafting team (or most likely utilize the same team that developed CIP-013) and have them draft the new plan; conduct at least one ballot to approve the new plan; have the NERC Board of Trustees approve it; and finally submit the new Implementation Plan to FERC. FERC would then have to mull it over a little bit, then issue a new Order approving it. FERC would most likely give NERC 90 days to do this and NERC would almost certainly comply, but depending on the timing of when FERC approves the new plan, when it’s published in the Federal Register, etc., the resulting implementation date will at most be three months before what it would have been anyway, and more likely be the same date. So there will have been a huge uproar and lots of meetings, documents generated, votes tallied, etc. – and the result will be literally nothing. I simply don’t see this happening (in fact, I’m now surprised that FERC suggested it in the first place, although I must say it’s only recently that I’ve come to realize this).

Since I’m in kind of a snarky mood, and since this is something I’ve been meaning to write about anyway, I’d like to point out that my third reason above would probably not be a factor at all if FERC hadn’t decided to give NERC just one year to develop a supply chain security standard, when they issued Order 829 in July 2016 (Commissioner LaFleur dissented from the order as a result of this, and she issued an elegant eight-page memo which is linked in my post just referenced. I agreed with her in the post that one year was simply not enough time, especially since FERC hadn’t issued a NOPR[iv] saying they were considering ordering a standard. Had they done this, it would have given the industry a lot of time to think about what form the standard should take, as they commented on the NOPR).

As I pointed out in this post, the big problem with CIP-013 is that R1 requires the entity to develop a plan to identify and mitigate risks attendant on the supply chain, but doesn’t provide any list of risks that should be addressed, beyond the “six things” in R1.2. This seems to have led some at NERC and at least one region to come to view the standard as just being about those six things – you deal with them, and you’re good. In this view, R1.1 can be ignored. This is clearly wrong, but the problem is that, because of the absence of any list of risks (I prefer the word “threats”, but this was FERC’s term and the drafting team just adopted it) in R1.1, there is simply nothing to audit, unless the entity just doesn’t do anything meaningful at all to comply with the requirement.[v]

I’m hoping this omission will be addressed in the next version of CIP-013, but in the meantime, CIP-013 R1.1 isn’t auditable. Of course, the auditors will still be able to look at your plan and issue one or more Areas of Concern if they think you’ve missed something in it. I actually think this is almost as good as having R1.1 be auditable, since most entities will treat an AoC as being just as actionable as a PNC. But doing this essentially relies on each individual auditor to determine for him or herself what are the risks that should be addressed in the plan; it would be much better if these were all gathered in the requirement itself, as in CIP-010 R4 (see end note iv below).

I contend this problem wouldn’t have happened if the drafting team had had more time to work on the standard. But when you have such a short deadline, you don’t dare introduce anything that could cause people to vote no, meaning the standards often have problems. You throw some words on the paper and leave the interpretation of what they mean for the auditors. CIP-014 suffers from this same problem; FERC ordered it developed in three months! Of course, NERC made the deadline. They always make the deadline. The question is what happens after the standard is implemented and the enforcement rubber meets the road.

P.S. I do want to point out that only one of the current Commissioners was in her position when FERC approved Order 829 - and that is Commissioner LaFleur, the one who dissented! The other four current Commissioners joined the Commission last year.


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. And if you’re a vendor to the power industry, TALLC can help you in various ways, including developing marketing materials, delivering webinars, etc. To discuss this, you can email me at the same address or call me at 312-515-8996.            


[i] 1/1/20 would be the date if FERC approves CIP-013 in May and possibly in June, whereas 4/1/20 would be the date if they approve it in the July-September quarter. It’s hard to believe they would take any longer than that.

[ii] All Regions should be able to review your plan at any time before compliance with CIP-013 becomes mandatory. After that date, it becomes more problematic. As I pointed out in this post, there is one Region that has an Entity Development program in place, which should – and I’m speculating on this, based on what I know about the work this group does in the Region in question – allow them to review and comment on your plan even after the compliance date. My guess (or at least hope) is that other Regions will have this in place in time to do some good for CIP-013.

And note that the Region won’t tell you whether your plan is “compliant” or not. But since CIP-013 R1.1 requires you to develop a plan to identify, assess and mitigate (although the word “mitigate” was left out, as I pointed out in this post. However, don’t even think about developing a plan that just identifies risks but does nothing at all to mitigate them! I can assure you that won’t fly) supply chain security risks, your Region can tell you whether they think you have done a good job of that or not. They can also point out things like risks you didn’t consider, mitigation ideas that might not work well, etc. This will be very valuable advice in any case, and the fact that it comes from your Region will make it all the more valuable.

[iii] Given that the rollout of CIP v5 was so smooth, with nobody – except me, of course – complaining about any ambiguities in the standards. J

[iv] FERC did provide a seemingly out-of-the-blue suggestion in the 2015 NOPR that ordered the development of CIP v6, that they were also considering ordering NERC to develop a supply chain security standard. But that was much different from issuing a NOPR just for the supply chain standard, since their 2015 action was interpreted as pretty much a call for a conference (which was held in January 2016). They should have issued a NOPR after that conference, rather than wait until the standard had been developed on their compressed timeline and then issue a NOPR after the standard had been developed and approved by NERC, when it was too late to order meaningful changes anyway – except in a version 2 which is undoubtedly 4 or more years away.

[v] How should CIP-013 have been written? I know I’ve said somewhere or other – and definitely in a book I’m now working on – that CIP-010 R4 is my poster child for writing a plan-based requirement. Attachment 1 of CIP-010 is actually part of the requirement, not guidance (this is crucial, of course). And it gives the entity a set of risks from Transient Cyber Assets and Removable Media that must be addressed in the plan required by R4. So the auditors can go through the plan and make sure it’s addressed all of these risks in a credible fashion. If the entity has missed one or two – and doesn’t have a good reason why they did so – then there might be a Potential Non-Compliance finding. This simply can’t be done with CIP-013 R1.1.

I do also want to point out that I attended a few of the drafting team meetings in person, and some of the phone meetings – and I never once raised these issues. In fact, it’s only recently become clear to me that plan-based requirements can’t be treated just as another form of the typical prescriptive NERC requirement. They really require a different auditing regime than is in place at NERC now. But given the current prescriptive NERC auditing regime, the best compromise is to put a list of risks in the plan, so that it can be audited under the current regime. But as I said, I saw through a glass darkly while CIP-013 was being developed, so I’m certainly not casting aspersions on the SDT. However, I think with more time (and perhaps looking at the example of CIP-010 R4), they might have realized that not having any criteria at all by which CIP-013 R1.1 could be audited wouldn’t end well. And it won’t end well.

Sunday, April 29, 2018

A Great ICS Security Guidebook



Through one of the many newsletters I receive, I came across a great document from Emerson called “Cybersecurity Guidebook for Process Control”. It has a simple purpose, which certainly isn’t new: to summarize in one short document everything that an organization needs to do to secure the process control systems in an industrial plant[i].

What is new is how successfully Emerson has achieved that purpose. Every other document that I have seen that attempts to do this has been essentially a list of best practices, without an understanding of the overall goal to be achieved and how the individual practices help to achieve it. Emerson’s guidebook starts out by stating that cyber security is an organizational risk, and must be addressed using a risk-based approach. The rest of the guidebook follows very naturally from this statement. It is divided into five sections – each generally a security domain like remote access. In each section, Emerson describes something you should start doing, something you should stop doing, and something you should continue doing.

Of course, I’ll promise there’s nothing in here you haven’t heard already. But I highly recommend you not skim through the guidebook for that reason. I ended up reading it twice, and literally stopping to think about each sentence. Whoever wrote this (my guess is it was a team) put a lot of work into crafting each sentence, and there is a lot packed into each one. What they’re recommending is obviously based on a lot of experience. They have clearly put a lot of thought into what are the most effective (and the least effective) practices.

Enjoy!


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 Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

[i] Even if you don’t have responsibility for securing a generating plant, I still recommend you read this. There is almost nothing in there that doesn’t apply to substations as well. If all you’re concerned about is control centers, this might be less relevant for you – but I still recommend you read it!