So far, we have discussed only the notion of standards for IoT because standards are often the basis for determining how systems are deployed. However, standards are not the only piece to consider. Other tools and techniques can help with implementing IoT systems in as secure a way as possible.
Regulations: Directives that safeguard information technology and computer systems, with the purpose of forcing companies and organizations to protect their systems and information from cyber attacks. Examples include NERC-CIP for power utilities in North America and the Directive on Security of Network and Information Systems (NIS Directive) in Europe. Organizations must adhere to regulations.
Standards: Details on how specific methods must be applied in a consistent manner. Techniques are generally documented in published materials, in an attempt to protect the cyber environment of a user or organization. The principal objective is to reduce risk, including to prevent or mitigate attacks. Conformance to adopted standards is usually compulsory and measured against to ensure an acceptable level of quality or attainment. Examples include IEC-62443 for industrial control system security.
Guidelines: Additional details on ways to secure an environment or system. These are similar to standards but are considered merely recommendations. An example is the NIST NISTIR 7628 guidelines for smart grid cybersecurity.
Policies: A written strategy to meet the security needs of an organization, providing a statement of intent by an organization’s management. Compliance is mandatory. Policies provide top-down requirements for the organization to protect assets and information, as well as to meet any regulations or legal requirements.
Procedures: Step-by-step actions that must be taken to implement policies and standards. These might include a series of detailed steps and instructions to accomplish an end goal. Procedures are mandatory. An example is the maximum duration for user account passwords and the point when new ones need to be created.
It is important to remember that standards are neither essential nor mandatory when designing and implementing IoT systems and platforms. However, they typically make the process easier and should extend the system lifecycle length by increasing the capability to introduce new technologies and upgrades that interoperate with what is already there.
So why is this important? What will standards help deliver in IoT to make them worth pursuing? ETSI outlines these key areas, which are clearly applicable to IoT:
Safety and reliability: In IoT, key focus areas must be delivered against. These include data privacy and security, as well as safety and environmental care in industrial environments. Standards help ensure that these areas can be met, which then improves user confidence and fosters the adoption of new technologies.
Interoperability: A fundamental requirement of IoT is the capability of devices to work together. This is supported by products, technologies, and services that adhere to standards.
Scalability: Scalability is critical in addressing the dynamic technical and business needs for IoT. All architectures and solutions must be capable of deployment for medium-sized instances and then must seamlessly scale up or down, as needed. This includes network, storage, analytics, and security, as required.
Support of government policies and legislation: Standards are frequently referenced or leveraged by those who create legislation to protect user and business interest and to support government policies. In highly regulated industries that leverage IoT, this is essential.
Business benefits: Organizations need a solid foundation to develop new technologies and enhance existing practices. Standards provide this foundation and help customers reduce both capital and operational costs. This could be through opening or establishing new markets for IoT, encouraging innovation, and increasing awareness of IoT initiatives and opportunities.
Choice: Standards provide the foundation for new features and options, enhancing both daily lives at work or in personal areas.
Security: We need to leverage standards and best practices to minimize the attack surface, get better visibility of security incidents, and leverage consistent tools to defend, detect, remediate, and report in the security environment. Before we design and implement the future IoT, we must first ensure that it is secure.
Without standards, there is a much greater chance that technologies and solutions will not work as expected, will have shorter lifespans, will be incompatible with other solutions and thus be siloed, and will confine consumers of IoT technologies to a single vendor with its own proprietary standard. These last two points have often been seen in IoT during the last few years.
This all sounds good in principle, but is it the same in practice? Can we just adopt open standards for IoT and see that everything will turn out okay? Naturally, other areas must be considered.
What do we mean by open standard? As with the definition of IoT, no single, agreed-upon definition exists for what constitutes an open standard. The ITU provides a good perspective, describing open standards as those available to the general public that are developed (or approved) and maintained via a collaborative and consensus-driven process to facilitate interoperability and data exchange among different products or services, for widespread adoption. In “What are open standards?” (2008) Stephen Walli further clarifies this and argues that technology interoperability standards are specifications that define the boundaries between two objects that have been put through a recognized consensus process. That consensus process could be a legal process supported by national standards organizations, by industry or trade organizations with a broad interest, or by a consortia or alliance with a narrower focus. Unfortunately, Walli admits that the standards process does not always seek to find the best technical solution; instead, it looks for the best consensus-driven solution for all participants.
This leads us to another nuance in the standards world. Open does not mean interoperable, although the two words are often used interchangeably. Open means that a system has been designed so that interoperability with it is possible. However, the other technology will have to work with a specific part or parts of a standard, and today there are many such standards. IoT entails multiple and diverse technologies, and these must communicate and interwork on all levels—communications and connectivity, software and applications, platforms to bring things together, and business and industry models. Only when all these areas have common standards will we have true interoperability.
This is a daunting challenge because we need to address architecture, system, hardware, data and file formats, languages and models, and communications protocols. Just because we use a particular protocol between devices and they can communicate with syntactic interoperability does not mean the devices can automatically interpret the information exchanged meaningfully and accurately to produce useful results (demonstrating semantic interoperability). Having an “open” architecture does not mean interoperable or open communications are included. So as we plan, design, and build our IoT systems and platforms, we need to be careful with our use of terms: Open does not necessarily mean open, and interoperable does not necessarily mean interoperable, despite what the standard states.
On the positive side, we do have examples today of open interoperable standards in technology, such as TCP/IP or UNIX, and we also have examples of an open, interoperable system, with the Internet. We now need to see the same methodology, principles, and practices emerge for IoT standards to meet the requirements of an open and interoperable IoT system. This will bring out the capability to provide services to and accept services from other systems, and to use the services exchanged to operate effectively together. Both the devices and users would benefit greatly. This is where standards should play the part, facilitating interoperability between products in heterogeneous multivendor, multinetwork, and multiservice and -application environments. Linked to this, standards groups should focus on working with other standards groups, consortia and alliances, and regulators to try to achieve interoperability.
In practical terms, we need standards to help deliver, in a consistent way, a heterogeneous architecture and communication approach for IoT platforms that are open and interoperable. For this to happen, we need to improve connectivity and communications protocols, leverage common processing and programming interfaces and languages, and provide orchestration and automation platforms that remove the barriers among diverse computing platforms, devices, and operating systems. This heterogenous design requirement flows neatly into the NFV and SDN domains, which focus on the outcomes of the system and the system resources instead of on specific physical boxes confined to specific tasks and not being interoperable with other vendors’ tasks or systems. We also need to change the approach from the traditional system, in which data is created, captured, and used by humans, to one in which potentially millions or tens of millions of devices are interconnected and interoperate by capturing and using data created by other devices. Only at this stage will we have a chance at true interoperability and open standards for IoT.