For Secure & Robust ICS

We have been hopeful this information would be released on the S4x16 Main Stage, and now we can confirm that Sean McBride of iSight Partners will be presenting their GridStrike research.

Inspired by the FERC study showing a major power outage if nine key US substations were “knocked out”, iSight Partners decided to perform a similar analysis.

FERC spent approximately $1M on the study and had access to private and sensitive information. Sean will show what can be determined from only public information with a much lower budget. He will also discuss what open source information utilities should be protecting.

S4x16 is Jan 12-14 in Miami South Beach

David Perera of Politico released a good article yesterday on the difficulty of taking out the electric grid. Unfortunately the headline writers missed the mark, “US Grid Safe From Large Scale Attack, Experts Say“, and it is difficult to write two very different points in one mainstream press article. Let me try with our ICS security focused audience.

Point 1 – Taking Down An ICS Doesn’t Necessarily Cause A Catastrophe

The article did a good job of capturing this point, but it is broader than the electric grid.

Some ICS will continue to run just fine if large portions of the control systems are lost, particularly servers and workstations.

There are often safety systems to prevent really bad things from happening. Admittedly the quality of implementation of these safety systems vary a great deal.

Some of the safety measures cannot be changed over the network or even serial connections.

The skilled offensive cyber adversary / hacker will likely take control of the insecure by design and fragile ICS if he has network access, and he will be able to take all or part of the ICS down. The Operations Group will not be able to use the ICS to monitor and control the physical system. The impact of this will vary by sector and system.

Take down some electric distribution SCADA systems and there will be a delay in knowing about an outage. Take down a pipeline leak detection system, and they will likely shut down the pipeline in a few hours. Take down a gas or electric meter reading SCADA, and they will estimate bills and perhaps send people out for a manual read. Take down a turbine control system and that unit in the plant will likely not generate power until it is fixed. Take down a food manufacturing plant control system and some will run on manual operations, while others will be shut down.

The key point that David’s article captured is just because the ICS that run generation and transmission in the power grid are insecure by design and fragile it does not mean that even a skilled hacker or researcher can cause a widespread blackout.

Point 2 – The US Grid & Other Critical Infrastructure Are Definitely Not Safe From The Right Team Of Attackers

With the addition of ICSage: ICS Cyber Weapons to S4 Week we have been thinking a lot about nation state or well funded offensive security teams going after critical infrastructure ICS. We believe it would consist of:

A “Hacker”. Actually the easiest job as Dillon Beresford, Project Basecamp and others have demonstrated.

An Engineer. They need to understand the process or system that is being attacked, and determine what would cause the damage they desire. This could be expensive, hard to replace physical equipment damage that would cause a long term outage. Release of materials harmful to people and the environment. Damage to reputation. Or something subtle like Stuxnet that causes a maintenance or equipment failure issue that is costly, difficult to diagnose and saps confidence in the process.

An Automation Expert. Once the Engineer has determined what should be done, and the Hacker has provided access to the ICS, the Automation Expert has to write the logic to implement the attack. This could be logic in a PLC, changed displays, database changes, or a variety of other ICS modifications. This is a real challenge since the Automation Expert likely cannot simulate the process completely. This may have been the most impressive aspect of Stuxnet.

I’m seeing a major shift that started at S4x14 and is continuing at S4x15 to the engineering and automation aspects of attacking and defending ICS. S4x13 showed exploit after exploit of vulnerable ICS components. The leading researchers have moved beyond that and are now looking at what to do with the owned ICS and how to defend against the really bad things a skilled attack team would want to do.

What David’s article probably couldn’t tackle is the somewhat conflicting ideas that while a highly skilled hacker or researcher likely couldn’t cause a catastrophic impact to a critical infrastructure ICS, the electric grid and other critical infrastructure is highly vulnerable to a talented and motivated team with the right mix of skills.

The vaunted safety systems often have holes in them, and the people on sites can usually tell you how they would cause long term damage to the physical system. Just a couple of examples:

Safety systems are often implemented in safety PLC’s. These are your typical insecure by design PLC’s with extra redundancy. And there has been a push for years now by some vendors to integrate the control and safety systems. Change the safety logic and it will either stop the process when it shouldn’t or fail to stop the really bad things from happening.

One of my favorite examples is vibration monitoring. This is often a separate system or application, such as Bently Nevada. It can be configured to trip a turbine or some other physical system if vibration reaches a certain level. Simply change the trip value, set it to a constant value, change the scale, … and it doesn’t provide the proper safety function.

Or the safety system was designed to stop problems that have seen by equipment failure or human error, but they never considered what an active attacker would do. This is why efforts to take the ICS Safety Approach with ICS Security has never worked.

All that said, David did his homework and wrote a good article. Perhaps a better title would have been “Hackers Would Have A Very Difficult Time Taking Out US Power Grid”.

The President/CEOs of the American Public Power Association (APPA), Edison Electric Institute (EEI), and National Rural Electric Cooperative Association (NRECA) felt a recent WSJ article critical of the electric sector’s cyber security “warrants response from the electric-power industry”. It is a shame the response was weak and devoid of any argument or evidence that the WSJ was wrong in their reporting.

Together with our members, we work closely with the North American Electric Reliability Corp. to set standards that protect grid reliability and security. Before becoming enforceable, all draft standards go through three levels of approval—the industry, the independent NERC Board of Trustees and the Federal Energy Regulatory Commission.

Is that the best you got? Why not have three data points that clearly show NERC CIP is effectively improving the cyber security of the bulk electric system? And then point to a white paper on how you are benchmarking improvement in the bulk electric system cybersecurity posture and the results showing that improvement, lessons learned, goals for next 1-3 years, etc.

The fact that utilities are writing the rules that determine the cybersecurity regulatory requirements for bulk electric system owner/operators (themselves) is actually damning, not a positive debating point. Self interest would dictate that utilities keep regulatory requirements as minimal as possible, even if the utility was planning on spending more time and money on cyber security. There is no need or incentive to create regulatory risk to address security risk.

A clear example of this avoid regulation thinking are the statistics in the infamous Assante letter of April 2009. He highlighted survey results that showed that 71% of the vendors in power generation said their risk assessment found the NERC CIP standards did not require them to implement any cyber security measures. There were additional damning stats that showed the CIP emperor was naked. The numbers have not greatly improved, although CIP Version 5 is designed to change this.

Mandatory standards with fines would not have been necessary if the utilities had prudently developed cybersecurity programs to address the risk to ICS in the bulk electric system. (A small number were working diligently on the issue and NERC CIP critiques are always an unfair broad brush) Why would one expect the majority of utilities that did not feel the ICS cyber risk warranted the expenditure of time and money to write standards that would require them to spend time and money. NERC standards historically worked best when the majority of utilities saw a shared risk in the bulk electric system and wanted to force the laggards into action for their own self interest.

While NERC CIP has a multitude of problems and I would not be a CIP defender, there are clear examples where it has improved cybersecurity in the bulk electric system. Some of the owner/operators who wanted to do nothing on ICS cybersecurity have been forced to put in security perimeters, deploy anti-virus, perform training and security awareness, create inventories, … It is terribly inefficient, but it is progress for those that were doing nothing.

The letter to the WSJ is awful marketing. A terrible product makes Marketing’s job difficult, but the CIP standards deserve a better message than “WSJ you’re wrong; we are writing and implementing good standards. Really, we are doing the right thing for the security of the grid.” Since CIP compliance has been mandatory for many years now, there should be some hard, compelling data that CIP is improving the security of the grid.

Spring is here, and that means generally cool, but not cold days. Days where the wind blows through open windows, a light jacket is all you need for walking around, and both Daylight Savings Time and the axial tilt of this wonderful planet have graced us sunshine into the evenings. These are the days when we have a chance to emerge from our electronic hibernation, away from our power-sucking gadgets in our winter nests, and enjoy the fellowship of our fellow humans.

And if you go to the Generation Focused Security Training in Denver on April 17th and 18th, you’ll also know that this is partly why Spring is big outage season for power stations in many parts of the United States. You’d know that now is when the drop in electricity demand corresponding to the weather and human activities allows many power stations that have been running since ~October to come down for much needed maintenance and upgrades.

Now is your chance. The Generation Focused Security training is intended to communicate good cyber security concepts in the context of a generation station, and links those concepts with the paired NERC CIPv5 Foundations course offered by our partner, EnergySec.

Day 1 is the excellent CIP v5 Foundations course offered by EnergySec. The Foundations training will prepare attendees to face version 5. In this course we will:

Explain the 19 terms with new or revised definitions and other important terms that are still undefined

Describe the 13 categories of assets to which requirements apply

Explain the new bright line criteria and the three tier (High/Medium/Low) approach to asset classification

Walk through a detailed mapping and discussion of the new, revised, and retired requirements

Discuss the two new standards in version 5

Explore future changes that may result from the FERC Order on version 5

Provide references and discussion on the pertinent NERC filings and FERC rulings on these standards

Day 2 of the paired course will examine and impart established cyber security concepts in the context of a Generation Station, and link those concepts to the Foundations points from Day 1. The intructor shall discuss all concepts in the context of a model plant, designed to allow conversations on different control systems and networks. Emphasis will be on how cyber security measures have been successfully and unsuccessfully applied in the generation environment, strategies for implementation and operation, common problems and solutions. And finally, the course will discuss vulnerabilities in control systems, and introduce all students to tools used by penetration testers and hackers to better prepare them for challenges ahead.

As the generation business is different, so too are the ideas and concepts when applying cyber security concepts to the operating environment. And placing cyber security controls into the generation context will be increasingly important over the next two years, as more Generation is brought into the mix of NERC CIP regulations.

Those interested may register on the EnergySec website here. Cost for the paired training is $1,295.00 total, a savings of $100 is recognized when signing up for both courses. Seats are limited to the first 25 participants, and EnergySec partners are offered their customary training discount.

Yesterday’s post on the CIPC meeting in St. Louis got a little long, thanks to exposition from me regarding the ES-ISAC. If you find yourself wondering what I’m talking about, take a look at the post. Onward…

NERC staff also discussed the kickoff of the CIPV-Whatever standards development team, which is responsible for addressing changes in CIPv5 that FERC is requiring (see Order 791 for the nitty gritty). For those of you who have been sleeping, get some coffee, because all the development efforts will be going down over the next 6-8 months to meet the FERC required filing data of February 5, 2015. The major changes are for 4 specific areas, which NERC has created 4 subgroups to address the varying areas.

The major point about the CIPV-Whatever development at CIPC is that NERC is calling for participation by owners and observers in each of the subgroups. They want technical and policy experts to weigh in, I assume swiftly, on how things should be addressed. This is *especially* important for owners that have assets that were previously not under consideration as Critical Assets. The decisions made in the Low Impact Assets subgroup will affect what requirements your Low Impact asset must comply with, so you should weigh in on the sanity/insanity of those rules. And fair warning, there will be no discussion of “no controls” for Low Impact, that question was decided well over a year ago. Participate, and prosper, or ignore and take what comes.

It’s my opinion (and I heard this voiced during the NERC Atlanta conference as well) that the interests Low Impact assets may not be represented fully during the subgroup deliberations. It is imperative that future Low Impact asset owners work with their industry groups, those who understand their interests, to provide guidance and information so that the development team can write objective controls that are appropriate for your operating environment. As with all standards efforts, you get back what you put in.

One of the more interesting presentations at CIPC was regarding the use of Attack Trees to help evaluate the risk to the bulk electric system from High Impact, Low Frequency events. I first came upon Attack Trees being used to evaluate critical infrastructure in a 2012 ICSJWG presentation by Mark Fabro, but the concept itself is much older. To summarize, the basic idea is to represent how a given system could fail (in this case, failure is through cyber security means, but it certainly isn’t restricted to it). I learned a similar, but far less subjective, method to calculate overall system failure timeframe from the individual component failure timeframe.

Now, the term “Attack Trees” is a really sensational one, it evokes images of paratroopers, tanks, and trees-carrying-guns, so I caution readers that this is a formal risk assessment process, not a Michael Bay movie.

CIPC met this past week in St. Louis, with a good agenda of cyber, physical, and compliance items. A bit of background for non-CIP folks, the CIPC stands for Critical Infrastructure Protection Committee, an advisory panel to NERC and the ES-ISAC “in the security areas for physical, cyber, operations, and policy matters”. The CIPC meets several times a year to discuss security topics, share information regarding critical infrastructure protection, to develop guidelines for use by NERC members for implementing security, and to assist in the development of the NERC standards (in this case, the CIP standards).

First off, this year appears to be the year of the ES-ISAC. ES-ISAC stands for the Electricity Sector Information Sharing and Awareness Center. Seeing the name, it may have been established due to gov’t action. Maybe, possibly, yes. Every odd-numbered CIPC presentation either pointed to the ES-ISAC as a definitive source for some piece of information, or was discussing changes to the ES-ISAC’s composition/structure and how those changes benefited members. It’s stated purpose is to facilitate information sharing between the gov’t and industry in the area of threats, vulns, and protective measures.

When the 1200 and CIP regulations came out after the 2003 NE Blackout, the ES-ISAC took a hard right to the jaw, and hasn’t really recovered from it. That ‘hard right’ was being operated by NERC , which was now responsible for enforcement the new reliability regulations. I spent a good chunk of 2005-2011 hearing the following question: “Why the heck would I report my vulnerabilities to my auditor??”.

With that history in mind, the most important changes presented at CIPC is that ES-ISAC is freeing itself from the perceived influence of the regulatory side of NERC. There was already a policy in place that didn’t allow communication from ES-ISAC to Audit/Enforcement, but there are steps being taken to wholly separate it out. CIPC presentations indicated that ES-ISAC is going to be a separate corporation from NERC in the near future, and the reporting structure has already been changed. ES-ISAC is now under the CSO, Tim Roxey, and he reports directly to the CEO, Gerry Cauley. This goes in with a general theme of the conference that the ES-ISAC was being stood up as the central coordinating point for electric power. Time will tell how the ES-ISAC fares in presenting themselves to industry as a separate and valuable entity outside of NERC, but the message was very clear at this meeting.

If this is the position of the ES-ISAC, and of the CIPC in particular, the corrective actions they have taken regarding the relationship with Audit/Enforcement are just the beginning. The bulk of the industry remains jaded from years of frustrating cyber security regulatory compliance. Additionally, ES-ISAC will need to show that it is valuable to the electric power industry in a way that is under-served by less sector specific organizations like ICS-CERT and SANS. And, ES-ISAC will need to do this while utilities gear up to work with the massive changes in scope that the CIPv5 is bringing around.

To do this successfully and in a way that adds value, I think the ES-ISAC needs to move beyond the bare bones coordination, recitation, and disclosure of vulnerabilities that ICS-CERT provides. ES-ISAC needs to provide the same type of raw data, but accompany it with analysis-in-context to electric power participants. At minimum, this analysis must support engineers from struggle with evaluating the risks to their systems, or that might be turning to the CIP regulations as their de-facto process. ES-ISAC should provide mitigation that is specific to the way electric power operates and maintains our SCADA, DCS, and other control systems. In this, ES-ISAC has an advantage; They can communicate the specific (and potentially sensitive) context directly to members, but a possible disadvantage is that I’m not sure if they have any charter restrictions that may prevent them from developing/presenting context themselves.

For example, a vulnerability in a PLC would be less of an risk in a normal Control Center environment; Control Centers generally don’t make extensive use of PLCs. But, a PLC vulnerability might be extremely important to a Generation plant, who typically use them in ancillary systems like water treatment, fuel handling, and waste removal. That level of context is missing right now, and it is certainly valuable to members who are concerned about cyber security issues. Without context, it’s easy for owners and operators to get lost in the flood of vulnerability notices that have been coming out, and that will likely continue as more and more cyber security research is conducted on the software and components that help monitor and control infrastructure.

This type of context doesn’t come easy… It requires building relationships with those that have operational experience, and those that have computer security and vulnerability experience, and distilling that into concrete guidance. Luckily, ES-ISAC has a wealth of operational types to draw from in CIPC participants, unlike many other cyber vulnerability organizations.

With all the furor about S4 over the past week, our readers may have missed some of the developments on the NERC CIP front.

Last week, NERC and electric power representatives (and a bunch of us consulting folks) met in both Phoenix and Atlanta for a one-day conference (so, two days total) on how to approach the development of the CIP Version 5 regulations. In the meetings, NERC staff solicited feedback on how the development team should address the various issues FERC wants fixed. The Atlanta meeting was well attended, and I heard the same regarding Phoenix.

First off… Regulations are a pain. They are often either too specific or too vague, and tend to funnel entities into a common approach to a problem that could technically have multiple, even equally acceptable, solutions. But, the regulations also provide a means of ensuring that entities apply appropriate consideration to the collective risk to the public from computer security issues, a classic example of an externality. So, when I talk about an approach, or recommend an alternative, I’m actually concerned that the industry is reducing choices when complying, and making it more difficult to protect the electric system efficiently.

Attendees came up with many items for the drafting team to consider. I’d like to highlight a few to explain in greater detail, and offer some thoughts on pros and cons to each approach from an industrial control system security perspective. If you’re not familiar with the CIP process right now, the drafting team is updating four main areas: Identify, Assess, and Correct (IAC) Language; Communication Networks, Low Impact Assets, and Transient devices.

First off, I won’t be covering the IAC language. IAC generally refers to the regulations requiring that entities look at their infrastructure, find problems, and correct those problems on basically a continuous basis. There was heartburn that the IAC language was basically not auditable. However, it appears that NERC has an approach I’m not currently familiar with that will fit this FERC directive called the “Reliability Assurance Initiative”.

Second, a lot of the comments and approaches repeated several of the assumptions that existed in the original version of the NERC standard. As examples, I mean the fact that utilities often make use of telecommunications infrastructure provided by 3rd parties, and that encryption tends to slow down SCADA communications. These assumptions were brought up back during development of the original standard, but haven’t been challenged since. My recommendation for this was that the development team develop a list of assumptions made during the original development that pertains to the FERC comments, and find out if those assumptions are still valid, as it pertains to the parts of the standard under review.

One of the more important comments I heard during the meeting was related to Low Impact Assets, the components of the electric system that don’t have much of a responsibility under the current Version 3 standards. These are things like smaller generation stations, and other assets that were not identified under the original V3 Critical Asset determination. The question was whether or not the owners/operators of many Low Impact Assets would have the financial and time resources to adequately participate in development, which I took to mean “Who will be the voice of Low Impact Assets?”. This is an important question, as the controls being developed for Low Impact Assets will touch the bulk of electric assets that had no controls required under CIP V3. Entities that previously had no real CIP requirements to follow will be spending money on these regulations, so their input is valuable.

There are concerns on requiring technical controls for Low Impact, namely because FERC direction allows NERC to consider alternative approaches to technical controls. Personally, I find it odd that an industry so flush with process automation is so adverse to developing automation of a security type. Technical controls or not, NERC is required to develop objective criteria for Low Impact Assets this year. My own contribution was that NERC should look at the past 10 years of ICS security history, and develop regulations designed to prevent the types of incidents that have affected electric power and industrial cyber security in the past.

Lastly, I finally got some background on the ‘Transient Devices’ category of the changes. Transient devices refers to anything connected to the critical asset for a defined period of time, so it includes laptops, removable media, and maybe even things like mice and keyboards (though I got some sharp comments back regarding most of those). In the V5 standard sent to FERC, transient devices did not need to be protected if they were only connected for 30 minutes days or less, reducing the paperwork required for these tasks. Reducing paperwork is a good goal, but given the capability and virus history surrounding transient devices, there will need to be requirements for transient devices.

All in all, I wish there had been more technical discussion of the various approaches (it certainly makes for a better ICS security blog post), but it’s likely my view was far too ambitious for a one day conference. As always, Tom Alrich has covered the meeting as well, and his views go much farther into the regulations and motivations of the parties.

*A sharp eyed reader pointed out I had put in ‘minutes’ instead of ‘days’ for the amount of time a transient device could be connected without needing NERC CIP protections. Thanks!

I’m Mike Toecker, Computer Engineer. I’ve been working in the Electric Power industry for about 8 years now, doing cyber security and compliance work associated with the NERC CIP regulations. I’ve worked for a major electric power consulting engineering firm for 6 years, a utility for a year, and now I work for an ICS security company.

I’ve had the opportunity during my career to assess control systems in control centers, transmission substations, and generation plants all across North America (now internationally). As part of NERC CIP compliance, I’ve had to assess impact from loss of a computer system, and how that could affect bulk system reliability. I’ve had to dig deep into how these systems function and into network and system architecture of ~38 different installations.

So, when I say that Master Fuzzing and Bare Serial vulnerabilities, like the 25 that Crain and Sistrunk responsibly disclosed via ICS-CERT, concern me, you need to pay attention. The Crain/Sistrunk vulnerabilities are the first ones we know of to demonstrate attacks on two unknown/underassessed threat vectors:

Compromising a Master from a Slave

Attacks without use of more modern (read: IP based) communications

I’m not going to talk about these new threats in detail today, they require a lot of time to cover. In this post, I’m talking history of development regarding the NERC regulations.

In the original development of both the NERC CIP and the previous NERC 1200 regulations, serial channels were considered less risky than their IP-based counterparts. And rightly so, at the time. There was almost no awareness of computer security issues in the planning and deployment of these systems, and insecure practices were rampant. Most of these practices revolved around truly horrible design and implementation of IP based networks, which were becoming the norm in electric power. Additionally, development took place after and during some of the roughest Microsoft Windows vulnerabilities, those like Blaster, SQL-Slammer, Sasser, and others. So, the developers of the original NERC regulations focused on these high profile vulnerabilities and the threat vectors they would come in over.

This led to a regulation where network security was the main technical component, where emphasis was on identifying critical systems, putting those systems in a perimeter, and locking down that perimeter. This has been the direction for the past ~10 years.

But, as we track the development of exploits, vulnerabilities, and viruses after this, NERC has not made significant changes to this approach. As everyone on the ‘Corporate’ side tightened their perimeters, restricted services, and locked the internet out from their networks, attackers moved to new threat vectors. These new threat vectors were not based on network services and direct communication via the internet, they were based in email, browsers, and browser based components such as Flash, Java, and others.

We’re once again in a new world of threat vectors, but this time they are ICS based. Compromise of the industrial controllers for Stuxnet should have rung a bell in NERC regulation development, it didn’t. Industry still has no strong standards for ensuring that logic designed is the logic running. The Crain/Sistrunk vulnerabilities are similar, we have research showing that Master stations can be compromised from the Slaves as early as June. And a few months later, we get another NERC CIP regulation submitted to FERC that explicitly exempts serial based connections from any regulatory security measures.

I find myself saying this often: The Crain/Sistrunk vulns are not the big deal. The big deal is that they demonstrate a general case that bare serial based communications are vulnerable to the same types of vulnerabilities that exist in IP communications. It shouldn’t be a surprise, but apparently it is. The NERC regulations have measures to protect, and detect, on threats against the IP communication vulnerabilities, but we do nothing against bare serial.

Crain/Sistrunk also demonstrate a general case where communications originating from a high security zone (a control center) to a low security zone (a non-critical substation) can be modified to compromise the high security zone. This vector was considered low-risk (I even heard the word ‘impossible’ uttered at least once) at the time. There were various reasons for this, most centered around the simplicity of many SCADA protocols, the lack of bandwidth on these connections, etc. This low risk was translated into a blanket exemption, which has been adopted by the industry as law.

Well, things are different now. While we’ve been lucky over the past ~10 years, and no threat vectors have required updates to the core of the NERC regulations, the general cases presented by the Crain/Sistrunk vulnerabilities require industry to take a second look at all our assumptions, exemptions, and protections from the past. How would we react if this were a vulnerability in lean burning gas turbines that caused them to burn out under certain grid conditions? What about if verbal communications between operators were often garbled or confused, and this led to problems coordinating activities between different entities?

Normally, NERC would start a workgroup to study the problem and make appropriate recommendations for addition to the regulations. Why this isn’t done, I don’t know. Most of the development activities for NERC CIP come straight out of FERC, trying to meet requirements in NOPR documents. Maybe I’m talking to the wrong people, and should start talking to FERC and the PUCs.

This post is part of a coordinated series of blog posts examining the details of version 5 of the NERC Critical Infrastructure Protection (CIP) standards. These posts, written by various individuals having direct experience with these standards, will point out security gaps, ambiguities, and areas that could prove challenging to audit. The purpose of the posts is to highlight areas for future improvement, and to draw attention to issues for which entities may wish to apply greater diligence than is currently required by regulation.

In this simulpost between from the Anfield Group, Stacy Bresler discusses the differences between the Information Protection Program in CIP Version 3 and the new IPP in Version 5. Stacy maintains that some of the language will be confusing in an audit, and that should be looked at carefully while the Version 5 transition is going on. – MHT

The requirement to establish an Information Protection Program (or something similar) has existed in the CIP standards from the very beginning. When I say very beginning, I mean since FERC’s Standard Market Design (SMD) Notice of Proposed Rulemaking (NOPR) Appendix G (called the Cyber Security Standards for Electric Wholesale Market Operations Participants) where it had a single sentence that stated:

Critical electric facilities shall restrict the distribution of maps, floor plans and equipment layouts pertaining to those facilities, and restrict the use of signage indicating critical facility locations.

Since that NOPR failed, Urgent Action Standard 1200 was created in 2003 and had this to say about information protection (1210):

This post is part of a coordinated series of blog posts examining the details of version 5 of the NERC Critical Infrastructure Protection (CIP) standards. These posts, written by various individuals having direct experience with these standards, will point out security gaps, ambiguities, and areas that could prove challenging to audit. The purpose of the posts is to highlight areas for future improvement, and to draw attention to issues for which entities may wish to apply greater diligence than is currently required by regulation.

There’s a wonderful line in every NERC CIP regulation located in the Exemptions section, stating that the following are exempt from the NERC CIP standards:

This simple statement allows entities to automatically remove a set of assets from NERC consideration that could otherwise be considered critical to the operation of the BES. The initial push for this requirement during the development of the original CIP standards was that entities often didn’t have any control of telecommunications networks, they only used them for communication. This is a valid, though poorly implemented, concern and was mainly in regards to contracts that would require re-negotiation and ensuring they weren’t trying to regulate non-electric entities.

The basic problem I have with this statement is simple: With the sweep of a pen, it removes an entire swath of potentially critical assets and communications from consideration without requiring commensurate protections to make up for the resulting vulnerability. It’s been years since the original CIPs, and the exemption has simply been imported without examining the underlying risks and vulnerabilities it causes. [Read more…]

Dale's Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.