Dave Norton

For those of you who know Dave, don’t panic at the title of this post: He isn’t dead! But he did retire from FERC at the end of January. Because of his huge contributions to the industry and to the NERC CIP standards, and because he is a close personal friend, I want to pay tribute to him. First, I’ll give you a short summary of why Dave is so important:

1. Dave has been doing networked computing and security for 41 years. He was one of the first CISSP’s, in 1998 (for some perspective, the World Wide Web was less than ten years old then, and the Netscape IPO had only happened three years earlier. This IPO is generally seen as the wakeup call that the Internet was going to be something big – it certainly was for me. Netscape was valued at a whopping $3 billion in that IPO, which now might be the starting bid for a small startup company with mediocre prospects).
2. Dave was part of the energy sector for 17 years. 10 of those years were with Entergy Transmission in New Orleans, including going through the Katrina experience!
3. NERC got into the cyber security regulation business in 2003, when the Board of Trustees approved Urgent Action 1200. This was a voluntary standard (all NERC standards were voluntary until the Electric Power Act of 2005 set up the FERC/NERC relationship that we all know and love today), and just applied to control centers of Balancing Authorities. But it was a successful standard for what it did, since the BA’s knew the unique position their control centers played in the Bulk Electric System and felt compliance with the standard was very important. Dave was an active participant on the Standards Drafting Team for UA1200.
4. However, an Urgent Action standard is temporary, and everybody wanted a permanent standard. In 2004, NERC’s Board approved a Standards Authorization Request (SAR) for NERC Standard 1300. This would expand UA1200 to apply to other assets than just control centers – especially Transmission substations and generating stations. Of course, Dave was on the UA1300 team as well.
5. Before Standard 1300 could be put into place, Congress passed the Electric Power Act of 2005. This act allowed FERC to regulate reliability of the electric power industry, and to choose an Electric Reliability Organization to draft and enforce the standards. Of course, NERC – having been doing this since 1967 – was the only logical choice for the ERO.
6. The EP Act explicitly required that NERC develop cyber security standards. So Standard 1300 was re-drafted as eight standards in the CIP family. Dave not only continued onto the drafting team for CIP v1, but he wrote the SAR for it.
7. When FERC approved CIP v1 in January 2008, they issued Order 706. This 600+-page document stated that FERC was approving v1 because they wanted something in place, but they had far more ambitious plans for CIP and wanted substantial changes. They laid these out in great detail in the order.
8. Of course, NERC standards can’t be changed once they’ve been approved by the NERC Board, so even as CIP v1 was implemented, a drafting team was formed to draft a new version of the CIP standards that would incorporate FERC’s changes. Dave was – of course! - an active member on this drafting team, which was called the CSO706 SDT.
9. The CSO706 SDT first met in the fall of 2008 to draft CIP v2. However, they ended up drafting not only v2, but also v3 and v4. These were all “stepping stones” on the way to CIP v5, which was approved in late 2012 (if you’d like more information on all these versions and why they were developed, see this post).
10. Dave was with the CSO706 team through most of this, but he left Entergy to join FERC in 2011, which made him no longer eligible to remain on the SDT.

As you see, Dave has been at the forefront of NERC’s cyber security efforts since their beginning. He has contributed in many ways, but I’d like to illustrate the important role he played by reprinting a section from an “open letter” I wrote in October 2010. It was distributed by Honeywell, my employer at the time (I didn’t start my own blog until January 2013).

In this open letter, I described a meeting of the CSO 706 SDT that I’d just attended in Toronto. The meeting had been mainly concerned with CIP v4, which the team was in the process of balloting with NERC (it was approved by the NERC ballot body in December 2010). I marveled that, after a grueling day or two making revisions to v4 for the next ballot, the team still had time and inclination to have a freewheeling discussion of what CIP v5 should look like. Dave had earlier been chosen to lead a team to make suggestions, and he presented their ideas:

“At the Chicago SDT meeting in August, a subcommittee had been formed—led by the venerable Dave Norton of Entergy—to re-examine the foundations of CIP, and report on their findings at this meeting. Of course, they weren’t charged with making fundamental decisions—that is for the whole SDT. Rather, the subcommittee developed a very insightful “Review of Critical Issues” which outlined the fundamental considerations for the new CIP.

These “considerations” formed the basis for the SDT’s discussion of V5. While that discussion was wide-ranging, the full SDT remarkably coalesced on a framework for V5 that was a huge change from both CIP Versions 1-3 and from the version (CIP-010 and -011)[i] that was discussed in Dallas this spring. I will list below important points from that discussion, without (in most cases) identifying who made them.

The discussion started with a delineation of the fundamental problems with the current CIP standards. These include:

1. There is no room for any error in following the current CIP standards. Dave mentioned a large entity that had missed five of 30,000 access removals in one year, and had to self-report all of these as violations. Ironically, he pointed out that this entity was doing a very good job with CIP, but those five misses (i.e. 1/6000th of the total) will loom as large for them as five misses at a small entity that might only have 200 total access removals in a year (i.e., the misses are 1/40th of their total).

2. There is no good way to work for improvement. Dave said the stigma of self-reporting a violation has caused at least some people to be fired—so who is going to stick their neck out and admit they’ve missed something, even if doing so could lead to improving the process that led to the violation?

3. While VRFs and VSLs are in theory in place to mitigate the impact on the organization of a self-reported violation, these only come into play after the violation has been reported. And most organizations will do their best to avoid reporting any violations.

4. The current standards are “one-size-fits-all.” There is no allowance for degree of impact on the BES, or for differences between control centers, generation plants, and substations. Dave also pointed out that protecting “bastion” assets—such as control centers and generation plants—is quite different from protecting field assets such as substations.

5. There is no allowance—other than TFEs—for legacy equipment.

6. There is no specification of what the controls in CIP-003 through -009 are protecting against. Thus, many entities question why they should have to implement anything at all.

7. There is no way under the current standards to incorporate the entity’s actual vulnerabilities— e.g., the results of vulnerability assessments—into the controls that are applied.

8. While many (including FERC) have pointed to NIST 800-53 as the blueprint for a new CIP, there are many problems with that. As the CISO of a large government entity—which has had to follow 800-53— pointed out, there are far too many controls required. Many of these controls provide only marginal benefit, while there are a few that provide huge benefits (configuration management, awareness and training, and personnel risk assessments). Because 90% of security threats are from insiders, controls such as these—which protect from insider threats— are much more important to implement than many others.”

  

I hope you’ll notice that Dave’s suggestions helped plant seeds for a number of features of the current CIP landscape, which are undoubted improvements from the previous CIP versions. These include Find, Fix and Track (#1); the Reliability Assurance Initiative (#2); High, Medium and Low-impact assets (#4); the need to treat large Control Centers as High impact (#4); and the language like “per device capability” in some of the CIP requirements, that eliminates the need for filing TFE’s (#5).

There are also several items on Dave’s list that have yet to be addressed in the CIP standards; these will need to wait for when all the standards are non-prescriptive and risk-based, like CIP-013. So we’re not finished with Dave’s agenda yet!

PS: Before he rode off into the sunset, Dave listed for me a number of changes he would still like to see in the CIP standards. I am going to expand on those a little bit (unlike me, Dave won't use two words where one will do!) and put them up as a post within a week or two.

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

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996. 

---

[i] Tom (2018). The first attempt at a new CIP version after v3 was called CIP-010 and -011. 010 consisted of the applicability section of the new standard, which was like CIP-002-5 (it included bright line criteria and the new concept of BES Cyber Systems). 011 consisted of all the other requirements. This new proposal was unveiled at an SDT meeting in Dallas, which had a large number of on-site attendees and over 600 remote ones. There was widespread opposition to the proposal, mainly because it was such a radical change from CIP v3. The drafting team shelved that idea, so these draft standards never even were voted on. The drafting team then started work on CIP v4, which replaced CIP-002-3 with a new version based on the bright line criteria (but still using the concept of Critical Cyber Assets) – however, CIP-003 through -009 remained exactly as they were in v3. When the SDT started considering v5 in early 2011, they decided to add two more standards, which became CIP-010-1 and CIP-011-1. Of course, these had nothing to do with the original drafts that got shot down in Dallas.