Latest News

Mistakes in the development of RG 5.71/NEI 08-09

Mistakes happen to all humans in all endeavors.  The purpose of this post is NOT to criticize or shame anyone, but rather to point out some opportunities for improving NEI 08-09 Rev 7.  The current version of that document (the basis for the Cyber Security Plans at nuclear licensees in the US) has a number of issues.  I spoke about the overall issues here and in my previous post I spoke about specific controls included that provide no value.  In this post I am going to address some of the mistakes that led to these issues.

  1. Insufficient methodology used to select the controls
  2. Only one control baseline
  3. No useful mechanism for tailoring the baseline

Let’s examine these issues in more detail:

Insufficient methodology used to select the controls

According to the folklore, the methodology used to determine which of the NIST SP 800-53 controls to include in RG 5.71 and NEI 08-09 was simple: all controls designated within the “High” baseline within SP 800-53 were included.  This approach was too simple.  It ignored what the High Baseline was all about (HINT: Top Secret information.)  Hillary’s email server could’ve benefited from the High Baseline (Whoa!, is it too soon?), but nuclear power plants, not so much.

The High Baseline is heavily skewed toward protecting the confidentiality of sensitive information, something that is NOT a priority in most Operational Technology environments, including nuclear power generation.  OT in general and nuclear power specifically are much more interested in protecting the integrity and availability of the operations, but the NIST prescribed process, which includes utilizing the Federal Information Processing Standards (FIPS) publications 199 and 200 to categorize the information and information systems is far more concerned with protecting classified information than operations.  This wasn’t a good fit, and it was even more convoluted in that the document used as the basis of RG 5.71 and NEI 08-09 was a draft of revision 3 of SP 800-53.  There were controls in the draft that did not make it into the final version and controls in the High Baseline that did not make it into any baseline upon publication.  In short, the methodology was flawed.

Only one Control Baseline

The methodology produced a mess of a control baseline, an inadvertent one-size-fits-none approach.  As discussed in my previous post, there are some controls that will not be implemented at any licensee for any CDA, and that’s all well and good.  If you read RG 5.71 and NEI 08-09, you’d get the impression that all Critical Digital Assets at a nuclear power plant all have about  the same level of risk.  Network placement and use of wireless are the only differentiation between Safety, Security, and EP CDAs specified in RG 5.71 and NEI 08-09 .  That is silly.  It’s not true that the same level of risk exists, and everyone knows it.  Compromising the ability for the plant to know wind speed and direction WILL NOT and CAN NOT have the same impact to a plant as compromising the ability to provide emergency power.

To their credit the NRC and the industry have tried to address this issue through publication of NEI 13-10, however, it is an extremely confusing document that lacks consistent structure.  There are a mixture of scope determining attributes, i.e. characteristics of CDAs that indicate what baseline to apply (Indirect Impact CDA, Indirect Impact CDA within the BOP that could cause a TRIP, EP CDA, Direct Impact CDA) and the specific controls required for the baselines intermixed within the tables as well as spread out throughout various sections of the document.  The chart below shows what I believe to be the simplest flow for the guidance in NEI 13-10 Rev 4:

Screen Shot 2016-07-14 at 12.43.40 PM


No Useful Mechanism for tailoring the baseline

There is no formal definition of a Threat Vector and the Attack Pathways defined by the NRC are generally insufficient to determine the necessity of applying the appendix D and E controls.  This should be self evident to all who have been involved in assessing CDAs to date, for those who have not had the pleasure, an example should provide clarity:

A badge card reader is a CDA, it is connected to a network so it can query the security computer to determine if a badge card presented to it is authorized access to its associated door.  It is acquired by the plant through the procurement process.  It is in an area where personnel that may or may not be authorized access to CDAs are present.  Based on this description, three of the five Attack Pathways are applicable (Network, Physical, Supply Chain) yet,  many of the Appendix D and E controls would provide NO useful, much less necessary, security capability for a badge card reader.

None of the controls that protect logical interaction with CDAs are necessary, i.e. there cannot be any negative consequence to the badge card reader if those controls fail or are not applied, yet the attack pathways do exist. There is no industry-wide or NRC endorsed process for doing threat vector analysis.  Additionally, there is no specific guidance anywhere, other than NEI 10-09, LOL (Full disclosure, I was a contributing author of that document), of which Attack Pathways apply to which controls.  This guarantees that absence a grass-roots collaboration by the industry, something that I believe must, but to date has not happened, individual licensees with come to their own, perhaps diverse, conclusions based on their own, perhaps incompatible, processes.