Industrial Computing and CyberSecurity

Earlier this week the government of Canada released a renewed cyber security strategy. It’s great that it recognizes that cybersecurity fundamentally underpins Canadian innovation and prspoerity.  A few years ago I helped Public Safety Canada develop the “Fundamentals of Cyber Security for Canada’s CI Community.” After endorsing the NIST Cybersecurity Framework, the fundamentals aspired to SMASH the status quo for cybersecurity by:

• Simplifying the guidance,
• Proposing Measurements that described a sound cybersecurity program
• Described Actions instead of simply providing guidance
• Looked to Scalable activities to reach all Canadian organizations
• Harness as many stakeholders as possible to address the end-to-end security challenge

The fundamentals provided a good start, but they didn’t fit too well with some of the realities of operating critical infrastructures. The administrative computing systems were well covered, but the process control/industrial computing (ICS) platforms were not. For example: Configuring systems for automatic updates might not work for remote, embedded computing systems. As I think about version 2 of this document, I’ve been noodling about where the guidance would be the same and where there would need to be differences. From there, the guidance could be better tailored.

The similarities for cybersecurity between administrative computing and Industrial computing are perhaps more straightforward to outline. As a result, I won’t go into too much detail here. Some quick themes that immediately jump out are: Policy, People, Process, Skills, Governance and the Adoption of a Risk Managed Approach. Of course, we could quibble about overlap between some of these themes, but I think we get a sense of the macro-level similarities.

The “differences” is where I think some time should be spent; to consider if there are themes for industrial computing / Internet of Things where organizations should consider an alternative set of controls / guidance. This may well be a challenge since this domain will deal with IT enabled devices along a continuum from very simple/exceptionally inexpensive to the very sophisticated/ exceptionally expensive. I suggest that we could consider the entire continuum since the IoT / ICS solutions may share similarities despite cost or complexity. Here is the start of a list of things to consider as we develop renewed guidance for industrial computing security:

1. Embedded – These systems may not be visible to the end user directly and might not have a readily accessible user interface. There may also be a variety of third party contributors to the final solution. An automotive control system may be an amalgam of real time operating systems, user experience applications, sensor add-ins and radio stack firmware. The roles and responsibilities may need to be more clearly defined.
2. Uncertain boundaries – the ICS / IOT solution may interact with a variety of other dissimilar computing environments. I recall an automated IV medicated dispensing system that had two principle systems: a process control system and a user interface system. The IT department was reluctant to perform IT remediation on the devices since they were uncertain about the interaction between the two environments and the impact that they had on each other.
3. Periods processing - Many of these devices will be used in remote regions with low or no bandwidth. Even when connected to a communications network, they may not be accessible via the internet. They might lie dormant for extended periods of time in absence of events to enable them. These devices may also find themselves with power constraints. Every compute operation may shorten the lifespan of a battery-operated device.
4. Certification / Legal – Many of these devices operate kinetically in the physical world and could impact people in a negative way if they operate or are used improperly. As a result, many of the solutions in ICS / IoT require certifications prior to being permitted to operate. Cybersecurity guidance in this space must consider the impact of controls / process on legal / certification.
5. Uncertain Environments – These systems may not be found in clean, dry and temperature-controlled environments. They might not even be found near urban regions. Imagine an automated plastic waste collection robot in the middle of the Pacific Ocean. What guidance would you give to respond to a security breach in that device. And for that matter, these devices will most certainly require a different approach to physical security than the locked cabinet or zoned computer room.
6. No downtime – While there are most definitely systems in the administrative environment where downtime cannot be tolerated, the impact of the outage may not be as life critical as the impact in the ICS world. Should a differentiation be made in this theme?
7. Non IT Staff – Many of these ICS systems are managed and operated by non IT staff that use these automated tools as part of a non-IT related outcome. The mechanic of the automated mining cart may not be familiar with traditional IT terminology, processes and tools. As a result, the guidance should address the various roles and responsibilities in this community.
8. Measurement – What isn’t measured doesn’t get performed. Are there different measurements that need to be taken to describe the maturity of a cyber security program in the Industrial Computing Space? We all know that the absence of an exploit does not indicate an absence of vulnerabilities. 
9. Unique/custom protocols – There are a variety of different open protocols or even custom protocols used in the ICS space that are not commonplace in the ICS/IOT world. We simply need to look at the exploitations conducted via the CanBus to see that there is a need to provide unique guidance along this theme.
10. Data ownership / control – Data is increasingly becoming the currency of the digital world. As a result, some ICS/IOT suppliers maintain ownership of the data associated with the operation of their solution. Cybersecurity guidance for ICS may need to call out the roles and responsibilities associated with the collection/use of the data as well as the security implications associated with it.

That’s just a quick rundown of 10 differences that I came up with, I’m sure there are others. What unique characteristics for ICS do you think would need to be addressed in Cybersecurity guidance of IoT/ICS? Which of these 10 should not be included? Let’s start a conversation about guidance that people can use to keep all Canadian’s safe.