Friday, March 29, 2019

Wrong URL in yesterday's post

Yesterday's post was about one thing: A rerun of a previous post. Instead of copying the old post and pasting it into a new one, I simply started yesterday's post with the URL for the old one. Except it wasn't.

So here's the correct URL: https://tomalrichblog.blogspot.com/2017/07/a-contradiction-in-cip-013.html I have entered it in yesterday's post as well, but I'm putting it up now, since a lot of people just read my posts in the email feed.

Thursday, March 28, 2019

A contradiction in CIP-013: the rerun



While looking for another post today, I ran across this one. I’ve just reread it. Other than looking like a ransom note (I used to have weekly fights with Blogger, the software used by Blogspot, because it seemed to randomly choose different fonts at different places. Now it seems to have calmed down, although I still have a few problems), I think it’s still very valid.

Of course, the contradiction described in this post will remain between the requirements in question (CIP-013-1 R1.2.5 and CIP-010 R1.6). And this is the starkest illustration I know of the difference between a risk-based requirement and a prescriptive one. I’m afraid the latter will win out here, of course. In other words, you’d better be prepared to show you verified integrity and authenticity of every patch for every Medium or High impact BES Cyber System, regardless of the degree of risk it poses for the BES, or for that matter the degree of risk posed by the vendor – even though R1.2.5, as well as the rest of CIP-013, not only allows but practically requires you to take account of risk.

Of course, this isn’t an accident, since FERC in Order 829 directed that the new supply chain security standard be risk-based. And in doing so, they saved NERC from itself, since there is literally no way that all supply chain risks to the BES could be addressed with a prescriptive standard (NERC’s usual modus operandi, of course); NERC entities would probably have to spend about the entire US GDP on CIP 13 compliance (with a small chunk of that still going to CIP 2-11 and CIP 14 compliance, of course).


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. To discuss this, you can email me at the same address.

Monday, March 25, 2019

Your chance to make history and learn valuable stuff at the same time!



Two weeks ago, I wrote a post pointing out a unique opportunity to anybody in or associated with the North American electric power industry. This opportunity is to join the Supply Chain Working Group (SCWG) of the NERC CIPC. The bar to joining is pretty high, though: You have to be a user of electricity in North America. No others need apply.

The post is a little long-winded (imagine that!), although I still recommend you read it. But here is a Cliff Notes version, which I’ve augmented since I realize I left out an important consideration: Joining the SCWG provides you the opportunity to do your job better, if you’re involved with helping a NERC entity come into compliance with CIP-013:

  1. I like CIP-013 a lot because it states up front exactly what it’s about. The purpose of CIP-013 (stated in Section 3) is “To mitigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems.” And R1.1 clarifies that by saying the entity needs to develop a plan “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).”
  2. That’s the good news. The bad news is…              that’s all there is. There’s no list of risks that you need to consider in your plan, and there’s no list of actions you can take to mitigate those risks (the exception to this is R1.2, which lists six mitigations that you have to include in your plan. These are there because FERC ordered they be included in Order 829). Where can NERC entities get that information?
  3. I discussed various possibilities for this in my first post on the SCWG, but the bottom line is that there isn’t going to be any “official” list of risks and mitigations for you to consider including in your CIP 13 plan – just disjointed guidance from one group or another. However, I’m quite pleased with the way the SCWG is already quickly turning into the crowdsourced implementation guidance provider for CIP-013. Since their white papers are from the people in the trenches, what they produce will be both authoritative and useful, and its value will increase with each person who joins the discussions.
  4. As I mentioned in the first post, there are five sub-groups in the SCWG, each developing a white paper that deals with an important area of supply chain security (I’m leading one of those groups, dealing with the “supply chain risk management lifecycle”). The groups are starting to have web meetings, and based on the first of those meetings that I attended last week, I can say they will be extremely useful – both to the industry, because there is some really good discussion and debate going on that is likely to result in very useful guidance, and to the people who participate, because they will take home a lot of good information that will help them develop their CIP-013 plans.
  5. And how are these groups providing guidance? They may not all know it yet, but I predict they will all be providing discussions of a) risks that apply in the particular area they’re addressing, and b) mitigations that can be applied for those risks. That is, exactly what I just said is needed!
  6. I’ve become a big fan of crowdsourced intelligence, mainly because of Yelp. I travel a lot, and usually rely on Yelp to point me to good (and inexpensive) restaurants. I can truthfully say I have never eaten at a restaurant that was near the top of the Yelp search that led me to it, that wasn’t good. When you have so many people contributing reviews (although I’ll admit I’ve almost never done that. Hey, freeloading is a time-honored tradition!), they’re just not going to be all wrong. I feel the same about the SCWG sub-groups: the more people that give input to the papers they write, the more useful and high-quality they will be. And meanwhile, those people will benefit tremendously from the discussions (since a lot more is said on the phone than will ever make it into the white papers).

So if you would like to join the SCWG, drop me an email at tom@tomalrich.com, and I’ll get this to Tony Eddleman of NPPD (the chairman) and Tom Hofstetter of NERC (the NERC ­facilitator­). They will put you on the list, and get you invitations to the upcoming sub-group meetings (including the first meeting of my group, at 12 PM Eastern Time this Wednesday) as well as to the monthly phone calls for the whole group. I’d like you to email me rather than Tony and Tom directly, since I don’t want to inundate them with separate emails. I sent them seven names just today, and I did that with four or five separate emails, since I thought each person who emailed me was probably the last for the day. I’d like to consolidate them and send them just one or two emails a day, since they both have day jobs (and Tony, who’s with the Nebraska Public Power District, is helping deal with the consequences of the severe flooding in that state).


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. To discuss this, you can email me at the same address.

Friday, March 22, 2019

News from 2025: There has never* been a successful hack of the US grid!



*Except for possibly multiple successful hacks in 2017 and 2018. The Director of National Intelligence’s 2019 Worldwide Threat Assessment (based on intelligence gathered by the FBI and CIA) has this paragraph (p. 6):

Russia has the ability to execute cyber attacks in the United States that generate localized, temporary disruptive effects on critical infrastructure—such as disrupting an electrical distribution network for at least a few hours—similar to those demonstrated in Ukraine in 2015 and 2016. Moscow is mapping our critical infrastructure with the long-term goal of being able to cause substantial damage.

The undisputable implication of this statement is that Russian hackers penetrated the control centers of multiple electric utilities and planted malware that could cause an outage. When this report was released, many cyber professionals in or knowledgeable of the electric power industry believed this conclusion to be wrong. However, since no investigation was conducted at the time, six years later there is still no evidence that the FBI's and CIA’s statements in that report were wrong.



Pretty sad, isn’t it? You never can erase an asterisk from your record. Just ask Barry Bonds and Sammy Sosa.


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

Monday, March 18, 2019

There is a solution!



After my last post, I received emails from a couple of people who understand NERC CIP very well. They were disturbed that I seemed to be saying we should throw away mandatory cyber security standards for the power sector altogether, due to the huge cost of compliance with CIP. Rest assured, I’m not saying that. I think mandatory standards are absolutely essential, since – as everyone admits – the only sure-fire way to get adequate funding for cybersecurity in almost any organization is if there are mandatory standards in place.

However, I think it’s possible to design standards that wouldn’t lead to the majority of total industry spending on CIP going to activities that have little to no impact on security, but which are required for compliance - as an informal “poll” that I have been taking over the past few years leads me to believe is the case today. In fact, we have such a design in front of us. CIP-013-1, while certainly not perfect, comes very close to being my model for how all of the CIP standards should be rewritten.

But the fact that it is so economically inefficient is just one of five problems that I see with the current CIP standards regime (i.e. the standards currently in effect). I have mentioned all of these problems in posts at various times in recent years, but I have never written about them together in one place. Last summer, I got about two thirds of the way through a book that tries to do that, as well as propose a solution. However, since then I’ve been too busy to finish it.

Last spring I was fortunate enough to be asked by the editor of Cybersecurity: A Peer-Reviewed Journal (a UK-based publication) to write an article for this year’s journal, which is actually published in quarterly 100+-page editions. I chose the topic of “How can we effectively regulate grid security?” The article describes – at a very high level, of course – the five problems I see with the current NERC CIP compliance regime (which includes more than the standards themselves), and very briefly outlines how I’d address them.

I’d love to be able to finish my book so I can fill in the details on these topics, but at the moment I feel that putting food on the table is more important (I have this funny thing about food…).[i] Fortunately, I just reread the article and I think it provides a very good summary of what I will say in the book – in about 1/25 of the space!

Going by the articles from previous years that I was provided as samples, the journal publishes very high-quality work; so you may feel you would like to invest the $295 to subscribe for this year (there is no online version). However, if you don’t want to do that (or you’d like to try before you buy), I was given permission to make my article available a month after it was published, which was last month. I’m now doing that (using a proof copy I was sent).

Since I can’t attach PDFs to this blog (only JPEGs, and I’ve only done that once), I need you to drop me an email at tom@tomalrich.com if you would like to read the article (it’s 10 pages). I promise that no salesman will email you back and I’ll send it to everybody who asks, whether or not you’re a competitor to my huge consulting business (however, if you work for a Russian or Chinese state-sponsored organization, I won’t send it to you - although I don’t expect anybody from one of those organizations to send me an email from their official account! Of course, there’s nothing in the article that could in any way guide attacks on the North American power grid).

And I’d like to hear comments on the article! I think it’s becoming more relevant all the time, especially since NERC needs to soon make some pretty fundamental decisions about what they want CIP to be when it grows up. I hope to have a post out on that subject within a couple weeks.


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. To discuss this, you can email me at the same address.

[i] I’ve also decided that I would like to put out a book on supply chain cyber security risk management and CIP-013, before I go back to the other book. This one will be much easier to write, since I’m currently “writing” it as part of my work (at the moment all of my work is on CIP-013).

Friday, March 15, 2019


Lew on CIP 13: Your plan and how it will be audited – part I

Note: part II of this post (part 4 of the series) will be out later this month. Lew told me he's writing a new article on CIP-013, which will appear in this month's newsletter - I will wait for that before I do this post. If you want to receive that before I do my post, you can sign up on the first page of RF's web site.

This is the third of four posts discussing what Lew Folkerth of the RF NERC Region has written about CIP-013 in RF’s December and February newsletters. The first two parts of this series (both written in January) are here and here; they deal with the December article, since that was the only one published at the time. In this post and the next one, I will focus on the February article, while still pointing out a couple items from December that I haven’t discussed yet.

As I said earlier, I believe Lew understands CIP-013 better than anyone else at NERC or the Regions. In fact, I’ll go so far as to say that he understands it better than anyone else on the planet, although I don’t want to extend that to the Solar System or the Milky Way – that would be going a bit too far, since some distant planet may well harbor someone who knows CIP-013 better than Lew!

I also want to point out that this post, like the previous two in this series, doesn’t confine itself to just repeating what Lew said in his articles. In some cases I disagree with him, although these are regarding details, not his fundamental approach to CIP 13. More often, I expand one or two sentences of his into one or two pages, both because I’m much more verbose than he is, but also because he’s constrained to a small amount of space in the newsletter – whereas I can bloviate as much as I want.

You can retrieve the December newsletter here and the February one here. You find Lew’s articles, as always, by going to the left side of the first page of the newsletter and clicking on “The Lighthouse”. I also recommend you sign up to receive the newsletter regularly (it comes out six times a year), by going to RF’s home page and signing up about two thirds of the way down the page. Lew writes an article in every newsletter, and they are always worth reading.

Lew’s February article is entitled “A Structure for CIP Risk Management Plans”, and it is clearly intended to apply to all NERC CIP standards or requirements that mandate risk management plans. But as he points out, CIP-013 will be “the first explicitly risk-based CIP Standard” – so it’s currently the only standard that requires a risk management plan[i]. He points to some of the new requirements now being discussed by the CIP Modifications drafting team as probably being future examples of risk-based CIP standards or requirements, but of course they are a long way from becoming standards.[ii] So this article could just as well have been called “A Structure for CIP-013 Risk Management Plans”.

I like CIP-013 a lot and I consider it the future of all CIP standards, but I’ll admit it gives the NERC entity just about no information about what should be in their supply chain cyber security risk management plan (or CIP-013 plan, which is easier to say). And there has been no official guidance on this subject published by NERC or any other organization (there is the Implementation Guidance published by the drafting team, but it still exists only in draft form and I don’t believe it will ever be finalized, for reasons that are too depressing to recount here). So I think it’s a huge help that Lew was willing to lay out what he thinks should be in your plan (and since what he thinks carries a lot of weight with CIP auditors in all of the NERC regions, it certainly behooves any NERC entity to pay attention to this).

Lew says the following sections should be in your plan. He breaks them into four areas, based on NIST 800-30’s four phases of the risk assessment process: Frame, Assess, Monitor and Respond.

I. FRAME

Scope
I’ll admit I hadn’t thought of explicitly including a scope section in the plan, but it makes sense. However, I’m not sure I agree with everything he says in this section of his article. He says your plan should “include an inventory of Cyber Assets that are covered by your plan, as well as a list of vendors that may be affected by implementation of the plan”. While I think it’s a good idea to list vendors (of course, it’s also good to keep in mind that that list will change over time), I don’t think Cyber Assets is the right category of assets to list. CIP-013 applies to Medium and High impact BES Cyber Systems. True, BCS are usually implemented on Cyber Assets, but the software they run often isn’t confined to one of the Cyber Assets – and sometimes, of course, the software runs on virtualized hardware, which doesn’t meet the definition of Cyber Asset at all.

Also, I would qualify his use of the term “inventory”. What CIP-013 is definitely not about is the BCS that you already have – it’s about the ones you will purchase once the standard is in place. I think Lew might have meant to say that the inventory is of the types of BCS that you expect to purchase in the future (again, with the caveat that these will change as well). So I would reword what he says and write “Your plan should include an inventory of types of Medium and High impact BES Cyber Systems that are covered by your plan, as well as a list of vendors that may be affected by implementation of the plan.”

Objectives
Lew’s paragraph on Objectives reads “The objectives of the risk management plan should be clearly identified. For example, your CIP-013-1 risk management plan should include the four objectives from FERC Order 850 P2, as well as any additional objectives that are appropriate for supply chain risk management at your organization.”

Lew listed FERC’s four objectives in his December article. They were originally stated in Order 829, in which FERC ordered NERC to develop the standard in 2016, and in Order 850, in which FERC approved CIP-013 (and the revised CIP-005 and CIP-010 that go with it) in October of last year.

In my first post in this series, I pointed out that, while it’s obviously a good idea to show how your plan meets FERC’s four objectives, the real objective of CIP-013 is found in the statement of purpose at the beginning of the standard: “To mitigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems.” What does this mean in practice? R1.1 answers that question: The plan needs 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).”

Lew did state that, besides showing that your plan meets FERC’s four objectives, you should show it meets “any additional objectives that are appropriate for supply chain risk management at your organization.” This does go beyond what’s in FERC’s list of objectives, but I don’t think it goes far enough. I would rewrite Lew’s paragraph on Objectives to say:

The objectives of the risk management plan should be clearly identified. The objectives of your CIP-013-1 risk management plan should include the four objectives from FERC Order 850 P2, as well as the objectives stated in R1.1.”

Of course, I’ll admit that the objectives of R1.1 don’t necessarily jump out of the page in well-ordered ranks, so here’s what I think they are:

  1. Identify important supply chain cyber security risks to the BES, resulting from:
    1. Procuring vendor equipment and software;
    2. Procuring vendor services;
    3. Installing vendor equipment and software;
    4. Using vendor services; and
    5. Transitions between vendors.
  2. Determine the degree of each risk[iii] identified, by determining its likelihood and impact.
  3. Rank risks by their degree, and choose the highest risks for mitigation.
  4. Rank the risks that underlie the six mitigations in R1.2 at the top of the list.[iv]
  5. Using appropriate policies, procedures and technologies, mitigate[v] those risks.

These are all implicitly included in R1.1, even though that might not be obvious. I don’t have time to explain my reasoning for this here, but if you disagree I’m willing to fight you to see who’s right (you’d have to pay your travel to Chicago, of course).

Risk assessment methodologies
Lew’s words for this section are: “The methods you use to assess risk should be spelled out in this section. Each methodology (you can use more than one) will lay out the steps you will need to take to assess the risks you identify.  These steps should take into account the inputs to the process (e.g., threat sources, threat events, vulnerabilities, predisposing conditions, etc.).   Simpler may be better here, but you will need to select the methodologies that you determine are best suited to your organization. If you create a complex methodology to assess your risks, then you will need to be able to explain that methodology to an audit team.”

Of course, Lew isn’t telling you here what your risk assessment methodology should be. In his December article, he did give a broad suggestion of this: It should be based on NIST 800-30, NIST’s “Guide for conducting risk assessments”. Lew said regarding 800-30: “I expect developing a plan by implementing this document and approach would work well for CIP-013-1.” I agree with him on that, and I’ll add that 800-30 has played a big role in the methodology I’ve developed with my clients. However, I would add that you shouldn’t think all of 800-30 will be applicable to CIP-013 compliance. As with other NIST documents, it is aimed at a very wide audience (basically, any organization in the US, although all NIST 800 series document are in theory aimed only at Federal government agencies), and you always have to separate what applies in your case from what doesn’t.

Definitions
Lew says “Any terms used in risk management that may be ambiguous and that are not defined in the Standard should be defined here. Try to keep to generally accepted definitions. Unusual definitions will probably be questioned.” Once again, this is very good advice. You should define the terms you’re using in your risk analysis – including risk, vulnerability, impact, likelihood, etc. And you should make sure you’re following those definitions.

You definitely shouldn’t assume that everyone knows what a risk or a threat is. It’s true that everyone knows what they are – but everyone has a different idea! More importantly, the auditors will almost inevitably have a different idea of what these terms mean than you do, and I can absolutely guarantee that different auditors will define them differently.  This of course creates a lot of problems in the NERC Operations and Planning standards, as well as in the prescriptive requirements in CIP-003 through CIP-011. However, it isn’t really a problem in CIP-013. As long as everyone – NERC entity and auditor - knows what the terms in their methodology mean, it’s fine if their definitions don’t agree.

I also want to point out that you can “define” a term without coming up with a Webster’s-style definition. What’s much more important is showing how each term fits into your methodology. For example, NIST 800-30 uses “threat” as its fundamental term (as do I). The risk assessment process starts with identifying threats, and builds from there. However, the authors point out that you could just as legitimately start with vulnerabilities as your fundamental term (in fact, the Recommendations section of every security vulnerability assessment that I’ve ever seen – including NERC CIP-010 R3 SVA’s – uses this approach). I think trying to base your CIP-013 risk assessment on vulnerabilities rather than threats would make the approach more cumbersome (although I don’t have time or space to tell you why I think this). But making vulnerabilities fundamental would certainly be doable, if you saw some big advantage.


II. ASSESS

Identify possible risks
The first step in the Assess phase of your plan should be risk identification, since R1.1 starts out with “identify and assess” risks. From the work I’m now doing with clients on CIP-013, I believe risk identification (although I prefer “threat identification”. See end note ii below) may well be the hardest part of the CIP-013 compliance process – or at least it’s the one that requires the most creativity.

Why do I say creativity is needed? Because CIP-013 doesn’t provide a list of risks that you should consider for mitigation in your plan. It would be great if NERC developed such a list, but I know it won’t happen. Other organizations will hopefully recommend risks to be considered, including one I’m part of, the Supply Chain Working Group of the NERC CIPC. The SCWG is currently developing six short papers on supply chain risk management (and – in a momentary lapse of good judgment – I have volunteered to lead one of those groups, which is tasked with writing a paper on supply chain risk management lifecycle. Since the SCWG is open to everybody, if you would like to participate in the web meetings for drafting this paper, please drop me an email at the address at the end of this post); these papers will certainly provide suggestions for risks you should consider for mitigation in your CIP-013 plan.

But there are lots of other sources of risk information as well. Lew lists four of them in his article, but other good ones include:

1.       The 2018 NRECA/APPA white paper on supply chain risks for small entities (although I don’t see anything in there that doesn’t apply to large entities as well. I think it’s a very good document for any electric utility, whether subject to CIP-013-1 or not);
2.       The 2015 UTC white paper on cyber supply chain risk management for utilities (also very good);
3.       The 2014 DoE/NERC CIPC (ESCSWG) document on cybersecurity procurement language (really excellent);
4.       The 2018 North American Generator Forum white paper on supply chain security management;
5.       The 2018 NERC/EPRI report on supply chain risk assessment;
6.       The 2019 NERC draft report on cyber supply chain risks;
7.       NIST800-53 r4 Appendix F-SA; and
8.       NIST 800-161.

There is a big difference between the sources Lew cites and the ones above. Lew’s are sources primarily of technical vulnerability information (like DHS NCCIC or the E-ISAC), while mine are sources of mitigations for supply chain risks. While neither Lew’s sources nor mine can be used without restating what is provided, I believe that in general particular technical vulnerabilities aren’t directly related to supply chain risks; rather, they are related to more general cyber risks that apply to the systems directly. In my opinion, supply chain risks have much more to do with processes and procedures (executed at utilities or vendors) that are used in procurement and installation of procured products, than they do with particular technical vulnerabilities in those products. In other words, I prefer the sources I’ve listed over Lew’s.

But even using my sources, you have to “restate” the mitigation to identify the risk “behind” it. For example, one of the mitigations listed in the APPA/NRECA document is “Limiting the systems that can be accessed remotely”. What’s the risk that this mitigates? You could state it as “The risk that systems that don’t need to be accessed remotely will nevertheless be accessible.”

Of course, even limiting your search for supply chain security risks to the sources I’ve stated, there are a huge number of risks to consider! The next step will be assessing each risk to determine its magnitude, which will probably be low, medium or high. It would probably be a good idea at this point not to even assess any risk which you are sure is low (i.e. you would only assess high or medium risks, which means high or medium likelihood and/or high or medium impact). If even that seems to be too many – and I’ll stipulate that anything above 50 is too many – then you might just select high risks for assessment).

Once you have a list of risks that you have selected for assessment, you can go on to the next steps of assessing and prioritizing risks. However – and I hate to disappoint you – I’m going to save that discussion for Part II of this post, coming soon to a blog near you! That part will not only finish the discussion of Lew’s February article; it will also go on to discuss how CIP-013 will be audited.
­


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. My offer to NERC entities of a free webinar workshop on CIP-013, described in this post, is still open! Let me know if you would like to discuss that, so we can arrange a time to talk.


[i] I know some would argue that CIP-014 is a risk management standard. CIP-014 R4 requires the owner of a Transmission substation or Control Center that is in scope to perform a physical “threat and vulnerability assessment”, while R5 requires them to develop a physical security plan to address the threats and vulnerabilities identified in the assessment. Of course, the physical security plan is risk-based, but it isn’t a risk management plan – since it doesn’t allow the entity to identify and assess other risks, and mitigate those. I’m not dogmatic about this, but I just don’t think it’s the same thing as CIP-013 R1.

[ii] I also consider the existing “plan-based” CIP requirements to be implicitly risk-based – this includes CIP-003-7 R2, CIP-007-6 R3, CIP-010-2 R4 and CIP-011-2 R1. These all require the entity to have a plan or program (although even that is just implicit in CIP-007-6 R3) to achieve a certain objective, but IMHO there is no way to do that without considering risk. The objective you are achieving is always risk mitigation, e.g. risk from malware in CIP-007-6 R2 or from use of TCAs or RM in CIP-010 R4.

[iii] You may have noticed that it’s awkward to talk about the “degree of risk” of a risk. I would prefer that my step 1 required the entity to identify threats to the BES, not “risks to the BES”; then step 2 would require the entity to determine the degree of risk posed by each threat. This is the terminology used by NIST 800-30, and it also makes sense to me. I think of risk as a magnitude, whereas a threat is simply a statement of something that poses danger, such as “A software vendor won’t have good internal security, and a malicious third party will plant malware in one of their products while in development.” However, CIP-013 uses the term risk in both cases – and this follows FERC Order 829, which does the same thing. I don’t want to confuse my readers too much by introducing a different terminology at this point, although I’m strongly suggesting my clients should follow 800-30’s example in this regard.

[iv] R1.2 lists six mitigations that are mandatory – and they’re mandatory because FERC said (in Order 829) that they need to be included in the risk management plans. Like any mitigations, these six mitigations are all based on particular risks. However, unlike all of the other risks you identify and assess for your CIP-013 plan, you essentially need to rank these six risks as the highest and place them at the top of your list; this way, they’ll definitely “make the cut” to be mitigated. But these six risks are in no way intended to be the only ones you mitigate in your plan, although I know some people – including at least one or two CIP-013 drafting team members – who believe that CIP-013 is pretty much just R1.2, while R1.1 is simply some flight of fancy that can be ignored. I certainly can’t say that auditors will consider doing this a violation, but I can say that this strategy will strip away most of the benefits that would come from correctly complying with CIP-013.

Think about it. I don’t think there should be much doubt that supply chain is the most important area of cyber threats in the world today (if not the most important), for just about any industry and any organization. So why wouldn’t you want to identify all important risks and mitigate the most important of these (which includes the six R1.2 risks, of course), since you’re allowed to choose the risks you want to mitigate in CIP-013? In CIP-002 through CIP-011, you aren’t given the chance to look for important threats and mitigate them, using dollars allocated to you because of management’s fear of NERC/FERC noncompliance – so if you decide that phishing or ransomware should get a lot more attention than patch management in CIP-007 R2, you have to do that using another budget, not your NERC CIP budget. You have to implement the mitigations described in the CIP 2-11 requirements, and you don’t have any power to make substitutions. In CIP-013, these choices are all up to you.

[v] You may notice that the word “mitigate” isn’t in R1.1. Even though the drafting team included that in the purpose statement, they left it out of the main requirement! Of course, there’s no question at all that your CIP-013 plan should include mitigation of risks, not just identification and assessment.

Thursday, March 14, 2019

The FOIA request



Someone emailed me today to ask if I was the blogger behind the FOIA request for NERC to identify the NERC entities behind Notices of Penalty. No, I’m not, although I know who the blogger is. I don’t actually know him and we’ve never exchanged emails. He’s one of the many practitioners of the great sport of Utility Bashing, which I have written about in at least three posts, including this one, this one and this one. It sounds like this gentleman and some of his friends have decided that the best way to reveal the decrepit state of security in the electric power industry is to get the names of all CIP violators.  

If these people were right that CIP violations automatically equate to bad security, I might agree with their effort. But as I pointed out in this post after the $10MM Duke fine was announced, CIP compliance isn’t a good measure of cybersecurity. Electric utilities spend huge amounts of resources on tasks that are required for CIP compliance, but have little to nothing to do with security. And this inevitably siphons money away from mitigating cyber threats that aren’t addressed at all in CIP nowadays (and never will be, until there is a fundamental rewrite of the CIP standards and compliance regime), including the four I mentioned in the post just referenced: phishing, ransomware, machine-to-machine access into Electronic Security Perimeters, and vulnerabilities in custom-developed software.

A utility that tried to treat all cyber threats the same (whether or not they’re subject to a CIP requirement), and allocated their cyber risk mitigation resources strictly based on the degree of risk posed by each threat, would probably end up paying a big bill like Duke. And a utility that threw every dime they had into CIP compliance and had a program that auditors swooned over, would of course always have clean audits. Yet which one would have better cybersecurity? No question, it would be the first one. Because they would be spending every dollar so that it mitigated the highest amount of cyber risk. The 100% compliant utility would be spending large amounts of their cyber budget mitigating risks that were already pretty well mitigated, while ignoring some of the biggest cyber risks in the world today.

I’ve heard there’s a good chance the FOIA request will succeed, to the extent of getting NERC to reveal names of violators that are a number of years (five?) old. I don’t think that’s a bad thing. But I also don’t think it will improve grid security at all. Indeed, to the extent it will make utilities devote even more cybersecurity dollars to making sure they have absolutely bulletproof CIP compliance programs and even less to cyber threats not covered by CIP at all, it will weaken grid security, not strengthen it.


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. To discuss this, you can email me at the same address.

Wednesday, March 13, 2019

“Securing the Manufacturing Supply Chain: Getting Tactical” – upcoming conference in Chicago


I’m pleased to call your attention to what promises to be a very good ICS (industrial control systems) supply chain security conference in Chicago on April 10. The sponsor of the event is the Digital Manufacturing Institute, a Chicago-based initiative funded by the Department of Defense, other federal departments, and a number of major companies, to innovate and promote use of digital manufacturing technologies.

Of course, a major component of this effort is cyber security, and – as we all should know by now – supply chain security is almost without a doubt the biggest cyber threat facing the industrial sector, and especially the electric power industry, nowadays. The Institute was named DoD’s hub for cyber security in manufacturing a year ago. As you probably know, DoD buys lots of manufactured products and operates its own manufacturing facilities. For obvious reasons, they are extremely concerned about securing their own supply chain, as well as that of American businesses.

The conference itself is being organized by Verve Industrial Protection, a company you should get to know if you don't already.

You can read about, and sign up for, the event here (there’s a $150 fee, unless your organization is already a member of the Institute). I will be speaking on a panel in the morning with three others, one of whom is Eric Byres, one of my heroes. He is the founder of Tofino Security and inventor of their technology (now sold under the Belden name) for ICS firewalls. He is now the CEO of aDolus Inc., a research company investigating security technologies to aid in the detection of malicious and counterfeit software in “smart devices” used in the industrial, aerospace, and medical fields.

Of course, the power industry is just one “manufacturing” industry, but it has a special concern about supply chain security now because the current Russian attacks on the industry are coming through the supply chain. I’m told that a person particularly knowledgeable about those attacks will be presenting about them at the conference. Hope to see you there!


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. To discuss this, you can email me at the same address.

Monday, March 11, 2019

The full story of the Triton attack



Blake Sobczak of E&E News conducted a great investigation of the Triton malware attack and published it last week. The publication is normally behind a paywall, but Blake gave me a link to a public copy. This is very good reading, partly because it’s a wonderful piece of reporting, but also because this is such a significant attack against industrial control systems. As Robert M. Lee of Dragos has been saying for a while (and as I heard him say again last Friday at RSA), this is the first attack on ICS that was designed to kill people – perhaps quite a lot of them.

And by the way, guess which nation-state was most likely behind this attack? Just look at my last post. What a surprise!


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.

Sunday, March 3, 2019

General Gerasimov does us all a big favor!


Yesterday’s New York Times features an article that begins with these two sentences: “The chief of Russia’s armed forces endorsed on Saturday the kind of tactics used by his country to intervene abroad, repeating a philosophy of so-called hybrid war that has earned him notoriety in the West, especially among American officials who have accused Russia of election meddling in 2016. At a conference on the future of Russian military strategy, Gen. Valery V. Gerasimov, the chief of the general staff, said countries bring a blend of political, economic and military power to bear against adversaries.”

Further down in the article, there’s this sentence: “Though definitions of the term vary, some analysts see a progression from the blend of subversion and propaganda used in Ukraine to the tactics later directed against Western nations, including the United States, where Russia’s military intelligence agency hacked into Democratic Party computers during the 2016 election. Russia denies interfering in the election.”

Even further on: “In the 2013 article, General Gerasimov wrote that there were no clear borders between war and peace in the modern world. Militaries fight in peacetime, he said, and political and economic means are deployed in war.”

Of course, nothing directly stated above should be hugely surprising to anyone who has followed the news on Russia in recent years. So why am I bringing this up? Because of what is directly stated (by a Moscow journalist who’s still alive, so he must reflect Putin’s opinions) in the last sentence of the article. This sentence quotes Pavel Felgenhauer, a military analyst and columnist in Moscow for the newspaper Novaya Gazeta, as saying “We don’t care what the West thinks, we are enemies.”

Of course, this was implicitly stated by Gen. Gerasimov. Just consider the following syllogism (my wording, but it’s all directly implied by his statements and by recent news articles in the Wall Street Journal):

  1. “We fight our enemies using both military and other means, including cyber attacks.”
  2. “We have launched serious cyber attacks against the US in many forms, including the 2016 elections and also a continuing campaign aimed at penetrating the systems that control the power grid. One purpose of those attacks is to be in a position to cut off power to key military facilities in the event of an armed conflict.”
  3. “Therefore, the US is an enemy of Russia, just as much as if we were in a purely military conflict. The only reason we’re not using military means (possibly including nuclear weapons, as we have repeatedly threatened) is we don’t think it’s an appropriate time to do so. That might change in the future, since we’ll most likely be at war with the US for a long time.”
  4. “Have a nice day.”
So we all owe a big debt of gratitude to General Gerasimov. At least there can be no misunderstanding of where we stand in Russia's eyes! Certainty is a wonderful thing...
Which reminds me: I wrote a post recently (currently well over 1,000 views) that wondered why nobody seems to be in any great hurry to investigate the statement by the CIA, FBI and the Director of National Intelligence in this year’s Worldwide Threat Assessment, to the effect that the Russians now have the ability to “bring the grid down…for at least a few hours” - using malware planted by cyber attacks, of course. This is especially odd, since an outage caused by the Russians in the Ukraine in 2015 (and a follow-on in 2016, presumably to show that the Russians were busy improving their malware all the time, in case anyone thought of trying to pull the same trick on them) was investigated – with great publicity - by various government agencies and other groups, and the findings were the subject of white papers and DHS briefings across the country. 

Has my post created a flurry of activity, with people jumping on planes to find out what happened and inform the electric power industry so they can shore up their defenses against these attacks – and root out the malware that may already be in their control networks (and it’s a lot shorter ride from DC to any US city than it is from the US to Kiev, except for the ride from DC to Honolulu. But I don’t believe the Russian attacks have targeted Hawaii, perhaps because an outage there would never spread to the mainland grid)?

I know it will surprise you greatly to hear this, but even though I’ve kept my phone close to me day and night, I have yet to hear of any investigation either being under way or starting. Not only that – I’ve contacted two people who hold responsible positions at two of the four organizations that I believe should do the investigation (namely the NERC E-ISAC, FERC, DoE and DHS. I name them because the investigation would need to look at the evidence that the FBI and CIA have already gathered, then determine whether or not the Russians have actually penetrated networks at grid control centers; this is the only plausible way an outage of any size could be caused in the US. Only another government agency –and while NERC isn’t technically a government agency, it is a “delegate” for FERC, which is part of DoE – would be allowed to see this evidence, although I can see private organizations like SANS and Dragos being brought in to help the agency or agencies doing the investigating).

While both of these people did engage in a short email dialogue with me, neither one has gotten back to tell me a) the investigation is underway; or b) they are getting ready to start one; or c) they already have investigated the FBI and CIA statement, and – while they can’t tell me the conclusion, of course – they are satisfied they know what actually happened. I would be more than happy to hear any of these three things. And of course, I wouldn’t publish it in this blog, or anywhere else.

Two more questions:

  • Has anyone given me a good reason why there shouldn’t be an investigation of this? I’ve heard a few of those, and I’ll discuss them in a post in the (relatively) near future. Suffice it to say that I don’t think any of them hold water. (Note on 3/31: I'm now up to over ten excuses, a few of which are just misunderstanding, but at least a few of which may be deliberate attempts by what I'm beginning to call the "government-cyber complex" to divert attention from this. I intend to write a post on one of the latter this week)
  • Then do I have a good idea what might be the real reason there’s been no investigation? Yes, I do. I’ll also address them in a post in the relatively near future, so you’ll have to live in suspense for the time being. I’ll give you a hint now: It doesn’t involve any particular US government official. 
Of course, hopefully my phone (or email) will ring with news from one of the four organizations, and I won't have to do any more posts on 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