Cisco Press

In this sample chapter from Orchestrating and Automating Security for the Internet of Things: Delivering Advanced Security Capabilities from Edge to Cloud for IoT, the author team raises awareness of what should be considered when planning to secure an IoT system and highlights some of the more robust standards and best practices used today that can help.

Topics covered in this chapter include

• Today’s Standard Is No Standard

• Defining Standards

• The Challenge with Standardization

• IoT Standards and Guidance Landscape

• Standards for NFV, SDN, and Data Modeling for Services

• Communication Protocols for IoT

• Specific Security Standards and Guidelines

Today’s Standard Is No Standard

IoT can be complex and quite broad in what it attempts to address and deliver. IoT can also look and feel very different between each implementation or use case. Yet consistently, for IoT to deliver on the promised business value through connecting things and leveraging produced data for business insight, it must enable devices, networks, and applications to seamlessly work and interoperate together to produce “smart” outcomes. It must also do this in a secure way. If we are unable to deliver on this promise, then we might as well revert back to proprietary or single-vendor solutions and give up on the potential value IoT brings. The question is, will this ever happen? And will we see a time when only a few open IoT standards exist to easily enable the implementation of solutions in a consistent, secure, and manageable way?

In 2015, a McKinsey and Company report concluded that incompatibility is the number one problem facing IoT growth. The authors argued that interoperability among IoT systems is critical. Of the total potential economic value IoT enables, interoperability is required for 40 percent on average and for nearly 60 percent in some settings. With the estimated value of IoT reaching between $4 trillion and $11 trillion in revenue by 2025, the opportunity is huge. McKinsey and Company concluded, “The true potential of the market will be determined by the ability of policymakers and businesses to drive technology and innovation that is interoperable, secure, protective of privacy and property rights, with established business models that better facilitate and enable data sharing.” Clearly, to realize the benefit and value IoT can create, interoperability and standards are a must. This includes standards for interoperability and for securing the IoT.

As outlined in Chapter 1, “Evolution of the Internet of Things (IoT),” IoT has existed for many years. Various forms of standardization now being leveraged for IoT also have existed for years. Remember, we are using IoT here as an umbrella term that also includes industrial IoT and market- or sector-specific initiatives. Clearly, there are differences in terms of use cases and requirements; however, from a technology perspective, there are also many similarities. Even before the term IoT was widely adopted, elements of IoT, such as standardized communication protocols, were being explored. Standards for IoT started to really grow around 2013, with several maturing enough through 2014 to offer limited certification programs. Some of these earlier standards have even started to come to fruition and deliver against use cases. We have also seen some early harmonization of standards efforts for IoT. One example is the Open Connectivity Foundation (OCF), formed when the AllSeen Alliance and the OCF came together under the OCF umbrella, with the aim of providing the interoperability element of an IoT solution at all levels, including silicon, software, platform, and finished goods. The OCF message is clear and accurate: Interoperability standards are the starting point, but standards must progress to include security as a foundation and must address requirements for consumers, business, and industry to deliver value.

The reality, though, is that this is a nice success story in a sea of disparity and competing standards. Despite industry analysts cautiously predicting that 2017 would be the year when standards started to really align, this was not the case. The only agreed-upon conclusion is that we are still a long way from a universal IoT standard—or even two or three IoT standards. Today’s perspective from both analysts and researchers is that this disparity is likely to continue over the next few years at the very least.

So why is alignment difficult? After all, IoT is now accepted as a phenomenon, and consumers, vendors, businesses, and industries want it to succeed and provide the value it promises. If only it were that simple. In practice, a wealth of considerations have an impact on the creation and shaping of standards for IoT:

• There is still no single, agreed-upon definition of IoT. Without a universally accepted definition, how do you standardize for it?

• Many different forces continue to shape the IoT landscape, and these forces themselves are evolving. These forces can be broadly grouped into market and social trends, business digitization and transformation, the evolving workforce, and next-generation mobility for people and devices.

• As we discussed in Chapter 3, “IoT Security Fundamentals,” we need to standardize many different areas of IoT. An IoT system might contain communications, management, architecture, data normalization, services, security, hardware, applications, analytics, and so on. Even if one part were standardized, we might encounter interoperability issues with the other parts. Defining what and how things should be standardized is another challenge with no current answer.

• Different verticals and industries often have their own requirements and perspectives, thus driving different standards based on their needs. This could mean differences such as IT and OT standards within the same organization, or specific industry vertical initiatives such as smart cities, digital manufacturing, or smart energy that have different regulations or guiding principles.

• New use cases continue to arise, often driven by the advent of new technology. How can we constantly ensure that standards apply? Creating security by design is difficult if the use case is ahead of technology and security for that requirement. New use cases often leverage proprietary measures with the aim of them becoming standardized at some stage, but this usually results in limited security response capabilities (and even more standardization efforts).

• New technologies and technology architectures are still being developed. If we consider advancements in areas such as NFV, SDN, cloud, fog, software-defined automation (SDA), and autonomic networking, and couple this with new technology areas such as deterministic networking, NB-IoT and LoRa in the RF space, and 5G, and then throw in aspects of Big Data, analytics, machine learning (ML), and AI, we can see that the potential arena is huge. The Gartner Hype Cycle for the Internet of Things (2016) in Figure 4-1 highlights this landscape and shows the emergence of IoT areas; all of these need to be secured and, if possible, standardized.

• Not all IoT solutions will be deployed in greenfield environments. In fact, a good percentage of environments exist today and are evolving. This means that legacy and proprietary technologies need to be integrated, further muddying the standardization opportunity.

• IoT is more complex than either IT or OT on their own. This might seem pretty obvious because often a combination of IT and operational technologies and systems is needed to deliver against a use case. However, IoT is often approached in the same way organizations address new technology as part of their core IT or OT business. By its very nature, IoT usually generates more data, is more geographically dispersed, contains new devices, involves new technologies, and produces a mixed IT/OT deployment environment.

• IPv6 is an enabler for IoT. IoT6.eu believes that many arguments and features (including scalability, a solution to the NAT barrier problem, multi-stakeholder support, and features such as multicast, anycast, mobility support, autoconfiguration, and address scope) demonstrate that it will be a key communication enabler for IoT in the future. IPv6 also supports tiny operating systems, provides increased hardware support, and supplies new protocols focused on interoperability among different layers of the IoT stack.

• Legislation and regulations are starting to arise. Early examples include NERC-CIP, for power utilities in North America, and ENISA, which focuses on delivering a governance framework to coordinate cybersecurity standardization within Europe.

• A major challenge is that standards groups, alliances, and consortia often consist of large vendors who are unlikely to want to give up their market share. We are starting to see potential shifts here, with customers demanding interoperable efforts. One example is the Open Group Open Process Automation standard, driven by Exxon Mobil requirements for its next-generation processing environments.

• The speed of standards development is usually slow. This contrasts with development within the communications industry, where technology moves at pace to address customer business needs. This pace can result in proprietary efforts because of business demand, not necessarily vendor choice.

• Security itself is not a simple phenomenon. It must be addressed across the board and built in from scratch, not just piecemeal. Security can often be a driver for change, but usually it is playing catchup to try to secure a lack of interoperability.

As a result, we are still waiting for the IoT market to develop an approach that would allow for a fully end-to-end, consistent security strategy. We also need to realize that many standards, guidelines, and consortia have existed before IoT (technology has been around for some time) and must still adapt to IoT. These other standards should not necessarily be discarded; they have already shown value.

Looking at these challenges, IoT remains something of a puzzle. The use cases and business scenarios require interoperability and simplification of technology to work, with enabling technologies rationalized around robust and secure standards that also include legacy environments. However, these use cases and business scenarios are still evolving, with new endpoints and technologies being frequently introduced into a landscape without appropriate standardization. This makes the idea of standards an even more complex and challenging task. We will look at this more closely in this chapter as we explore the following topics:

• How standards are defined

• Why we need standards

• An overview of the IoT standards landscape

• Standards for NFV and SDN

• Security standards for IoT and NFV/SDN

The aim of the chapter is not to detail or recommend standards and guidelines, but to raise awareness of what should be considered when planning to secure an IoT system. We also highlight some of the more robust standards and best practices today that can help.

Defining Standards

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.

The Challenge with Standardization

So what does this mean in terms of choosing the right IoT standards to focus on? First, we need to understand who is involved in standardization or guidance efforts:

• Alliances: An alliance is an agreement between two or more parties to pool re-sources to make a more powerful impact. It usually is not a legal partnership entity, agency, or corporate affiliation.

• Consortia: A consortium agreement is a private agreement between two or more parties that outlines rights and obligations among themselves. The objective is to pool resources to achieve a common goal. However, the members are responsible only to the group in regard to the obligations in the consortium contract. Each member remains independent in normal business operations, with no say over other members’ work that is not related to the consortium.

• Standards bodies: Known as standards organizations, standards bodies, standards-developing organizations (SDO), or standards-setting organizations (SSO), their primary activities are developing, coordinating, revising, and producing technical standards to address the needs of a group. Standards bodies can be international, regional, or national.

• Regulatory bodies: These bodies set mandatory or legal requirements, often drawing from standards to leverage existing best practices developed by expert committees using a consensus-based and transparent process.

If we attempted to research and outline every standard and set of guidelines that applies to IoT, we would need to write volumes, as you will see from the compiled list of 109 different bodies later in this chapter (see Figure 4-2)—and this is not an exhaustive list. Furthermore, some of the groups have multiple standards or guidelines that apply to IoT. One example is the IEEE, which outlines 80 of its own IEEE standards as applicable to IoT (see http://standards.ieee.org/innovate/iot/stds.html) and has an additional 45 standards in development for this space. Working through this minefield, we also need to understand that standards are often driven by consortia and alliances, which naturally push for their own interests. Beyond that, standards are usually merely a best fit, not the best technical solution. So why do we bother?

The answer is simple: Without standards, we will not see the potential returns and benefits promised by IoT. At a bare minimum, we need communication standards for interoperability. Without interoperability, different devices and systems from different vendors will not work with one another, and this will return us to the silos of yesterday. Yet we must go beyond just connectivity to realize the benefits.

As the industry evolves, we have an increasing need for a standard model and process, not just to allow devices to communicate, but also to perform common IoT back-end tasks such as security, automation, analytics, and business insight. As end users continue to drive this need, we will see different IoT solutions interoperating with common back-end services, guaranteeing levels of interoperability, portability, serviceability, and manageability that are impossible to achieve with current IoT solutions. A 2015 Gartner study argues that this next-generation IoT system will be delivered as a service (aaS), aligning with our approach for the SDN- and NFV-focused platform we discuss in detail in Chapter 8, “The Advanced IoT Platform and MANO.” This means that the scope of standards we need to address is not limited to the traditional IoT ones, but should be expanded to include SDN and NFV. We also need standardized ways to deliver the necessary IoT capabilities as a service and we need security-specific standards that might not have been developed with IoT in mind.

As we look to architect, design, and build our IoT systems, we need to carefully consider what standards are out there today and which standards are developing. We need to choose wisely. We currently have a broad collection of standards, alliances, consortia, and also regulatory bodies to help, and we outline these in the next section. From a security perspective, standards will help our cause. We need standards to minimize the attack surface, gain better visibility of security incidents, and provide consistent and usable tools to defend, detect, remediate, and report security incidents.

The following are some practical considerations:

• Do not create something that already exists. The U.S. Department of Homeland Security recommends building on recognized architectural and security practices as part of a strategy to secure IoT. Many tested practices used in traditional IT and network security can be applied to IoT. These approaches can help identify vulnerabilities, detect irregularities, respond to potential incidents, and recover from damage or disruption to IoT devices and systems.

• Start with basic, consistent architecture and cybersecurity standards and best practices, and apply them to not only the IoT system, but also the entire IoT ecosystem that might form part of a solution.

• Leverage sector- or market-specific best practices and guidelines, where available, to address unique architectural and security approaches or regulation.

• Try to assess industry indicators for which standard will win out in the long term. Backing the wrong standard could result in a system that eventually becomes noninteroperable or obsolete, and this has time and money implications. Look at the standards bodies that the large vendors and industry players are backing. Of course, this could be a challenge if multiple industry-leading IoT companies, such as Cisco, Intel, IBM, GE, and Microsoft, appear to be hedging their bets and working across multiple consortia.

IoT “Standards” and “Guidance” Landscape

The standards, guidelines, consortia, and alliances landscape is broad, with a wealth of options. In the short term, these options likely will increase, but the industry eventually needs to converge to realize the IoT vision. Figure 4-2 shows the main groups that exist in 2017, although this is not an exhaustive list.

Before looking at an overview of the standards, we need to emphasize the importance of risk. This is usually the first step in deciding what needs to be protected. No specific risk standards exist for IoT, although many IoT or IoT-related standards do contain elements of risk. Internationally recognized standards such as ISO 27001 and ISO 27005, IEC 62443, NIST SP 800-39 and SP 800-37, and the Open Group Risk Taxonomy Standard also cover both the IT and OT angles for IoT. In addition, be sure to keep in mind the proposed new framework we suggest in Chapter 2, “Planning for IoT Security.”

The following section outlines the key standards, alliances, consortia, and guidelines in four main areas that need to be considered for IoT systems. The Glossary contains information and links to all 109 resources.

• Umbrella: Covers the entire IoT stack, but with no specific market or sector focus

• Industrial/sector/market: Covers the entire IoT stack, with a specific market or sector focus

• NFV/SDN: Covers NFV or SDN in general, but not specifically for IoT (although some of these groups do have specific IoT focus areas)

• Security: Covering security in general, security for IoT specifically, or security for a specific market or sector

Each grouping has a link or a drive for IoT, based on industry direction or market research (whether directly or indirectly focused on IoT); each grouping also has a security element. The security elements of each standard are not called out specifically in this chapter, and additional information is available on the website of each group. The groups are listed in alphabetical order, not in order of importance or applicability.

Architectural or Reference Standards

• The Alliance for Internet of Things Innovation (AIOTI; https://aioti-space.org/) was founded in March 2015 by the European Commission. Its aim is to create and foster a European IoT ecosystem to accelerate the adoption of IoT. As part of this work, the AIOTI is supporting the convergence of IoT standards, researching how to remove barriers to IoT adoption, and aligning the EU with the rest of the world’s IoT activities.

• The European Telecommunications Standards Institute (ETSI; www.etsi.org and www.etsi.org/technologies-clusters/clusters/connecting-things) has focused its IoT-specific work since May 2015 on ensuring interoperable and cost-effective solutions for M2M, particularly for smart services and applications for IoT. The ETSI is developing standards for data security, data management, data transport, and data processing, with specific initiatives in smart devices, appliances, homes, buildings, connected vehicles, smart grids, and cities. ETSI collaborates with oneM2M in IoT.

• The Institute of Electrical and Electronics Engineers (IEEE; http://standards.ieee.org/innovate/iot/index.html) has several IoT-focused groups, including the IEEE IoT Initiative, established in 2014, and the IEEE P2413 working group. The IoT Initiative has developed (and continues to develop) a number of standards and is a central point for all IEEE IoT activities. The IEEE P2413 working group focuses on developing an IoT reference architecture, covering basic building blocks, their capability to be integrated into multitiered systems, and security.

• The ITU Telecommunication Standardization Sector (ITU-T; http://www.itu.int/en/ITU-T/studygroups/2017-2020/20/Pages/default.aspx) launched its Internet of Things Global Standards Initiative in 2013. Its work is driven by Study Group 20 (SG20), with a focus on IoT and smart cities and communities. Its goals include standardization requirements for the coordinated development of IoT technologies such as M2M and ubiquitous sensor networks, as well as an end-to-end architecture for IoT.

• The Internet Engineering Task Force (IETF; https://trac.tools.ietf.org/area/int/trac/wiki/IOTDirWiki) is the leading Internet standards body. It has a specific IoT group that is coordinating related efforts across its working groups, reviewing specifications for consistency, and monitoring IoT-related activities in other standards groups.

• The Internet Research Task Force (IRTF; https://www.internetsociety.org/publications/ietf-journal-april-2016/internet-things-standards-and-guidance-ietf), part of the IETF, has been working on various IoT-related initiatives since 2005. Today it has seven working groups, focused on IPv6 over Low-power WPAN (6LoWPAN), Routing Over Low-power and Lossy networks (ROLL), Constrained RESTful Environments (CoRE), 6TiSCH WG (IPv6 over the TSCH mode of IEEE 802.15.4e), Concise Binary Object Representation (CBOR), and IRTF Thing-to-Thing Research Group (T2TRG).

• IoTivity (https://www.iotivity.org/) founded its open source framework for IoT device-to-device connectivity in 2016. The project is sponsored by the Open Connectivity Foundation (OCF) and hosted by the Linux Foundation.

• The IPSO Alliance (https://www.ipso-alliance.org/) was formed in 2008 with a mission to establish and develop industry leadership for a platform that includes the definition and support of smart objects, with an emphasis on object interoperability on protocol and data layers and also identity and privacy technologies. For IoT smart objects, this includes libraries, repositories, design kits, lifecycle management, and interoperability, with a focus on openness and accessibility.

• The Object Management Group (http://www.omg.org/hot-topics/iot-standards.htm) is a technical standards consortium that is developing several IoT standards, including ones that focus on the Data Distribution Service (DDS) and Interaction Flow Modeling Language (IFML), dependability frameworks, threat modeling, and a unified component model for real-time and embedded systems. The Object Management group has also managed the IIC since 2014.

• The Open Connectivity Foundation (OCF; http://openconnectivity.org/), renamed in 2016 from the previous Open Interconnect Consortium (OIC), develops specification standards, creates interoperability guidelines, and provides a certification program for IoT devices. It is one of the largest IoT organizations (members include Microsoft, Intel, Cisco, and Samsung) and it sponsors the open source IoTivity Project.

• The Open API Initiative (https://www.openapis.org/) provides a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful API web services as part of the OpenAPI Specification. Development started in 2010, with the OpenAPI Specification released in 2016.

• The OpenFog Consortium (OFC; www.openfogconsortium.org) was established in November 2015 with the founding members ARM, Cisco, Dell, Intel, Microsoft, and Princeton University Edge Computing Laboratory. OpenFog is a public–private ecosystem formed to accelerate the adoption of fog computing to solve the bandwidth, latency, and communications challenges associated with IoT, Artificial Intelligence, robotics, the tactile Internet, and other advanced concepts. This includes defining a reference architecture of distributed computing, network, storage, control, and resources to support intelligence at the edge of IoT (including autonomous and self-aware machines, things, devices, and smart objects in a variety of disciplines and fields).

• The Organization for the Advancement of Structured Information Standards (OASIS; https://www.oasis-open.org/) was founded in 1998. It currently promotes industry consensus and produces standards for security, IoT, cloud computing, energy, content technologies, and emergency management.

The main umbrella groups for IoT security are the National Institute of Standards and Technology (NIST) and the Cloud Security Alliance. The section “Specific Security Standards and Guidelines,” later in this chapter, covers both.

Industrial/Market Focused

• The Industrial Internet Consortium (IIC; www.iiconsortium.com) was established March 2014 with the founding members in AT&T, Cisco, GE, IBM, and Intel. The focus of the IIC is to accelerate the industrial IoT, to promote open standards and interoperability for technologies in industrial and machine-to-machine environments. This includes defining use cases and test beds, creating interoperability reference architectures and frameworks, influencing the standards process for the Internet and industrial systems, and facilitating the open sharing of information, ideas, and experiences. The IIC also seeks to build confidence in new approaches to security.

• The Open DeviceNet Vendors Association (ODVA; www.odva.org) was founded in March 1995 and underwent a 2014 relaunch. Members are suppliers of devices for industrial automation application. Current efforts target transforming industrial automation in integrated cyber-physical systems, with connectivity between things inside and outside the plant. Its approach includes technologies such as SDN, time-sensitive networks (TSN), mobility, cloud, and industrial cybersecurity to make IIoT a reality.

• The Open Group Open Process Automation (http://www.opengroup.org/open-process-automation) was established in September 2016, driven by the needs of ExxonMobil. It was standardized by the Open Group because of its applicability to multiple organizations and industries. The Open Process Automation Forum is an international forum of end users, system integrators, suppliers, academia, and other standards organizations whose aim is to develop a standards-based, open, secure, and interoperable process control architecture. A key element in this is to offer a customer-driven standard, pushing control vendors away from proprietary systems. The standard is a good mix of users and suppliers of process automation systems, and scope covers edge to cloud because of IoT.

• The Manufacturers Alliance for Productivity and Innovation (MAPI; https://www.mapi.net/forecasts-data/internet-things-industrie-40-vs-industrial-internet) was revived in 2011. It developed Industrie 4.0 for industrial applications of IoT, which focuses on automation and data exchange in manufacturing technologies, including cyber-physical systems, IoT, and cloud computing. Four design principles are central to Industry 4.0: interoperability, or the capability of machines, devices, sensors, and people to communicate with each other via IoT or the Internet of People (IoP); information transparency, or the idea that information can create a virtual copy of the physical world by enriching digital plant models with sensor data; technical assistance, or the capability of assistance systems to support humans in making informed decisions, as well as the capability of cyber-physical systems to physically support humans by doing work deemed unsuitable for people; and decentralized decisions, or the autonomy of decision making for cyber-physical systems.

• oneM2M (http://www.onem2m.org/), formed in July 2012, focuses on developing communications architecture and standards, as well as security, interoperability, and specifications for machine-to-machine and IoT technologies. Its framework supports a number of verticals including healthcare, industrial automation, smart grid, connected car, and home automation.

• OLE for Process Control (OPC; www.opcfoundation.org), founded in 1996, provides an interoperability standard for the secure and reliable exchange of data in the industrial automation space and other industries, including IoT. The developed specifications have been created by industry vendors, end users, and developers. In 2008, OPC-UA (OPC Unified Architecture) was launched, providing a service-oriented architecture to integrate individual OPC specifications into a single framework.

• The Smart Grid Interoperability Panel (SGIP; http://www.sgip.org/cybersecurity/) was established in December 2009. SGIP focuses on interoperability standards to advance power grid modernization and accelerate the interoperability of smart grid systems and devices. It has a specific IoT effort within the energy industry to incorporate common data models and IoT communication protocols.

• The Thread Group (https://www.threadgroup.org/), formed in July 2014, drives an IPv6 networking protocol for IoT to automate home devices such as lighting and security systems on a local wireless mesh network. Thread provides a certification program for Thread-based devices.

The main security standards and regulations for the industrial space include IEC 62443 for industrial control systems, IEC 62351 for power automation, and NERC-CIP for the North American power industry. These are covered in the section “Specific Security Standards and Guidelines,” later in this chapter.

Standards for NFV, SDN, and Data Modeling for Services

A 2015 Gartner report recommends a number of principles for IoT solutions architects:

• Design IoT solutions for software-defined things, leveraging a software-defined architecture.

• Build up the technology skills and expertise for the management of large-scale, automated, event-driven systems.

• Invest in technology and expertise in virtualization and software portability, including containerized microservices.

• Choose platforms that offer agility, extensibility, and openness.

These relate directly to the capabilities of NFV and SDN and the level of flexibility, programmability, and automation they provide. NFV and SDN are often used interchangeably, but they are two very distinct technology areas. However, combining them in discussion can bring additional value to some of the complex IoT challenges, as you will see in later chapters of this book. Interestingly, as with IoT, no single standards body exists for NFV or SDN. The SDX Central research repository monitors organizations and standards bodies that exist to enhance SDN, NFV, and NV (network virtualization) adoption and implementation. Its annual report in 2016 listed 138 different organizations. However, we do see a lot of interoperability and openness in the industry to allow different vendor solutions to come together. Not only do we continue to see adoption in the service provider and enterprise spaces, but there is a trend for adoption in the ever-growing IoT space because of the flexibility and features they provide over traditional static network architectures.

Chapter 6, “Evolution and Benefits of SDX and NFV Technologies and Their Impact on IoT,” covers NFV and SDN in detail but a brief overview is provided here to give some context in terms of the technology and standards.

Network functions virtualization (NFV) offers a standardized way to architect, implement, and manage networking services. (As we highlight later in this chapter, this can also be extended to other services beyond the network.) The concept involves replacing dedicated network infrastructure devices such as routers and firewalls with standard servers, switches, storage, cloud, or even a fog/edge computing infrastructure. NFV decouples network functions such as routing, switching, and security from proprietary or dedicated hardware appliances, to allow them to run in software.

The aim is to leverage standard IT virtualization technologies to consolidate hardware and to virtualize network functions into building blocks that can connect or chain together to create end-to-end communication services. This can be realized for any control plane function or data plane processing in wired and wireless network environments.

NFV was really born in 2012 when seven of the leading global network service providers came together under the ETSI Industry Specification Group for NFV. This is the main group for developing the requirements and architecture for virtualization for various functions within telecom networks and for the architectural standards for NFV, such as the NFV MANO (Management and Orchestration) architecture. It has become the de facto standard for NFV.

The NFV framework has three main components, as Figure 4-3 shows. The Virtualized Network Functions (VNF) are network functions that are implemented in software and can be deployed in a network functions virtualization infrastructure (NFVI). The NFVI is the overall hardware and software components where VNFs are deployed. The NFV management and orchestration (MANO) environment is the architectural framework that contains the functional blocks, data repositories used by these blocks, and interfaces through which the functional blocks exchange information for the purpose of managing and orchestrating NFVI and VNFs.

Software-defined networking (SDN) is an approach to design, build, and operate networks by separating the control and data forwarding planes. This enables the network to become directly programmable and dynamic, and it abstracts the lower-level infrastructure functionality. The term arose in the mid-1990s. However, it really became established in 2011 when the Open Networking Foundation was founded to promote SDN and used OpenFlow as the key protocol to describe how to make changes to the network in a standardized way. SDN and OpenFlow are sometimes used interchangeably, but this is inaccurate. OpenFlow is a protocol, and other communication mechanisms can be used to deliver SDN capabilities.

Several different architectures separate the control logic to off-device resources, but all SDN approaches include an SDN controller and both southbound and northbound APIs (see Figure 4-4).

With the close alignment of NFV and SDN as advanced technology areas, some groups are concerned with standards and best practice for SDN, NFV, or often both. The following is a compilation of the key groups and their focus areas, listed alphabetically.

• The Alliance for Telecommunications Industry Solutions (ATIS; http://www.atis.org/) SDN and NFV Focus Group was launched in January 2014, with a focus on the service chaining of hardware/NFV appliances using SDN concepts. This includes developing application interface APIs and OAM interface APIs for service chaining in an OpenStack and OpenDaylight framework.

• The Broadband Forum Member (BBF; https://www.broadband-forum.org/) works on both SDN and NFV, with a focus of delivering cloud-based broadband and NFV into the home via service provider networks. In 2017, the BBF entered into a memorandum of understanding (MoU) with the SDN/NFV Industry Alliance to promote the development of network transformation and cloud evolution.

• The European Telecommunications Standards Institute (ETSI; http://www.etsi.org/technologies-clusters/technologies/nfv) is the main global driver for NFV. The NFV group was founded in November 2012 by seven leading telecoms operators, and ISG NFV became the home of the Industry Specification Group for NFV.

• The Institute of Electrical and Electronics Engineers (IEEE; https://sdn.ieee.org/) has standardization efforts for SDN underway via two research groups and two study groups. It is examining standardization opportunities in software-defined networks, network functions virtualization, and related areas. The IEEE currently has produced eight standards for SDN.

• The International Council on Large Electrical Systems (CIGRE; http://www.cigre.org/) has a working group focused on developing the IEEE P1915.1 standard, which specifies the security framework, models, analytics, and requirements for SDN/NFV. CIGRE seeks to understand and address security models, terminology, and analytics (essential components of SDN and NFV environments) to ensure confidentiality, integrity, and availability. It also aims to produce a framework of guidelines for the procurement, deployment, and management of SDN and NFV technologies.

• The International Telecommunication Union Telecommunication Standardization Sector (ITU-T; http://www.itu.int/en/ITU-T/sdn/Pages/default.aspx) has focused on SDN since November 2012. The ITU-T has adopted Resolution 77 to push for standardization in SDN and also performs SDN-focused work in the group WTSA-12.

• The Internet Engineering Taskforce (IETF; https://ietf.org) is working on both SDN (through RFC 7426 SDN) and a new IETF SDN standards group (I2RS), to work on southbound programming protocols and NFV and network service chains.

• The Internet Research Task Force (IRTF; https://irtf.org/concluded/sdnrg) has an SDN group whose aim is to benefit all types of networks, including wireless, cellular, home, enterprise, data centers, and wide-area networks. The Software-Defined Networking Research Group (SDNRG) seeks to identify approaches that can be defined, deployed, and used in the near term, as well identify future research challenges. Key areas of interest include solution scalability, abstractions, and programming languages and paradigms that are particularly useful in the context of SDN. It also provides a forum for researchers to investigate problems in the SDN field, and it provides direct input into standards for other groups, such as ETSI, the IETF and the IEEE.

• The Internet Society (ISOC; https://www.internetsociety.org/) has IRTF and IETF groups that focus on NFV and SDN and provide architectural oversight to the Internet Architecture Board (IAB; https://www.iab.org/).

• The Metro Ethernet Forum (MEF; https://mef.net/), founded in 2001, facilitates industry-neutral implementation environments for service orchestration (OpenLSO) and L2–L7 connectivity services (OpenCS) based on technologies such as SDN and NFV. Its goal is to develop agile, assured, and orchestrated services for the digital economy and the hyperconnected world.

• The Open Data Centre Alliance (ODCA; https://opendatacenteralliance.org/) was established in October 2010. ODCA is driving a federated cloud architecture with common standards for both hardware and software. It focuses on the widespread adoption of enterprise cloud computing through best practice sharing and collaboration. ODCA has work groups for both SDN and NFV and includes organizations such as BMW, Royal Dutch Shell, and Marriott Hotels.

• OpenDaylight (https://www.opendaylight.org/) promotes an open source SDN platform for building programmable and flexible networks. The OpenDaylight Foundation was formed in 2013 and consists of solution providers, individual developers, and end users that include service providers, enterprises, and universities.

• The Open Networking Foundation (ONF; https://www.opennetworking.org/) is a nonprofit, user-driven organization dedicated to accelerating the adoption of SDN and NFV. The ONF really drove the SDN movement in 2011; it includes companies such as Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo! that aim to standardize SDN and OpenFlow. In 2017, ONF announced an Open Innovation Pipeline to guide the industry toward the next generation of SDN and NFV. Network device disaggregation, open source platforms, and software-defined standards are key priorities.

• The Open Platform for NFV (OPNFV; https://www.opnfv.org), formed in 2014 by the Linux foundation, facilitates the development and evolution of NFV components for open source ecosystems. OPNFV created a reference platform through system-level integration, deployment, and testing, to accelerate the transformation of enterprise and service provider networks. Members include AT&T, Juniper, Brocade, China Mobile, Cisco, Dell, Ericsson, IBM, and Intel.

• The Optical Internetworking Forum (OIF; http://www.oiforum.com/) has an architecture and signaling working group that is defining interfaces for SDN.

Data Modeling and Services

Data modeling is the process of creating a data model for an information system by applying formal methodologies to model data in a standard, consistent, and predictable way so that it can be managed as a resource. As with everything else, data modeling has a number of competing standards. A data modeling language is required to standardize how we describe and create capabilities and how we can deploy this as a service. For automation and scale into an open heterogenous environment in which any service from any vendor might need to be deployed into any device, we need to leverage a standards-based, model-driven, service-centric approach. This must abstract the service intention from the service instantiation and also separate the instantiation from the devices services will be deployed in. This means being open to device type (multivendor) and also to where the device is deployed (edge, fog, network, data center, or cloud). The standard must also be understood and processed by an NFV- and SDN-based orchestration system.

Many debates have questioned the best choice of modeling language for services in NFV and SDN environments. Typically, the choice comes down to YANG or TOSCA. Both have merits and strengths, but in the context of IoT, with a potentially widely distributed environment with multiple devices from multiple vendors and an architecture that could be very non–cloud focused, YANG has the best applicability. Indeed, YANG has become the standard data modeling language of choice in all environments for a number of reasons, including its applicability throughout an automation and orchestration stack:

• Network infrastructure

• Data plane programmability

• Operating systems

• Controller programmability

• Cloud and virtualization management

• Orchestration and policy

In addition, we have recently seen some of the first IoT- and fog-specific YANG models created for customer implementations in smart cities, automotive manufacturing, oil and gas, and power utilities. All are orchestrated and automated to deliver end-to-end secure customer use cases, leveraging the NFV- and SDN-based platform we describe in Chapter 8. We highlight this new approach later in this section, to show the additional flexibility and capability of YANG.

The IETF uses YANG to specify models, and YANG is also used in many standards-development organizations (SDO), consortia, and open source projects, including the Broadband Forum, IEEE, ITU, MEF, and OpenDaylight, among others. As a data modeling language, YANG is used to model configuration and state data manipulated by the NETCONF network configuration protocol. Figure 4-5 shows an overview of YANG.

YANG can be used to model both configuration data and the state data of network elements, in addition to event notifications from network elements. Data modelers thus can define remote procedure calls that can be invoked on network elements via the IETF standardized NETCONF protocol. YANG is protocol independent and can be converted into any encoding format, such as XML or JSON, that the configuration process supports.

YANG models have traditionally been used to describe networking capabilities and device configurations that leverage the NETCONF protocol. However, it is flexible and powerful enough to be extended to other areas of service definition. As mentioned earlier in this chapter, for IoT, it is essential to include the fog and edge devices, the data pipeline, service assurance, multitenancy, and additional security (see Figure 4-6). The flexibility of YANG enables the extension of the ETSI MANO architecture to encompass these additional areas and address the entire IoT stack.

In the advanced IoT orchestration and automation system that will be detailed in Chapter 8, YANG is the service model language leveraged for both device and service modeling. Chapter 8 outlines how the YANG model works and how the orchestration system leverages it to translate service intent, through to an automated deployment of the service for full use cases via service “function packs.” This includes automation capabilities for the complete IoT stack, including infrastructure, virtual network infrastructure, physical devices, virtual environments (VMware, Linux docker, and so on), service assurance, the data pipeline (message brokers, data transformation, and so on), applications and microservices, and, of course, security.

Communication Protocols for IoT

IoT is about connectivity and interoperability, as previously outlined. Without these basic elements, we cannot deliver business value. Therefore, we need communication to happen—and in as uniform a way as possible. As with IoT standards, the standards for protocols and media are heavily fragmented. This section provides an overview of the key communications protocols required for IoT to be successful. It also covers the main wireless offerings that provide the pervasive coverage essential to IoT and touches on some essential wired ones. This section aims to give an overview of the key communications protocols so that you understand what is required from a platform connectivity perspective, especially at the edge and fog layers of the system. This is not designed to be a detailed protocol analysis because much information already exists in this area.

As you have already seen, many emerging and competing networking technologies are being adopted for IoT. Various consortia/alliances, vertical markets, and vendors offer differing technologies for IoT connectivity. Traditional enterprise technologies such as Wi-Fi and Ethernet can be applied for IoT. At the same time, new technologies are being developed specifically to meet the challenges of IoT, especially closer to the edge where specific device, distance, or bandwidth challenges need to be addressed. However we look at it, communications are still the foundational enabler for IoT and are needed for all use cases.

Communication protocols are a set of rules that allow two or more devices in hardware or software to establish a reliable communication system that allows data to be transmitted between them. Rules include syntax, semantics, and synchronization, as well as error recovery mechanisms.

The most common communications model is the Open Systems Interconnection (OSI) model (see the left side of Figure 4-7), which breaks communications into seven functional layers for easier implementation of scalable and interoperable networks. Each layer delivers a specific function and handles clearly defined tasks while interfacing with the layers located directly above and below it. The model is the most widely used in network communications today, with clearly defined layers allowing easier implementation of interoperable and scalable networks.

Although this model is applicable in IoT, it faces certain challenges, especially when devices are very simple and have limited capabilities and computing. A layered approach such as this introduces complexity to the device or software and usually requires more code and memory. It also introduces data overhead because every layer requires additional framing and control messages. More complexity and data transmitted can mean increased power consumption by devices; again, this might not suit an IoT deployment with simple, battery-powered devices. A layered approach does enable more flexibility and scale, however, and also provides the best opportunity for interoperability.

As a result, we see various implementations in IoT. Some use the full OSI reference model, from physical layer to application layer. Others specify only parts of the OSI reference model and leave the remaining aspects of communication up to other technologies. This has led to a more simplistic version of the OSI model for IoT that maps more closely to the TCP/IP model. The right side of Figure 4-7 shows how the model can be simplified for IoT deployments. Some layers are collapsed here, without losing any functionality. This does not mean that one approach is better than the other, particularly because different applications running on top of the communications have different requirements; it simply makes choosing the right option more of a challenge when taking interoperability into account.

This section discusses protocols and communication media, aligning them with the IoT-centric model. Within our focus on communications for data exchange, we look at last-mile communication technologies to the things, or within the fog/edge layers. It is important to make a distinction here because the requirements are different and still emerging. The core networks remain the same and are typically service provider or enterprise based (such as with MPLS). The main change involves connecting the multitude of things together to allow them to communicate between themselves locally or else bringing them back via some kind of backhaul to a central location. Some examples you already are familiar with from the IoT standards overview section; the aim here is to reference the communication elements within them. A fundamental concept to understand is that there is no “one size fits all” approach. A deployment in a smart city might have Ethernet and Wi-Fi connections, whereas a deployment to a remote oil field could be cellular or satellite.

This is extremely important when architecting the system and can dictate architectural and technology decisions. As an example, a gateway might need to be leveraged to provide protocol translation from a legacy system at the edge so that it can be transported through the IoT system by the platform. In another case, a particular function (such as real-time analytics) might have to happen locally because limited bandwidth will not allow a certain amount of data to be transmitted. A more powerful endpoint might thus be deployed to do analytics and data normalization at the fog layer.

From the perspective of the IoT platform, it is important to understand that a wide variety of these protocols need to be addressed as uniformly as possible. This can include IP or non-IP, and different protocols are likely to exist at different levels of the IoT hierarchy. The IoT platform must provide connectivity interfaces for these protocols at the edge or fog layers, whether natively or via a gateway, and must provide a way to securely transport the data flows to their destinations at any level. This applies to both the control and content/data planes.

Following the IoT-centric model, a number of key IoT communication types are mapped out in Figure 4-8.

This model has four layers to cover the communications stack. Although it covers all the functions required, not all of the protocols fit neatly into one level. For example, DTLS fits into the transport, application, and session levels. Similarly, 6LoWPAN fits into the network, physical, and MAC levels. However, this model provides a good starting point for organizing thoughts around communication.

Physical and MAC Layers

This layer covers how a device is physically connected to a network via wired or wireless mechanisms, as well as how devices are uniquely identified by a MAC address (or potentially another method) for physical addressing. Most standards combine the physical and MAC layer protocols; these protocols are essential in establishing communication channels. For IoT, considerations when designing at this level include devices that need to operate with a long battery life, require low power consumption, and have less processing capabilities. Other points to consider are lower bandwidth availability and the need to scale in terms of connecting and operating many more devices in a single environment.

In IoT, wired Ethernet 802.3 and Wi-Fi 802.11 a/b/g/n standards are often leveraged, depending on the environment. Smart cities and manufacturing plant floors are good examples with dense coverage. Other technologies in use include 802.15.4 (802.15.4e, 802.15.4g, WirelessHART, ISA100.11a), cellular (2G, 3G, 4G, CDMA, LTE), Low Power Wide Area Network LPWAN (Long Range Radio LoRa, SigFox, Narrow Band IoT NB-IoT), 802.16 WiMax, RFID, NFC, Bluetooth (including Bluetooth Low Energy BLE), and Zigbee.

Network Layer

This layer focuses on logical addressing and how to deliver packets of information between source and destination endpoints, particularly between different networks. Routing and encapsulation protocols need to be lightweight (constrained devices) and highly scalable (potentially millions of endpoints).

The Internet Protocol (IP) is an essential element of IoT. This includes both IPv4 and IPv6; the latter is essential to address scale. IPv4 provides around 4.3 billion addresses in total, which can create a challenge as we move toward the predicted 20–50 billion endpoints by 2020. IPv6 provides around 340 billion billion billion billion addresses, meaning that the scalability challenge is negated. However, not all IoT devices need a unique or a public address; many will be deployed on private networks that will continue to use private address ranges or will be hidden behind gateways at the edge and fog layers of the network.

The use of IP not only provides interoperability benefits, but also helps with longevity and future-proofing of solutions. With the speed of change of IoT devices and technologies, the physical and data link layers evolve every few years. Using IP provides support for a smooth evolution of technologies, without changing core architectures, affecting the stability of deployments, or introducing new use cases. Even if the endpoints do not support IP, gateways can be deployed at the edge or fog levels to provide connectivity and transport, as well as to support multiple physical and data link layer types.

Many last-mile communication options can be unreliable and unpredictable, so a new routing protocol was created to address routing for constrained devices such as those in wireless sensor networks. The IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) routes IPv6 traffic over low-power networks and lossy networks (LLN). LLNs are a class of network in which both the devices and their communication mechanisms are constrained. LLN devices are typically constrained by processing power, memory, and battery; their communications are characterized by high loss rates, low data rates, and instability. LLNs can scale from a few dozen up to thousands of devices.

In areas with low-power radio communication, the IPv6 Low Power Wireless Personal Area Network (6LoWPAN) can be leveraged. It was designed with very constrained devices in mind and allows IPv6 to be used over 802.15.4 wireless networks. 6LoWPAN optimizes the transmission of IPv6 packets over LLNs such as IEEE 802.15.4 through header compression.

Transport Layer

This layer addresses secure end-to-end communication, including reliability, bandwidth, and congestion management, as well as sequencing and session maintenance. Operating in constrained and highly geographically dispersed environments, as well as leveraging physical media that is less reliable, makes User Datagram Protocol (UDP) the protocol of choice in place of the more heavyweight Transmission Control Protocol (TCP). Transport Layer Security (TLS) and Datagram TLS (DTLS) are typically leveraged for secure transport.

Application Layer

This layer covers application-level messaging and provides the interface between the user and the desired IoT application. Hypertext Transfer Protocol (HTTP) and Secure HTTP (HTTPS) continue to be leveraged in IoT. In addition, the Constrained Application Protocol (CoAP) is often leveraged as a lightweight alternative to HTTP as a specialized web transfer protocol for use with constrained nodes and constrained networks. It is often used in combination with 6LoWPAN.

To allow data exchange and facilitate control of the data pipeline, a messaging service is often leveraged within IoT deployments. Messaging protocols such as Message Queue Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), and Extensible Messaging and Presence Protocol (XMPP) have been leveraged for some time. More recently, feature-rich message services such as the Cisco Edge Fog Fabric (EFF) have been introduced, providing detailed topologies, strong QoS mechanisms, and real-time analytics capabilities as part of the IoT data/content pipeline management.

Industrial IoT environments and specific markets continue to use more industry-specific protocols that have been designed over many years to address certain vertical or market needs. IEC 61850 Sampled Values (SV), Generic Object Oriented Substation Event (GOOSE), and Manufacturing Message Specification (MMS), IEC 60870, Modbus, Distributed Network Protocol (DNP3), and OLE for Process Control (OPC), provide the core communication mechanisms for industrial environments such as power utilities, manufacturing, oil and gas, and transportation.

Many IoT environments, particularly industrials, have a requirement to connect legacy devices and sensors. This means that, in addition to IP- and Ethernet-based protocols, serial-based protocols must be connected. This not only adds integration complexity, but it introduces security considerations.

In summary, as well as in practice, different IoT standards use many of these protocols. Choosing the right protocol often comes down to the vendor, the environment, the network topology, the bandwidth available, and the vertical or market in which the use case will be deployed. Other considerations can include power constraints and usage, reliability requirements, and, of course, security. Some of the options listed, such as IEEE 802.15.4, have security mechanisms built in, such as access control, message integrity, replay protection, and message confidentiality.

Specific Security Standards and Guidelines

This leads nicely into the focus area of the book: security. This section explores some of the challenges of standardizing security for the IoT. We look at some key standards and guidelines for security in IoT environments and conclude with some considerations for implementing these as part of the security perspectives discussed in Chapter 2. Standards are available for every layer of the IoT stack, such as Internet Protocol Security (IPsec), Transport Layer Security (TLS), and application layer cryptography. This section does not dive into the technologies themselves, but instead looks at the groups working on bringing technologies together into more of a cohesive approach to security for IoT.

As in the previous sections, standards for security are also widespread and diverse. Many applicable security standards exist, and traditional IT or OT best practices are already being leveraged in many cases. These will continue to be applicable for IoT. With many new security technologies being developed to address new use cases, technologies, and protocols, the landscape is still changing. Research from Forrester (see Figure 4-9) shows that this is set to continue for the foreseeable future, with multiple security requirements still developing for IoT.

The following standards and guidelines have a specific focus on IoT security, either as an existing best practice that has been applied to the IoT space or as a new best practice generated by IoT demand. Again, these are listed alphabetically, not in order of importance.

• The European Telecommunications Standards Institute (ETSI; http://www.etsi.org/news-events/news/1015-2015-10-news-etsi-nfv-isg-publishes-security-and-reliability-specifications) has several NFV-focused security areas:

  • Problem statement (NFV-SEC 001)

  • Cataloguing Security Features in Management Software Relevant to NFV (NFV-SEC 002)

  • Security and Trust Guidance (NFV-SEC 003)

  • Privacy and Regulation: Report on Lawful Interception (LI) Implications (NFV-SEC 004)

• The Institute of Electrical and Electronics Engineers (IEEE; https://standards.ieee.org/develop/project/1915.1.html) P1915.1 standard for SDN and NFV provides a framework to build and operate secure SDN/NFV environments. This standard specifies a security framework, models, analytics, and requirements to secure SDN and NFV.

• The IoT Security Foundation (https://iotsecurityfoundation.org/) was established in September 2015 to help secure IoT, accelerate adoption, and maximize potential benefits by providing knowledge and clear security best practices to those who specify, make, and use IoT products and systems.

• The Open Web Application Security Project (OWASP; https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project) was established to better understand the security issues associated with IoT and to enable better security decisions when building, deploying, or assessing IoT technologies. OWASP has ten IoT security projects to help with this: IoT Attack Surface Areas; IoT Vulnerabilities; Firmware Analysis; ICS/SCADA Software Weaknesses; Community Information; IoT Testing Guides; IoT Security Guidance; Principles of IoT Security; IoT Framework Assessment, Developer, Consumer and Manufacturer Guidance; and Design Principles.

• The Online Trust Alliance (OTA; https://otalliance.org/), established in 2005, aims to educate users and develop and advance best practices and tools to enhance users’ security, privacy, and identity. OTA does this with data sharing and collaboration through working groups, committees, and training. OTA is also a member of other organizations committed to collaboration, law enforcement, and data sharing.

• The Secure Technology Alliance (https://www.securetechalliance.org/?utm=scapop), formed in March 2017, is a multi-industry association working to stimulate the understanding, adoption, and widespread application of secure solutions, including smart cards, embedded chip technology, and related hardware and software. This includes secure technologies for authentication, commerce, and IoT to protect privacy and data. The Secure Technology Alliance was formerly called the Smart Card Alliance; it changed its name in March 2017.

• IoT IAP (http://www.iotiap.com/), established in November 2016, addresses security challenges related to IoT. As a working paper, it outlines ideas and approaches to improve today’s security situation.

• The Cloud Security Alliance (CSA; https://cloudsecurityalliance.org/) is a leading organization dedicated to defining and raising awareness of best practices to secure cloud computing environments. CSA offers cloud security-specific research, education, certification, events, and products, including ones focused on IoT.

• I am the Cavalry (https://www.iamthecavalry.org/), formed in 2013, aims to ensure that technologies with the potential to impact public safety and human life are worthy of trust and focus on IoT. It accomplishes this in a number of ways, including education, outreach, and research.

• The National Institute of Standards and Technologies (NIST; https://pages.nist.gov/cpspwg/) launched Cyber Physical Systems in 2014. The Cyber-Physical Systems Public Working Group (CPS PWG) focuses on Cyber-Physical Systems, or “smart” systems, that promise increased efficiency and interaction between computer networks and the physical world. It seeks to enable advances that improve the quality of life, including those in personalized healthcare, emergency response, traffic flow management, and electric power generation and delivery. CPS covers many IoT use cases and includes a consensus vocabulary and reference architecture to facilitate interoperability between elements and systems, as well as promote communication across the breadth of CPS. Timing, dependability, data interoperability, and security are considered first-order design principles for CPS.

• The National Institute of Standards and Technologies (NIST; https://www.nist.gov/publications/guidelines-smart-grid-cybersecurity) launched its NISTIR 7628 guide-lines in September 2014. This three-volume report, Guidelines for Smart Grid Cybersecurity, presents an analytical framework that can be used to develop effective cybersecurity strategies based on specific characteristics, risks, and vulnerabilities. It provides methods and supporting information that acts as a guide for assessing risk and identifying and applying appropriate security requirements. This approach recognizes that the electric grid is changing from a relatively closed system to a complex, highly interconnected environment that includes IoT elements, and it advocates using cybersecurity requirements that also evolve accordingly.

• The National Institute of Standards and Technologies (NIST; http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf) publication SP 800-160 Systems Security Engineering, launched in November 2016, addresses IoT from an engineering-driven perspective and documents actions necessary to develop more defensible and survivable systems (including machine, physical, and human components). It also addresses the capabilities and services delivered by those systems.

• The International Electrotechnical Commission (IEC; https://www.certsi.es/en/blog/iec62443-evolution-of-isa99) launched the IEC 62443 standard for Cyber Security for Industrial Control Systems in 2009, based on previous work from ISA99 that was started in 2007. IEC 62443 is the most widely adopted industrial security standard globally; it continues to evolve, particularly in areas such as IoT.

• The International Electrotechnical Commission (IEC; http://iectc57.ucaiug.org/wg15public/Public%20Documents/White%20Paper%20on%20Security%20Standards%20in%20IEC%20TC57.pdf) launched the IEC 62351standard in 1999. Its focus is on data and communications security in power systems management, along with the associated information exchange. It consists of a series of standards, with a focus on end-to-end security.

• The North American Electric Reliability Corporation (NERC: http://www.nerc.com/Pages/default.aspx) launched the Critical Infrastructure Protection regulations for bulk power in North America in 2007. NERC is regulated and requires legal compliance, including cybersecurity.

• The IoT Global Council (https://www.iotglobalcouncil.com/), launched in May 2014, is a membership organization for new business leaders of the IoT industry. It focuses on IoT data and security.

• The Internet Research Task Force (IRTF; https://www.ietfjournal.org/internet-of-things-standards-and-guidance-from-the-ietf/) has established security-related works with IoT relevance and focus, launched under the IETF. This includes working groups for DTLS In Constrained Environments (DICE), Authentication and Authorization for Constrained Environments (ACE), and Lightweight Implementation Guidance (LWIG).

• The Industrial Internet Consortium (IIC; http://www.iiconsortium.org/IISF.htm) is an umbrella type standard with an industrial focus, and has produced a specific cybersecurity framework for the IIoT.

In addition to these established standards and best practices, new ones continue to emerge that focus on interoperability and standardization. A great example is Manufacturer Usage Description (MUD), which introduces a set of network capabilities that provide an additional layer of protection to devices connecting to the IoT system. The focus of this work is security related to smart objects, although it goes further than this. Again, YANG is used as a standardized model to generate and parse manufacturer usage descriptions. Network management systems retrieve these descriptions to instantiate security and communication policies associated with those devices. A manufacturer should know what a device is intended to do; for example, a light bulb should not be communicating with a voice server, but it should be communicating with its controller. The concept, then, is to use the manufacturer’s product knowledge to create network policy that can be easily understood and enforced. Put simply, an IoT system should be capable of automatically finding out what a device should be allowed to do and enforcing policies that prevent it from going beyond those limits. At the time of this writing, MUD is currently being reviewed via the standard RFC process; however, organizations (including Cisco) are already working on adoption.

As you have probably concluded from this chapter, many standards and approaches to standards exist for IoT and IoT security. Later chapters of this book zoom in on providing a standardized methodology to deploy and manage security in an open way, leveraging NFV and SDN and automation to ensure that the approach can scale. Instead of competing with existing IoT and security standards, this methodology will actually provide a way to orchestrate and automate the deployment of standards and guidelines, while also bringing a number of enhancements. Security, particularly for IoT, is a multifaceted and difficult challenge, and we will not likely see standards or best practices that completely (or even partly) eliminate the risks of cyber attacks against IoT devices and systems anytime soon. However, a standardized approach to the IoT system, and to the security of the system and by the system, can ensure that deployments meet and even exceed reasonable standards for security. This moves the focus of the approach away from individual devices (which vary greatly in terms of capability) and more toward system-level security (which can more uniformly be provided by an IoT platform).

Summary

As organizations look for the best methods of designing, architecting, and deploying IoT systems, they must consider practical questions:

• What value does a given standard bring to IoT deployment? Are there any demonstrable examples of deployments?

• What are the risks of not using a specific standard—or any standard at all? Do the potential business gains in the short term perhaps outweigh future challenges?

• What are the risks if a chosen standard fails? (A practical option we highlighted earlier was to monitor which industry vendors are backing which standards and make an educated choice.)

• Is there a way to influence a standard? If so, what process or cost is involved? (This can help you understand whether a standard is being driven to truly achieve openness and interoperability, or whether it is being driven for the benefit of one or more participants.)

When looking at standards, whether they focus on IoT, address IoT security in particular, or act as a technology enabler for IoT, remember to consider the security aspects for an IoT deployment. At a minimum, a successful security standard provides the following:

• Scalability and ease of deployment and management. Technologies such as NFV and SDN allow for large-scale automation. This must include policy management, upgrades, and the capability to deploy new devices or use cases without impacting existing ones.

• Protection for devices, no matter where they are deployed in the full IoT stack, from edge to cloud/DC.

• Visibility and monitoring capabilities, in an automated way, to ensure that the system and, ultimately, you are aware of attacks.

• Protection of the end-to-end data pipeline, from initial creation to ultimate consumption.

• Autonomy. IoT often means a devolved and distributed architecture. Devices and lower parts of a system architecture must continue to effectively monitor and enforce security policies and requirements, even if visibility to the system head end is lost.

As the industry moves forward, efforts to evolve and improve standards will consolidate. This is required if we are to deliver technology changes and enable more advanced use cases, applications, and value propositions. The current landscape might be fragmented and complex, but history has shown that we do need standards to minimize complexity in deploying systems and minimize the security attack surface. Standards can help us gain better visibility of security incidents and leverage consistent, best-practice tools to defend, detect, remediate, and report on our IoT deployments.

References

3GPP, http://www.3gpp.org/

Alliance for Internet of Things Innovation (AIOTI), https://aioti-space.org/

AllSeen Alliance, https://allseenalliance.org/

Bluetooth Low Energy (BLE), https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/low-energy

Bridge Alliance, http://www.bridgealliance.com/

Broadband Internet Technical Advisory Group, https://www.bitag.org/

Cloud Security Alliance (CSA), https://cloudsecurityalliance.org/group/internet-of-things/

DASH7, http://www.dash7-alliance.org/

Digital Living Network Alliance (DLNA), https://www.dlna.org/

EEBus Initiative, https://www.eebus.org/en/

EnOCEAN Alliance, https://www.enocean.com/en/

ETSI, http://www.etsi.org/technologies-clusters/clusters/connecting-things

European Committee for Standardisation (CEN), https://www.cen.eu/Pages/default.aspx

FIWARE Foundation, www.fiware.org

Global M2M Association (GMA), http://www.globalm2massociation.com/

GSMA Mobile IoT Initiative, http://www.gsma.com/iot/mobile-iot-initiative/

https://en.wikipedia.org/wiki/Cyber-security_regulation

https://en.wikipedia.org/wiki/Standards_organization

https://www.thethingsnetwork.org/community/thessaloniki/post/50-billion-iot-devices-will-be-connected-by-2020

The Home Gateway Initiative (HGI) http://www.homegatewayinitiative.org/

IEC 62443/ISA99, http://isa99.isa.org/

IEEE IoT Initiative, http://standards.ieee.org/innovate/iot/index.html,

Industrial Internet Consortium (IIC), www.iiconsortium.com

Industry 4.0, https://en.wikipedia.org/wiki/Industry_4.0

International Society of Automation, ISA100.11a, https://www.isa.org/isa100/

Internet Engineering Task Force, https://trac.tools.ietf.org/area/int/trac/wiki/IOTDirWiki

Internet Governance Forum, http://www.intgovforum.org/cms/component/content/article?id=1217:dynamic-coalition-on-the-internet-ofthings

Internet of Things Consortium, http://iofthings.org/

IoT European Research Cluster (IERC), http://www.internet-of-things-research.eu/

IoT Research Council, http://www.theinternetofthings.eu/

IoT Security Foundation (IoTSF), https://iotsecurityfoundation.org/

IoT World Alliance (formerly M2M World Alliance), http://www.iotworldalliance.org

IP for Smart Objects (IPSO Alliance), http://www.ipso-alliance.org/

IRTF Internet Research Task Force, IoT initiatives, https://www.internetsociety.org/publications/ietf-journal-april-2016/internet-things-standards-and-guidance-ietf

ISO/IECJTC-1 https://www.iso.org/isoiec-jtc-1.html

ISOC’s Internet of Food SIG, http://internet-of-food.org/

ITU, http://www.itu.int/en/ITUT/studygroups/2013-2016/20/Pages/default.aspx

Li-Fi Consortium, www.lificonsortium.org

LoRa Alliance, https://www.lora-alliance.org/

M2M Alliance, http://www.m2m-alliance.com/

MAPI Foundation, https://www.mapi.net/forecasts-data/internet-things-industrie-40-vs-industrial-internet

OASIS, https://www.oasis-open.org/committees/tc_cat.php?cat=iot

oneM2M, http://www.onem2m.org/

Online Trust Alliance, https://otalliance.org/initiatives/internet-things

Open Connectivity Foundation (OCF), https://openconnectivity.org

Open Group Open Process Automation, http://www.opengroup.org/open-process-automation

OpenFog Consortium (OFC), www.openfogconsortium.org

The Open Management Group, http://www.omg.org/hot-topics/iot-standards.htm

Open Mobile Alliance (OMA), http://openmobilealliance.org/

Open Source Internet of Things (OSIOT), http://osiot.org/

Open Web Application Security Project, https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project

Smart Grid Interoperability Panel, http://www.sgip.org/cybersecurity/

Thread Group, https://threadgroup.org

ULE Alliance, https://www.ulealliance.org/

W3C Web of Things (WoT), https://www.w3.org/WoT/

What are open standards?, https://opensource.com/resources/what-are-open-standards

WiHART, https://fieldcommgroup.org/technologies/hart

Wireless IoT Forum, http://www.wireless-iot.org/

Wi-Sun Alliance, www.e.org

The World Wide Web Consortium, https://www.w3.org/

Zigbee Alliance, http://www.zigbee.org/

Z-Wave Alliance, http://z-wavealliance.org/