A Security Rating Model for the Internet of Things (IoT)

Securing the Internet of Things (IoT)

Overview

The Internet of Things (IoT) is upon us and continues to promise astonishing growth, as sensors and actuators of every sort become ubiquitous in both our professional and personal lives.

In this article we acknowledge the coming wave and all of its glorified benefits and disruptive potential, and also examine the history and future of the security of such devices.

We elaborate the need for a simple and standard means by which to evaluate the relative security strength of IoT devices, and we propose a specific evaluation model to do so.

Our article concludes with a proposal and solicitation to conduct such evaluations for IoT products and discusses how this is mutually beneficial to vendors and consumers alike.

The Internet of Things (IoT)

Internet of Things (IoT)

According to Wikipedia, the Internet of Things describes networkable devices, from the simple to the complex, that collect, interact, and share data. This includes every conceivable type of electronic and electro-mechanical device such as cameras, thermostats, actuators, “wearables,” and appliances. In fact, much of the excitement surrounding the IoT is the prospect of interconnecting historically dumb and isolated devices, along with the means to remotely monitor and control them.

IoT Security

Internet of Things Security
IoT Security Has Not Historically Been Strong

As Forbes Magazine states, the IoT revolution is well underway, with the deployment of simple interconnected devices projected to grow at an exponential rate. This exciting news shadows a dark secret, however, that is not uncommon in emerging technologies, namely that the security of these newly interconnected devices is often weak or non-existent.

In the rush to market, and in a desire to reach the largest market possible, manufacturers prioritize simplicity over complexity, and seek to minimize the cost of their devices. Oftentimes, this means that security is considered a luxury rather than a necessity, and security features are omitted by design. This bias is furthered by the perception that IoT devices are often deployed on the “inside” of the network and are therefore at less risk than those directly accessible through the internet.

Certainly, high-end expensive components such as robots and complex systems will be found to exhibit strong security features, but lower-end market-entry devices typically will not. This is particularly important when we consider that a network most often contains a full spectrum of devices, and it is only as secure as its weakest node.

This will inevitably change as the marketplace matures and new products become available that offer more price/feature choices along the spectrum of industrial and consumer needs. Devices with security features will become available at price-points that reflect consumers’ willingness to pay for them. As we will argue later, this will be expedited by a clear means of understanding the security features inherent in such devices – clarity that is lacking in today’s marketplace.

We counter those forces inhibiting the development of secure devices with the realization that networks of interconnected devices are only as secure as their weakest node. This has significant security implications as the number of nodes in a network increases, which is exactly what the IoT revolution promises.

Evaluating Device Security

Internet of Things (IoT) Security
How To Compare IoT Device Security?

We will frame our proposal for a means to evaluate the relative security posture of interconnected devices as a set of characteristics that any device may or may not fulfill, with the pre-supposition that certain characteristics lead to more secure devices.

To establish the basis of our evaluation criteria, we put forth the following postulates, organized into categories relevant to security. None are expected to be perceived as controversial, but this elaboration will give us a common foundation for our later presentation of criteria. In short, if we agree on the following, then the evaluation criteria naturally follow.

User Authentication

This category describes factors relevant to access control – in other words, features to ensure that access, configuration, and use are limited to authorized parties.

  • Authentication: A system that protects administrative features with an authentication mechanism offers more access control than one that does not.
  • Strong Passwords: The stronger the passwords associated with accounts, the more difficult they are to guess, increasing confidence in the authentication process.
  • Brute-Force Protection: The existence of countermeasures that defeat or inhibit automated login attacks decrease the chances of unauthorized access.
  • Authentication Factors: More authentication factors incorporated into the authentication process decrease the chances of unauthorized access.
  • Account Creation: A system for which it is possible to create accounts with arbitrary names will frustrate brute-forcing attacks and preserve accountability better than a system with an immutable set of accounts.

Confidentiality

This category describes factors relevant to the protection of sensitive information and the control of a remote device.

  • Encrypted Storage: A device that encrypts the information it stores poses less risk of unauthorized access to sensitive information if it is stolen or compromised.
  • Encrypted Communications: The encryption of communications into and out of a device prevents the exposure of information to unauthorized individuals.

Integrity

This category describes factors that ensure the collective trustworthiness of the network and devices that comprise it.

  • Component Authentication: Products that trust one another or other systems without authentication are not as secure as systems that require mutual authentication.

Reliability

This category describes factors that relate to the degree to which a device protects itself from hostile interactions.

  • Resistance to Logical Tampering: A product that validates inputs and fails securely when presented with malformed or malicious input is less likely to be compromised than one that does not.
  • Resistance to Physical Tampering: A product that inhibits access to sensitive information through a tamper-resistant enclosure is more secure that one that does not.

Resilience

This category describes factors relevant to preserving the ongoing operations of the device.

  • Information Leakage: A product that does not identify itself (i.e. make, model, software version) through non-administrative means is less likely to be compromised via known vulnerabilities than one that does not.
  • Denial of Service: A product that resists attempts to degrade its performance through misuse is considered more secure than one that does not.

Management

This category describes factors that preserve the integrity of installing, configuring, and controlling a remote device.

  • Secure Administrative Connections: A product that protects the confidentiality of administrative connections is less likely to be compromised than one that does not.

Accountability

This category describes factors that promote the integrity of access control through logs and monitoring.

  • Logging: A product that logs access events (i.e. logins, logouts, failed logins, etc.) facilitates the detection of brute-forcing attempts and can be monitored more diligently than a product that does not produce such logs.


A Security Evaluation Model for IoT Devices

IoT Security Evaluation Model

If we grant that the above postulates are sound, then we can use them to define specific criteria that devices may satisfy that make them more secure and less likely to be compromised.

Ideally, we seek a means to calculate a security “rating” or “factor” rather than a “pass/fail” formula, because of the vast diversity of devices and deployment environments. In other words, it is not reasonable to award a single passing or failing grade to a device, because what might be acceptable in one use case might be unacceptable in another. This approach also acknowledges the reality that device security is itself a spectrum from “insecure” to “highly secure,” with various products occupying points along the way. A rating system that illuminates where any product sits on that spectrum will lead to more efficient marketplace in which cost and benefit of security features can be accurately assessed.

It must also be acknowledged that not all criteria may be applicable to all devices. For example, not all devices store information, and so criteria pertaining to the encryption of data in storage are not relevant. A flexible rating mechanism must gracefully account for such variations among diverse devices without penalizing them for lacking irrelevant features.

Lastly, as the alert reader may have surmised, not all security features are of equivalent benefit. Simply put, some add more security value than others. This phenomenon must be realized in whatever security rating model is employed.

In the remainder of this section, we define specific prioritized binary (i.e. yes/no) criteria that reflect our earlier postulates and with which we will calculate security ratings for IoT devices. Note that the presentation order is by priority, not in accordance with the postulates listed earlier.

Critical Criteria

1) Does the product require a login to access administrative features?
2) Does the product enforce strong password requirements?
3) Is it possible to easily update the product software?
4) Does the product support automated software updates?
5) Does the product validate and reject unacceptable input?
6) Does the product support secure administrative access?
7) Does the product fail securely ?

Important Criteria

8) Does the product feature anti-robot brute-force protection?
9) Does the product support multi-factor (i.e. > 1) authentication?
10) Does the product allow administrative accounts to be created?
11) Does the product allow the default administrative accounts to be removed or disabled?
12) Does the product encrypt the information that it stores?
13) Does the product encrypt its communications with other devices?
14) Does the product authenticate other devices and components it interacts with?
15) Does the product authenticate the update server?
16) Does the product fully redact its make, model, and software version in non-administrative communications?
17) Does the product securely log access events?

Valuable Criteria

18) Does the product verify downloaded software updates via digital signature?
19) Does the product feature any Denial of Service (DoS) resistance features?
20) Does the product resist physical tampering?

Calculating a Score

Each of the criteria has been expressed as a closed question designed to produce a “yes” or “no” answer. Furthermore, the questions have been consistently framed such that “yes” answers are indicative of a more secure product.

In order to reflect the priorities we defined above, the scoring is simply the sum of positive answers, weighted as follows:

  • Critical Criteria: 5 points for each positive answer
  • Important Criteria: 2 points for each positive answer
  • Valuable Criteria: 1 point for each positive answer

The mathematically inclined reader will notice that this weighting scheme results in a maximum possible score of 58. To normalize the result between 0 and 10, our formula becomes:

Round (Sum of Weighted Answers / 58.0 X 10)

We finish by classifying the resulting score using the following bands:

  • 0 – 4 Insecure
  • 5 – 7 Secure
  • 8 – 10 Highly Secure

Considerations

IoT Security Model Considerations

This section discusses some of the decisions inherent in the approach and both acknowledges and makes explicit the subjective nature of developing a model for this purpose. To once again summarize our goals, we seek to:

  • Define a standard and objective means to evaluate and classify the security posture of IoT devices
  • Craft a simple presentation of security ratings that can aid consumers in the procurement process of such devices

Clearly there is no single best model to accomplish these goals. Based upon a reasonable set of assertions about the relative security of network devices (i.e. our postulates), we have defined a prioritized list of evaluation criteria, a formula for calculating a security rating, and a classification scheme to resolve the final score into one of three ratings. We will consider each of them in turn.

The aggregation of criteria into the three priority categories (Critical, Important, Valuable) reflects our best judgment at this time regarding the relative value of various security features in contribution to the device’s overall defensive posture. This categorization is admittedly subjective, and because it is directly reflected in the weightings used in the formula, it is the most significant design aspect of the evaluation model. Changes in this regard will have substantive impact on the values produced by the model and must be carefully considered.

Let’s first acknowledge the subjective nature of some of the criteria. For example, the method rewards “strong password policy” without defining specific requirements. A similar example would be the ability to “easily” update the software associated with the device being evaluated. This lack of specificity is deliberate, intended to leave some interpretation of the criteria to the discretion of testing organization, and to be explained in the test notes, reports, and other collateral produced by the evaluation process. It is expected that this will allow testing organizations to distinguish themselves, as well as provide some future-proofing of the method as technologies continue to mature.

Regarding the formula and weightings, a quick review will show that the weighting of the criteria is contrived to ensure a “Secure” rating if all “Critical” factors are satisfied, while reserving the more desirable “Highly Secure” rating for products rich in security features. Criteria that do not apply are simply ignored, retaining a level playing field for competing products. In cases where competing products differ in their feature set, the approach rewards the security-oriented product.

The coercion of the numeric score into one of three categories (Insecure, Secure, Highly Secure) is done to simplify the rating scheme for the non-technical public. Consumers should see that devices with slight (non-material) differences in their security features should be rated similarly, while those with vast differences or lacking critical protections should exhibit different ratings.

Lastly, this is version 1.0 of the standard, and enhancements will no doubt be forthcoming as the method is employed and matures. Ratings and reports should contain a reference to the version of the standard used to avoid confusion in this regard.

Use Cases

Consumer Products

It is not difficult to envision a confused customer, standing in the aisle of the local office-supply store with two webcams in their hands, struggling to make an intelligent decision as to which one to buy. One aspect of that decision might be the relative security strength of the products, especially in cases in which the technology, feature sets, and price are largely comparable.

Let us further imagine that one of the products is clearly labeled with a security certified rating of “Highly Secure” from a well-known and respected security rating firm. This might facilitate the consumer’s decision, reduce their security risk, and reward the product’s manufacturer and vendor with the sale of the more secure product.

Note that while some customers might be satisfied with the rating alone, others might want to compare the actual numeric scores between products, and still others might review the evaluation report online detailing the specific criteria underlying the rating. All of this could be done in the store and at the time of purchase.

Industrial Control Systems (ICS)

In this scenario, we might find procurement staff in engineering firms seeking to fulfill material lists for engineering projects, either choosing the more secure products or searching for devices that meet the stipulated security rating requirements. Part of the diligence process in selecting devices might very well include some minimal security rating.

Alternatively, engineers would architect solutions based not only on their performance and cost, but also on their security profile. Device manufacturers would find themselves at a disadvantage by being silent on their device’s security features and corresponding rating.

In short, the ICS world is full of examples in which there is mutual advantage for solution providers and manufacturers to specify, demonstrate, and market their security-oriented features of their products and solutions. Our earlier recognition of the fact that any network is only as secure as its weakest component applies directly here.

Conclusion

The value of a standard evaluation and rating mechanism for the security of technical devices would be a significant innovation under any circumstances. When viewed in the context of the rapidly changing Internet of Things marketplace, it becomes essential. To that end, we have developed the “Security Model for IoT Devices” (version 1.0) with the vision that it will be valuable to device designers, vendors, and consumers.

We urge IoT device manufacturers to expedite incorporating security ratings into their product development and marketing plans.

About Affinity IT Security

Affinity IT Security is a security consulting firm that helps clients secure their networks, products, and software. We would welcome the opportunity to assist your security testing and conduct the security rating process for your products.

Contact us at info@affinity-it.com to discuss how we can add value to your development and marketing efforts as an independent security testing partner.