X-Frame-Options: DENY

Cybersecurity Principles of IoT v1.0

A note on the term "Device"

For our purposes here, we will consider a “device” as being any standalone embedded system that has integrated wired or wireless communication capabilities.

 

Principle  1

An end-to-end solution is designed, developed, operated and managed per industry-best-practice security and privacy guidelines.

Principle  2

A device has a rating established and identified by its manufacturer using the Device Security Rating System (DSRS) or similar.  

principle  3

Secure SDLC best practices and supporting tools are utilized for all software in the end-to-end solution.

PRINCIPLE  4

Systems and applications in the end-to-end solution are validated with security vulnerability testing prior to production release.

PRINCIPLE  5

To remain in operation, a deployed and functional device has a known and identifiable owner. 

PRINCIPLE  6

To remain in operation, a deployed and functional device always has a known and identifiable operator/maintainer.

PRINCIPLE  7

A device is clearly marked with the short link of its corresponding Device Security Level Agreement (DSLA).  

PRINCIPLE  8

The public vulnerability disclosure contact details are clearly identified on both the manufacturers Device Security Level Agreement (DSLA) page and any solution web sites.

PRINCIPLE  9

The Device Security Level Agreement (DSLA) identifies the public security or safety alerts filed for the device historically to date.

PRINCIPLE  10

The software update support timespan and frequency are clearly identified in the manufacturers Device Security Level Agreement (DSLA) page.

PRINCIPLE  11

All device Industry use classifications except "Consumer" provide a software update support timespan of not less than 6 years from manufacture date.

PRINCIPLE  12

The Device Security Level Agreement (DSLA) for a device identifies the software update mechanism as either Direct-Physical, Remote-Network-Automatic, or Remote-Network-Manual facilitated.

PRINCIPLE  13

The Device Security Level Agreement (DSLA) for a device identifies the firmware versioning history.

PRINCIPLE  14

A device with inbound network services running is supported with remote-network firmware updates by the manufacturer in order to remain in an operational state.

PRINCIPLE  15

A device without a User Interface notification system and without an owner/operator patch notification system implements Remote-Network-Automatic firmware updates.

PRINCIPLE  16

A device with a system classification of "Gateway" implements Remote-Network-Automatic firmware updates.

PRINCIPLE  17

A device storing personal or operationally sensitive information integrates data wipe capabilities into its design and architecture for standard use and decommissioning scenarios.

PRINCIPLE  18

Devices supporting sensitive or safety-critical functions are designed and architected to continue safe and secure operation during communications interruption or failure.

PRINCIPLE  19

A device is designed and architected to protect personal privacy through data collection transparency and anonymization of user activity.

PRINCIPLE  20

A device clearly identifies the collection or processing of personally identifiable data in the Device Support-Level Agreement (DSLA).

PRINCIPLE  21

A device in active use to identify and/or track persons and their activity is overtly identified as such to the public in the devices operating environment.

PRINCIPLE  22

A published Device Security Level Agreement (DSLA) may be updated once initially created provided the change history of material modifications is identified.