Monday, November 18, 2019

"(You) don’t know how lucky you are, boys…"



I noted a number of interesting statements at GridSecCon this year – as well as the Friday trip to SecureWorks’ headquarters in Atlanta, which proved to be very interesting - which I’d like to tell you about. I’ll gradually work through them as I get time; I hope I’m finished by the next GridSecCon!

One comment I found especially interesting was during a panel on natural gas security. Robert Mims of Southern Companies is in charge of cyber security for their natural gas division. He lamented the fact that his team consists of exactly four people, while his peer on the electric side has “hundreds” of people working for him.

What’s the difference? He doesn’t face a mandatory cyber standard like NERC CIP. He had no doubt that if he did, he would have a much bigger head count than he does (of course, even if the electric side didn’t have any mandatory cyber standards to worry about, I’m sure their team would still be multiple times the size of the gas team. There are just a lot more moving parts on the electric side, and in general I believe that the dangers of a cyber attack causing serious physical damage in gas are much lower than in electric).

And this goes to the real reason why mandatory standards are needed in some cases: the flow of money from management increases substantially when there are penalties to worry about (and I don’t think the monetary penalties are the biggest incentive for compliance. I’ve always said that power companies would do almost everything they could to avoid violations even if the “penalty” were a trip to Disney World. The reputational, etc. damage is much more painful than the monetary damage, in the long run).

So as much as I complain about problems with the CIP standards, I don’t want to see mandatory standards go away. However, I do think all security standards should follow one Golden Rule: As much as possible, they should simply require the entity’s cyber staff to do on their own what they would do if they received the same level of funding as they now do with the current NERC CIP standards, yet they didn’t have to comply with any standard. I contend they would “identify and assess” their cyber risks (to use the words found in CIP-013 R1.1, which is the best example so far of this approach), and mitigate the most important ones. And they would mitigate them using the most efficient approach possible – since they wouldn’t have to follow prescriptive requirements that inherently aren’t the most efficient approach, sometimes not by a long shot.

In other words, I would rewrite all of the CIP standards like CIP-013, although I’d make improvements to that, and there are other considerations as well[i]. But if you take away mandatory standards, you turn off the money spigot. Thus, a number of NERC entities have freely admitted to me that they would never get the same level of cyber funding as they do now, were it not for NERC CIP. Some even admit to justifying purchases as being “required by NERC CIP”, when in reality that’s not the case. But you didn’t hear that here, of course…

So tonight, you should thank your lucky stars that NERC CIP is mandatory, not a voluntary framework. As the Beatles said (in “Back in the USSR” from the White Album), “…(you) don’t know how lucky you are, boys…”


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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.

[i] If you’d like to hear more about this, listen to my recent webinar, or drop me an email and I’ll send you the slides.

Thursday, November 14, 2019

How NOT to comply with CIP-013, part I



I will admit that I’ve emphasized a little too much that there are many possible ways to comply with CIP-013 R1, and I need to swing the pendulum back in the other direction a little. While it’s true that the standard gives you very little to go on regarding what should be in your R1 plan, it’s also true that there are some things that definitely are required. This is especially true since NERC provided good information in their most recent Evidence Request Tool about what audits will focus on. If something will be audited on, you need to do it – at least that’s what my parents raised me to believe.

This post (and part II to follow very shortly) describes mistakes you can make, that can lead to your being non-compliant with CIP-013.

I. You don’t address both R1.1 and R1.2 in your plan
I’m sure that, even a year after FERC approved CIP-013, many long-time NERC compliance professionals look at R1 and have the following reactions:

  1. Their eyes glaze over when they read 1.1. All this talk about identifying and assessing risks, without telling you any concrete steps that you need to undertake, sounds like some sort of mystic writing from the Upanishads, not a NERC requirement. Every other NERC requirement they’ve seen tells you exactly what you need to do and when you need to do it, period.
  2. When their eyes fall on R1.2, they grab onto it like an old friend, even though it’s a friend that’s changed since the last time they saw him. The six items in R1.2 don’t tell you exactly what you need to do and when, but they at least do tell you particular objectives you need to meet, such as “Disclosure by vendors of known vulnerabilities related to the products or services provided to the Responsible Entity”.
It’s inevitable that many of these people will decide that R1.2 is the whole of R1, meaning that as long as your plan covers these six risks (there are actually eight, since R1.2.5 and R1.2.6 address two risks each), you’re fine. In fact, when a vendor of a software tool to aid in CIP-013 compliance spoke at GridSecCon, it was clear that he thought R1.2 was all that was required to be in the entity’s supply chain cyber security risk management plan.

Well, it’s not. R1.1 isn’t there just for the fun of it, but because the CIP-013 drafting team was taking FERC seriously when they said in Order 829 that NERC entities should identify supply chain risks to mitigate. True, FERC did require all of the specific items in R1.2 at various random points in their Order – and the SDT helpfully gathered them all into one place in the standard – but these are in no way intended to be the only supply chain risks that NERC entities face, or even the most important ones. It’s still up to the entity to identify (in complying with R1.1) other risks that are important and mitigate those, along with the risks in R1.2.

And if you don’t believe me, take a look at NERC’s Evidence Request Spreadsheet 3.0, discussed in the last item below.

II. You don’t address the five risk categories in R1.1
Although it’s not too obvious, R1.1 identifies five categories of supply chain risk that need to be “identified and assessed” in your plan. They are[i]:

  1. Product risks from procurement of equipment and software;
  2. Risks from procurement of services applying to BCS equipment and software;
  3. Product risks from installation of equipment and software;
  4. Service risks from installation of equipment and software; and
  5. Transitions between vendors.
Of course, each of these risk categories can include many different risks. I’ll provide one example for each category:

  1. The risk that a supplier’s software development environment will be compromised, and someone will plant a backdoor in software destined for one of your BES Cyber Systems – which they’ll later exploit (as happened with Delta Airlines last year, although in their case it was 800,000 credit card numbers that were stolen).
  2. The risk that a utility will contract with a vendor of services for BCS, who doesn’t vet their new hires properly. A person with malicious intent will inadvertently be hired and allowed to access – remotely or onsite – some of your BCS.
  3. The risk that a software product you install on one of your BCS won’t have the most recent patches applied to it, and will be compromised after you install it.
  4. The risk that a vendor will fire an employee who has onsite access to your BCS, and won’t immediately tell you about it. They will come to your site and take revenge on the vendor by disabling one of your BCS (of course, this is the risk behind R1.2.3. The risk behind R1.2.6 – actually two risks – also falls in this category. The other four items in R1.2 fall into category a).
  5. The risk that, when you leave one vendor and start purchasing from a different one, the first vendor won’t destroy all of the data they have stored about your BES Cyber Systems. Someone will hack into their network and steal the data.
I freely admit that, if you omit one or two of these categories in your plan, you’re very unlikely to be cited for a potential violation. When most people talk about CIP-013 (including people at NERC and the Regions), they usually discuss risks that fall into categories a and d. However, all five of these categories are called out in R1.1. You need to at least consider all of them. If you decide there aren’t any risks that are likely to apply to you in one of the categories, you should document why you made this decision, but you don’t need to try to dream up risks just for the sake of having at least one in each category.

III. Your procedures don’t match you plan
Whatever is in your R1 plan, there is one thing that is very certain: In R2, you need to do what you said you would do in R1. But what if your procedures don’t match what’s in your plan? CIP-013 isn’t that different from the other CIP standards, in that what really counts is the procedures you write to comply with it. The big difference is that, with say CIP-007 R2, you have to write patch management procedures that match what the different parts of that requirement mandate. With CIP-013 R2, you need to write supply chain security risk management procedures that match the plan that you developed in R1. So in R1.1, you’re literally writing the “requirements” that you have to have procedures for in R1.2!

So how do you avoid being non-compliant in this way? Simple (at least in theory): when you write your plan, you need to make sure there’s nothing in it that you aren’t positive you can do in practice. And if there’s something you’re not sure about, take it out of the plan. You can always add it back later.

For example, suppose you commit in your plan to conducting full security audits of say your top five suppliers. However, when it comes time to do the supplier audits (say, within a year of CIP-013 becoming enforceable), you realize how much staff time and money these will require, and you begin to think of all the other things you could do to mitigate supply chain security risks if you hadn’t committed the time and money to audits. You should certainly be able to change your mind at this point, but you will need to revise your plan so that it will match your new course of action. When you’re audited, you will need to provide both plans, as well as explain why you made the change between them (and emphasize how it will result in greater supply chain security risk mitigation).

This isn’t a new development in CIP. Since CIP v1, it has always been clear that you must show that you complied in full with any plan or program that you develop as part of the compliance process. For example, if in your CIP-008 R1 cyber security incident response plan you indicate that you will take a certain step in your incident response, yet your record of a CSIRP tabletop exercise doesn’t indicate you took that step, you can be (and entities have been) cited for this omission.

IV. You don’t have evidence that you fulfilled your plan
CIP-013 R2 is also like most of the other CIP requirements, in that it requires that you have documentation to show you did what you said you would do in your R1 plan. But it differs from most of the other CIP requirements, in that you’re not required – with one exception, discussed below - to have documentation of every instance when you did something that was called out in the plan.

The Measures section of R2 says you must have “documentation to demonstrate implementation of the supply chain cyber security risk management plan(s), which could include, but is not limited to, correspondence, policy documents, or working documents that demonstrate use of the supply chain cyber security risk management plan.” In other words, you must not only show the auditors that you developed a good R1 plan, but that you implemented the plan – yet at the same time, you don’t have to show that you followed it without fail in every instance.

For example, suppose your plan says you will send out a security questionnaire to vendors and suppliers every year. If the answers reveal that a vendor’s controls are weak in a particular area, you will talk with them to determine if they need your help or advice in implementing those controls (e.g., maybe a vendor really needs a SIEM, but has no experience or understanding of how to go about implementing and maintaining that).

Do you need to show documentation of every questionnaire you sent out and received, as well as of every phone call or email you sent to your vendors to follow up on deficiencies? No, but you do need to provide enough evidence to convince the auditor that you actually followed this particular part of your plan (that is, that you didn’t just throw stuff in your plan that you had no intention of following up on).

However, there is one part of your plan that does require evidence of every instance in which it was applied. I’ll talk about that in the next section.

V. You don’t execute and document procurement risk assessments (PRAs)
NERC’s most recent Evidence Request Spreadsheet v3.0 shows what evidence will be required in audit data requests:

  1. In the Level 1 DR, you will be required to “Provide each documented plan(s) that addresses the applicable requirement parts in CIP-013 R1.” In other words, you have to provide your plan and show it addressed both R1.1 and R1.2 (see next section for more on this).
  2. In the Level 1 DR, you will also have to list all of the “procurements” that were planned or in effect for high/medium impact BCS during the audit period. If you’re not sure exactly what a procurement is, see this recent post.
  3. In the Level 2 DR, the auditors will take a random sample of procurements from the list you provided, and ask you to provide the following for each selected procurement:
    1. “..evidence of the identification and assessment of 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).” In other words, evidence that you complied with R1.1 in your PRA.
    2. “..the following evidence:
                                                               i.      Notification by the vendor of vendor-identified incidents;
                                                             ii.      Coordination of responses to vendor-identified incidents;
                                                            iii.      Notification by vendors when remote or onsite access should no longer be granted to vendor representatives;
                                                           iv.      Disclosure by vendors of known vulnerabilities;
                                                             v.      Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System; and
                                                           vi.      Coordination of controls for (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s).

In other words, evidence that you complied with R1.2 in your PRA.

I think items 1 and 2 above are fairly self-explanatory at this point. However, what does item 3 mean? In other words, what should your PRA evidence contain, and what documentation will you need for it? At a high level, I think it should contain the following:

  1. The list of risks (although I use the term threats here) that you considered in the PRA. Do you remember the set of threats that you identified for mitigation in R1.1? You should consider a subset of these, namely those that apply to the vendor or supplier in question. And how do you determine what these are? Well, that’s magic, but if you’re interested in more information on it, see the last paragraph below.
  2. How you assessed those threats, to determine which were already mitigated (usually by the supplier or vendor) and which still need to be mitigated (at this point, that usually means you have to mitigate them, but there is still time to ask the supplier or vendor to help you – e.g. require that the vendor provide a security vulnerability assessment before shipping the product(s) to you). You do this using the vendor or supplier risk score (which should be calculated for each threat, not just an overall score for the vendor or supplier), combined with the product or service risk score (which would be a single overall score for that product or service) to get a “procurement risk score”. If that score is low, then this risk is mitigated for this procurement and no further action is needed on it. If it’s high or medium (or perhaps just high, if you’re being conservative), then you do need to determine what additional mitigations are required during the procurement to bring it to low (in my way of seeing things, a low risk score means the risk is mitigated).
  3. How you determined the mitigations required in this procurement, based on the risks you considered in the first step above (and that’s magic, too!).
Even though you don’t need to provide instance-by-instance evidence for all other items in your R1.1 plan, for procurements you do, since the auditors will randomly sample the procurements and require evidence for certain ones.

Would you like a little more explanation of some of the things I’ve just said? I’d be glad to do that – for your organization alone. I’m still offering a free two-hour (or less, if you prefer) webinar on CIP-013 compliance, for anybody in your organization who will be involved in the program. This includes people in procurement, legal, cybersecurity, and – oh, yes! – NERC compliance. The agenda is very flexible, so we’ll develop it in a discussion before the webinar. If you’re interested in this offer, please drop me an email at tom@tomalrich.com, and I’ll send you more information.


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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.

[i] I’m not going to go through the reasoning I used to arrive at this list, but I hope it won’t be too hard to discern. If you question how I got anything on this list, drop me an email and I’ll tell you.

Wednesday, November 13, 2019

My webinar recording is up!




The recording of the webinar I did last week on “How can we regulate cyber-security for critical energy infrastructure?” is now available. I thought the webinar went very well, with some very good questions. But I’d certainly appreciate hearing your comments as well, positive or negative. Just email them to me at tom@tomalrich.com.

BTW, if you'd like to see the slides, I'll be glad to send them to you. Just email me.


Any opinions expressed in the webinar are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.


Monday, November 11, 2019

Lew covers Lows, and Tom rants



The September/October edition of RF’s newsletter contains another great article by Lew Folkerth[i]. He has been concentrating on CIP-013 (as I have) since late last year, but in this article he switched to the other big current concern of the NERC CIP community: Low impact assets, and specifically the two new versions of CIP-003 R2 that are coming out early next year. And per what we’ve come to expect, he covers Lows with typical Folkerthian (I’ve just coined a word. Remember, you heard it here first!) thoroughness.

Specifically, Lew discusses every CIP requirement that applies to Lows, both those in effect now and those on the way. And he provides good insights into everything he discusses. So where are the flaws in this article? Nowhere that I can see.

I’ve had a few people ask me lately what’s the deal with the two new CIP-003 versions: CIP-003-7, which becomes effective on January 1, 2020, and CIP-003-8, which comes into effect on April 1, 2020. Most people can’t tell the difference between them, which is quite subtle, I’ll admit. Here’s the story (and here I’m speaking more directly than Lew, being a NERC employee after all, is permitted to): You should really just consider CIP-003-7 as the next version, and ignore CIP-003-8[ii]. Literally the only difference between the two is that CIP-003-8 incorporates a small change that FERC ordered when they approved CIP-003-7, but it’s almost inconceivable that you won’t already have incorporated that change when you develop your CIP-003-7 program.

That change has to do with the Transient Cyber Asset (i.e. laptop) controls in Section 5 of attachment 1 of CIP-003. When FERC approved CIP-003-7, they pointed out that the suggested controls relating to TCAs owned by a third party (almost always a vendor, of course) in Section 5 of Attachment 1 just suggest that the entity review what the vendor has done to mitigate the risk of malware being on the TCA, not actually mitigate it. They ordered that NERC revise the requirement so that it also requires mitigation of the risk.

Therefore, Section 5 of CIP-003-8 Attachment 1 contains the sentence

5.2.2 For any method used pursuant to 5.2.1, Responsible Entities shall determine whether any additional mitigation actions are necessary and implement such actions prior to connecting the Transient Cyber Asset.

Let me reword this for you: CIP-003-7 stated that you should review the vendor’s controls on TCAs, but it didn’t explicitly require you to do anything if you didn’t like those controls. This means, for example, that you would

  1. Discover that one vendor wasn’t doing anything at all to prevent malware on their laptops used at customers (which of course is highly unlikely in itself, since all vendors have lawyers who have told them in no uncertain terms the liability they’d face if one of their laptops infected – say – a critical substation and caused an outage).
  2. However, FERC assumed you would do nothing more about this, without being prodded by the CIP standards. So you wouldn’t.
  3. Then, when someone from the vendor came to your substation bearing one of those suspect laptops, you would just wave them through saying “Go ahead and connect to any device you want, even though there’s a good chance you have malware on your laptop. What could possibly go wrong?”
Of course, this is a ridiculous idea. Nobody who works in IT or OT, who isn’t literally insane, would do this. Yet FERC seemed to think this was a big problem, so they ordered NERC to change the requirement to make it clear the entity needs to do something when they have reason to believe a vendor isn’t doing what it should to protect its laptops from malware. This is roughly the equivalent of writing a law requiring parents to take action if they’re told their house is on fire and their children are trapped inside, based on the assumption that without such a law, they’ll just go about their business as usual, while saying “Really? Now that’s interesting….”

So FERC just ordered that NERC make this one change. But as you know, NERC can’t just edit a standard to put in a small change, then publish it and go out to lunch. To make the change that FERC ordered, NERC’s Rules of Procedure (RoP) require it to

  1. Write a Standards Authorization Request for this change, and ballot that SAR;
  2. Have a drafting team make the change (in this case, it was the CIP Modifications SDT, which drafted CIP-003-7 originally and which is still working today); then
  3. Submit it for a first ballot by the NERC ballot body. There were 205 votes for and 30 against in that first ballot in the fall of 2018, yet the RoP doesn’t consider that final (not because this isn’t a sufficient majority, but because I believe there always has to be another ballot after any standard meets the required majority, for some reason). Thus, there had to be a “Final Ballot”, which was submitted and approved more than six months after the first one.
  4. Of course, after that the NERC Board of Trustees had to approve CIP-003-8 at their next quarterly meeting, and finally FERC had to approve it, which took a few months in itself.
So now we have a new version of CIP-003 that differs by one sentence from CIP-003-7, and in practice literally requires entities to do something they’re all already doing for CIP-003-7 compliance. Yet NERC still has to go through the above process, which stretched out more than a year. Granted, I doubt anyone had to devote a huge amount of time to this, since it was all fairly routine. And since the SDT that had developed CIO-003-7 was still operating, NERC didn’t have to put together a new SDT, which would have been a big job in its own right. But the fact that everyone had to go through all these steps for what could easily have been a one-hour fix (which shouldn’t have even been needed in the first place) is pretty disappointing.

So who’s to blame for this? FERC deserves some blame, because they ordered the change. But the funny thing is that FERC always orders NERC to make changes to CIP standards that they approve (and there are few if any CIP approvals where they haven’t ordered at least one change), yet never admits that they know that NERC’s Rules of Procedure require it to go through the full standards development process for even the slightest change; instead, they just state that NERC should change the standard. Of course, I’m sure FERC isn’t allowed by law to consider NERC’s internal procedures when they decide a change is needed to a standard they’ve just approved.

So the real blame falls on the NERC Rules of Procedure – although not on any particular NERC employees. Since the above is the only way to make a change in a NERC standard that’s already approved, it’s a real inhibitor to improving existing standards (e.g. coming up with some “definition” of “programmable”, which NERC put in the SAR for the CIP Modifications SDT, but which they’ve never addressed and never will, perhaps because there really isn’t a workable definition of that word), as well as developing new standards to address new threats like phishing and ransomware.

Phishing and ransomware have both been around for many years (especially phishing) and are perhaps the two most destructive cyber threats today, yet there is now not even any discussion about developing new CIP requirements to address them. I think this is a problem, but I’m not at all inclined to suggest developing these two requirements now. In my webinar last week – for which the recording should be available soon – I described a mechanism for removing changes to CIP from the standards development process. Once that is done, then any important new threat could be easily incorporated into CIP – but this would also require that all of CIP be rewritten as non-prescriptive, risk-based requirements. But until that happens – and I think various pressures will drives this to happen, within a few years – trying to develop any more CIP standards not explicitly required by FERC will literally end up causing more harm than good.

Have a nice day. 


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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.

[i] There’s also a PDF that includes all 34 of the CIP/cybersecurity articles that Lew has written for the newsletter, starting in late 2015 (including this one). You can find that here.

[ii] Of course, you can’t really ignore it, since your compliance documentation will need to reflect that you were complying with CIP-003-7 for three months and then you became compliant with CIP-003-8. And don’t be snarky – like this post – and point out to the auditors that you were compliant with CIP-003-8 on January 1 anyway, since there was no way you could develop a CIP-003-7 program without also complying with CIP-003-8. Leave that to me.

Sunday, November 10, 2019

Upcoming speaking engagement



I was quite honored to be asked recently to be the keynote speaker at the second annual IEEE Smart Grid Cybersecurity Workshop, which will be held on Thursday and Friday December 12 and 13 at the same hotel in Atlanta where the NERC CIP will meet on Tuesday and Wednesday (which I’ll also attend); the agenda is here. My topic will be – what else? – “Developing your Supply Chain Cyber Risk Management Plan”.

Of course, if you are a cynical person like me, you might point out that the smart grid has to do primarily with distribution, while CIP-013 (which of course requires the entity to develop a supply chain cybersecurity risk management plan) is a standard for Bulk Electric System assets. Why talk about CIP-013 at this workshop?

Fortunately, I already have my answer for you: I’m not talking just, or even primarily, about CIP-013. Any utility, in fact any organization that runs using computing hardware and software that they purchase, is subject to supply chain cybersecurity risks, and should have a risk mitigation plan. Exactly the same considerations go into developing a plan for cyber assets to be deployed on the distribution grid as for BES cyber assets. So there, smarty pants. And I won’t be alone in discussing supply chain security. There’s a panel on that topic right before me.

I’ll 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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.


Saturday, November 9, 2019

What could possibly go wrong?




 “The system design did not include a consideration for jaywalking pedestrians.” 

– NTSB’s Vehicle Automation Report, explaining that the software inside the Uber self-driving SUV that killed an Arizona woman last year was not designed to detect pedestrians outside of a crosswalk. 




Thanks to my brother Bill for bringing this to my attention. For Wired's in-depth story on this, go here. It seems both Uber and Boeing don't seem to get the idea that human beings don't always react the way you expect they will. This is the reason why I don't think a self-driving car could ever make a left turn in traffic safely.


Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.



Friday, November 8, 2019

Francois Lemay’s remarks at GridSecCon




I’ve posted summaries of the remarks of two members of the panel that I moderated at GridSecCon (here and here), as well as my own. The last summary (since two of the panels didn’t send me their remarks, which is fine – it was just a suggestion I made to them) is from Fancois Lemay, Cyber Security Specialist with Hydro Quebec. His comments are very succinct but obviously well thought out and definitely worth reading!


The Gordian Knot
An old Greek legend where "several knots are so tightly entangled that it's impossible to see how they were fastened.
  
The Supply chain Gordian Knot (supply chain web)
Our industry, the most critical of critical infrastructure, is currently having a data revolution where IT and OT converge, and our networks are more and more exposed to threats

Our supply chain got so entangled and complex in our critical infrastructures that we don't know any more what technologies are really deployed ?

Take security in our own hands
·        Our industry has technology that we cannot patch, and old products for which suppliers will not offer any support.
·        We still find equipment with backdoors, hardcoded passwords and multiple exploitable vulnerabilities.
·        We have Geopolitical issues with suppliers (Kaspersky, Huawei).
·        Sometime, our suppliers get breached (waterhole) and they don't know - or they know, but they’re a lot more concerned with managing their reputation than taking care of their clients.

We need to have the means to take security in our own hands, with:

·        CIP-013
·        Cybersecurity contractual clauses
·        Software and hardware Integrity
·        Cybersecurity Certification program (CyberSecure Canada, UK Cyber Essentials)
·        Vulnerability assessment tools
·        Political and reputational decisions to make
·        Government certification for critical systems and assets


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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.