CommLaw Monitor https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor News and analysis from Kelley Drye’s communications practice group Wed, 27 Nov 2024 10:32:35 -0500 60 hourly 1 Securing IoT Devices (Part 2): Inside the NIST Guidance Document for IoT Device Manufacturers https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor/securing-iot-devices-part-2-inside-the-nist-guidance-document-for-iot-device-manufacturers https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor/securing-iot-devices-part-2-inside-the-nist-guidance-document-for-iot-device-manufacturers Thu, 22 Aug 2019 11:27:44 -0400 At the end of July, the National Institute for Standards and Technology (“NIST”) released draft cybersecurity guidance for IoT device manufacturers. The document, titled Core Cybersecurity Feature Baseline for Securable IoT Devices: A Starting Point for IoT Device Manufacturers, is intended, according to NIST, identify the cybersecurity features that IoT devices should have “to make them at least minimally securable by the individuals and organizations who acquire and use them.” The NIST document is not a rule or requirement for IoT devices, but rather is a continuation of NIST’s effort to foster the development and application of voluntary standards, guidelines, and related tools to improve the cybersecurity of connected devices.

NIST is seeking comment on the document through September 30 of this year and it held a workshop in August for interested parties to discuss the document. In a prior post, I blogged on takeaways from that workshop. Now, it’s time to take a closer look at the NIST document itself.

Overview of the Baseline

The NIST Baseline (“NISTIR 8259” in government-speak) is subtitled “A Starting Point for IoT Device Manufacturers,” and it is intended as just that. NISTIR 8259 builds upon a base document released in final form on June 27, 2019 relating to cybersecurity and privacy risks for the Internet of Things. IoT manufacturers should review NIST’s Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks before digging into the Baseline document. Considerations (also known as NISTIR 8228) identifies high-level considerations that make IoT security different than IT security and offers suggestions for mitigating cybersecurity and privacy risks. Its intended audience primarily are the users and organizations deploying IoT devices, but it has meaning for manufacturers, network operators and service providers in the space as well.

The NIST Baseline takes these considerations to the manufacturing side, offering (as NIST describes it) to help IoT device manufacturers “understand the cybersecurity risks their customers face” so IoT devices can provide the minimal features to make them securable. (For a discussion of the different meanings that “securable devices” can have in this context, see my blog post on the NIST workshop.)

Securing IoT Devices

The NIST Baseline explains that cybersecurity risks for IoT devices have two high-level risk mitigation goals: protecting device security and protecting data security. As noted in the user-focused Considerations document, the challenges in doing so stem from three features of the Internet of Things:

  1. IoT devices interact with the physical world in ways conventional IT devices usually do not. (In other words, they are, by their nature, connected devices.);
  2. Many IoT devices cannot be accessed, managed, or monitored in the same ways conventional IT devices can; and
  3. The availability, efficiency, and effectiveness of cybersecurity features are often different for IoT devices than conventional IT devices.
The NIST Baseline focuses on a generic customer to define the “core” baseline features. The draft notes that manufacturers may need to identify and implement additional features beyond the core baseline that are most appropriate for customers of their particular devices and applications, and offers information on how manufacturers can do this.

For the “core,” NIST identifies six features that IoT devices should address:

  1. Device Identification. How the IoT device can be uniquely identified, both logically and physically.
  2. Device Configuration. How the device’s software and firmware can be changed and who is authorized to make such changes.
  3. Data Protection. How the device can protect from unauthorized access and modification the data that it stores and transmits.
  4. Logical Access to Interfaces. How the device can limit (logical) access to its local and network interfaces so that only authorized users may access these elements.
  5. Software and Firmware Updates. How the device can be updated by authorized entities only, using a secure and configurable mechanism.
  6. Cybersecurity Event Logging. How the device can log cybersecurity events and make the logs accessible to authorized entities only.
For each core feature, the NIST Baseline identifies, in table form, the key elements to consider, the rationale for the feature and several reference documents that may be helpful in addressing the feature. In keeping with NIST’s limited role, the Baseline focuses on the “what” that needs to be addressed, not on the “how” manufacturers should address it.

Separate from the core features, the NIST Baseline also discusses two areas relevant to securing IoT devices. First, it discusses considerations for implementation of these features in the design and manufacturing process. Second, it discusses considerations in communicating these features and the cybersecurity risks of IoT devices to the manufacturer’s customers and users of the device (users who may not necessarily have been the ones to purchase or configure the device).

Issues for Comment

Unlike FCC or FTC notices seeking comment, the NIST Baseline does not provide specific questions or issues for comment. Instead, the Baseline simply seeks feedback from all stakeholders on the draft, in order to assist NIST in refining the document.

The NIST workshop that I attended offers some insight into the comment areas that NIST would find helpful. In the discussion group sessions, NIST first asked whether the six core features were sufficient, and whether any other considerations should be added to the list. My group spent a lot of time discussing the relationship between the Baseline and efforts to create industry-specific standards or best practices. NIST seemed very interested in determining whether the Baseline would serve as a useful starting point for those efforts.

Second, the discussion group was asked whether customer communication should be a core feature or a separate consideration (as in the draft now). This seemed to focus on the role that shared responsibility among manufacturers, users, control organizations (like a corporate IT group) and/or the government played in securing devices (or making them securable).

Finally, our discussion group was asked about two potential additions to the Baseline. First, we were asked whether considerations in protecting legacy devices in an IoT network should be added. This question raised the issue of the role a single IoT device plays in a larger network, such as a smart home configuration where multiple devices (potentially from multiple manufacturers) are controlled by a central hub device. Second, we were asked whether exterior threats to the devices, such a DDoS attack or botnet attacks, should be part of the Baseline.

Any and all of the above should be fair game for comment to NIST on the Baseline. Comments on the NIST draft may be submitted through September 30. Kelley Drye is working with device manufacturers on potential comments to NIST. If you are interested in submitting comments, please feel free to contact us.

]]>
FCC Extends Review of E-Reader Coalition Petition https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor/fcc-extends-review-of-e-reader-coalition-petition https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor/fcc-extends-review-of-e-reader-coalition-petition Wed, 23 Oct 2013 14:09:26 -0400 Kelley Drye Telecommunications paralegal Jennifer Rodden contributed to this post.

Earlier this year, a coalition of e-reader manufacturers (Amazon, Kobo and Sony Electronics) petitioned for waiver from the disabled access requirements applicable to Advanced Communications Services (“ACS”) under the 21st Century Communications and Video Accessibility Act of 2010 (“CVAA”). The Coalition seeks a class waiver from the accessibility requirements for e-readers, such as Kindles, on the grounds that such devices are designed, marketed and used primarily for reading and not for ACS, although they may include some simple browsing and messaging capabilities (e.g., to email documents for viewing on the e-reader). Several consumer groups opposed the petition, and the matter was under consideration when the federal government shutdown commenced.

On October 22, 2013, the Consumer & Government Affairs Bureau of the FCC extended its review of the petition. It did so by granting a temporary waiver – until January 28, 2014 – for compliance with its ACS rules to a class of e-reader equipment. The waiver noted that over the next three months, the Consumer and Governmental Affairs Bureau would further evaluate the primary purpose of the e-reader equipment in question and examine the product life cycle of such e-readers to determine the appropriate duration of any further waiver, should it be granted.

The waiver applies only to e-reader devices that: (1) have no LCD screen; (2) have no camera; (3) are not offered or shipped to consumers with built-in ACS client applications, though the devices may include a browser and social media applications; and (4) are marketed to consumers as reading devices and promotional material does not advertise the capability to access ACS.

]]>
FCC Continues to Enforce Transfer of Control Violations https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor/fcc-continues-to-enforce-transfer-of-control-violations https://www.kelleydrye.com/viewpoints/blogs/commlaw-monitor/fcc-continues-to-enforce-transfer-of-control-violations Wed, 24 Jul 2013 10:04:58 -0400 On July 17th, the FCC adopted a consent decree entered into between the Enforcement Bureau and AccessLine Communications Corporation, a facilities-based and resold long distance carrier holding domestic and international Section 214 authority. The consent decree, which resolved an investigation into alleged unauthorized transfers of control by AccessLine and its parent, Telanetix, is but the latest in a continuing series of such enforcement actions. As we have discussed here previously (see, e.g., December 12, 2011 International Carrier Settles Transfer of Control Violations with FCC), these episodes remind carriers of the importance of monitoring all transactions which may result in a change of their ownership (whether substantial or pro forma) to ensure that required FCC approvals are obtained before consummation.

This recent consent decree addresses allegations that in 2010, without obtaining prior FCC approvals, Telanetix entered into a security purchase agreement which transferred control of Telanetix, and indirect control of AccessLine, to a third party. AccessLine and Telanetix filed applications for approval of the change in ownership in early 2013 and approvals issued from the Wireline Competition Bureau and International Bureau in March. Shortly thereafter, the Enforcement Bureau issued a Letter of Inquiry regarding the transaction. Under the terms of the resulting consent decree, AccessLine is required to implement an internal compliance regimen focused on compliance with Section 214 obligations. In addition, AccessLine will make a voluntary contribution of $16,000, reflecting the base FCC penalty for two violations, respectively, of domestic and international Section 214 transfer of control approval obligations (as well as several associated FCC Rules). The adopting order and consent decree are provided in the attached links.

]]>