Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Move to secure IoT devices
CHANNEL

Move to secure IoT devices 

There are three ways to address the dismal state of IoT security. Developers could do the right thing and incorporate reasonable security controls. Customers could refuse to buy insecure products. Legislators could step in. California chose door number 3.

California Senate Bill 327, which became law on September 28, 2018, is, while inadequate, a step in the right direction. Many media outlets have reported that it outlaws default passwords, but the actual legislation is broader and less definitive:

“1798.91.04. (a) A manufacturer of a connected device shall equip the device with a reasonable security feature or features that are all of the following: 

(1) Appropriate to the nature and function of the device. 

(2) Appropriate to the information it may collect, contain, or transmit. 

(3) Designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure. 

(b) Subject to all of the requirements of subdivision (a), if a connected device is equipped with a means for authentication outside a local area network, it shall be deemed a reasonable security feature under subdivision (a) if either of the following requirements are met: 

(1) The preprogrammed password is unique to each device manufactured. 

(2) The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.”

While the legislation clearly discourages default passwords, subsection (a) establishes a broad general requirement for reasonable security features, while subsection (b) weakly accepts products without a default password as acceptable. The reference to “authentication outside the local network” makes little sense; even devices intended for use only from the LAN are subject to attack by malware and can be conscripted into botnets large enough to threaten critical infrastructure and national security.

Conspicuously absent from the new California law are provisions to ensure executive accountability. IoT developers face significant pressure to deliver products and software updates quickly. Business owners and corporate officers must accept responsibility for security decisions.

Establishing baseline security requirements for IoT devices is no easy task, but technology savvy California could have done much better. The legislation makes the same mistake commonly found in ineffective corporate policies: It mixes broad high-level requirements with a specific technical requirement. And it does so poorly.

At a high-level, securing IoT devices requires much more than features. Developers must consider security and privacy requirements throughout the product life cycle. This includes making appropriate architecture, design, implementation, test, and documentation decisions.

IoT devices are a broad category, with varying security requirements. Some process and store sensitive personal information, while others only provide small glimpses into the habits of the user. Despite these differences, establishing baseline security requirements is both viable and clearly necessary.

Ideally, stakeholders, including product developers, consumers, security professionals, and governments, would come together to establish a realistic and practical standard. Here are some items it should include:

  • Human safety must be paramount.
  • Product documentation provided to users must explain what information is collected by the device, the sources of the information, how it is used, and where it is sent. This must be sufficiently detailed that a user can understand the data flows, and fully appreciate data exchanged with other devices and servers.
  • Product documentation provided to users must clearly explain how data is protected at rest and in transit.
  • Product development documentation must include security and privacy requirements.
  • Software developers must be trained in secure development practices.
  • Test plans must include positive and negative test cases to verify the correct operation of security functions.
  • A vulnerability scanning tool (commercial or open source) must be used prior to release. Where technically feasible, the test configuration should include a credentialed scan of the operating system.
  • Penetration testing of functionality exposed to the network must be conducted.
  • Product security features must be enabled by default. The product must default to a secure configuration.
  • The end user must be able to restore the device to a secure state, even if it has been compromised.
  • Consent must be obtained before using UPNP or a similar protocols to enable inbound connections from the Internet to the device.
  • With the exception of Internet protocols that do not commonly support encryption, such as DNS and NTP, were technically infeasible, IoT devices must use standards-based encrypted protocols such as current versions of TLS and SSH.
  • Only necessary network services may be exposed.
  • Cryptographic (including hash) algorithms with known security weaknesses must not be used.
  • Cryptographic keys must be a minimum of 128-bit (symmetric), 2048-bit (RSA), or equivalent.
  • Products should require the end user to set a password during initialization. Where this is not feasible, shipping each device with a unique password is acceptable. Default passwords must not be used.
  • Passwords must be salted and hashed in accordance with current best practices.
  • If access is allowed from outside the LAN, multi-factor authentication must be available.
  • An update mechanism must be capable of updating all software components, including any third-party operating system or software. The update mechanism must verify the integrity of updates (for example using a digital signature) prior to installation. When technically feasible, the updates must be automatic, or the customer must be able to choose, with the default being automatic updates.
  • Product end-of-life must be considered and accounted for in the design and implementation.
  • Where technically feasible, the product must produce an audit log that includes all security-relevant events.
  • These requirements apply to the IoT devices as well as any other service, including cloud-based services, that are required to use the device.
  • A qualified security professional should review the product’s design and compliance with these requirements, and prepare a report. An officer of the corporation (or owner if not incorporated) must acknowledge the findings of the report in writing. If a report by a qualified security professional is not produced, the owner or officer must provide a written statement to that effect.
  • All documentation related to these requirements must be retained for a minimum of three years from the sale of the last unit of the product.

A baseline standard backed by legislation would move to secure IoT devices.

Have a security question you’d like answered in a future column? Eric would love to hear from you.

 

Author: Eric Jacksch Email: eric@jacksch.com

Eric Jacksch is a leading cybersecurity analyst with over 20 years of practical security experience. He has consulted to some of the world’s largest banks, governments, automakers, insurance companies and postal organizations. Eric was a regular columnist for Monitor Magazine and has contributed to several other publications.

Related posts

Leave a Reply

Required fields are marked *