Chapter 3. Approaches to Secure Development

IoT systems are evolving, as new capabilities that take advantage of IoT connectivity continue to be introduced. Autonomous shuttles will soon ferry riders around connected cities, relying on streams of environmental and traffic data to operate safely and make scheduling decisions.

Manufacturing plants are already incorporating collaborative robots (cobots) that increase efficiency and improve performance. Industrial control systems are gaining access to new data sources, for better decision making through cloud connectivity.

These new complex and connected engineering projects must be designed to be safe and resilient, while at the same time assuring the confidentiality and integrity of sensitive information.

This chapter discusses processes and approaches that can be used to develop safe, secure, and resilient IoT systems. We will cover the following topics:

• The Secure Development Life Cycle (SDLC)
• Handling non-functional requirements
• Verification...

The Secure Development Life Cycle (SDLC)

How security is handled in the development life cycle is frequently a reflection of the industry and its conventional or dictated development methodologies. Some product types, such as aircraft or cars, are simply not amenable to pure Agiledevelopment methodologies, because of the complexity and dependencies built into their supply chains, and the absolute nature of the intermediate and final delivery dates of their products.

Regardless, in many cases, development organizations do have some latitude when selecting a development methodology. This section spells out common development approaches and provides guidance on implementing security rigor within those approaches.

When selecting a development methodology, building security in from the beginning means that well-thought-out security, safety, and privacy requirements are elicited, and made traceable throughout the development and update of an IoT device or system. By system, we mean a collection...

Handling non-functional requirements 

Non-functional requirements handle the aspects of the system that are not directly related to the functionalities of the system. SEBOK—the systems engineering body of knowledge maintained jointly by INCOSE and the IEEE computer society (https://www.sebokwiki.org/wiki/Non-Functional_Requirements_(glossary))—defines them as follows: 

Quality at

tributes or characteristics that are desired in a system, that define how a system is supposed to be.

Non-functional requirements include security, performance, availability, resilience, safety, reliability, dependability, scalability, sustainability, portability, and interoperability.

IoT systems will require different variations of these requirements, depending on the context in which the system is designed to operate (C. Warren Axelrod, Engineering Safe and Secure Software Systems, Artech House).

 

For example, an IoT system that provides management features for a critical infrastructure system will have more safety...

The need for software transparency

Software transparency provides development teams with a solid understanding of the components within their products. 

As of the time of writing, there are efforts to enhance the transparency of software through efforts such as the Software Bill of Materials (SBOM), led by the National Telecommunications and Information Administration (NTIA). An argument can be made that having an IoT product SBOM is a side-effect of having good development processes in place. 

Transparency also provides a valuable tool within the software supply chain. Providing users with an understanding of the third-party libraries used within a product can provide those users with important security knowledge.

For example, the OpenSSL Heartbleed vulnerability discovered in 2014 resulted in a worldwide, catastrophic security hole exposing the majority of the internet's web servers (read more at https://en.wikipedia.org/wiki/Heartbleed). Many companies did not even know about their exposure...

Summary

This chapter explored development methodologies that can be used to develop IoT products. We discussed the waterfall, Spiral, Agile, and DevOps methodologies, and reviewed ways in which security engineering can be used to define and track security requirements, and build security into the design phase of a product.

We discussed non-functional requirements, including security, safety, and resilience, and touched on the need for software transparency and automation in the verification and validation process. 

In Chapter 4, Secure Design of IoT Devices, we will discuss the challenges that IoT system developers face when trying to secure their systems, and a set of secure design goals for IoT systems.