Skip to main content

assurance-class

2.2 Assurance Class

Determining the security objectives across the full diversity of IoT-class applications is a subjective endeavour. Even within vertical sectors such as consumer and enterprise, the security measures and strength of controls will vary depending on the actual use case. In making the Framework more practical across a range of applications, this version has adopted a risk-based approach derived from the commonly used CIA Triad [ref 46]1. Whilst it is not a perfect model, its simplicity is its strength, and good security practice can be derived from the core principles.

Depending on the market and application into which the product is intended to be used, a risk assessment may require a higher assurance class to mitigate the determined level of risk. Consider the following example: a fictional case of a Wi-Fi relay box used in a remote monitoring station, where the threat to the enterprise operation is considered low, could be assessed under Assurance Class 1 requirements. However, when deployed into a hospital, with higher threat dependencies, it could be assessed to be under Assurance Class 4 requirements. A further example is provided in section 2.2.1.

In order to apply an appropriate level of security assurance to a product, the requirements in the Framework are classified using the following assurance classes:

  • Class 0: where compromise to the data generated or loss of control is likely to result in little discernible impact on an individual or organisation

  • Class 1: where compromise to the data generated or loss of control is likely to result in no more than limited impact on an individual or organisation (requirements in ETSI. DCMS, NCSC CoP demand Class 1 at a minimum)

  • Class 2: in addition to class 1, the device is designed to resist attacks on availability that would have significant impact on an individual or organisation or impact many individuals. For example, by limiting operations of an infrastructure to which it is connected

  • Class 3: in addition to class 2, the device is designed to protect sensitive data including Personally identifiable information (PII)

  • Class 4: in addition to class 3, where compromise to the data generated or loss of control have the potential to affect critical infrastructure or cause personal injury

For each assurance class, indicative levels of confidentiality, integrity and availability are shown in Table 1 below.

Security Objective

Assurance ClassConfidentialityIntegrityAvailability
Class 0BasicBasicBasic
Class 1BasicMediumMedium
Class 2MediumMediumHigh
Class 3HighMediumHigh
Class 4HighHighHigh

Table 1: Assurance Class Security Objectives

The definitions of the levels of confidentiality, integrity, and availability are as follows:

  • Confidentiality

    • Basic – devices or services processing public information

    • Medium – devices or services processing sensitive information, including Personally Identifiable Information, whose compromise would have limited impact on an individual or organisation

    • High – devices or services processing very sensitive information, including sensitive personal data whose compromise would have significant impact on an individual or organisation

  • Integrity

    • Basic – devices or services whose compromise could have a minor or negligible impact on an individual or organisation

    • Medium – devices or services whose compromise could have limited impact on an individual or organisation

    • High – devices or services whose compromise could have a significant or catastrophic impact on an individual or organisation

  • Availability

    • Basic – devices or services whose lack of availability would cause minor disruption

    • Medium – devices or services whose lack of availability would have limited impact on an individual or organisation

    • High – devices or services whose lack of availability would have significant impact to an individual or organisation, or impacts many individuals

    [ref 11, 12, 13 & 14 were used as the basis of the above definitions]

Please Note: The Framework Assurance Class is provided for guidance only. A supplier may know of application specific concerns that would change the class values. Requirements deemed “not applicable” must be supported by credible evidence to explain the case.

2.2.1 Determining Security Goals – An Example

To illustrate via a practical example, consider the security features required by a connected thermostat used in a commercial greenhouse. The Assurance Class selection for the device might be determined in the following way:

  • Confidentiality is Basic: the underlying assumption is that the thermostat does not store sensitive, confidential, or personally identifiable information

  • Integrity is Medium: for a thermostat in a commercial greenhouse, poor data integrity could have a business/financial impact

  • Availability is Medium: the thermostat in a commercial greenhouse setting is likely to be part of an environmental control system. As such an individual sensor failure will have little impact, yet a denial- of-service attack across multiple sensors carries a greater commercial risk

In this case, the thermostat may be classified in the following way:

Security Objective

Assurance ClassConfidentialityIntegrityAvailability
Class 1BasicMediumMedium

Table 2: Example of Assurance Class Security Objectives

Footnotes

  1. CIA Triad has no original source, but for more info visit: [ https://www.techrepublic.com/blog/it-security/the-cia-triad]