The following is an excerpt from RIoT Control: Understanding and Managing Risks and the Internet of Things by Tyson Macaulay and published by Elsevier/Morgan Kaufmann. This section from chapter six describes the safety risks requireemnts in IoT and how they are related to security requirements.
Safety is not exactly the same as security
Ask any industrial control system (ICS) engineer whether enterprise IT security standards and processes are useful in their environment, and he/she is likely to say "partially but definitely not completely." ICS security practitioners have for many years rejected the overtures of IT security experts and standards, claiming that ICS is not the same and has different requirements.
They were right. They are right! The lessons learned from those early encounters between ICS and IT now extend to the IoT -- which has combined the two practices inextricably:
ICS + IT = IoT
To try and summarize it: ICS and IT have different performance and reliability requirements. ICS especially uses operating systems and applications that may be considered unconventional to typical IT support personnel. Furthermore, the goals of safety and efficiency can sometimes conflict with security in the design and operation of control systems (for example, requiring password authentication and authorization should not hamper or interfere with emergency actions for ICS).
In a typical IT system, data confidentiality and integrity are typically the primary concerns. For an ICS, human or property safety and fault tolerance to prevent loss of life or endangerment of public health or confidence, regulatory compliance, loss of equipment, loss of intellectual property, or lost or damaged products are the primary concerns. The personnel responsible for operating, securing, and maintaining ICS must understand the important link between safety and security.
In a typical IT system, there is limited or even no physical interaction with the environment. ICS can have very complex interactions with physical processes and consequences in the ICS domain that can manifest in physical events.
Safety as an IoT requirement also addresses one key aspect of system behavior: protection against entropic (random) faults of an unintentional nature.
The following safety requirements might overlap and be interdependent with other requirements to follow in this book, but they are worth understanding independently because of the critical nature of safety in the IoT.
Information technology (IT) is full of false claims about performance, which will represent a large safety risk to the IoT. Vendors of IT hardware and software alike will publish claims about performance metrics that simply cannot be replicated. This is all too common; however, industry has learned to adapt to this chronic overstatement of performance by discounting vendor claims, requiring (expensive) trials and proof-of-concept demonstrations, and generally over provisioning infrastructure.
Customers often buy a network device expecting that it will perform at 1 Gbps, for instance, only to find that once they configure it the way they need its performance drops to half or even less! Similarly, organizations invest in software expecting that it will handle (again, just an example) 100 transactions per millisecond, only to find that the vendor performance claims are supported only with very specific hardware configurations that are not appropriate to the customer environment.
In the IoT, where the logical-kinetic/cyber physical interfaces predominate, performance will be about features and metrics like: time criticality, delay, or jitter -- reliability of performance; whereas some of the IT-related metrics like maximum throughput might not be important. We will discuss such performance metrics subsequently in this section.
In the IoT, performance of endpoint, gateway, network, and cloud/data-center elements needs to be as advertised by product and service vendors.
Clarity of performance in products and services is an essential requirement of the IoT. When it comes to performance in the IoT, both product and service vendors need to be aware that fudging the numbers or being deliberately vague or deceptive drives untold risks.
Reliability and consistency
ICS includes safety instrumented systems (SIS), which are hardened information elements built for high reliability and associated with failing safely and predictably. This is what the IoT needs.
Conversely, IT elements from the enterprise network and data center (DC) environment are typically not built for high reliability; they are integrated into high-availability (HA) pairs and clusters. HA is a cheap substitute for hardware and software reliability because it is assumed that even with poor reliability, most (or at least half) the elements will remain functional after a failure in one element.
RIoT Control: Understanding and Managing Risks and the Internet of Things
Written by Tyson Macaulay
Published by Elsevier/Morgan Kaufmann
Get your copy of RIoT Control: Understanding and Managing Risks and the Internet of Things
IT design conventions related to high availability and clustering do not extend well into the more remote parts of the IoT, such as gateways and endpoints, where the economics (business cases) just do not make sense and the services cannot be deployed based on safety techniques that rely on doubling up on infrastructure.
Many ICS processes are continuous in nature and must therefore be reliable. Unexpected outages of systems that control industrial processes are not acceptable. ICS outages often must be planned and scheduled days or weeks in advance. Exhaustive pre-deployment testing is essential to ensure reliability of the ICS.
In addition to unexpected outages, many control systems cannot be easily stopped and started without affecting production and safety. In some cases, the products being produced or equipment being used is more important than the information being relayed. Therefore, use of typical IT strategies, such as rebooting a component, are usually not acceptable solutions due to the adverse impact on the requirements for high availability, reliability, and maintainability of the ICS.
Similar to the requirements for performance, reliability in the IoT needs to come with more significant and robust specifications with regard to reliability. Measures like mean time to replacement (MTTR) or mean time to failure (MTTF), which are common in the network and DC world, will need to be extended out towards the edges of the network, in which devices cannot be deployed in HA or clustering designs.
Overall, safety in the IoT will require that gateway elements especially, but also endpoints, become more reliable and consistent in stand-alone performance.
Nontoxic and biocompatible
Much like concerns today about batteries, compact florescent lights, mercury thermostats, and ozone-depleting air conditioning units, a substantial safety risk in the IoT will be associated with the impact of materials used to build IoT devices.
The IoT in many cases will be about devices that are destined to be absorbed into the environment or embedded into living tissues and bodies. For instance, environmental sensors might be deployed with the expectations and business assumptions that once they cease working, they will be left in place to simply decay and disappear. Alternately, the current generation of wearable technologies will inevitably evolve into other devices that will be placed more directly on the skin for longer periods of time or will be embedded. The implants of today will certainly become connected, for the purposes of better monitoring, diagnostics, and management.
IoT devices will need to be designed with environmental safety in mind. Devices made of toxic materials will probably engender rougher regulation and monitoring of their distribution, use, and disposal -- raising costs.
Safety of the IoT will have a lot to do with not only how the devices act and respond to commands, but what they do to the environment in which they operate, both during and after their useful life.
The need to start engineering devices with newer, specially developed biocompatible materials will potentially mean that other safety features such as reliability and predictability may suffer because the world of information processing and computing is very demanding in terms of physical stresses. Moves toward more environmentally friendly, safe materials in the construction of IoT endpoints will absolutely have effects on the data processing and management assurance of those devices, if for no other reason than that it will reflect a change in the system.
Understanding the safety and risk trade-offs associated with the use and adoption of new, safe materials in the IoT will be critical for risk managers.
Related to the issue of toxicity in IoT safety is the matter of safety and disposability. What happens when the device reaches end-of-life, is made obsolete, no longer wanted, or is defective and cannot be repaired? From a safety perspective, the environmental issues are clear -- but the linkages between safety and information security associated with disposability may not be apparent at first glance.
Read the entire chapter
Download the PDF of chapter six to learn more!
In the security world, hardware and software disposal is a well understood security process and requirement. Device, system, and service owners in the IoT all must be sure that information is destroyed in the process of disposal of IoT devices, and unauthorized access is not granted to personal or proprietary information (operating systems, configurations, designs, and so on). Many spectacular information security breaches have occurred due to poor or missing disposal practices.
There are disposal issues around safety, too, that will have cascading impacts to IoT security and risk management overall.
Disposability will affect safety in the IoT in relation to elements like the biological and environmental toxicity of the IoT endpoint and edge devices. Will they poison the users? Will they become hazardous once they reach landfills or incinerators in the thousands or millions, or once they get decommissioned but left in place, whether embedded into asphalt or embedded into living flesh?
For instance, in the case of wearables or devices that might get embedded into objects or people, there will evolve clear requirements for mechanically and environmentally stable materials such as:
- Batteries and energy collection and conversion parts
- Processors and memory
- Packaging, housing, and monitoring and control interfaces
- Substrates and functional materials
While safety may dictate that certain materials be used and others be avoided, the impact on information security may be hard to balance as a requirement. For instance, tamper proofing or tamper resistance of information processing or storage parts may require materials that do not meet safety and disposability criteria! Or, disposable battery types may not support the availability requirements and service levels of information security.
Safety and change management in the IoT
Change management is paramount to maintaining the security of both IT and IoT systems, and is also applicable to both hardware and firmware. As every student of information security knows, patch management required to fix vulnerabilities and other security-impacting flaws is a major supplicant to change-management processes.
Unpatched systems represent one of the greatest vulnerabilities to an IT system. Software updates on IT systems, including security patches, are typically applied in a timely fashion based on security policy and procedures intended to satisfy compliance (organizational) requirements. These procedures are often automated in enterprise IT, using server-based tools and auto-update processes.
Yet, software updates in the IoT cannot always be implemented on an automated basis. In the IoT, each software update may have safety-critical dependencies associated with it, whether it be associated with downtime for patching or the fundamental stability and performance of the IoT system after patching. IoT updates will need to be thoroughly tested and sanctioned by the potentially multiple stakeholders, such as the various equipment, application, and service vendors, as well as the user of the application.
The IoT system, as a whole, may also require revalidation and certification as part of the service level agreement (SLA) and compliance processes stipulated in contracts to high-assurance clients like governments or banks.
Change management process from IT might be the basis for change management in the IoT, but wholesale adoption would be inappropriate and such practices would represent risk to an IoT system or service.
Tyson Macaulay is a Chief Technology Officer and Chief Security Strategist with more than 20 years in the security industry and experience at firms such as Fortinet, Intel and Bell Canada. Based in Sunnyvale, California, he is also a researcher with lectureship, books, periodical publications and patents dating from 1993. Tyson supports the development of engineering and security standards through the International Standards Organization (ISO), and Professional Engineers of Ontario. His specialties are Telecom-grade security design, Enterprise Risk Management, Technical Risk Management, Security Architecture, Security Methodology, Security Audit and Compliance, Security program development and Governance, International Standards development, Internet of Things (IoT), and International Security Standards.
Reprinted with permission from Elsevier/Morgan Kaufmann, Copyright © 2016