Core Cybersecurity Feature Baselinefor Securable IoT ...85 cybersecurity risks their customer s face so IoT devices can provide cybersecurity features that 86 make them at least minimally

Withdrawn Draft

Warning Notice

The attached draft document has been withdrawn, and is provided solely for historical purposes. It has been superseded by the document identified below.

Withdrawal Date January 7, 2020

Original Release Date July 31, 2019

Superseding Document

Status 2nd Public Draft (2PD)

Series/Number NIST Interagency or Internal Report (NISTIR) 8259

Title Recommendations for IoT Device Manufacturers: Foundational Activities and Core Device Cybersecurity Capability Baseline

Publication Date January 2020

DOI https://doi.org/10.6028/NIST.IR.8259-draft2

CSRC URL https://csrc.nist.gov/publications/detail/nistir/8259/draft

Additional Information

https://doi.org/10.6028/NIST.IR.8259-draft2

https://doi.org/10.6028/NIST.IR.8259-draft2

https://csrc.nist.gov/publications/detail/nistir/8259/draft

https://csrc.nist.gov/publications/detail/nistir/8259/draft

Draft NISTIR 8259 1

Core Cybersecurity Feature Baseline 2

for Securable IoT Devices: 3

A Starting Point for IoT Device Manufacturers 4

5 Michael Fagan 6

Katerina N. Megas 7 Karen Scarfone 8 Matthew Smith 9

10 11 12 13

This publication is available free of charge from: 14 https://doi.org/10.6028/NIST.IR.8259-draft 15

16 17 18

https://doi.org/10.6028/NIST.IR.8259-draft

Draft NISTIR 8259 19

Core Cybersecurity Feature Baseline for 20

Securable IoT Devices: 21

A Starting Point for IoT Device Manufacturers 22

Michael Fagan 23 Katerina N. Megas 24

Applied Cybersecurity Division 25 Information Technology Laboratory 26

27 Karen Scarfone 28

Scarfone Cybersecurity 29 Clifton, VA 30

31 Matthew Smith 32

G2, Inc. 33 Annapolis Junction, MD 34

35 36


39 40

July 2019 41 42

43 44

U.S. Department of Commerce 45 Wilbur L. Ross, Jr., Secretary 46

47 National Institute of Standards and Technology 48

Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology 49


National Institute of Standards and Technology Interagency or Internal Report 8259 50 38 pages (July 2019) 51


Certain commercial entities, equipment, or materials may be identified in this document in order to describe an 54 experimental procedure or concept adequately. Such identification is not intended to imply recommendation or 55 endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best 56 available for the purpose. 57 There may be references in this publication to other publications currently under development by NIST in 58 accordance with its assigned statutory responsibilities. The information in this publication, including concepts and 59 methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, 60 until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain 61 operative. For planning and transition purposes, federal agencies may wish to closely follow the development of 62 these new publications by NIST. 63 Organizations are encouraged to review all draft publications during public comment periods and provide feedback 64 to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at 65 https://csrc.nist.gov/publications. 66

Public comment period: July 31, 2019 through September 30, 2019 67 National Institute of Standards and Technology 68

Attn: Applied Cybersecurity Division, Information Technology Laboratory 69 100 Bureau Drive (Mail Stop 2000) Gaithersburg, MD 20899-2000 70

Email: [email protected] 71

All comments are subject to release under the Freedom of Information Act (FOIA). 72


https://csrc.nist.gov/publications

mailto:[email protected]

NISTIR 8259 (DRAFT) CORE CYBERSECURITY FEATURE BASELINE FOR SECURABLE IOT DEVICES

ii

Reports on Computer Systems Technology 73

The Information Technology Laboratory (ITL) at the National Institute of Standards and 74 Technology (NIST) promotes the U.S. economy and public welfare by providing technical 75 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test 76 methods, reference data, proof of concept implementations, and technical analyses to advance 77 the development and productive use of information technology. ITL’s responsibilities include the 78 development of management, administrative, technical, and physical standards and guidelines for 79 the cost-effective security and privacy of other than national security-related information in 80 federal information systems. 81 82

Abstract 83

This publication is intended to help Internet of Things (IoT) device manufacturers understand the 84 cybersecurity risks their customers face so IoT devices can provide cybersecurity features that 85 make them at least minimally securable by the individuals and organizations who acquire and 86 use them. The publication defines a core baseline of cybersecurity features that manufacturers 87 may voluntarily adopt for IoT devices they produce. The core baseline addresses general 88 cybersecurity risks faced by a generic customer. Manufacturers often know more about their 89 customers and the risks they face, so the publication also provides information on how 90 manufacturers can identify features beyond the core baseline most appropriate for their 91 customers and implement those features to further improve how securable their IoT devices are. 92 This approach can help lessen the cybersecurity-related efforts needed by IoT device customers, 93 which in turn should reduce the prevalence and severity of IoT device compromises and the 94 attacks performed using compromised IoT devices. 95 96

Keywords 97

cybersecurity baseline; cybersecurity risk; Internet of Things (IoT); manufacturing; risk 98 management; risk mitigation; securable computing devices; software development 99


iii

Acknowledgments 100

The authors wish to thank all contributors to this publication, including the participants in 101 workshops and other interactive sessions; the individuals and organizations from the public and 102 private sectors, including manufacturers from various sectors, as well as several manufacturer 103 trade organizations who provided feedback on the preliminary essay; and colleagues at NIST 104 who offered invaluable inputs and feedback. 105 106

Audience 107

The main audience for this publication is IoT device manufacturers seeking a better 108 understanding of how to identify the appropriate cybersecurity features for their IoT devices, or 109 wanting a common language for communicating with others regarding these features. A 110 secondary audience for this publication is IoT device customers (i.e., individuals and 111 organizations) that want to specify which cybersecurity features they need from IoT devices 112 during their evaluation and acquisition processes. 113 114

Note to Reviewers 115

NIST welcomes feedback on any part of the publication, but there is particular interest in the 116 following: 117 118

1. Section 3 is intended to help IoT device manufacturers better identify the cybersecurity 119 risks their expected customers (individuals and organizations) are likely to face, instead 120 of assuming a generic set of risks faced by a generic set of customers. This would help 121 manufacturers identify the cybersecurity features their customers need their IoT devices 122 to have. Is the proposed process for identifying features appropriate and reasonable? If 123 not, how can it be improved? 124

2. Are the cybersecurity features and the key elements of those features defined in Section 4 125 the right set for a generic starting point for IoT devices? If not, which cybersecurity 126 features and key elements should be added, removed, or changed, and why? 127

3. We have received considerable feedback that the lack of transparency into the 128 characteristics of many IoT devices can make it harder to understand and address the 129 cybersecurity risks for those devices. Feedback on how useful the communication 130 considerations outlined in Section 6 may be for consumers and manufacturers, as well as 131 how the considerations can be improved, is particularly important. 132

Trademark Information 133

All registered trademarks and trademarks belong to their respective organizations. 134 135


iv

Preface 136

The overall objective of this publication is to provide voluntary guidance for IoT device 137 manufacturers to help in identifying and planning device cybersecurity features for their 138 products. A key motivation for developing this publication is also to help address the problem of 139 IoT devices being compromised by attackers and joined to botnets, where they can be used to 140 perform distributed denial of service (DDoS) attacks. Use of large numbers of IoT devices in 141 botnets for the Mirai botnet attack in the fall of 2016 highlighted the vulnerable state of many 142 IoT devices. 143 144 In 2017, Executive Order 13800, Strengthening the Cybersecurity of Federal Networks and 145 Critical Infrastructure, was issued to improve the Nation’s cyber posture and capabilities in the 146 face of increasing threats. The Executive Order tasked the Department of Commerce and 147 Department of Homeland Security with leading a process to “…identify and promote action by 148 appropriate stakeholders to improve the resilience of the internet and communications ecosystem 149 and to encourage collaboration with the goal of dramatically reducing threats perpetrated by 150 automated and distributed attacks (e.g., botnets).” [1] 151 152 The outcome of this joint effort was A Report to the President on Enhancing the Resilience of the 153 Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed 154 Threats. [2] Released in May 2018, it identified a number of actions for the IoT ecosystem that 155 should be undertaken. While that report was being developed, NIST had already recognized the 156 need to help organizations understand what cybersecurity risks might be associated with IoT 157 devices. NIST released draft Internal Report (NISTIR) 8228: Considerations for Managing IoT 158 Cybersecurity and Privacy Risks in September 2018. [3] 159 160 Through related stakeholder engagement and comments received during the NISTIR 8228 public 161 comment period, as well as the contents of the Report to the President, NIST identified a critical 162 gap area in guidance on cybersecurity feature baselines1 for IoT devices. Actions needed to 163 address this gap were included in a November 2018 document, A Road Map Toward Resilience 164 Against Botnets. The road map identified tasks and timelines for meeting the objectives in the 165 Report to the President. The road map also sequenced the tasks; before assessment, labeling, or 166 awareness initiatives could begin, a core cybersecurity feature baseline that could be considered 167 common across all IoT devices was needed. The road map called on NIST, in collaboration with 168 stakeholders, to define this core cybersecurity feature baseline as a key action to promote raising 169 the basic cybersecurity features of IoT devices and harmonizing across sectors. [5] 170 171 This draft document defines the core cybersecurity feature baseline for IoT devices, and it also 172 outlines practices for secure software design and development that can improve the security of 173 IoT devices. This content helps address three of the botnet roadmap tasks: “Define Core Security 174 Capability Baseline,”2 “Enable Risk Management Approach to IoT Security,” and “Publish Best 175

1 The term “baseline” should not be confused with the low, moderate, and high control security baselines set forth in NIST

Special Publication 800-53 [4] to help federal agencies meet their obligations under the Federal Information Security Modernization Act (FISMA) and other federal policies. In this document, “baseline” is used in the generic sense to refer to a set of foundational requirements or recommendations.

2 The roadmap referred to “capabilities”; to avoid confusion with the use of “capabilities” in other NIST documents, this publication uses the word “features” instead. The meaning is the same.


v

Practices for IoT Device Manufacturers.” This document also provides the foundation for 176 additional road map tasks to be addressed in the future, especially the creation of extensions of 177 the core baseline targeted at specific use cases with unique challenges. 178 179


vi

Call for Patent Claims 180

This public review includes a call for information on essential patent claims (claims whose use 181 would be required for compliance with the guidance or requirements in this Information 182 Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be 183 directly stated in this ITL Publication or by reference to another publication. This call also 184 includes disclosure, where known, of the existence of pending U.S. or foreign patent applications 185 relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents. 186 187 ITL may require from the patent holder, or a party authorized to make assurances on its behalf, 188 in written or electronic form, either: 189 190

a) assurance in the form of a general disclaimer to the effect that such party does not hold 191 and does not currently intend holding any essential patent claim(s); or 192

b) assurance that a license to such essential patent claim(s) will be made available to 193 applicants desiring to utilize the license for the purpose of complying with the guidance 194 or requirements in this ITL draft publication either: 195

i. under reasonable terms and conditions that are demonstrably free of any unfair 196 discrimination; or 197

ii. without compensation and under reasonable terms and conditions that are 198 demonstrably free of any unfair discrimination. 199

200 Such assurance shall indicate that the patent holder (or third party authorized to make assurances 201 on its behalf) will include in any documents transferring ownership of patents subject to the 202 assurance, provisions sufficient to ensure that the commitments in the assurance are binding on 203 the transferee, and that the transferee will similarly include appropriate provisions in the event of 204 future transfers with the goal of binding each successor-in-interest. 205 206 The assurance shall also indicate that it is intended to be binding on successors-in-interest 207 regardless of whether such provisions are included in the relevant transfer documents. 208 209 Such statements should be addressed to: [email protected] 210 211

mailto:[email protected]


vii

Executive Summary 212

Manufacturers are creating an incredible variety and volume of Internet of Things (IoT) devices, 213 which incorporate at least one transducer (sensor or actuator) for interacting directly with the 214 physical world, have at least one network interface (e.g., Ethernet, WiFi, Bluetooth, Long-Term 215 Evolution [LTE], ZigBee), and are not conventional IT devices for which the identification and 216 implementation of cybersecurity features is already well understood (e.g., smartphone, laptop). 217 Many IoT devices provide computing functionality, data storage, and network connectivity for 218 equipment that previously lacked these functions. In turn, these functions enable new efficiencies 219 and technological capabilities for the equipment, such as remote access for monitoring, 220 configuration, and troubleshooting. IoT can also add the ability to analyze data about the 221 physical world and use the results to better inform decision making, alter the physical 222 environment, and anticipate future events. [6] 223

IoT devices are acquired and used by many customers: individuals, companies, government 224 agencies, educational institutions, and other organizations. Unfortunately, IoT devices often lack 225 efficient and effective features for customers to use to help mitigate cybersecurity risks. 226 Consequently, some IoT devices are less easily secured using customers’ existing methods 227 because the cybersecurity features they expect may not be available on IoT devices or may 228 function differently than is expected based on conventional IT devices. This means IoT device 229 customers may have to select, implement, and manage additional or new cybersecurity controls 230 or alter the controls they already have. However, new or tailored controls to sufficiently mitigate 231 risks to the same level as before may not be available to all customers or implementable with all 232 IoT devices. Compounding this problem, customers may not know they need to alter their 233 existing IT processes to accommodate IoT. The result is many IoT devices are not secured 234 properly, so attackers can more easily compromise them and use them to harm device customers 235 and conduct additional nefarious acts (e.g., distributed denial of service [DDoS] attacks) against 236 other organizations.3 237

Addressing the challenges of IoT cybersecurity necessitates educating IoT device customers on 238 the differences in cybersecurity risks and risk mitigation for IoT versus conventional IT, as NIST 239 has documented in Internal Report (IR) 8228, Considerations for Managing Internet of Things 240 (IoT) Cybersecurity and Privacy Risks. [3] The challenges also necessitate educating IoT device 241 manufacturers on how to identify the cybersecurity features customers need IoT devices to have. 242 This includes improving communications between manufacturers and customers regarding 243 device cybersecurity features and related expectations. 244

This document presents a core baseline of cybersecurity features for all IoT devices that makes 245 devices at least minimally securable by the customers who acquire and use them. This 246 publication does not specify how customers should secure the IoT devices they deploy and use; it 247 only addresses the importance of manufacturers making all IoT devices minimally securable for 248 3 In 2017, Executive Order 13800, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure [1], was

issued to improve the Nation’s cyber posture and capabilities in the face of intensifying threats. The Executive Order tasked the Department of Commerce and Department of Homeland Security with creating the Enhancing Resilience Against Botnets Report [5] to determine how to stop attacker use of botnets to perform DDoS attacks. This report contained many action items, and this document fulfills two of them: to create a baseline of cybersecurity features for IoT devices, and to publish cybersecurity practices for IoT device manufacturers.


viii

their customers. The core baseline is intended to help customers achieve a basic cybersecurity 249 posture that mitigates general cybersecurity risks. These features are not exhaustive, and IoT 250 device manufacturers are encouraged to use the core baseline as a starting point. Ultimately, by 251 including cybersecurity features in the IoT devices they design and develop, IoT device 252 manufacturers can help enable IoT device customers to effectively manage their cybersecurity 253 risk, as well as strengthening the security of their devices. 254


ix

Table of Contents 255

Executive Summary .................................................................................................... vii 256 1 Introduction ............................................................................................................ 1 257

1.1 Purpose and Scope ........................................................................................ 1 258 1.2 Publication Structure ....................................................................................... 2 259

2 Background ............................................................................................................ 3 260 3 Cybersecurity Feature Identification .................................................................... 6 261

3.1 Expected Customers and Use Cases ............................................................. 6 262 3.2 Device Cybersecurity Features ....................................................................... 6 263

4 The Core Baseline for IoT Devices ....................................................................... 9 264 5 Cybersecurity Feature Implementation .............................................................. 14 265

5.1 Device Specifications .................................................................................... 14 266 5.2 Cybersecurity Feature Inheritance ................................................................ 15 267

6 Cybersecurity Information to Provide to Customers ........................................ 17 268 7 Secure Development Practices for IoT Devices ................................................ 20 269 References ................................................................................................................... 22 270 271

List of Appendices 272

Appendix A— Acronyms and Abbreviations ............................................................ 25 273 Appendix B— Glossary .............................................................................................. 26 274 275


1

1 Introduction 276

1.1 Purpose and Scope 277

The purpose of this publication is to help improve how securable IoT devices are (e.g., easy for 278 device customers to secure within their systems and environments). IoT device manufacturers 279 will learn how they can help IoT device customers with cybersecurity risk management by 280 carefully considering which cybersecurity features to design into their devices for customers to 281 use in managing their cybersecurity risk. 282

The publication defines a core baseline of cybersecurity features based on common cybersecurity 283 risk management approaches as a starting point for manufacturers. Manufacturers are encouraged 284 to consider the particular use cases and risks of the systems and environments their devices may 285 be deployed within, in order to move beyond the core baseline to the set of features most 286 appropriate for their devices and customers. The use cases should reflect not only how the 287 devices would be used, but also how attackers might misuse and compromise the devices; the 288 latter has been extensively covered elsewhere and is out of scope for this publication. 289

IoT device manufacturers will also gain a better understanding of the need to clearly 290 communicate to customers the cybersecurity-relevant characteristics of their IoT devices. This 291 helps customers implement their cybersecurity risk management processes more effectively and 292 efficiently as they incorporate these devices into their systems and environments. Customers can 293 use this publication as a starting point to identify cybersecurity features they want their IoT 294 devices to have and to specify those features to manufacturers as part of procurement efforts. 295

The scope of this publication is IoT devices that have at least one transducer (sensor or actuator) 296 for interacting directly with the physical world, have at least one network interface (e.g., 297 Ethernet, WiFi, Bluetooth, Long-Term Evolution [LTE], ZigBee), and are not conventional IT 298 devices for which the identification and implementation of cybersecurity features is already well 299 understood (e.g., smartphone, laptop).4 All other types of devices considered part of the IoT 300 ecosystem are out of scope, but no IoT device operates in isolation. Rather, IoT devices will be 301 used in systems and environments with many other devices and components, some of which may 302 be IoT devices, while others may be conventional IT equipment. Manufacturers should also 303 consider the complexity of how IoT devices interact with other devices, systems, and 304 environments when identifying the cybersecurity features to incorporate into their devices. 305

Readers do not need a technical understanding of IoT device composition and features, but a 306 basic understanding of cybersecurity principles is assumed. 307

4 The usage of the term “baseline” in this document should not be confused with the low, moderate, and high control security

baselines set forth in NIST Special Publication (SP) 800-53 [4] to help federal agencies meet their obligations under the Federal Information Security Modernization Act (FISMA) and other federal policies. In this document, “baseline” is used in the generic sense to refer to a set of foundational requirements or recommendations.


2

1.2 Publication Structure 308

The remainder of this publication is organized into the following sections and appendices: 309

• Section 2 summarizes key points from NIST Internal Report (IR) 8228 that are 310 prerequisites for understanding the rest of this publication. 311

• Section 3 discusses considerations for IoT device manufacturers when identifying the 312 cybersecurity features their IoT devices will provide, based on the manufacturers’ 313 determination of likely cybersecurity risks their device customers will face. 314

• Section 4 defines the core baseline of cybersecurity features that acts as a starting point 315 for identifying features for IoT devices, as explained in Section 3. 316

• Section 5 explores considerations for manufacturers implementing cybersecurity features 317 for IoT devices. 318

• Section 6 explains the need for communication with customers regarding cybersecurity 319 risk mitigation, and provides examples of the types of information to be communicated 320 and how it could vary for different customers. 321

• Section 7 briefly discusses secure development practices for manufacturers that help 322 improve the security (reduce the prevalence of vulnerabilities) of IoT devices. 323

• The References section lists the references for the publication. 324

• Appendix A provides an acronym and abbreviation list. 325

• Appendix B contains a glossary of selected terms used in the publication. 326


3

2 Background 327

This section summarizes context and key points from NIST IR 8228 [3] that are prerequisites for 328 understanding the rest of this document. Readers who are already familiar with NIST IR 8228 329 can skip this section. Readers unfamiliar with NIST IR 8228 should be able to use the context 330 provided by this section to understand the rest of this publication, but unfamiliar readers are also 331 encouraged to refer to NIST IR 8228 for more details about these concepts. 332

Many IoT devices affect cybersecurity risks differently than conventional information 333 technology (IT) devices do (e.g., desktops, laptops, servers), which can be broadly seen through 334 three high-level considerations: 335

1. Many IoT devices interact with the physical world in ways conventional IT devices 336 usually do not. The potential impact of some IoT devices making changes to physical 337 systems and thus affecting the physical world needs to be explicitly recognized and 338 addressed from cybersecurity and privacy perspectives. Also, operational requirements 339 for performance, reliability, resilience, and safety may be at odds with common 340 cybersecurity practices for conventional IT devices. 341

2. Many IoT devices cannot be accessed, managed, or monitored in the same ways 342 conventional IT devices can. This can necessitate doing tasks manually or significantly 343 differently than for conventional IT for some IoT devices, expanding staff knowledge and 344 tools to include a much wider variety of IoT device software, and addressing risks with 345 manufacturers and other third parties having remote access or control over IoT devices. 346

3. The availability, efficiency, and effectiveness of cybersecurity features are often 347 different for IoT devices than conventional IT devices. This means organizations may 348 have to select, implement, and manage additional controls, as well as determine how to 349 respond to risk when sufficient controls for mitigating risk are not available. 350

Cybersecurity risks for IoT devices can be thought of in terms of two high-level risk mitigation 351 goals: 352

1. Protect device security. In other words, prevent a device from being used to conduct 353 attacks, including participating in DDoS attacks against other organizations, and 354 eavesdropping on network traffic or compromising other devices on the same network 355 segment. This goal applies to all IoT devices. 356

2. Protect data security. Protect the confidentiality, integrity, and/or availability of data 357 (including personally identifiable information [PII]) collected by, stored on, processed 358 by, or transmitted to or from the IoT device. This goal applies to each IoT device except 359 those without any data that needs protection. 360

Meeting any risk mitigation goal involves addressing a set of risk mitigation areas. Based on an 361 analysis of existing NIST publications such as the Cybersecurity Framework [7] and SP 800-53 362 [4] and the characteristics of IoT devices, common risk mitigation areas for IoT devices are: 363


4

• Asset Management: Maintain a current, accurate inventory of all IoT devices and their 364 relevant characteristics throughout the devices’ lifecycles in order to use that information 365 for cybersecurity risk management purposes. 366

• Vulnerability Management: Identify and eliminate known vulnerabilities in IoT device 367 software and firmware in order to reduce the likelihood and ease of exploitation and 368 compromise. 369

• Access Management: Prevent unauthorized and improper physical and logical access to, 370 usage of, and administration of IoT devices by people, processes, and other computing 371 devices. 372

• Data Protection: Prevent access to and tampering with data at rest or in transit that 373 might expose sensitive information or allow manipulation or disruption of IoT device 374 operations. 375

• Incident Detection: Monitor and analyze IoT device activity for signs of incidents 376 involving device and data security. 377

Risk mitigations within these areas carry certain expectations based on conventional IT devices 378 that may not be met or may be met significantly differently for some IoT devices, sometimes in 379 unexpected ways. As a result, there are one or more challenges that IoT devices may pose to 380 each expectation, such as not having expected device features (i.e., technical hardware, software, 381 and firmware functionality). The end result of these linkages is the identification of a structured 382 set of potential challenges with mitigating cybersecurity risk for IoT devices that can each be 383 traced back to the relevant risk considerations. 384

Figure 1 depicts the relationships among the major NIST IR 8228 concepts: risk considerations, 385 risk mitigation goals and areas, expectations, and challenges. For more information on any of 386 these, see Sections 3 and 4 of NIST IR 8228. [3] This document aims to help manufacturers of 387 IoT devices address gaps in IoT device features relative to conventional IT equipment, which 388 will help reduce challenges by aligning IoT devices better with expectations. 389


5

390

Figure 1: Relationships Among Major NIST IR 8228 Concepts 391


6

3 Cybersecurity Feature Identification 392

This section is intended to help IoT device manufacturers better identify the cybersecurity risks 393 their customers (individuals and organizations) face so IoT devices can provide the cybersecurity 394 features customers need. Manufacturers cannot completely understand all of their customers’ risk 395 because every customer, system, and IoT device faces unique risks based on many factors; 396 however, manufacturers can consider the expected use cases for their IoT devices, and then make 397 their devices at least minimally securable by customers who acquire and use them consistent 398 with those use cases. Minimally securable means the devices have the technical features (i.e., 399 hardware, firmware, and software) customers may need to implement cybersecurity controls 400 used to mitigate some common cybersecurity risks. Customers are still ultimately responsible for 401 securing their systems and the IoT devices they incorporate, including using additional technical, 402 physical, and procedural means, but cybersecurity features built into IoT devices generally make 403 risk mitigation easier and more effective for customers. 404

This section and the rest of the publication are intended to inform the existing cybersecurity risk 405 management practices IoT device manufacturers already follow as part of their IoT device design 406 processes. This section does not define a risk management methodology or process, but instead 407 provides additional considerations for manufacturers to be incorporated into existing processes. 408 Section 4 defines a core baseline of cybersecurity features that manufacturers can use as a 409 starting point for identifying the appropriate features for their IoT devices. The goal is for 410 manufacturers to consider cybersecurity risks in the context of the applicable use case or cases 411 for the IoT device so the device’s hardware, firmware, and software design can help mitigate 412 those risks. 413

3.1 Expected Customers and Use Cases 414

An early step in IoT device design is identifying the expected customers for the device. They 415 could be as broad as every person and organization, or they could be types of people (e.g., 416 musicians, cyclists, chefs, preschoolers) or organizations, such as small retail businesses, large 417 hospitals, energy companies with solar farms, or educational institutions with buses. Identifying 418 expected customers is vital for determining which cybersecurity features an IoT device should 419 implement and how it should implement them. For example, an enterprise might need a device to 420 integrate with its log management servers, but a typical home customer would not. 421

Another early step in IoT device design is defining use cases for the device based on the 422 expected customers. Each use case should explain how the customers will use the device, where 423 the device will be used (e.g., countries, jurisdictions within countries), what environments the 424 device will be used in (e.g., inside or outside; stationary or moving; public or private; movable or 425 immovable), likely system dependencies, and other aspects of device use that might be relevant 426 to the device’s cybersecurity risk. Each use case should also reflect how attackers might misuse 427 and compromise the devices to ensure that is taken into consideration. 428

3.2 Device Cybersecurity Features 429

The expected customers and use cases can serve as assumptions for identifying device 430 cybersecurity features. Here are a few examples: 431


7

• Device management: The method or methods likely to be used by device customers to 432 manage the device, if any, are important to consider. For example, an IoT device intended 433 for enterprise use could support integration with common enterprise systems (e.g., asset 434 management, vulnerability management, log management). If used, this feature would 435 give enterprise customers a greater degree of control and visibility into the devices’ 436 cybersecurity risk. For an IoT device expected to be used in home environments only, 437 this feature would not be relevant, and customers would expect a user-friendly way to 438 manage their devices, or even want the manufacturer to perform all device management 439 on their behalf (e.g., installing patches automatically without customer involvement). 440

• Configurability: Configurability is closely related to device management. For example, 441 making a device highly configurable is generally more desirable in enterprise 442 environments and less so in home customer settings. A home customer is less likely to 443 understand the significance of granular cybersecurity configuration settings and thus 444 misconfigure a device, weakening its security and increasing the likelihood of a 445 compromise. On the other hand, some configuration settings, such as enabling or 446 disabling clock synchronization services for the device and choosing a time server to use 447 for clock synchronization, may be desired by both enterprise and home customers. 448 Device configuration might be entirely omitted in cases where the device does not need 449 to be provisioned or customized in any way during or after deployment (e.g., does not 450 need to be joined to a wireless network, does not need to be associated with a particular 451 user). 452

• Network characteristics: Devices expected to be used on networks with low bandwidth, 453 unreliable networks, or other networks that significantly impede the flow of network 454 traffic might preclude the use of certain features. For example, depending on such a 455 network for downloading large updates might saturate the network connection, disrupting 456 other usage, and take far too long to get updates to the device. Manufacturers could 457 consider alternative update strategies, such as changing their processes so as to reduce the 458 size of updates, or distributing updates to administrators on high-speed network 459 connections and having the administrators manually transfer the updates to the IoT device 460 (which introduces additional cybersecurity risks from malware being transmitted by 461 removable media that may need to be mitigated). 462

• The nature of device data: There is a great deal of variability across IoT devices when it 463 comes to the nature of the data they collect, process, store, and transmit. Some devices do 464 not store any data, while others store data that could cause significant harm if accessed or 465 modified by unauthorized entities. Understanding the nature of data on a device in the 466 context of the customers and use cases can help manufacturers identify the features 467 needed to protect device data. Examples of possible features include data encryption, 468 device and user authentication, access control, and backup/restore. 469

• Access level: The cybersecurity features an IoT device needs can be greatly affected 470 based on how accessible the device is, either logically or physically. An example is an 471 IoT food vending machine in a public place, which is internet connected so suppliers can 472 track inventory and machine status. Vending machine users would not be required to 473 authenticate themselves in order to insert money and purchase a snack. However, the 474 vending machine would also be highly susceptible to physical attack. 475


8

NIST IR 8228, Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy 476 Risks [3] discusses additional cybersecurity-related considerations that manufacturers should be 477 mindful of when identifying cybersecurity features. It is recommended that IoT device 478 manufacturers read NIST IR 8228 and use the material in Sections 3 and 4 as the basis of 479 identifying the cybersecurity features their devices should provide. Tables 1 and 2 in Section 4 of 480 NIST IR 8228 list common shortcomings in IoT device cybersecurity and explain how they can 481 negatively impact customers. This includes references to Cybersecurity Framework 482 subcategories [7] and NIST SP 800-53 controls [4], which many organizations use when 483 discussing cybersecurity. 484

Manufacturers should also identify any known requirements in their use cases, such as sector-485 specific cybersecurity regulations or country-specific laws, so they can be mindful of those 486 requirements during feature identification. 487

Identifying the cybersecurity features devices need should happen as early in device design 488 processes as feasible so the features can be taken into account when selecting or designing IoT 489 device hardware, firmware, and software. For many IoT devices, additional types of risks, such 490 as privacy,5 safety, reliability, or resiliency, need to be managed simultaneously with 491 cybersecurity risks because of the effects addressing one type of risk can have on others. A 492 common example is ensuring that when a device fails, it does so in a safe manner. Only 493 cybersecurity risks are in scope for this publication. Readers who are particularly interested in 494 better understanding other types of risks and their relationship to cybersecurity may benefit from 495 reading NIST SP 800-82 Revision 2, Guide to Industrial Control Systems (ICS) Security. [8] 496

5 A number of privacy efforts, including the NIST Privacy Framework (https://www.nist.gov/privacy-framework), are

currently underway that are likely to inform needed IoT device features to support privacy. While the core baseline includes cybersecurity features that also support privacy, such as protecting the confidentiality of data, it does not include non-cybersecurity features that support privacy.

https://www.nist.gov/privacy-framework


9

4 The Core Baseline for IoT Devices 497

To provide manufacturers a starting point to use in identifying the necessary cybersecurity features for their IoT devices, this section 498 defines a core cybersecurity feature baseline (core baseline), which is a set of technical features needed by a generic customer to 499 support common cybersecurity controls that protect the customer’s devices and device data, systems, and ecosystems as described in 500 Section 2. The core baseline’s role is as a default for minimally securable devices, meaning that cybersecurity features will often need 501 to be added or removed from an IoT device’s design to take into account the manufacturer’s understanding of customers’ likely 502 cybersecurity risks. Also, the core baseline does not specify how the cybersecurity features are to be achieved, so manufacturers who 503 choose to adopt the core baseline for any of the IoT devices they produce have considerable flexibility in implementing it to effectively 504 address customer needs. Section 5 provides additional considerations for feature implementation. 505

Table 1 defines the cybersecurity features in the core baseline. Each row defines a feature and provides a numbered list of key elements 506 of that feature—elements an IoT device manufacturer seeking to implement the core baseline must meet in order to achieve the feature. 507 (Note: the elements are not intended to be comprehensive, nor are they in any particular order.) The third column explains the rationale 508 for needing the feature and its key elements to be included in the core baseline for the generic case. Finally, the last column lists 509 reference examples that indicate existing sources of IoT device cybersecurity guidance specifying a similar or related cybersecurity 510 feature. Definitions of selected terms from Table 1, the terms that are underlined, are provided after the table. 511

Each feature and key element in the core baseline stems directly from the contents of Section 4 of NIST IR 8228, and the core baseline 512 addresses the most common issues in IoT devices based on its findings. See NIST IR 8228 for more details on the rationales behind 513 everything in the core baseline. [3] 514


10

Table 1: The Core Cybersecurity Feature Baseline for Securable IoT Devices 515

Feature Key Elements Rationale Reference Examples Device Identification: The IoT device can be uniquely identified logically and physically.

1. A unique logical identifier 2. A unique physical identifier on it at an

external or internal location authorized entities can access

Note: the physical and logical identifiers may represent the same value, but they do not have to.

• This feature supports asset management, which in turn supports vulnerability management, access management, data protection, and incident detection.

• The unique logical identifier can be used to distinguish the device from all others, usually for automated device management and monitoring. The unique logical identifier can also be used for device authentication.

• The unique physical identifier can be used to distinguish the device from all others whenever the unique logical identifier is unavailable, such as during device deployment and decommissioning, or after a device failure.

• BITAG [9]: 7.2, 7.6 • CTIA [10]: 4.13 • ENISA [11]: PS-10, TM-21 • GSMA [12]: CLP11_5.2.1,

CLP13_6.6.2, 6.8.1, 6.20.1, 8.11.1

• IIC [13]: 7.3, 8.5, 11.7, 11.8 • IoTSF [14]: 2.4.8.1, 2.4.14.3,

2.4.14.4

Device Configuration: The IoT device’s software and firmware configuration can be changed, and such changes can be performed by authorized entities only.

1. The ability to change the device’s software and firmware configuration settings

2. The ability to restrict configuration changes to authorized entities only

3. The ability for authorized entities to restore the device to a secure default configuration defined by an authorized entity

• This feature supports vulnerability management, access management, data protection, and incident detection.

• Customers often want to alter a device's configuration for a variety of reasons, including cybersecurity, interoperability, privacy, and usability. Without a device configuration feature, a customer can only use a device as-is and cannot customize it to meet the customer's needs, integrate the device into the customer's environment, etc.

• Most cybersecurity features are at least somewhat dependent on the presence of a device configuration feature.

• Unauthorized entities may want to change a device's configuration for many reasons, such as gaining unauthorized access, causing the device to malfunction, or secretly monitoring the device's environment.

• The ability to restore a secure default configuration for a device is helpful when the current configuration contains errors, has been damaged or corrupted, or is otherwise no longer thought to be trustworthy.

• BITAG: 7.1, 7.2 • CSA2 [15]: 22 • CTIA: 4.7, 4.8, 4.12, 5.15 • GSMA: CLP12_5.3.1.3, 5.6.2 • IIC: 7.3, 7.6, 8.10, 11.1, 11.2,

11.5 • IoTSF: 2.4.7.7, 2.4.8, 2.4.15


11

Feature Key Elements Rationale Reference Examples Data Protection: The IoT device can protect the data it stores and transmits from unauthorized access and modification.

1. The ability to use accepted cryptographic modules for standardized cryptographic algorithms (e.g., encryption with authentication, cryptographic hashes, digital signature validation) to prevent the confidentiality and integrity of the device’s stored and transmitted data from being compromised

2. The ability for authorized entities to configure the cryptography use itself when applicable, such as choosing a key length

3. The ability for authorized entities to render all data on the device inaccessible by all entities, whether previously authorized or not (e.g., through a wipe of internal storage, destruction of cryptographic keys for encrypted data)

• This feature supports access management, data protection, and incident detection.

• Customers often want the confidentiality of their data protected so unauthorized entities cannot access their data and misuse it.

• Customers often want the integrity of their data protected so it is not inadvertently or intentionally changed, which could have a variety of adverse consequences (e.g., issuing the wrong command to a piece of equipment, concealing malicious activity).

• AGELIGHT [16]: 5, 7, 18, 24, 25, 34

• BITAG: 7.2, 7.10 • CTIA: 4.8, 4.10, 5.15 • ENISA: GP-OP-04, GP-TM-14,

GP-TM-24, GP-TM-32, GP-TM-34, GP-TM-35, GP-TM-36, GP-TM-39, GP-TM-40

• ETSI [17]: 4.4-1, 4.5-1, 4.5-2, 4.11-1, 4.11-2, 4.11-3

• GSMA: CLP12_5.1.5, 5.1.7.1, 5.2.2.1, 5.3.1.1, 6.2.1, 6.3.1.2, CLP13_6.1.1.6, 6.1.1.8, 6.4.1.1, 6.5.1.1, 6.11, 6.12.1.1, 7.6.1, 8.10.1.1, 8.11.1

• IIC: 7.3, 7.4, 7.7, 8.8, 8.11, 8.13, 9.1

• IoTSF: 2.4.5, 2.4.7, 2.4.8.8, 2.4.8.16, 2.4.9, 2.4.12.2, 2.4.12.11, 2.4.13.16, 2.4.16.1, 2.4.16.2

Logical Access to Interfaces: The IoT device can limit logical access to its local and network interfaces to authorized entities only.

1. The ability to logically or physically disable any local and network interfaces that are not necessary for the core functionality of the device

2. The ability to logically restrict access to each network interface (e.g., device authentication, user authentication)

3. The ability to enable, disable, and adjust thresholds for any ability the device might have to lock or disable an account or to delay additional authentication attempts after too many failed authentication attempts

• This feature supports vulnerability management, access management, data protection, and incident detection.

• Limiting access to interfaces reduces the attack surface of the device, giving attackers fewer opportunities to compromise it. For example, unrestricted network access to an IoT device enables attackers to directly interact with the device, which significantly increases the likelihood of the device being compromised.

• AGELIGHT: 10, 13, 14, 18, 39 • BITAG: 7.1, 7.2, 7.3 • CTIA: 3.2, 3.3, 3.4, 4.2, 4.3, 4.9,

5.2 • ENISA: GP-TM-08, GP-TM-09,

GP-TM-21, GP-TM-22, GP-TM-27, GP-TM-29, GP-TM-33, GP-TM-42, GP-TM-44, GP-TM-45

• ETSI: 4.1-1, 4.4-1, 4.6-1, 4.6-2 • GSMA: CLP12_5.6.1, 6.3.1.1,

7.1.1.2, CLP13_6.12.1, 7.10.1, 8.2.1.1

• IIC: 7.3, 7.4, 8.3, 8.6, 11.7 • IoTSF: 2.4.4.5, 2.4.5, 2.4.6,

2.4.7, 2.4.8, 2.4.13, 2.4.15


12

Feature Key Elements Rationale Reference Examples Software and Firmware Update: The IoT device’s software and firmware can be updated by authorized entities only using a secure and configurable mechanism.

1. The ability to update all the device’s software and firmware through remote (e.g., network download) and/or local means (e.g., removable media)

2. The ability to confirm the validity of any update before installing it

3. The ability to restrict updating actions to authorized entities only

4. The ability to enable or disable updating 5. The ability to set remote update

mechanisms to be either automatically or manually initiated for update downloads and installations

6. The ability to enable or disable notification when an update is available and specify who or what is to be notified

• This feature supports vulnerability management. • Updates can remove vulnerabilities from an IoT

device, which lowers the likelihood of an attacker compromising the device.

• Updates can correct IoT device operational problems, which can improve device availability, reliability, performance, and other aspects of device operation.

• AGELIGHT: 1, 2, 4 • BITAG: 7.1 • CTIA: 3.5, 3.6, 4.5, 4.6, 5.5, 5.6 • ENISA: GP-TM-18, GP-TM-19 • ETSI: 4.3-1, 4.3-2, 4.3-7 • GSMA: CLP11_5.3.3,

CLP12_5.8.1, 5.9.1.3, 6.6.1 • IIC: 7.3, 11.5.1 • IoTSF: 2.4.5, 2.4.6, 2.4.13.1

Cybersecurity Event Logging: The IoT device can log cybersecurity events and make the logs accessible to authorized entities only.

1. The ability to log cybersecurity events across the device’s software and firmware

2. The ability to record sufficient details for each event to facilitate an authorized entity examining the log and determining what happened

3. The ability to restrict access to the logs so only authorized entities can view them

4. The ability to prevent any entities (authorized or unauthorized) from editing the logs

5. The ability to make the logs available to a logging service on another device, such as a log server

• This feature supports vulnerability management and incident detection.

• Cybersecurity event logging provides a record of events that can be useful in investigating compromises, identifying misuse, and troubleshooting certain operational problems.

• CTIA: 4.7, 4.12, 5.7 • ENISA: GP-TM-55 • ETSI: 4.10-1 • GSMA: CLP11_5.3.4,

CLP12_5.7.1.2, 5.7.1.3, CLP13_6.13.1, 7.2.1, 9.1.1.2

• IIC: 7.3, 7.5, 7.7, 8.9, 10.3, 10.4

Definitions of selected terms from the table are as follows: 516

• An authorized entity is an entity that has implicitly or explicitly been granted approval to interact with a particular IoT device. 517 The core baseline features do not specify how authorization is implemented for distinguishing authorized and unauthorized 518 entities. It is left to the manufacturer to decide how each device will implement authorization. 519


13

• Configuration is “the possible conditions, parameters, and specifications with which an information system or system 520 component can be described or arranged.” [18] The Device Configuration feature does not define which configuration settings 521 should exist, simply that a mechanism to manage configuration settings exists. 522

• Cybersecurity events are observable occurrences with cybersecurity significance in an IoT device. (This definition is derived 523 from [4].) 524

• A device identifier is a context-unique value that is associated with a device (for example, a string consisting of a network 525 address). (This definition is derived from [19].) 526

• An entity is a person, device, service, network, domain, manufacturer, or other party who might interact with an IoT device. 527

• Firmware is “computer programs and data stored in hardware[…]such that the programs and data cannot be dynamically 528 written or modified during execution of the programs.” [4] 529

• An interface is a boundary between the IoT device and entities where interactions take place. (This definition is derived from 530 [20].) There are two types of interfaces: network and local. 531

• Local interfaces are interfaces that can only be accessed physically, such as ports (e.g., USB, audio, video/display, serial, 532 parallel, Thunderbolt) and removable media drives (e.g., CD/DVD drives, memory card slots). 533

• Local logical access is logical access to an IoT device that does not occur over a network. 534

• A logical identifier is a device identifier that is expressed logically by the device’s software or firmware. An example is a media 535 access control (MAC) address assigned to a network interface. 536

• Network interfaces are interfaces that connect the IoT device to networks. 537

• A physical identifier is a device identifier that is expressed physically by the device (e.g., printed onto a device’s housing, 538 displayed on a device’s screen). 539

• Remote logical access is logical access to an IoT device that occurs over a network. 540

• Software is “computer programs and associated data that may be dynamically written or modified during execution.” [4] 541

• An update is a patch, upgrade, or other modification to code that corrects security and/or functionality problems in software or 542 firmware. (This definition is derived from [21].) 543


14

5 Cybersecurity Feature Implementation 544

Manufacturers should implement cybersecurity features in ways that will be appropriate for their 545 customers. Two important aspects of feature implementation are defining the specifications for 546 the IoT device hardware, firmware, and software, and understanding how an IoT device may 547 inherit cybersecurity features from the system or environment it is deployed within. This section 548 discusses these aspects in more detail. 549

5.1 Device Specifications 550

Manufacturers properly provisioning device hardware, firmware, and supporting software to 551 provide the necessary cybersecurity features will help make the devices more securable. The 552 following considerations for manufacturers are suggestions and are not comprehensive: 553

• Select or build a device with sufficient hardware resources (e.g., processing, memory, 554 storage, network technology, power), as well as firmware and software resources, to 555 support the desired features. For example, encryption is processing-intensive, and a 556 device with limited processing might not be able to support encryption that customers 557 need. Some devices cannot support the use of an operating system or Internet Protocol 558 (IP) networks. 559

• Be forward-looking and size hardware resources for potential future use. As an example, 560 if a device has a 10-year lifespan, it may be necessary to update the encryption algorithm 561 or key length the device uses, and the new algorithm or key length may make encryption 562 more processing-intensive. 563

• Use hardware-based cybersecurity features. An example is having a hardware root of 564 trust that provides trusted storage for cryptographic keys and enables performing secure 565 boots and confirming device authenticity. 566

• Do not include unneeded features provided by hardware, firmware, and/or the operating 567 system; if the inclusion of such features cannot be avoided, ensure they can be disabled to 568 prevent misuse and exploitation. For example, if a device has local interfaces on its 569 external housing and the device is likely to be deployed in public areas, possible 570 approaches include offering a tamper-resistant enclosure to prevent physical access to the 571 interfaces, and offering a configuration option that logically disables the interfaces. 572

• Do not force the use of features that may negatively impact operations. A classic example 573 is authentication. Features intended to deter brute force attacks against passwords, such as 574 locking out an account after too many failed authentication attempts, can inadvertently 575 cause a denial of service for the person or device attempting to authenticate. In safety-576 critical environments, for example, such disruptions to access may not be acceptable 577 because of the danger they would cause. Customers often need flexibility in configuring 578 such features or disabling them altogether. 579

Manufacturers may want to consider using an established IoT platform instead of acquiring and 580 integrating hardware, firmware, and supporting software components (e.g., operating system). 581 An IoT platform is a piece of IoT device hardware with firmware and/or supporting software 582 already installed and configured for a manufacturer’s use as the basis of a new IoT device. An 583


15

IoT platform might also offer third-party services or applications, or a software development kit 584 (SDK) to help expedite IoT application development. Manufacturers can choose an adequately 585 resourced IoT platform instead of designing hardware, installing and configuring an operating 586 system or firmware, creating new cloud-based services, writing IoT device applications and 587 mobile apps from scratch, and performing other tasks that are error-prone and generally more 588 likely to introduce new vulnerabilities into the IoT device compared to adopting an established 589 platform. 590

Whether or not an IoT platform is being used for a device, manufacturers should carefully 591 consider the current status and expected lifespan of any third-party components or services 592 before including them in the IoT device design. Avoid using any hardware, firmware, or 593 software that is no longer maintained. 594

5.2 Cybersecurity Feature Inheritance 595

IoT device design processes may determine that certain cybersecurity features can be omitted 596 from IoT devices because equivalent protection will be inherited from elsewhere. For example, if 597 an IoT device is intended for use in an environment with stringent physical security controls in 598 place, a manufacturer might be able to omit restricting access to the device’s local interfaces 599 because the facility’s physical security can take care of it. On the other hand, an IoT device with 600 a particularly important function might merit keeping cybersecurity features for local interface 601 access restriction in order to provide an additional layer of security against attacks. 602

Another example of cybersecurity inheritance is an IoT device being dependent on an IoT 603 gateway or hub for its communications. Such an IoT device cannot fully function unless it 604 communicates directly with an IoT gateway or hub within its physical or logical proximity, with 605 the gateway or hub acting as an intermediary between the IoT device and other devices or 606 services. “IoT gateway” and “IoT hub” are terms without consistent definitions as of this writing, 607 but what matters is the functionality the gateway or hub provides, not the term used. Most IoT 608 gateways and hubs provide one or both of the following: 1) networking services that connect two 609 networks, usually with different protocols, and restrict the traffic between the two networks; and 610 2) application services that provide command and control functionality for IoT devices. 611

An IoT device that is properly shielded from devices outside its network by an IoT gateway or 612 hub can only be accessed in one of two ways—through the IoT gateway or hub, or within 613 physical proximity of the device—so that IoT device effectively inherits network logical access 614 protection from the IoT gateway or hub. An IoT gateway or hub with application services might 615 also be able to handle cybersecurity event logging for an IoT device, especially if the IoT 616 device’s internal cybersecurity events are not deemed significant enough to merit logging. 617 Dependency on an IoT gateway/hub has other positive security implications, such as a greater 618 chance of malicious activity involving the IoT device being detected (because its network traffic 619 passes through the IoT gateway/hub). However, shifting features from the IoT device to an IoT 620 gateway or hub makes the cybersecurity of that gateway or hub critical to the cybersecurity of 621 the IoT device. 622

A final group of examples involves device identifiers. An IoT device fully contained within 623 another IoT device might inherit certain cybersecurity features from the outer device, such as the 624


16

outer device’s unique logical and physical device identifiers. An IoT device that will be deployed 625 in an environment without physical access to the device, such as sensors embedded within a 626 structure or a substance, may not need a physical device identifier because the environment 627 around it provides unique identification for it. 628

These examples help illustrate why the core baseline of cybersecurity features is not intended to 629 be fully adopted by every IoT device; every IoT device has a unique set of expected customers 630 and use cases, and not all features in the core baseline will make sense to use in every situation. 631 It is important that manufacturers explain to customers, in sufficient detail, why any core 632 baseline features have been omitted from an IoT device so customers are aware the features are 633 absent and understand the rationale. 634


17

6 Cybersecurity Information to Provide to Customers 635

Many customers will benefit from manufacturers communicating to them more clearly about 636 cybersecurity risks involving their IoT devices. This section provides examples of information 637 that may be particularly beneficial to communicate to customers, especially in enterprise 638 environments. These examples are not unique to IoT, and they will not necessarily apply to all 639 IoT devices a manufacturer produces. However, the information is supportive of and particularly 640 applicable to IoT cybersecurity, and is likely to address cybersecurity challenges currently 641 affecting many IoT devices and customers. 642

Manufacturers should strive to present this information to customers as clearly as possible, in 643 terms the customer will understand, and in logical and physical locations the customer will see or 644 hear it and can readily locate it again whenever needed. Achieving this may require a different 645 approach for different kinds of customers based on their expectations and resources. In some 646 instances, this may mean presenting more or less information based on the customer targeted and 647 their needs. 648

Device Cybersecurity Features: Communicating to customers which cybersecurity features the 649 device provides, especially using common terminology (e.g., the feature names from the core 650 baseline), and how these features may affect risk helps customers better understand how to 651 manage risk for the device. Similarly, if features customers would expect to be provided by the 652 device are not, it would help if the missing features were identified as such so customers could 653 adjust their risk management accordingly. Manufacturers should also explain why the features 654 were not included. 655

For most customers, information on device cybersecurity features is likely to be more useful if it 656 includes an explanation of the assumptions the manufacturer made, such as how the device will 657 be used, what type of environment it will be used in, what cybersecurity features will be 658 inherited from elsewhere (e.g., an IoT gateway), and how responsibilities are expected to be 659 shared among the manufacturer, the customer, and others. 660

Device Transparency: Communicating to customers information about the device’s software, 661 firmware, hardware, services, functions, and data types helps customers better understand and 662 manage cybersecurity for their devices, particularly if the customer is expected to play a 663 substantial role in managing device cybersecurity. Important information for customers includes: 664

• Usable information on cybersecurity-related aspects of the device, including device 665 installation, configuration, usage, management, maintenance, and disposal. This 666 information should include the effect on the device if the cybersecurity configuration is 667 made more restrictive than the secure default (e.g., losing some device functionality). 668

• An inventory of the IoT device’s current internal software and firmware, including 669 versions, patch status, and known vulnerabilities. The ability to inventory the IoT 670 device’s internal software and firmware could be offered as a device feature. 671

• A list of sources of all of the IoT device’s software, firmware, hardware, and services. 672


18

• Sufficient information on the IoT device’s operational characteristics so they can 673 adequately secure the device (e.g., make information on characteristics available on a 674 website; use a standard protocol so devices can provide basic information to authorized 675 parties). 676

• A list of the functions the IoT device performs (i.e., the device should not perform any 677 hidden functions customers would not expect or want). 678

• A list of data types the IoT device may collect and the identities of all third parties that 679 can access that data. 680

• The identities of all parties (including the manufacturer) who have access to or any 681 degree of control over the IoT device. 682

Software and Firmware Update Transparency: Manufacturers communicating expectations 683 about when updates may be released and who is responsible for performing updates, as well as 684 providing information on the contents of each update, helps customers plan their cybersecurity 685 mitigations and maintain the cybersecurity of their devices, particularly in response to emerging 686 threats. Practices include: 687

• Set customer expectations on if and when updates will be made available. 688

• Define the circumstances under which updates will be issued (e.g., controlling execution 689 of faulty software, identification of previously unknown vulnerabilities in protocols). 690

• Either inform the customer which entity (e.g., customer, manufacturer, third party) is 691 responsible for performing updates, or give the customer the option to designate who will 692 be responsible. 693

• Notify the customer if installing an update may alter existing configuration settings. 694

• Notify the customer or the customer’s IoT device of update availability and contents 695 (e.g., altered or new functions or features). 696

Support and Lifespan Expectations: Communicating to customers the length of time a 697 manufacturer intends to support a device and how long the device may be able to function helps 698 customers plan their cybersecurity mitigations throughout the device’s support lifecycle, which 699 may be shorter than how long the customer wants to use the device. Practices include: 700

• State the timeframe for the end of product support. 701

• State the timeframe for product end-of-life. 702

• Inform customers of what functionality, if any, the device will have after support ends 703 and at end-of-life. 704

Decommissioning: Communicating to customers the options, if any, for securely 705 decommissioning a device helps customers plan for securely disposing of devices. Practices 706 include: 707

• Provide customers sufficient information on whether the IoT device can be 708 decommissioned and how they can decommission it, such as removing all user and 709


19

configuration data from the device and associated systems (e.g., cloud-based services 710 used by the device), rendering the device inoperable, or transferring ownership to another 711 party. 712

It is also important for manufacturers to keep the cybersecurity information they communicate to 713 customers easily accessible and up to date. Accessibility includes communicating in language 714 customers will understand. For example, a home user will likely have less technical knowledge 715 than enterprise customer points of contact (e.g., a system administrator), so messages to these 716 different groups should take that into account to avoid confusion. The amount and focus of 717 information may also vary between customers since they will have different needs, preferences, 718 and abilities, with some customers requiring less information than others about various aspects of 719 their devices and features. How customers are contacted may also vary by customer and by 720 device. For some devices, customers, and use cases, it may be more efficient and effective to 721 have some of the information and notifications of changes come directly from the IoT devices or 722 connected interfaces (e.g., smartphone app) instead of mailing lists and other means. 723

Keeping customers up to date means notifying them of significant changes to previously 724 communicated information. The same recommendations for messaging discussed above apply 725 for follow-up communications, but extra care should be taken to avoid too many or contradictory 726 follow-up messages, which could lead some customers, particularly home customers, to ignore 727 important messages. 728


20

7 Secure Development Practices for IoT Devices 729

The previous sections of this publication have focused on what manufacturers can do to make 730 devices minimally securable. This section covers a different topic: manufacturers improving how 731 secure their IoT devices are by following secure software development practices. Although this 732 does not directly improve how securable devices are for customers, it can improve the security of 733 deployed devices in ways that customers cannot. As a recent NIST white paper, Mitigating the 734 Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework 735 (SSDF) [22] states, following secure software development practices should help manufacturers 736 “reduce the number of vulnerabilities in released software, mitigate the potential impact of the 737 exploitation of undetected or unaddressed vulnerabilities, and address the root causes of 738 vulnerabilities to prevent future recurrences.” 739

There are many existing standards, guidelines, and other publications on secure software 740 development. IoT device manufacturers interested in more information can consult the NIST 741 white paper on secure software development [22] which highlights selected practices for secure 742 software development. Each of these practices is widely recommended by existing secure 743 software development publications, and the white paper provides references from nearly 20 of 744 these publications. Manufacturers looking for information on secure software development can 745 use the references as a starting point. 746

All of the white paper’s practices are relevant for IoT devices, but some are particularly 747 noteworthy, especially for IoT device software developers who are relatively new to 748 cybersecurity: 749

• Manufacturers ensuring their workforce has the necessary skills to securely develop IoT 750 devices will help manufacturers more easily design and produce such devices. SSDF 751 practices: 752 o PO.2, Implement Roles and Responsibilities 753

• Manufacturers taking steps to protect code and give customers the ability to verify 754 software integrity helps prevent IoT devices from executing malicious code. SSDF 755 practices: 756 o PS.1, Protect All Forms of Code from Unauthorized Access and Tampering 757 o PS.2, Provide a Mechanism for Verifying Software Release Integrity 758 o PS.3, Archive and Protect Each Software Release 759

• Manufacturers taking steps to reduce vulnerabilities in IoT devices will make devices 760 inherently more secure and reduce the number of vulnerabilities that need to be mitigated 761 by customers. This includes both the initial development of IoT device software and all 762 updates made to the software after its release. SSDF practices: 763 o PW.3, Verify Third-Party Software Complies with Security Requirements 764 o PW.4, Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating 765

Functionality 766 o PW.5, Create Source Code Adhering to Secure Coding Practices 767


21

o PW.7, Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and 768 Verify Compliance with Security Requirements 769

o PW.8, Test Executable Code to Identify Vulnerabilities and Verify Compliance with 770 Security Requirements 771

o PW.9, Configure the Software to Have Secure Settings by Default 772

• Manufacturers accepting and responding to vulnerability reports helps customers 773 maintain the cybersecurity of their IoT devices as new threats emerge. SSDF practices: 774 o RV.1, Identify and Confirm Vulnerabilities on an Ongoing Basis 775 o RV.2, Assess and Prioritize the Remediation of All Vulnerabilities 776 o RV.3, Analyze Vulnerabilities to Identify Their Root Causes777


22

References 778

[1] Executive Order no. 13800, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, DCPD-201700327, May 11, 2017. https://www.govinfo.gov/app/details/DCPD-201700327

[2] Department of Commerce and Department of Homeland Security (2018) A Report to the President on Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats. (Department of Commerce and Department of Homeland Security, Washington, DC). https://csrc.nist.gov/CSRC/media/Publications/white-paper/2018/05/30/enhancing-resilience-against-botnets--report-to-the-president/final/documents/eo_13800_botnet_report_-_finalv2.pdf

[3] Boeckl K, Fagan M, Fisher W, Lefkovitz N, Megas K, Nadeau E, Piccarreta B, Gabel O’Rourke D, Scarfone K (2019) Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8228. https://doi.org/10.6028/NIST.IR.8228

[4] Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 4, Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

[5] Department of Commerce (2018) A Road Map Toward Resilience Against Botnets. (Department of Commerce, Washington, DC). https://www.commerce.gov/sites/default/files/2018-11/Botnet%20Road%20Map%20112918%20for%20posting_0.pdf

[6] Simmon E (forthcoming) A Model for the Internet of Things (IoT). (National Institute of Standards and Technology, Gaithersburg, MD).

[7] National Institute of Standards and Technology (2018) Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and Technology, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018

[8] Stouffer K, Pillitteri V, Lightman S, Abrams M, Hahn A (2015) Guide to Industrial Control Systems (ICS) Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-82, Rev 2. https://doi.org/10.6028/NIST.SP.800-82r2

[9] Broadband Internet Technical Advisory Group (BITAG) (2016) Internet of Things (IoT) Security and Privacy Recommendations. (Broadband Internet Technical Advisory Group (BITAG), Denver, CO). https://www.bitag.org/documents/BITAG_Report_-_Internet_of_Things_(IoT)_Security_and_Privacy_Recommendations.pdf

[10] CTIA (2018) CTIA Cybersecurity Certification Test Plan for IoT Devices, Version 1.0.1. (CTIA, Washington, DC). https://www.ctia.org/about-ctia/test-plans/

https://www.govinfo.gov/app/details/DCPD-201700327

https://csrc.nist.gov/CSRC/media/Publications/white-paper/2018/05/30/enhancing-resilience-against-botnets--report-to-the-president/final/documents/eo_13800_botnet_report_-_finalv2.pdf



https://doi.org/10.6028/NIST.IR.8228

https://doi.org/10.6028/NIST.SP.800-53r4

https://www.commerce.gov/sites/default/files/2018-11/Botnet%20Road%20Map%20112918%20for%20posting_0.pdf

https://www.commerce.gov/sites/default/files/2018-11/Botnet%20Road%20Map%20112918%20for%20posting_0.pdf

https://doi.org/10.6028/NIST.CSWP.04162018


https://www.bitag.org/documents/BITAG_Report_-_Internet_of_Things_(IoT)_Security_and_Privacy_Recommendations.pdf

https://www.bitag.org/documents/BITAG_Report_-_Internet_of_Things_(IoT)_Security_and_Privacy_Recommendations.pdf

https://www.ctia.org/about-ctia/test-plans/


23

[11] European Union Agency for Network and Information Security (ENISA) (2017) Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures. (European Union Agency for Network and Information Security (ENISA), Athens, Greece). https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot

[12] Groupe Spéciale Mobile Association (GSMA) (2017) GSMA IoT Security Assessment. (Groupe Spéciale Mobile Association (GSMA), London, UK). https://www.gsma.com/iot/iot-security-assessment/

[13] Industrial Internet Consortium (IIC) (2016) Industrial Internet of Things Volume G4: Security Framework. (Industrial Internet Consortium (IIC), Needham, MA). https://www.iiconsortium.org/IISF.htm

[14] IoT Security Foundation (IoTSF) (2017) IoT Security Compliance Framework, Release 1.1. (IoT Security Foundation (IoTSF), Livingston, Scotland). https://www.iotsecurityfoundation.org/best-practice-guidelines/

[15] Cloud Security Alliance (CSA) IoT Working Group (2015) Identity and Access Management for the Internet of Things. (Cloud Security Alliance (CSA)). https://cloudsecurityalliance.org/download/identity-and-access-management-for-the-iot/

[16] AgeLight Digital Trust Advisory Group (2019) IoT Safety Architecture & Risk Toolkit (IoTSA) v3.1. (AgeLight Advisory & Research Group, Bellevue, WA). http://agelight.com/iot.html

[17] European Telecommunications Standards Institute (ETSI) (2019) Cyber Security for Consumer Internet of Things. ETSI Technical Specification 103 645 V1.1.1. (European Telecommunications Standards Institute (ETSI), Sophia Antipolis Cedex, France). https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf

[18] Johnson A, Dempsey K, Ross R, Gupta S, Bailey D (2011) Guide for Security-Focused Configuration Management of Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-128. https://doi.org/10.6028/NIST.SP.800-128

[19] Barker E, Chen L, Roginsky A, Vassilev A, Davis R (2019) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3. https://doi.org/10.6028/NIST.SP.800-56Ar3

[20] Committee on National Security Systems (2015) Committee on National Security Systems (CNSS) Glossary. (National Security Agency, Ft. Meade, MD), CNSS Instruction (CNSSI) No. 4009.

[21] Souppaya M, Scarfone K (2013) Guide to Enterprise Patch Management Technologies. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-40, Rev. 3. https://doi.org/10.6028/NIST.SP.800-40r3

https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot

https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot

https://www.gsma.com/iot/iot-security-assessment/

https://www.iiconsortium.org/IISF.htm

https://www.iotsecurityfoundation.org/best-practice-guidelines/

https://cloudsecurityalliance.org/download/identity-and-access-management-for-the-iot/

http://agelight.com/iot.html

https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf

https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf

https://doi.org/10.6028/NIST.SP.800-128

https://doi.org/10.6028/NIST.SP.800-56Ar3



24

[22] Dodson D, Souppaya M, Scarfone K (2019) Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF). (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Cybersecurity White Paper. https://csrc.nist.gov/CSRC/media/Publications/white-paper/2019/06/07/mitigating-risk-of-software-vulnerabilities-with-ssdf/draft/documents/ssdf-for-mitigating-risk-of-software-vulns-draft.pdf

779

https://csrc.nist.gov/CSRC/media/Publications/white-paper/2019/06/07/mitigating-risk-of-software-vulnerabilities-with-ssdf/draft/documents/ssdf-for-mitigating-risk-of-software-vulns-draft.pdf




25

Appendix A—Acronyms and Abbreviations 780

Selected acronyms and abbreviations used in this document are defined below. 781

BITAG Broadband Internet Technical Advisory Group CD Compact Disc CNSS Committee on National Security Systems CNSSI Committee on National Security Systems Instruction CSA Cloud Security Alliance DDoS Distributed Denial of Service DVD Digital Video Disc ENISA European Union Agency for Network and Information Security ETSI European Telecommunications Standards Institute FISMA Federal Information Security Modernization Act FOIA Freedom of Information Act GSMA Groupe Spéciale Mobile Association ICS Industrial Control System IIC Industrial Internet Consortium IoT Internet of Things IoTSA Internet of Things Safety Architecture & Risk Toolkit IoTSF Internet of Things Security Foundation IP Internet Protocol IR Internal Report IT Information Technology ITL Information Technology Laboratory LTE Long-Term Evolution MAC Media Access Control NIST National Institute of Standards and Technology PII Personally Identifiable Information SDK Software Development Kit SP Special Publication SSDF Secure Software Development Framework USB Universal Serial Bus WiFi Wireless Fidelity

782


26

Appendix B—Glossary 783

Selected terms used in this document are defined below. 784

Actuator A portion of an IoT device capable of changing something in the physical world. [3]

Authorized Entity An entity that has implicitly or explicitly been granted approval to interact with a particular IoT device.

Configuration “The possible conditions, parameters, and specifications with which an information system or system component can be described or arranged.” [18]

Core Baseline A set of technical features needed by a generic customer to support common cybersecurity controls that protect the customer’s devices and device data, systems, and ecosystems

Core Cybersecurity Feature Baseline

See core baseline.

Cybersecurity Event An observable occurrence with cybersecurity significance in an IoT device. (derived from [4])

Device Identifier A context-unique value that is associated with a device (for example, a string consisting of a network address). (derived from [19])

Entity A person, device, service, network, domain, manufacturer, or other party who might interact with an IoT device.

Firmware “Computer programs and data stored in hardware[…]such that the programs and data cannot be dynamically written or modified during execution of the programs.” [4]

Interface A boundary between the IoT device and entities where interactions take place. (derived from [20])

IoT Platform A piece of IoT device hardware with firmware and/or software already installed and configured for a manufacturer’s use as the basis of a new IoT device. An IoT platform might also offer third-party services or applications, or a software development kit to help expedite IoT application development.

Local Interface An interface of an IoT device that can only be accessed physically, such as a port or a removable media drive.

Local Logical Access Logical access to an IoT device that does not occur over a network. Logical Identifier A device identifier that is expressed logically by the device’s software

or firmware. Minimally Securable IoT Device

An IoT device that has the technical features (i.e., hardware, firmware, and software) customers may need to implement cybersecurity controls used to mitigate some common cybersecurity risks.


27

Network Interface An interface that connects an IoT device to a network (e.g., Ethernet, WiFi, Bluetooth, Long-Term Evolution [LTE], ZigBee).

Physical Identifier A device identifier that is expressed physically by the device (e.g., printed onto a device’s case, displayed on a device’s screen).

Remote Logical Access

Logical access to an IoT device that occurs over a network.

Sensor A portion of an IoT device capable of providing an observation of an aspect of the physical world in the form of measurement data. [3]

Software “Computer programs and associated data that may be dynamically written or modified during execution.” [4]

Transducer A portion of an IoT device capable of interacting directly with a physical entity of interest. The two types of transducers are sensors and actuators. [3]

Update A patch, upgrade, or other modification to code that corrects security and/or functionality problems in software or firmware. (derived from [21])

785

Documents

Core Cybersecurity Feature Baselinefor Securable IoT ...85 cybersecurity risks their customer s face so IoT devices can provide cybersecurity features that 86 make them at least minimally