NISTIR 8259: Securing IoT Devices of Tomorrow – Part 2

This is the second blog post covering NISTIR 8259 and securing IoT devices. If you missed it, be sure to check out part 1  where we cover the “pre-market” phase activities.

While the NISTIR 8259 framework may seem dry at a glance, the guidance it offers is crucial for IoT security.

Consumers want the devices they use to be secure and also supported. If we’re to make any progress, frameworks like this are highly valuable.

Post-Market Phase Activities 

As a customer, how can you measure the maturity of the manufacturer who produces an IoT product you want? If you are a device manufacturer, how can you ensure that you are meeting industry and customer security requirements?

NISTIR 8259 is here to meet those questions and provide actionable steps for securing IoT devices.

Today, we will talk about what steps manufacturers should be performing after they introduce their device to the market. Think about a time you may have purchased an IoT device just to find out that the manufacturer doesn’t help with the longevity or security of the product. No support center. No knowledge portal. No number to call to ask questions.

Better yet, let’s say you buy an IoT camera from RiskyCorp, LLC. A year passes and RiskyCorp has a massive data breach. Their communication with customers is severely lacking. You have no way of contacting them for support, so what do you do?

The “Post-Market” activities defined within NISTIR 8259 intend to reduce these outcomes. In part one,we walked through everything that needs to occur during the development of the device (or pre-market). This is summarized in the following four steps:

  • Activity 1: Identify Expected Customers and Define Expected Use Cases
  • Activity 2: Research Customer Cybersecurity Goals
  • Activity 3: Determine How to Address Customer Goals
  • Activity 4: Plan for Adequate Support for Customer Goals

Let’s pick up where we left off and walk through the fifth activity defined by NISTIR8259.

Activity 5: Define Approaches for Communicating to Customers

Clearly communicating to a broad range of customers can be quite a challenge for manufacturers. The following questions can help an organization develop a plan on how to conquer this challenge:

  1. What terminology will the customer understand?
  2. How much Information will the customer need?

A wide range of consumers interact with devices. These questions help manufacturers tailor their communication approach to a wide audience.

For example, some businesses may decide to provide a comprehensive set of documentation, intended to satisfy a broad set of unique consumers. Others may intend to keep it simple, and error on the side of brevity, to not confuse the reader.

  1. How/where will the information be provided?
  2. How can the integrity of the information be verified?

These questions bring up a great problem that we should consider. A manufacturer may not possess a knowledge portal that can house information. Additionally, how will a given customer ensure that the information they access is accurate? Will the average user be able to verify you are who you are by your website name?

Security of IoT Devices

Activity 6: Define What to Communicate to Customers and How to Communicate It

A manufacturer can communicate to an audience through various mediums.  These subpoints explore what a manufacturer will likely need to consider to understand these options.

4.2.1 Cybersecurity Risk-Related Assumptions

Manufacturers must think of the assumptions they have made. These can occur throughout the design and development of the device, for example:

  1. Who were the expected customers?
    • What happens when a device intended for organizations is used by a home customer?
  2. How was the device intended to be used?
    • What happens when someone uses a baby monitor as a home security solution?
  3. What types of environment would the device be used in?
    • Think of the considerations for a smart fridge in a public location vs. a personal device in someone’s home.
  4. How would responsibilities be shared among the manufacturer, the customer, and others?
    • Should the customer be required to issue patches to the device? Is it reasonable for a home audience to uphold that responsibility?

4.2.2 Support and Lifespan Expectations

Communicate expected lifespans for the device(s). This will help customers plan the length of their use of the device. To figure out what to communicate, consider the following:

  1. How long do you intend to support the device?
  2. When do you intend for device’s end-of-life to occur?
  3. What functionality, if any, will the device have after support ends and at end-of-life?
  4. How can customers report suspected problems with cybersecurity implications, such as software vulnerabilities, to the manufacturer? Will reports be accepted after support ends? Will reports be accepted after end-of-life?

4.2.3 Technical and Non-Technical Means

Expand on how a customer may account for risk. Communicate information about the technical means the device or a related device or service provides. To think about how you should communicate this, answer the following:

  1. Which technical means can be provided?
    • by the device itself (device cybersecurity capabilities)?
    • by a related device?
    • by a manufacturer service or system?
  2. Which technical or non-technical means should the customer provide themselves or consider providing themselves?
  3. How is each of the technical and non-technical means expected to affect cybersecurity risk?

The situation I imagine goes something like this: a critical vulnerability is released for an IoT device I’ve bought. The company who built it had never considered the implications of such a vulnerability, nor how to advise its consumers on how to resolve the vulnerability.

Now I’m stuck without a fix, and likely will turn off the device for good. Not a great outcome, is it?

4.2.4 IoT Device Composition and Capabilities

This topic guides businesses to decrease the likelihood of such a scenario. Effective communication helps customers understand how they can manage their cybersecurity risks. Communication should completely cover the device’s software, firmware, hardware, services, functions, and data types.

This communication is crucial if we expect the customer to address emerging IoT device risk (see 4.2.1 question 4). To find out what is appropriate to communicate, answer the following:

  1. What information do customers need on general cybersecurity-related aspects of the device, including device installation, configuration (including hardening), usage, management, maintenance, and disposal?
  2. What is the potential effect on the device if the cybersecurity configuration is made more restrictive than the secure default?
  3. What inventory-related information do customers need for the device’s internal software and firmware, such as versions, patch status, and known vulnerabilities? Do customers need to be able to access the current inventory on demand?
  4. What information do customers need about the sources of the device’s software, firmware, hardware, and services?
  5. What information do customers need on the device’s operational characteristics so they can adequately secure the device? How should this information be made available?
  6. What functions can the device perform?
  7. What data types can the device collect? What are the identities of all parties (including the manufacturer) that can access that data?
  8. What are the identities of all parties (including the manufacturer) who have access to or any degree of control over the device?

4.2.5 Software and Firmware Updates

Continuing the thought process, this section provides guidance around notifying customers of updates. Manufacturers should help customers address their risk, right?

Communication of useful updates for device software and firmware may be the best way to do this. Useful communication can be achieved through consideration of the following:

  1. Will updates be made available? If so, when will they be released?
  2. Under what circumstances will updates be issued?
  3. Which entity (e.g., customer, manufacturer, third party) is responsible for performing updates? Or can the customer designate which entity will be responsible?
  4. How can customers verify and authenticate updates?
  5. What information should be communicated with each update?

4.2.6 Device Retirement Options

Lastly, it is important to consider that every device will have an end date. Accounting for these questions will ensure that process is as frictionless as possible:

  1. Will customers want to transfer ownership of their devices to another party? If so, what do customers need to do so their user and configuration data on the device and associated systems (e.g., cloud-based services used by the device) are not accessible by the party who assumes ownership?
  2. Will customers want to render their devices inoperable? If so, how can customers do that?

Conclusion

We can only hope that the number of high-profile IoT device exploits will decrease over time. We can only hope that more support is offered to device customers. Do you think adoption of NISTIR 8259 can help? Only time will tell. If you made me guess, I would say the IoT security buzz is far from over.

Share to

Share

Share to

Like our content? Subscribe and stay informed.