USCG Icebreaker opening path through the ice*
This past year has been disappointing for governments and institutions issuing documents on critical infrastructure protection. The European Union has issued a draft of the Cyber Resilience Act[1] and NIS2 Directive[2]. Across the Atlantic the U.S. has after a series of high-profile cyber incidents on its infrastructure (Colonial Pipeline shutdown[3], Oldsmar water[4]) issued several cyber security policy documents including a National Cybersecurity Strategy[5]. I have gone through these and other documents and was disappointed at the noble efforts to come up with ways that will guide practitioners with protecting the technologies used to monitor and control processes governed by the laws of physics and engineering. Most of these documents do not adequately address this issue by limiting the vision to securing the IT in the home and office. In each case I looked at I did not see much appreciation for process control and evidence of input from the engineers who know critical infrastructure runs. For an analysis of three of them I refer to my article about the US cyber strategy[6] , the NIS2 Directive[7] and EU cyber resilience work in Linkedin[8]. So I was ready to be disappointed again upon hearing about the publication of the U.S. Government’s Cyber Informed Engineering Guide[9]. But I am happy to say that after reading it I am not. On the contrary it is what the doctor ordered. Why do I say that?
First the document makes clear who the audience is right from the beginning. It is clearly written for “the engineers who design, build, operate, and maintain the physical infrastructure.[10]” The authors argue quite logically that they “are best positioned to leverage a system’s engineering design to diminish the severity of cyber attacks or digital technology failures.”[11] One might also ask who the authors are. The Guide is published by the U.S. Department of Energy’s Office of Cybersecurity, Energy Security, and Emergency Response (CESER) with substantial weight carried by Idaho National Laboratory. Certainly the drafters of this Guide included those who know how critical infrastructure runs.
Then the Guide goes on to explain that it goes beyond the long discussed “secure by design” concept to extend it “beyond software design, introducing cybersecurity considerations that engineers can address at the earliest stages of system engineering, long before the incorporation of software and security controls.”[12] This is to be accomplished through the application of 12 principles listed on page 9.
The Guide goes on to explain each principal in detail and includes some helpful examples from the world of engineering. One of the Guide’s strongest features is the listing of questions to help the user of the Guide with applying the principles. For example in covering Principle Nr. 4 Design Simplification, one of the questions asked on page 45 is “Are there alternate, non-digital means to satisfy a given requirement?” The consideration of using an analogue solution as opposed to a digital one is hinted at several times in the Guide. Perhaps this is in recognition that some digital systems cannot be adequately secured from compromise. The number of questions listed is overwhelming and one must ask who will oversee applying the principles in the Guide? It will take more than one designated person to organize something of this scale. Rather a unit will need to be established to digest the guide’s principals and organize the work.
In terms of establishing a cybersecurity capacity the tendency is to rely on automated systems to detect and react to incidents rather than having a human element as part of the monitoring and control. The creation of a capability, i.e. unit/division/staff to monitor for and respond to incidents seems to be a key enabler in performing the work in the design phase supporting Principle Nr. 6 Active Defense.
One area for improvement would be to provide more case studies. Even though this was a US DoE prepared document the case that was chosen to demonstrate the application of the principles was based on a water facility and not a power utility or pipeline operator. Do not get me wrong the demonstration of the principles using the water facility as an example is fine but there have been cyber-attacks on power grids, pipelines and petrochemical plants. Adding these energy-related cases of applying the Guide’s principles would add more interest and reach a wider audience ( the energy sector is also mentioned earlier in the document as a priority sector on page 8). The use of brief inserted examples such as on pages 14-17, 20, 84, 87, 95 to illustrate the motivation behind a guiding question are very useful. It would help to have more of them as they provide deeper insight into the process.
Some were quick to voice skepticism and disappointment over this Guide. One thinks that governments which are subject to marketing hype cannot come out with something objective[13] and another laments the amount of time that may pass before some good result becomes visible.[14] These views of skepticism should not discourage those who want to design resilient systems to read and consider to apply the Guide’s principals. Governments can make informed decisions on CIP if they reach out to the engineers and are open to their informed suggestions and viewpoint. While one can understand the desire for a quick win it must be understood that the problems faced in CIP today have been present for many years and have become more complex with the application of the latest and dynamically changing technologies. The Guide offers a way to organize the work and manage the chaos in trying to understand what needs to be protected, what threatens them and how the identified assets can be protected right from the beginning of a project rather than expensively fixing it later which is where we are at now. It is also free from an IT bias toward data protection and puts the focus on what is needed: protecting the physical process in keeping with the desired parameters.
The answer to this articles’ question raised in the title is YES.
[1] https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act
[2] https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
[3] https://www.cisa.gov/news-events/news/attack-colonial-pipeline-what-weve-learned-what-weve-done-over-past-two-years
[4] https://industrialcyber.co/utilities-energy-power-water-waste/oldsmar-water-treatment-plant-incident-allegedly-caused-by-human-error-not-remote-access-cybersecurity-breach/
[5] https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf
[6] Vytautas Butrimas, Impressions of the US National Cybersecurity Strategy, SCADASEC, 15 March 2023. http://scadamag.infracritical.com/index.php/2023/03/15/impressions-of-the-u-s-national-cybersecurity-strategy-of-2023/
[7] My take on the NIS2 Directive https://www.linkedin.com/posts/activity-7003987809585790976-nVDJ?utm_source=share&utm_medium=member_desktop accessed 2023-09-04.
[8] My take aways from the “EU Cyber Resilience Act” Factsheet, https://www.linkedin.com/posts/activity-6977502655833083904-mnNT?utm_source=share&utm_medium=member_desktop Accessed 2023-09-04.
[9] US Department of Energy, Cyber-Informed Engineering
Implementation Guide,. https://inldigitallibrary.inl.gov/sites/sti/sti/Sort_67122.pdf
[10] Ibid.,, page 6, https://inldigitallibrary.inl.gov/sites/sti/sti/Sort_67122.pdf
[11] Ibid., page 6.
[12] Ibid., page 6.
[13] https://www.linkedin.com/feed/update/urn:li:ugcPost:7102131256259211266?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7102131256259211266%2C7102374461198254080%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287102374461198254080%2Curn%3Ali%3AugcPost%3A7102131256259211266%29
[14] Dale Peterson, Where’s the early win?, Digital Bond, 29 August 2023, https://dale-peterson.com/2023/08/29/wheres-the-early-win/
*Photo Public Domain <a href=”https://commons.wikimedia.org/wiki/File:120106-G-IA651-272_(6668116881).jpg”>U.S. Department of Defense Current Photos</a>, Public domain, via Wikimedia Commons
