Tuesday, October 16, 2018

FERC will approve CIP-013 on Thursday




The first item on the just-released agenda for FERC’s monthly Sunshine Meeting this Thursday reads “RM17-13-000 Supply Chain Rise Management Reliability Standards”. You probably are surprised that FERC seems to be moving in a direction nobody had predicted: Rise Management. And I have to admit that I am fairly surprised at this, although I’m not sure exactly what “rise” refers to and why it needs to be managed. However, the more likely explanation for this neologism is that it’s actually a misspelling of “risk management”. And then it makes perfect sense: FERC has CIP-013 on their agenda for Thursday.

And now I’m going to go way out on a limb: I predict that FERC will approve CIP-013 (along with the new versions of CIP-005 and CIP-010, which are part of the CIP-013 “package”), not remand it (of course, they’ve never remanded a CIP standard that was presented to them, no matter how many problems they found with it – so saying this isn’t much of a stretch). But the big question is what else they will include in the order. I’m not going to predict exactly what they’ll include (a fool’s errand, if there ever was one!), but I will tell you some of the things I’m looking at:

1. EACMS

First, what will they say about Electronic Access Control or Monitoring Systems (EACMS)? In FERC’s Notice of Proposed Rulemaking (NOPR) on CIP-013 this January, they evinced a lot of concern that these aren’t included in CIP-013 now (as approved by NERC, CIP-013-1 only applies to Medium and High impact BES Cyber Systems). I would guess they will order that EACMS be included, but the question is when they will need to be included.

FERC’s normal procedure is to state that the standard they’re approving needs to be changed in a certain way, but not to provide a particular deadline for doing this. Because NERC’s Rules of Procedure don’t allow a standard that has been approved by the NERC Board of Trustees to be changed, this in fact means that this item will go on the agenda for the next version of the standard being approved. But FERC does have the ability to order a “compliance filing” (I may not have the terminology right), providing a short deadline for something to be done. If they do that for EACMS, there would have to be a) a quick drafting/balloting/approval process for version CIP-013-2, which includes EACMS in scope, followed by b) the start of development of CIP-013-3, to include everything else that FERC orders.[I]

2. Low impact BCS

What will they do about Low impact BES Cyber Systems? Should they be included in CIP-013? When FERC ordered NERC to develop a standard for supply chain cyber security risk management, they stated that it should apply to BCS, but they didn’t mention anything about impact ratings. The first draft of CIP-013 included a separate requirement for Low impact BCS, which was perhaps one of the reasons why that draft received 9% approval. Not too surprisingly, Lows were removed from the subsequent drafts.

In their NOPR, FERC didn’t say whether or not they wanted Lows included in CIP-013, but they did order NERC to look at the issue. NERC’s report (really written by EPRI) came out in September. Not too surprisingly, NERC/EPRI didn’t directly weigh in on whether Lows should be included in CIP-013, but it seemed to me that they think it wouldn’t be a terrible idea (of course, nobody thinks that Lows should have to comply at the same level as Mediums and Highs do). So I think it’s likely that FERC will order that Lows be included, but since they won’t order this as a compliance filing, it will be done at the normal NERC standards development and approval pace – meaning the earliest that Lows would have to comply with CIP-013 would be 2 ½ - 3 years from now.

Implementation period

In their NOPR, FERC also suggested that the proposed implementation period for CIP-013, eighteen months, was too long; they suggested that twelve months would be more appropriate. For those keeping score at home, if FERC approves CIP-013 this week, the implementation date will be July 1, 2020. So if the implementation period were shortened to twelve months, the date would be January 1, 2020.

However, I think it’s unlikely that FERC will do this, since they can’t just wave their magic wand and change the CIP-013 implementation plan. In order for the plan to be changed, there will need to be a number of steps, including drafting a Standards Authorization Request, impaneling a Standards Drafting Team (although it’s very likely the team that drafted CIP-013-1 will be assigned this task), drafting the changes (and if FERC orders a compliance filing for EACMS as well, that would also probably be included in the SAR), balloting the first draft, revising the draft after the first ballot doesn’t get the required 67% approval…all the way up to FERC review and approval. As long as this whole process takes less than 90 days (which is like saying “As long as Congress can pass a new budget within a week of introduction…”), the implementation date will still be April 1, 2020. And if it takes more than 90 days, the date will be July 1, 2020 – so FERC will have advanced the implementation date by exactly 0 months, 0 weeks and 0 days, and put through a huge amount of grief in the process. Seems like a lot to go through to achieve nothing.

The big one

The biggest thing I’m looking for in FERC’s Order approving CIP-013 – but I’ll admit I’m not at all expecting to find it – is a discussion of what I see as the fundamental problem with CIP-013:

  1. R1.1 is really the guts of the standard. It requires the entity to look over all of the supply chain cyber security risks they face and develop a plan to mitigate the most important of those risks.
  2. R1.2 lists six particular mitigations that must be included in the plan (each of which corresponds to a particular risk, which isn’t stated but is definitely implied). These are listed because FERC ordered that those six mitigations be included in the standard.
  3. While these six mitigations all address important risks, they are far from being the six most important supply chain cyber security risks facing the participants in the Bulk Electric System. It’s easy to find others.
  4. One risk that jumped into the news a couple weeks ago (but has always been in the background), was that of compromise of hardware by a nation-state. Of course, I’m referring to the Chinese motherboard compromise reported by Bloomberg.
  5. Another important risk not addressed in R1.2 is the risk that software developed by the NERC entity itself will contain vulnerabilities that aren’t patched. CIP-013 R1.2.4 and R1.2.5, along with the much-loved CIP-007 R2, do a very good job of addressing the risk that software developed by a vendor will contain unpatched vulnerabilities – but obviously they are no help when it comes to software developed by the entity itself.
  6. A third serious risk, again not addressed in R1.2, was outlined in a sidebar to the October 8 Bloomberg Business Week article on the Chinese attack. The sidebar recounts how “at least two…customers downloaded firmware…meant to update..network cards. The code had been altered, allowing the attackers to secretly take over a server’s communications…” R1.2.5 wouldn’t have addressed this problem, since it just requires that the end user verify that the patch they’ve downloaded actually came from the vendor. If the vendor itself has been compromised, the user is just SOL (which I believe refers to a new designation in the NERC Functional Model).
  7. And when you think about it, if the vendor’s network has been compromised (and DHS recently indicated that the Russians compromised lots and lots of vendors to the power industry, although they seem to have some problems distinguishing vendors from utilities and control centers from generating plants. Another post on this problem is coming to a blog near you soon), this leads to an almost infinite number of risks. For example, what if you get a correctly-formatted technical bulletin from your relay vendor, telling you that they need remote access to five relays immediately, to check to see if they have a vulnerability they’ve just discovered – and when you give them that access, they use all of them to open circuit breakers on key transmission lines? After one such incident, you would realize what was going on, but the damage would have been done (especially if they did that to five other large utilities for say 25 other lines).
The moral of this story is that, if the entity just focuses their CIP-013 compliance effort on R1.2, they will be just as susceptible to the risks described above as if they hadn’t complied at all. And yet I have yet to hear anything from NERC, including the Implementation Guidance for CIP-013 itself, that focuses on anything other than R1.2 – or that even mentions the idea of developing an R1.1 plan that carefully considers all important supply chain cyber security risks.[ii]

Of course, the big problem here is that NERC only officially knows how to audit prescriptive requirements. A non-prescriptive, plan-based requirement like R1.1 just falls off the radar screen – when all you have is a hammer, everything looks like a nail.

So I’m hoping that FERC will make some mention in their Order that they want NERC to work with the entities to develop good supply chain cyber security risk management plans that consider all important supply chain threats (and maybe give them a list of threats they should consider). But I ain’t holding my breath. In other words, I think true supply chain cyber security risk management will likely remain an elusive goal for the power industry even after CIP-013 is fully implemented, even though without doubt (at least in my mind) one of the two biggest sets of cyber risks to all industries now are supply chain risks (think Target, NotPetya, etc).[iii]


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; we also work with security product or service vendors that need help articulating their message to the power industry. To discuss this, you can email me at the same address.

[i] FERC’s NOPR not only questioned why EACMS weren’t covered by CIP-013, but also Physical Access Control Systems (PACS) and Protected Cyber Assets (PCAs). However, they obviously think the lack of EACMS in CIP-013 poses a much bigger BES risk than does the lack of PACS and PCAs, which is why they raised the idea of ordering they be added immediately.
[ii] I readily admit that the big problem with R1.1 is it doesn’t provide any list of risks that need to be considered for inclusion in the plan, so it’s a lot to expect an overstressed NERC CIP staff at any but one of the largest utilities to do a good job of that for themselves. At one point, I hoped that some group like NATF or the trade associations would produce a list of threats that should be considered (not an enforceable requirement of course, but at least a starting point for most utilities). However, the very disappointing guidance that NATF recently put out led me to honestly wonder whether the author(s) had even read R1.1.
[iii] The other biggest risk is that posed by phishing. Which by the way is another risk not addressed at all by NERC CIP.

Wednesday, October 3, 2018

What does CIP-013 R1.2 tell us?


In a recent post, I pointed out that CIP-013 R1.1 is close to un-auditable. This is because it requires the entity to develop (and implement) a supply chain cyber security risk management plan, but it gives very little information about what should be in the plan. Specifically, it should include a list of risks that should be addressed in the plan, but it doesn’t do that – meaning the entity is on their own to draw up that list[i]. However, R1.1 does provide some high-level information on what the plan should cover; I discussed that in the post.

Now I want to turn to R1.2. What does this requirement tell us? As you know if you’ve read CIP-013, R1.2 provides a list of six “things” that the entity needs to do. What are these things, and how do they relate to the supply chain cyber security risk management plan that’s mandated in R1.1?

Let’s look at the first thing, numbered R1.2.1: “Notification by the vendor of vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity”. Let’s pull this apart. It’s essentially saying that a vendor needs to notify you (i.e. the NERC entity responsible for compliance with CIP-013) when they identify a security incident related to products or services you buy from them.

How does this relate to the R1.1 plan? R1.1 says the Responsible Entity needs to identify supply chain cyber security risks. It doesn’t also say you also have to mitigate those risks, but that is clearly implied. What would be the purpose of CIP-013 if you were just required to identify a bunch of big, hairy risks you face, then you could simply declare your job done? It would obviously make no sense to do that, and I predict that anyone who omits risk mitigation in their actual CIP-013 R1.1 plan will not fare well at the hands of their auditor.[ii]

So the six things in R1.2 must be either risks or mitigations. They clearly aren’t risks, so they must be mitigations. In other words, each one lists a high-level mitigation for a particular supply chain cyber security risk. The entity is required to implement all six of these mitigations. While the risks that are being mitigated aren’t explicitly stated, it isn’t too hard to state them:

  1. R1.2.1 (quoted above) describes mitigation of the risk that a security breach at a vendor won’t be reported in a timely fashion to users of the vendor’s products, leading to cyber security incidents involving the vendor’s systems installed on user networks.
  2. R1.2.2 reads “Coordination of responses to vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity”. This is mitigation of the risk that a vendor whose products are found to have a serious vulnerability won’t provide adequate assistance to their users in mitigating that vulnerability, leading again to security incidents at users, caused by the vendor’s products.
  3. R1.2.3 reads “Notification by vendors when remote or onsite access should no longer be granted to vendor representatives”. This is a mitigation of the risk that a vendor will terminate an employee who had electronic and/or physical access to users’ systems, and that ex-employee will take out their resentment for this action on those systems.
  4. The mitigation described by R1.2.4 is “Disclosure by vendors of known vulnerabilities related to the products or services provided to the Responsible Entity”.  This mitigates the risk that users will experience cyber security incidents that could have been avoided had they been notified of the vulnerabilities.
  5. R1.2.5 reads “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System”. Of course, this is really two mitigations, addressing two risks. Verification of software integrity mitigates the risk that a malicious actor will tamper with a vendor’s software or firmware during the process of delivery (electronic or on physical media) to the user. Verification of software authenticity mitigates the risk that a malicious actor will set up a fake web site or otherwise impersonate the vendor, so that the user obtains software or firmware that is damaging to their systems.
  6. Finally, R1.2.6 describes this mitigation: “Coordination of controls for (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s)”. The risk here is the one behind the recent (but ongoing) Russian attempts to compromise grid control systems by first compromising vendors and then hijacking their ability to access their products remotely for maintenance and troubleshooting purposes.
So CIP-013 R1.1 calls for a supply chain cyber security risk management plan, but doesn’t identify the risks that need to be addressed in that plan. On the other hand, R1.2 simply lists six supply chain risks (and their mitigations) and tells the entity to “address” them. So how are the two parts of R1 related to each other? Is this an either/or requirement, where you have to comply with R1.1 or R1.2, but not both? My interpretation is that the six risks in R1.2 must without question be included in the R1.1 plan, but they in no way are intended to be the only risks that are identified and mitigated in the plan.

It would be very hard to argue that the six risks are all that need to be included in the plan, since R1.1 calls on the entity to “identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s)”. It certainly doesn’t just say “Develop a plan to implement the six risk mitigations in R1.2.”

Yet if you look at almost any of the guidance on, and discussion of, CIP-013 that has come out from NERC or the Regions as well as other organizations like NATF, you’ll see close to no discussion of anything but these six things[iii]. I haven’t seen any discussion from NERC or anyone else (other than myself) about what should go into a CIP-013 R1.1 supply chain cyber security risk management plan.  Is this because the six risks (and their mitigations) that I’ve just enumerated are far more important than all other supply chain cyber security risks? Is that why the drafting team specifically called them out in R1.2?

I certainly won’t deny that these are important risks. However, they are called out in R1.2 because FERC specifically required that these six mitigations be included in the new standard, when they ordered that it be developed in July 2016[iv].

But there are certainly lots of other supply chain cyber security risks that should be addressed as well. Last week, I was fortunate to be able to attend the Software and Supply Chain Assurance Fall Forum, held at the offices of the MITRE Corporation in McLean, Virginia. This is a quarterly event that has been going on for a couple of years, although I just recently heard about it. It is a gathering of cyber security professionals working at various U.S. Departments (including DoD) and the “Three-letter Agencies”, who are very concerned about supply chain security. I will write a post on some things I learned at this meeting in the near future.

The group now includes attendees from private industry, and this meeting’s theme was the energy industry. There was some discussion of CIP-013, and Howard Gugel of NERC gave a very good presentation on the standard and all the activities going on around it. However, Howard unsurprisingly didn’t dwell on the idea of the R1.1 plan (frankly, I’m not sure he even mentioned it) and spent more time discussing the six mitigations in R1.2, and especially the question of the role of contract language in obtaining vendor participation for addressing those six mitigations (since they are all vendor risks).[v]

In the Q&A period, two audience members brought up risks they thought were very important, that they were surprised weren’t mentioned by Howard. One questioner brought up[vi] the risk of malicious code and back doors being embedded in chips purchased by a vendor in Asian markets because they are low cost – which has been discussed a lot in the past few years.

The other was the risk of unpatched vulnerabilities in software that was developed by the NERC entity itself, or was custom-developed for it. Both CIP-007 R2 and CIP-013 R1.2.5 only deal with patches released by vendors for their software. The gentleman who asked the question (who was the main organizer of the conference) was incredulous that this risk was nowhere addressed in CIP. I pointed out that this was the whole idea of the R1.1 plan – that the entity needed to consider all of the important risks in their plan, not just the six from R1.2. Of course, there are lots of other supply chain risks we could discuss as well – some of which you’ll find in the NERC/EPRI Supply Chain Risk Assessment report from September.

And folks, here’s the point of this post: Supply chain is by far the biggest cyber threat area for most industries now, and without doubt it’s the most serious for the power industry – just look at the Russian attacks. If the industry treats CIP-013 as just being about the six risks in R1.2 and nothing else, CIP-013 won’t mark a watershed in grid security (as well as supply chain security in general) – which it could be if implemented properly. Even more importantly, you will be leaving your OT network completely open to a lot of serious supply chain security risks, just because they didn’t happen to be one of the six listed in R1.2. I certainly hope NERC will wake up and realize they have to make an effort to help the entities understand the need for developing a comprehensive supply chain cyber security risk management plan. And maybe FERC can nudge them a little in that direction when they approve CIP-013.

Before I go, I want to bring up one concern that a lot of people may have – especially when they hear me bringing up the need to “comprehensively” treat all supply chain security risks. Does this mean that, instead of just worrying about six risks, you’ll have to worry about say five times that number? The six risks are already looking like a good amount of work. Do you really have the bandwidth and the resources to address all important supply chain security risks in your plan?

I want to remind you that this isn’t a supply chain cyber security plan; it’s a supply chain cyber security risk management plan. The essence of risk management is that you consider the degree of risk posed by each threat you face, and then allocate your resources toward mitigating the most serious threats. For threats that pose less risk, you allocate fewer resources or perhaps none at all.

Whatever the amount of dollars or hours you have available to spend on risk mitigation, you will always mitigate the most risk – i.e. get the most bang for your buck – if you allocate those toward the greatest risks. With prescriptive requirements – like most of the “legacy” CIP requirements, and like CIP-013 R1.2 – you don’t get any choice on how you allocate your resources. You have to spend whatever it takes to comply with the prescriptive requirements, and if you have a few nickels left over you might try to mitigate a couple other risks to a small degree – even though you may think these other risks are much greater than the ones addressed by the prescriptive requirements. When it is up to you to identify threats, rank them, and mitigate them according to the risk each one poses, your entity will be more secure – and the BES will be, too. What’s to lose by doing this?


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. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.                   


[i] To speak more accurately, the problem isn’t exactly that R1.1 doesn’t provide information about what should be in the plan. The real problem is that NERC’s very prescriptive enforcement format (based on auditing, of course), simply isn’t suited for plan-based requirements like CIP-013 R1. If there were a collaborative format in which the Regions could freely work with an entity to make sure they developed a good plan, then worked with them to make sure the plan was implemented well, the fact that R1.1 doesn’t provide much guidance on what should be in the plan wouldn’t matter so much.  
But because NERC only knows how to do strict auditing-based enforcement, it simply isn’t possible for them to officially work with the entity to understand what they need to do to develop a good plan – because of auditor independence concerns, of course. To some degree, all of the Regions actually do work with their member entities as they come into compliance – and some more than others. But it is always a kind of don’t ask/don’t tell sort of enterprise. I hope someday NERC can have a different enforcement model for the CIP standards, since cybersecurity is completely different from electrical engineering – which is ultimately what the 693 standards are based on. Prescriptive requirements and audits just don’t work for cyber. 
[ii] However, this is a pretty amazing omission. It would be like an ordinance for obeying stop signs spending a lot of time describing the different types of stop signs, but never actually requiring that you stop for one! As I said, I don’t think there’s any possibility that this omission will invalidate CIP-013-1, but I certainly hope FERC adds this to their to-do list for NERC for CIP-013-2, as they develop their Order approving CIP-013-1. I can think of a few other things I would like to see on that to-do list as well, so if one of the Commissioners wants to call me or invite me over for beers (I would come, even though I live in Chicago! – although I wish they’d invited me when I was in DC and McLean, VA last week), I’ll be glad to describe my ideas to them. These have all been stated in my posts at various times, but who has time to read through all of those things? I certainly don’t. 
[iii] The one exception to this rule that I know of is the recent NERC Supply Chain Risk Assessment report, which was prepared by EPRI. It is a good document, and does list some different supply chain risks that have nothing to do with the six things. However, it also doesn’t even pretend to provide guidance for CIP-013 compliance. 
[iv] The six mitigations appear at different points in the order, but they all were directly ordered by FERC. The drafting team had the good idea to gather them all in one place in the new standard, rather than have six separate prescriptive requirements for them. 
[v] As much as I think it’s a big mistake just to focus on the “six things” in developing your R1.1 plan, I think it’s an even bigger mistake to believe that the only real way to mitigate the six risks is to use contract language, as I discussed in this post. 
[vi] I admit this person brought up his question during a different discussion of CIP-013 on the first day of the conference (Howard spoke on the second day). My response discussed below was also given on the first day.

Wednesday, September 26, 2018

When will FERC approve CIP-013?


I must admit that I expected FERC to approve CIP-013 by now. I thought it was close to certain that they would approve it in September, since a) NERC turned it in for their approval at the end of September 2017, and b) September was the last month they could approve CIP-013 in time for it to come into effect on April Fool’s Day 2020. Now the compliance date will be July 1, 2020, unless FERC doesn’t approve CIP-013 until after Q4 – in which case the date will be October 1, 2020.

The next possible date for FERC to approve CIP-013-1 is at their monthly Sunshine Meeting the third Thursday of October. FERC issued their Notice of Proposed Rulemaking (NOPR), which said they intend to approve CIP-013-1, in January. This means it will be at least nine months between the NOPR and the Order approving the standard.

This is definitely on the long side, although not unprecedented. FERC issued their NOPR saying they would approve CIP version 5 in April 2013 and they approved it in Order 791 on November 22, 2013[i], which is seven months. CIP v5 was a complete rewrite of all of CIP, including adding two new standards. While CIP-013-1 is a very different kind of standard from any of the currently enforced CIP standards and therefore requires a lot of scrutiny, it would be hard to argue that it needs as much as did CIP v5. In any case, this is why I don’t think FERC will continue their pondering beyond Q4, so I believe it is likely the compliance date will be 7/1/2020.

What’s ironic about this is that FERC, in their Order 829 mandating that NERC develop a supply chain security standard, gave NERC only a year to a) write a Standards Authorization Request and get it approved by the ballot body; b) form a drafting team and set them to work developing the first draft; c) submit the first draft to the ballot body and have it roundly voted down (I believe it received nine percent positive ballots - not exactly good enough, given that 68% is required for approval); d) redraft and re-submit the standard (which the drafting team had to do three times); e) have it approved at the next quarterly NERC Board of Trustees meeting after final approval by the ballot body; f) have the lawyers put on their final touches; then finally g) submit the standard to FERC for them to approve.

The amazing thing is that NERC was able to do all of this and still meet the one-year deadline. And guess what happened? FERC will now have taken at least 13 months to approve CIP-013, and maybe more than that. Hurry up and wait, it seems.

I do need to point out that there is only one FERC Commissioner still in office from when Order 829 was issued. And that Commissioner, Cheryl LaFleur, actually dissented from the Order because she thought that FERC should give NERC more time (to read her elegant six-page dissent, go to page 67 of the PDF of the Order).

I totally agreed with her position in my post on the Order. Now I am even more sure that she was right, for this reason: While I think that CIP-013 is very well-written, and is the closest approach yet to how I would rewrite all of CIP if given the chance, it suffers from the near-fatal flaw of being fundamentally un-auditable under NERC’s current prescriptive compliance enforcement process. I have discussed that problem in a number of different posts already, most recently here. Since the problem of making plan-based requirements (which is what the requirements of CIP-013 are) auditable by NERC had already been solved by the CIP v6 drafting team when they drafted CIP-010 R4 (as I explained in the post just linked), I think the CIP-013 drafting team would probably have discovered the same solution if they had had more time to develop the standard. As it is, they had a million fires to deal with just to get CIP-013 passed, and perfection wasn’t something they could afford to aim for.[ii]

In the NOPR, Commissioner LaFleur clearly identified this problem. She issued a statement with the NOPR that included this passage: ““The proposed standards would provide significant flexibility to registered entities to determine how best to comply with their requirements. In my view, that flexibility presents both potential risks and benefits. It could allow effective, adaptable approaches to flourish, or allow compliance plans that meet the letter of the standards but do not effectively address supply chain threats. I hope that we will see more of the former, but I believe the Commission, NERC, and the Regional Entities should closely monitor implementation if the standards are ultimately approved” (my emphasis). In my opinion, this is exactly the big problem with CIP-013.

However, this problem isn’t insurmountable. The NERC Regions aren’t constrained to pass every CIP-013 supply chain cyber security risk management plan handed to them, simply because it has the correct title at the top. Even in the strictest auditing regime, an auditor would be allowed to use necessary judgment to determine what constitutes a “good” plan.

So I guess the real problem is not that CIP-013 is un-auditable, but that the auditors will be free to use lots of discretion in auditing, with one auditor stamping a plan as acceptable that another auditor – perhaps within the same Region – would deem unacceptable. This can be avoided if there is a serious effort to develop guidance that describes what should be in a good plan (this might be developed by NERC or by a third party. Unfortunately, neither the CIP-013 Implementation Guidance document prepared by the standards drafting team, nor the recent document put out by the North American Transmission Forum, provides any serious guidance on how to put together a good CIP-013 plan).

Of course, such guidance can’t be considered binding either on the auditor or on the entity being audited, but at least it would provide an indication of the level of performance that should be deemed acceptable; the entity wouldn’t have to follow the guidance exactly, but if they turned in a very minimalist plan, they would need to be able to convince the auditor that it provided roughly the same level of protection as does the plan described in the (as yet unwritten) guidance.

CIP-002-5.1a R1 provides a good illustration of what I mean by this. Perhaps the biggest ambiguity in complying with this requirement (and that’s saying a lot) is that the definition of BES Cyber Asset uses the phrase “impact on the Bulk Electric System” without any further description of what that means. Yet an entity needs to have some idea of what BES impact means, in order for them to have any confidence that they have identified their BES Cyber Systems properly in complying with R1. This is because almost any device that uses electricity – my electric toothbrush, for example – could be considered to have some miniscule impact on the BES.

The Guidance and Technical Basis attached to the standard describes the BES Reliability Operating Services. The BROS were an official part of the CIP-002 R1 compliance process in the first draft of CIP v5 (which was soundly voted down in December 2011), since they formed part of the BES Cyber Asset definition itself – a BCA was defined then as a Cyber Asset that fulfilled a BROS. However, the drafting team, when they met to pick through the wreckage of the first draft at ERCOT’s headquarters in January 2012, decided that the BROS weren’t really an auditable concept – so they moved them into the Guidance and Technical Basis. But the important thing is that they didn't throw out the BROS altogether.

To be honest, I didn't think NERC entities would pay much attention to the BROS after this (since it was no longer mandatory to consider them), but I’ve been pleasantly surprised to see that a number of NERC entities still consider whether a Cyber Asset fulfills one or more BROS, as they decide whether or not it’s a BES Cyber Asset. So, while an entity isn’t required to identify any system that fulfills a BROS as a BCS, and while an auditor isn’t allowed to require the entity to perform the BROS analysis in identifying their BCA/BCS, in fact there has been a tacit agreement among entities and auditors that they will do exactly this.

So it’s good news that there is this tacit agreement regarding identifying BCA/BCS using the BROS, but at the same time it’s bad news that the BCA definition is so open-ended that unwritten and unspoken agreement is required to make audits something more than pin-the-tail-on-the-donkey exercises. By the same token, it’s bad news that CIP-013 R1.1 provides close to no guidance on what should be in the entity’s supply chain cyber security risk management plan, but it will be good news if there can be some tacit agreement between entities and auditors that a certain yet unwritten guidance document provides a good description of what should be included in a good plan.

Ya gotta count your blessings where you can find them, I guess.


Please note that the free CIP-013 webinar workshop offer I made this summer is still good! Just drop me an email and we can set up a time to discuss this by phone.

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.

[i] Fifty years almost to the hour after the assassination of President Kennedy in 1963. Coincidence, you say? I don’t know…
[ii] And I will admit that, while I did attend some of the on-site and phone-based drafting team meetings, it never occurred to me that this flaw was present, or that CIP-010 R4 exemplified a solution. This realization only came to me this year, as I’ve been working on a book about CIP’s problems and how they can be fixed. Had I realized this, I would certainly have brought it up to the drafting team, although they simply didn’t have the time to deal with it then.

Thursday, September 13, 2018

What does CIP-013 R1.1 tell us?



If you’re a CIP-013 groupie, you may have noticed that I focus on CIP-013 R1.1 a lot in this blog, and not so much on the other CIP-013 requirements. In fact, I’ve only discussed R3 once, and I’ve never discussed R2, since all it says is “Each Responsible Entity shall implement its supply chain cyber security risk management plan(s) specified in Requirement R1.” Not much to discuss there!

And in R1, I focus on R1.1, instead of R1.2. Is this because I don’t like big words like “authenticity” and “Interactive Remote Access” – both of which are found in R1.2? No. While it’s true that I don’t approve of excessive polysyllabilality, I myself have been known to use long words at times. The reason I focus on R1.1 is that this is without doubt the heart of CIP-013. In R1.1, the entity draws up their Supply Chain Cyber Security Risk Management plan, while in R2 and R3 the plan is implemented and then reviewed annually.  If the entity doesn’t draw up a good plan because they don’t know what to put in it, they obviously won’t implement anything worth implementing, or review anything worth reviewing. For that entity, the whole CIP-013 exercise will be a waste of time and money.

But the loss will go beyond the entity. As the Russian cyber attacks recently brought into the open by DHS show, the bad guys have figured out that the best way into every large organization nowadays – and most certainly electric utilities – isn’t to mount a full assault on the front gate of the castle, with its myriad protections. It’s to go around to the back door with a single lock on it that the tradesmen use. To continue the somewhat strained metaphor, if the attackers can find a place to hide in the cart that brings in the hay for the animals, they stand a much better chance of breaking in to the castle. So supply chain attacks are already becoming the vector of choice for the discriminating cyber hacker. This is the biggest vulnerability for the electric sector, even though as of now there haven't been any successful supply chain attacks on control networks, except for two wind turbines.

In this post from August, I stated that I think CIP-013 R1.1 is un-auditable, because it provides nothing for the entity to key on to include in their plan – and I used CIP-010 R4 Attachment 1 as my poster child for a good plan-based requirement. As long as NERC auditors are only allowed to focus on whether the entity has complied strictly with the specific wording of a requirement (which is the case now, unfortunately), a requirement that doesn’t have some specific wording for the auditors to key on is simply un-auditable. CIP-010 R4 Attachment 1 provides specific (although not prescriptive) criteria for what should be in the plan; CIP-013 R1.1 doesn’t.

However, I’m exaggerating when I imply that R1.1 provides no help at all to the entity as they develop their plan; there is some information in there, and it is enough to get you started in writing your plan. This post will list the information that I have found in R1.1. It doesn't provide anything near a workable guide to developing a CIP-013 plan, but it at least is a start.

Here’s the full text of R1.1:

(The plan(s) shall include)…one or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).

And here’s what I get out of this all-too-brief text:

  1. The last time I took a close look at R1.1 in this blog, I decided there was no significance to be assigned to the fact that it begins by mandating “..processes used in planning..” That seems to be the Department of Redundancy Department at work. You are developing a plan for supply chain cyber security risk management. You aren’t developing a plan for “processes used in planning supply chain cyber security risk management”. So ignore these words.
  2. The plan is to “identify and assess cyber risks to the BES from vendor products and services…” You may notice that there’s nothing about mitigating those risks. I assume this is just an oversight. Of course, being required to identify and assess risks, but not having to do anything to mitigate those risks, wouldn’t make any sense. So you need to read this as a requirement to “identify, assess and mitigate” risks.
  3. But what are these risks you have to mitigate? Aye, there’s the rub. CIP-010 R4 also requires you to develop a risk management plan. In Attachment 1 to that requirement, you find a list of types of risk that you need to mitigate in the plan, as well as high-level suggestions for how to mitigate these risks. What do you find in CIP-013 R1.1? You find the two bullet points (i) and (ii). What are these? Are these risks to be mitigated, too?
  4. No, I call these “risk areas”. They are essentially subdivisions of the overall world of supply chain cyber security. They aren’t risks themselves, so you still need to find risks to address within each one of these areas. But this does at least provide guidance on where to start.
  5. What specifically are the risk areas? Even though there are two bulleted points, there are actually five risk areas. Notice that the two points are preceded by the words “risks…from vendor products or services..”  This means you need to consider each of the two bullet points from the points of view of both vendor products and vendor services.
  6. Next, notice that bullet (i) is “procuring and installing vendor equipment and software”. Breaking this up yields “procuring vendor equipment and software” and “installing vendor equipment and software”. Each of these is itself a risk area, but remember that we are supposed to look at these from the points of view of both products (which means hardware and software) and services. So this means we have to add “procuring vendor services” and “installing vendor services” to the list of risk areas.
  7. Of course, you don’t “install” services! But you do utilize them. So I reword the second of these as “utilizing vendor services”.
  8. As for bullet point (ii), it’s already sufficiently general that we don’t need to list separate risks areas for products and services.
So here’s my list of risk areas that need to be addressed in your CIP-013 plan (and these are enforceable, since they are explicitly stated in the requirement, even if they’re a little hard to see initially):

a)      Procuring vendor equipment and software;
b)      Installing vendor equipment and software;
c)       Procuring vendor services;
d)      Utilizing vendor services; and
e)      Transitions between vendors.

Now you know at least where to begin as you develop your plan. Your plan needs to address each of these five risk areas. From there, you need to find important risks to mitigate in each area. There’s more information for your plan, to be gleaned from R1.2. I’ll discuss that in another post soon.


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. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.         
               


Wednesday, September 12, 2018

500,000!



Today this blog passed 500,000 “pageviews” (meaning someone went to a page in the blog, even though they might have read more than one post), since its inception at the end of January 2013. This doesn’t include people who read the posts from the email feed – and as of today, there are 639 subscribers to the feed (by the way, I have no idea who they are).

Of course, 500,000 hits is probably a slow Thursday morning for one of the Kardashians’ blogs, but I’ll take it. I honestly thought a few years ago that, once NERC CIP version 5 came into effect, the CIP news would kind of die down and I’d start having trouble finding something to write about. Fortunately for me but unfortunately for you (if you work in CIP compliance for a NERC entity), there has continued to be lots of controversy and confusion, as well as new standards developed and approved – and when things were a little slow this summer, the Russians stepped in to save the day[i]! I guess I was just born lucky.

So I suspect it might be a little while before I run out of things to talk about. I once thought I might focus on reviews of online cat videos – I guess I’ll always have that as a fallback option.


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. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.    



[i] And when the story of the attacks themselves was flagging, DHS' confused and shifting portrayals of the attacks took up the slack very nicely. Verily, my cup runneth over.

Friday, September 7, 2018

Two comments on yesterday’s post



I received two very good comments on yesterday’s post. In neither case do I think it’s warranted to change the post, but I want to get both of these in the open for the sake of openness (we believe in transparency here at Tom Alrich’s Blog!).

First Comment
In yesterday’s post, I was making the point that DHS had clearly implied a number of times that the Russian cyber attackers had compromised control centers of US electric utilities. The examples I used were four quotations from two articles by a Wall Street Journal reporter who had attended the first of DHS’ four briefings on this matter. In both of these articles, she wrote about conversations on the Russian attacks that she had with DHS staff members (as well as staff from other government agencies, such as DoD), both before and after the briefings.

The third of the four quotations was this one:

“Here’s a real smoking gun. Later in the same article, you find this quote ‘In March, Homeland Security and the FBI pinned responsibility on…Energetic Bear, for intrusions into utilities that gave attackers remote access to critical industrial-control systems, called SCADA.’ SCADA is found in utility control centers, not plant control rooms. Again, this isn’t a direct quote from DHS, but I'm also sure the reporter didn’t dream that they said this.”

This morning I received this email from Kevin Perry, recently retired CIP compliance auditor from the SPP Regional Entity:

“SCADA is not limited to control centers.  SCADA is Supervisory Control and Data Acquisition and is any system that performs those functions.  In the control center, SCADA is often combined with network applications like state estimation and contingency analysis to be an Energy Management System (SCADA/EMS).  The plant control system at a generating plant is a SCADA system.  As is the process control system at a paper mill and other automated manufacturing facilities.”

By the way, I wish to take this occasion to wish Kevin a happy retirement (although it sounds like it might be anything but retirement, as is often the case in this industry). He has been a real thought leader on NERC CIP (in fact, I would say the thought leader, although his position as an auditor limited what he could say publicly). He taught me almost everything I know about the intricacies of CIP version 5 (although he and I have a couple long-standing differences of opinion on that version – which of course is the foundation for all the current CIP standards, even though some of them are now on a higher version number. It’s unlikely that either of us will move to the other’s side on these issues, although we can always have a civil conversation about them). He was vice chair of the NERC CSO706 drafting team during its first year, when they drafted CIP versions 2 and 3 (the team went on to draft v4 and v5). He was also chairman of the NERC CIPC and a member of the team that drafted Urgent Action 1200, the predecessor to CIP. I believe he – until his retirement before Labor Day – was one of perhaps two people in the ERO Enterprise (i.e. NERC and the Regional Entities) that was most knowledgeable about CIP.

In his statement, Kevin is saying that it isn’t necessarily true that DHS was referring to control centers when they said SCADA systems had been penetrated, since generating plants are controlled by SCADA systems. I agree it’s technically true that generating plant control systems are SCADA, and it’s also true that, in all other industries, the systems that run a plant are called SCADA. But in the power industry, systems that run generating plants are called distributed control systems (DCS). I’ve never once heard the term SCADA used in reference to a generating plant.

However, I think the sentence from the WSJ article, that appears right after the one I quoted, makes it quite clear that the person who said this (from DHS or the FBI) had utility control centers in mind. It reads “These systems govern power flows and keep electricity supplies balanced with demand and thus prevent blackouts." This could only refer to the control center of an electric utility.

Second Comment

The second comment was posted on yesterday’s post itself by “JasonR”. He commented:

"’HMI screen shot showing a diagram of a gas combustion turbine’ - this evidence alone doesn't mean a Control Center was compromised. Almost all entities have read-only stations connected to a server which has a read-only historical feed from Production (typically via a data diode). Often times, the same exact "client" interface is used, and other than a lack of control access, it appears identical. Further, both the gas turbine HMI and wind farm could be monitored by a single entity with views into each system as I described, and no compromise on any control networks. This all could be just one CxO's laptop that was hacked who had read-only access to view both.’

JasonR is obviously a very technically savvy guy. For those like me who don’t quite fit that description, let me translate this. He’s saying two things. The first is that, just because the attackers obtained a screen shot of a Human-Machine Interface (HMI) screen and the HMI should always be on the control systems network[i], it doesn’t mean the attackers actually penetrated the control network. This is because there are various technologies (the most common being a “data diode”) that allow secure one-way transfer of data (like HMI screens) from the control network to the IT network. So the attackers could have viewed the HMI screen just by attacking the IT network, which is much easier than attacking the control network.

The implication of what Jason says is that there wasn’t actually any penetration of the control network at the small combustion turbine unit that was depicted in the HMI screen that DHS displayed during the web briefings on the Russian cyber attacks. And the implication of this statement is that I was wrong in asserting “This means that either a) Christopher Krebs, the person who said that only one facility - and at that facility only two wind turbines - was compromised was wrong; or b) Leslie Fulop, the earlier spokesperson who said that a single plant was compromised, was wrong.” In fact, if it turns out a CT plant’s control network wasn’t penetrated (because, as Jason implies, the Russians only accessed the IT network), then neither Christopher nor Leslie was wrong – rather, I was, for which I apologize if this is true.

However, I don’t think I was wrong. This is because Leslie Fulop emphasized that the asset that was penetrated was a very small generating plant, whose loss wouldn’t affect the grid at all. If it was a very small CT plant that was attacked, it’s unlikely the plant would have put in place a data diode (which isn’t cheap) to safely transfer data from the control to the IT network. What’s much more likely is that, in this small plant, there is no distinction at all between the IT and control networks – meaning that penetrating the IT network is the same as penetrating the control network. So the Russians had access to the control systems, no matter which “network” they thought they were attacking.

Jason’s second point is that it’s possible that only one generating entity was attacked, but it controlled both a wind farm and a small CT plant. There could have been a manager who receives production data from both assets on his or her laptop. As in Jason’s first point, this would be a safe practice if the production data were transferred securely, for example with a data diode. Again, the Russians could have penetrated the laptop without having to penetrate the control network. In this case, neither on the wind farm nor on the CT plant would the control network have been penetrated. Once again, if this were true both Christopher and Leslie would be right, and I would be wrong.

However, I find this scenario very hard to believe. For one thing, I doubt there are too many generators that have both a small wind farm and a small CT plant (it’s kind of like finding a very small company that operates both a bakery and a quick lube franchise. Not much synergy there). Almost all of the time, it will be one or the other. More importantly, if a manager is receiving access to real-time production data on his or her laptop, it must mean that it’s read-only data, meaning the manager doesn’t have any control of the power generation process. So it doesn’t matter that the Russians penetrated his or her laptop – they’re never going to be able to affect either the wind turbines or the CT plant! But in that case, what was the point of these briefings, if the Russians never once obtained the ability to make any impact on the US grid at all?


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. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.         



[i] In the first Ukraine attacks, the attackers entered via the IT network, but they were able to get into the control network (and thus to the HMIs) because the VPN connection didn't use multi-factor authentication – a definite violation of good ICS security practice and NERC CIP! Since the attackers had been rooting around the IT network for months, they had some engineer's credentials, and used those to get into the control network. This is how they were so easily able to trip circuit breakers to cause outages.

Thursday, September 6, 2018

What if it really was control centers?



As I described in my last post, until last Friday I believed that a) despite whatever misleading statements were made in the DHS briefings on the Russian attacks (and duly broadcast in the press), the Russian attacks didn't penetrate any utility control center (i.e. EMS) networks. I also believed that b) while it was unfortunate that the two walk backs by DHS were different (one said that only a single plant was compromised, but the second said that just two wind turbines were compromised), it was certainly conceivable that the first one was mistaken and the second was simply a correction of it.

However, last Friday a longtime industry observer pointed out to me that the single piece of concrete evidence of compromise of a control system network that was presented in the DHS briefings was an HMI screen shot showing a diagram of a gas combustion turbine, which had been taken by the attackers and uploaded . It seems that both a gas CT plant and a wind farm were compromised. This means that either a) Christopher Krebs, the person who said that only one facility - and at that facility only two wind turbines - was compromised was wrong; or b) Leslie Fulop, the earlier spokesperson who said that a single plant was compromised, was wrong.

However, I still believe that this confusion was just that – not intentional. But for me to continue to believe this much longer, I (and presumably others) would like DHS to, for once and for all, say exactly how many control system networks were compromised and what kinds of assets they were associated with (gas CT plants, wind farms, coal plants, nuclear plants - God forbid! - or anything else). Since this will be DHS’ fourth story, I sure hope this doesn’t have holes as well.

But now I want to ask, what if a) is wrong above? That is, what if there were actually one or more utility control centers penetrated – meaning the actual OT network, not the IT network that’s physically contained in the control center? Why am I asking this? Does it mean I've begun to think that really happened? No it doesn’t, mainly because the implications of that, if true, would range from serious to truly horrific. But there are obviously a lot of people outside of the utility industry (including in the technology press) who are quite ready to believe this, which is why the story rocketed around the world a month ago that the Russians had penetrated “hundreds” of US utilities and were poised to throw the entire US into darkness at a single word from Mr. P. I contend these people wouldn’t hold this view so easily if they knew the real implications – which I’ll outline shortly.

But why do these people believe the story? Of course, it’s because it came from major press reports. And where did those reports come from? Was it just the fertile imaginations of some reporters? Unfortunately not. There were a number of statements from DHS during the briefings that a reasonable person would assume meant that multiple utility control centers had been compromised. Here are a few of them:

  1. Jonathan Homer of DHS said in the first briefing that “They got to the point where they could have thrown switches” and disrupted power flows[i]. Of course, we all know that he was talking about software “switches”, but by talking about disrupting power flows he could only be referring to software running in utility control centers, not control rooms of individual generating plants. An attacker that penetrated a plant control room wouldn’t be able to do anything more than shut down the plant. And since DHS has admitted that the “single plant” that was compromised was very small and couldn’t affect the grid if it was lost, there is simply no way that this is what Mr. Homer could have meant when he talked about disrupting power flows (assuming the walk back is correct).
  2. The second WSJ article on this topic, dated August 7 (which I wrote about in this post), starts by saying “Top administration officials are..(discussing striking back)..to deter attacks such as the successful penetration of U.S. utilities by Russian agents last year.” One paragraph later, the article says “Hackers..claimed ‘hundreds of victims’ in a campaign against the energy sector that ultimately put them inside the control rooms of U.S. electric utilities where they could have caused blackouts..” Again, you can't cause a blackout by shutting down a single small generating plant (and you usually can't cause one by shutting down a big plant, given the redundancy built into the grid). Admittedly, neither of these is a direct quote from someone at DHS, but I sincerely doubt this reporter was just making the stuff up.
  3. Here’s a real smoking gun. Later in the same article, you find this quote “In March, Homeland Security and the FBI pinned responsibility on…Energetic Bear, for intrusions into utilities that gave attackers remote access to critical industrial-control systems, called SCADA.” SCADA is found in utility control centers, not plant control rooms. Again, this isn’t a direct quote from DHS, but I'm also sure the reporter didn’t dream that they said this.
  4. In the next paragraph, the article continues “In April, Russian hackers were using…internet routers..as another way to…maintain a hidden presence in control networks…” This is of course a different Russian attack campaign (those guys have been really busy!) that attacked routers. I hadn’t heard that this resulted in penetration of control networks at utilities, but they’re saying it did.

What’s most disturbing about this is not so much that these statements were reported, but that DHS has done nothing to set the record straight, except for the two walk backs which themselves need to be walked back. So when they do their third walk back, I would also like them to explicitly state whether they know of any penetration of U.S. utility control networks (meaning EMS or transmission SCADA) by the Russians, Chinese, Nigerians[ii], Maldive Islanders…whoever.

Nevertheless, I continue to believe that no utility control centers were penetrated. Why do I say this? There are two reasons. The first is that there would definitely have been a lot of very noticeable activity if that had happened. When the Ukraine attacks happened, there was a big inquiry and there were lots of briefings, both classified (initially) and unclassified; for an attack in the US, there would have been much more than this. I have heard nothing about any of these things happening.

The second reason is that, if it’s true that just a single small EMS system was penetrated, the two DHS people who said that only a small plant or two wind turbines were compromised should obviously be immediately fired, both because they lied and because they presumably inhibited DHS from taking the needed steps to notify the industry and the public of the danger. And if - let’s say - even one large utility control center (controlling a major urban area) was compromised, not only should these people be fired, but there should be a full investigation of how that happened and whether higher-ups were involved. If we’re really talking about a city being threatened with a major blackout (which will very likely result in deaths, especially if it’s more than a few hours) due to deliberate actions or inaction by people at DHS, we are now talking about treason, not just dereliction of duty.

And this is why I don’t believe any utility control centers were compromised, despite all the DHS statements implying (or stating) otherwise.

However, we seem to be forgetting something very important: If the Russians have compromised one or more major utility control networks and could be poised to cause a major outage (as most of the news stories on the attacks indicated), this constitutes a true national emergency. I am mystified that this hasn’t been done already, but somebody needs to get on the red phone to Mr. P and tell him very clearly that he needs to immediately cease all cyber attacks against US critical infrastructure (which now includes voting systems, of course), and make sure any malware that has been planted has been removed. He will have 48 hours to get this done, at which point a set of rapidly escalating sanctions will be put in place.

This time the sanctions won’t just consist of putting even more financial pressure on some of his oligarch cronies or exposing to all the world where he’s stashed the approximately $35 billion he’s reported to have amassed for himself (all on his modest salary, I’m sure).  One of the progression points might be banning Russian aircraft from all airspace worldwide (of course, this would require coordination with our allies, which seems to be a lost art in Washington these days. Hopefully, somebody still remembers how to coordinate with, rather than bash, our allies) until full compensation is paid to the families of all victims of the shooting down of Malaysian Airlines flight 17 in 2014, as well as to their governments for the direct expenses and general grief their countries have suffered because of this event.

P.S.
Someone suggested to me that the fact that we hadn’t come down harder on the Russians so far for their vigorous attempts to penetrate utility control networks was because we have been doing the same with their utility control networks, and – unlike the Russians – we may have actually succeeded in penetrating them. In other words, everyone does it, so we’d be self-righteous to make a big deal about it – especially since the Russians didn’t succeed.

Here’s a story about another national emergency: the Cuban missile crisis of 1962, when President Kennedy found out the Soviets had installed nuclear-armed missiles in Cuba, aimed of course at the US. Khrushchev had installed them in response to a) the US’ attempted invasion of Cuba at the Bay of Pigs in 1961, and b) NATO’s recent installation of Jupiter nuclear missiles in Italy and Turkey aimed at, naturally, Russia.

Kennedy didn’t tell people to calm down, since the Soviets were quite justified in being a little upset about these two events. Rather, he did what was necessary to defend the US. If in fact the US has penetrated Russian utility networks, great! We all know that the US isn’t going to launch a cyber “first strike” on a foreign power grid. And we also know that Russia has already launched one of these in the Ukraine. Let’s not wait around for them to launch one here. 


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. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.                        



[i] This was quoted in the Wall Street Journal article of July 23. The quotation marks didn’t include the phrase ‘and disrupted power flows’. But I seriously doubt the reporter just inserted that phrase on her own – she was probably paraphrasing Mr. Homer.

[ii] Perhaps the Nigerian prince who has been emailing me to send him money has given up trying to get blood from a stone and has turned to hacking SCADA for a living.