Device Classes

A device class, or more precisely, a device security class, is a statement of the security requirements for a device in terms of its requirements for Confidentiality, Integrity, and Availability, expressed as LOW, MODERATE or HIGH ratings for each of the three. Within the ITS Architecture, devices are the building blocks for physical objects. So if the devices that implement a physical object collectively meet a given device class, that physical object does as well.

Device security classes are intended to be of use to suppliers of devices and systems for use in C-ITS deployments. A device can only be used to play a role in a particular application if it meets the security requirements of that role; however, higher security requirements will in general translate to more expensive devices. The concept behind the device security class is to develop collections of security requirements which suppliers can develop to, allowing them to provide the most cost-effective solutions that meet the security requirements.

Since there are three security levels, there are potentially 27 (33) different device security classes. In principle, suppliers could develop devices in each of these classes. In practice, there will likely be economies of scale in reducing the number of classes. As such, various analyses have led to the establishment of five device classes:

  1. Every physical object is covered by a device class that matches or exceeds its security requirements
  2. Every physical object is covered by a device class that exceeds its security requirements under no more than two headings

The first property ensures that physical objects meet the security requirements; the second ensures that implementations are not significantly more expensive than necessary, relative to security requirements. Device security classes are intended to be of use to suppliers of devices and systems for use in C-ITS deployments. A device can only be used to play a role in a particular application if it meets the security requirements of that role; however, higher security requirements will in general translate to more expensive devices. The concept behind the device security class is to develop collections of security requirements which suppliers can develop to, allowing them to provide the most cost-effective solutions that meet the security requirements.

There are currently five physical object device security classes defined:

ClassConfidentialityIntegrityAvailabilityDetailed Controls
Class 1LOWMODERATEMODERATEClass 1 controls for CVRSE, ITSRE, Vehicle OBE
Class 2MODERATEMODERATEMODERATEClass 2 controls for CVRSE, ITSRE, Vehicle OBE
Class 3MODERATEHIGHMODERATEClass 3 controls for CVRSE, ITSRE, Vehicle OBE
Class 4HIGHHIGHMODERATEClass 4 controls for CVRSE, ITSRE, Vehicle OBE
Class 5HIGHHIGHHIGHClass 5 controls for CVRSE, ITSRE, Vehicle OBE

Additional information describing how to read and interpret controls is available here. Background material describing the format, use and means to interpret PICS is also available.

These device security classes were derived by analyzing the requirements associated with application-constrained information flows, and then combining those flows at physical object boundaries to determine matching device requirements. While this resulted in roughly one dozen device classes, a more moderate number is desirable to realize economies of scale. While additional classes may be added in the future, these five provide a baseline.

Control documentation is largely sourced from NIST 800-53r4 (revision 5 was not available at the time of the analysis), with the notable exception of privacy-focused content which is based on ISO 15408-2. For the NIST-sourced material, the control definition and supplemental guidance are largely consistent with the NIST source (i.e., limited customization relevant to the V2I environment); all of the content in the Approved Mechanisms and Protocol Implementation Conformance Statements (PICS) sections were created as a result of the analysis and specifically for the V2I environment. For the ISO-sourced controls, all of the material shown here was created as part of the V2I cybersecurity analysis process.

See the Databases page for more information. The key detailed material is in the security database, though the physical database may also be useful when extracting information from the security database