Having a framework for a boat does not guarantee that it will float or sail well.

A drawing of the 17th Century Swedish warship "Vasa" which had a flaw in the design of the framework. The bottom was too narrow and caused the ship to tip over when it tried to sail out of port.

The above is a drawing of the framework of the 17th Century Swedish warship “Vasa”. The design of the bottom was too shallow and caused the ship to tip over when it tried to sail out of port. Lately governments have been issuing cybersecurity policy documents that are shallow in their depth of understanding of what they need to protect and from what threats.

Have read the NIST Cybersecurity Framework (CSF) 2.0[1] released  for public comment on August 8, 2023 and have these observations to share:

In a sense the “if it ain’t broke, don’t fix it” rule has not been followed.  Right from the beginning the authors note that the title of the earlier version has been changed from the original “Framework for Improving Critical Infrastructure Cybersecurity” to a “Cybersecurity Framework”. The rationale is that the new title reflects the author’s intention for the framework to be used ‘by all organizations”.  This in my opinion weakens the document by introducing an unhelpful ambiguity in determining what needs to be protected. In short it could not be understood that everything needs to be protected, which is not realistic considering that resources to implement the advice in the Framework will be limited. Having the focus on critical infrastructure makes good sense in a national policy document where protecting economic activity, national security and well-being of society should be main objectives. By the way the document later contradicts itself  on line 99 where it states “The voluntary Framework is not a one-size-fits-all approach to managing cybersecurity risks.  An important and wise recognition of reality but why start off by saying the document applies to all organizations?

Since the title of the document refers to “cybersecurity” in general then it is important to determine what it is the authors are seeking to protect.  Again as at the beginning the authors are seeking a broad application of the Framework as seen on line 139-139 where it is stated that it  “applies to all information and communications technology (ICT), including information technology (IT), the Internet of Things (IoT), and operational technology (OT) used by an organization”.  It extends the umbrella even further to “to all types of technology environments, including cloud, mobile, and artificial intelligence systems”.  The latter is a very topical subject and has also found a place here. This broad application in my opinion is a sign of a poor understanding of the various environments where technology is being used. There are many caveats to consider when applying security practices to data centric and process control environments.   Having a framework that covers both is a mistake. Better to have a framework for each environment.  One for where data is the focus of protection and one for where the focus is on protecting the technologies used to monitor and control processes[2] governed by the laws of physics and chemistry.  To put it more clearly one for the electric utility’s billing department and one for power generation and distribution operation.

I am sorry to say again that we have another IT cybersecurity biased document[3] which now, in addition, the authors think will cover every environment.  For example let us look at the statements about the “intended audience

The primary audience as stated on line 150 is for “those responsible for developing and leading a cybersecurity program”.  It appears that the main burden for implementation is placed on the CISO.  This may be fine for the office IT environment where the CISO should have the training, but it is doubtful whether  this knowledge can be successfully applied when addressing the issues peculiar to process control environments (See these short video modules on “Industrial cybersecurity for CISO’s”[4]).

The authors also say on line 156  that the Framework is also for “policymakers (such as associations, professional organizations, and regulators)”.  This is fine but why not also include that it would be useful to automation engineers and senior plant engineers? They know how things run (the physical process)  and could be of great help (especially with explaining the caveats)  in assisting the CISO in implementing the Framework.

The next disappointment is the lack of attention to describing the threats.  To conduct risk management, in addition to knowing what assets need protection it is vital to know what can threaten those identified assets.  Figure 3 which illustrates “Cybersecurity Framework Profiles” does include a graphic depicting “Threat Environment”, but this is not developed in the text with an appropriate description.  A lost opportunity to inform the reader about the kinds of threats and the associated skill sets that would inform work on developing security profiles.  Ransomware and cybercrime are not even listed as threats which usually appear in such documents. Material is available, which is not found here, from the documented cases of advanced persistent threat (APT) attacks on critical infrastructure[5]

For the most part this document is focused on cyber threats to data, privacy and those that can come through the supply chain.  Much language is devoted to addressing privacy and supply chain threats.  Figures 7 and 8 feature “privacy” in the center of the graphics.  Again the bias towards protecting data is stressed as is stated on lines 640-642   where it states that  “Cybersecurity risk management is essential for addressing privacy risks related to the loss of confidentiality, integrity, and availability of individuals’ data. For example, data breaches could lead to identity theft”. 

Grossly missing is any understanding of the link between cybersecurity and control[6].  Especially the technologies that are also cyber vulnerable and control physical processes that can lead to fatalities, damage to property and environment.   The one threat that does get worthy attention is the cyber threat that can come through the supply chain.  This is discussed in its own dedicated section 3.5. One of the few times where clear actionable  advice is provided for how this threat can be addressed in contracts and procurements from vendors.

In summary while this is a valiant attempt by a government agency to get everybody organized[7] around a framework for cybersecurity, more effort is needed  to research and add a section on the cyber threat environment.  One that includes documented and successful efforts by advanced persistent threat actors to take away the view and control of a physical process found in critical infrastructure.  The places where we get our electricity, water and heat from. Turning the focus away from critical infrastructure protection to cover all systems and putting responsibility on the back of the CISO without appreciating the contribution of the engineers that know how things run are just a few serious flaws in this draft document.


[1] https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.ipd.pdf https://www.nist.gov/system/files/documents/2023/08/07/CSF%202.0%20Core%20with%20Examples%20Discussion%20Draft%5B74%5D.pdf

[2] The word “process” is used 13 times in the document but mostly associated with “Business Process” and not a physical process.

[3] The number of times words like “data” and “information” are revealing (used 30 and 49 times respectively).

[4] https://www.isa.org/training/microlearning-modules/iacs-cybersecurity-for-cisos

[5] Here is one example from another agency in the same government. https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-110a

[6] Only mentioned 5 times in the text and mostly associated with “access control”.

[7] reminded of a classic line from the comedian Jonnathan Winters in the film “The Russians are Coming, The Russians are coming”:  “we gotta get organized”

http://scadamag.infracritical.com/index.php/author/vytautas/

NOTE: The views expressed within this blog entry are the authors’ and do not represent the official view of any institution or organization affiliated thereof. Vytautas Butrimas has been working in cybersecurity and security policy for over 30 years. Mr. Butrimas has participated in several NATO cybersecurity exercises, contributed to various international reports and trade journals, published numerous articles and has been a speaker at conferences and trainings on industrial cybersecurity and policy issues. Has also conducted cyber risk studies of the control systems used in industrial operations. He also collaborates with the International Society of Automation (ISA) on the ISA 62443 Industrial Automation and Control System Security Standard and is Co-chair of ISA 99 Workgroup 16 on Incident Management and member of ISA 99 Workgroup 14 on security profiles for substations.

Related posts