Securing The Internet of Things (IoT): A Security Model for Interconnected Devices

IoT Security Model

The Internet of Things (IoT)

The Internet of Things (IoT) describes the current and oncoming exponential proliferation of smart devices in every aspect of life. It is exciting and intriguing because it holds the potential to fulfill the promise of improving our quality of life in a way and at a rate without historical precedent. This phenomenon is well documented, and discussions of the economic implications and some tantalizing hints at what is to come, can be found here, here, and here.

IoT includes sensors, controllers, wearables, implants, and actuators that will gather and report data, support remote presence, and otherwise illuminate our world in a way we have never seen before. When combined with Big Data Analytics and Artificial Intelligence (AI), the potential is, without hyberbole, awesome.

There is a dark side to the IoT revolution, however, and it is the tendency of the devices involved to exhibit little or no cybersecurity.  The objective of this article is to define a model to objectively assess device security and clearly communicate it.  Clear insight into device security will allow consumers to compare the relative security strength of similar products.

The Dark Side of IoT

As we rush to understand and inexorably embrace this new era of ubiquitous smart devices, it will result in the explosive growth of devices and inter-connectivity. It is sobering to reflect that our track record on securing networks and the devices that comprise them is not very good, and there are many reasons to think that the situation is about to get a lot worse.

One of the factors driving current network “insecurity” is the complexity of contemporary IT infrastructure. There are often dozens of applications running on platforms comprised themselves of a “stack” of operating systems, middleware, services, and databases. There are hundreds of relevant security factors and no simple way to measure the relative security posture of one device to another, or one network to another. In short, representing the security of complex configurations in a single metric is very challenging.  The news is full of security breaches that are the result of network insecurity.

Although common sense tells us that the security situation will not improve as a consequence of adding large numbers of insecure devices, the one advantage that the IoT revolution brings to the security challenge is simplicity. Many IoT devices are simple in nature and purpose, and this simplicity is simultaneously a blessing and a curse. The simplicity is a curse because IoT devices tend to exhibit weak security features or omit them entirely. The blessing is that the security of simple devices can be evaluated in a straightforward manner.  Thus, we can at least accurately measure and compare the relative security of similar devices.

Measuring the Risk of Interconnected Devices

It is the inherent simplicity of IoT devices that empowers us to objectively measure their relative security; that is, to express their innate resistance to hacking and propensity to exhibit exploitable vulnerabilities in a single metric. It is worthwhile to ponder what factors would be relevant in this regard, and whether a scoring system could be defined to compare the relative “security hardness” of similar devices.

The value of a standardized and objective means to calculate the security “grade” of a device would be profound, as it would inform purchase decisions and empower consumers to express their opinion on the importance of security by “voting with their wallets.” The real value of security in a particular product could be quantified by market-share and price, since an efficient market would presumably reward those vendors  producing affordable products with the features demanded by their customers.

Our objective here is to define such a model for IoT devices.

Security Factors of Interconnected Devices

What does it mean to say that a device is “secure” or not ?  Let’s consider some product characteristics that would lead it to be more or less secure. We must first acknowledge that devices range greatly in purpose and complexity, and that  not all factors necessarily apply to all devices. We put forth the following factors as general-case postulates in order to move toward a standardized risk calculation model. We have organized the factors into categories for clarity.

User Authentication

The following factors relate to the rigor with which a user must identify himself to satisfy the authentication requirements of the device.

  • Authentication: A system that protects administrative features with an authentication mechanism offers more access control than one that does not.
  • 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.
  • Create AccountsA system for which it is possible to create accounts with arbitrary names will frustrate brute-forcing attacks and be more secure than a system with an immutable set of accounts.

Confidentiality

  • 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 CommunicationsThe encryption of communications into and out of the device prevents the exposure of information to unauthorized individuals.

Integrity

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

Reliability

  • Updatable: A system that can be updated to newer software versions will be less likely to contain vulnerabilities that one that contains immutable software.
  • Automated Updates: A product that can be configured to automatically update software when new versions are released will likely be updated more reliably than a product that does not, and therefore will be less likely to contain vulnerabilities.
  • Authenticated Update Server: A product that authenticates the server from which it downloads product software is less likely to be spoofed into downloading and running malicious code.
  • Digitally Signed Downloads: A product that verifies the origin of its software before using it is less likely to be spoofed into running malware than a product that does not perform such verification.
  • 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

  • Information Leakage: A product that does not identify itself (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

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

Accountability

  • Logging: A product that logs access events (logins, logouts, failed logins) facilitates the detection of brute-forcing attempts and can be monitored more diligently than a product that does not produce such logs. Note that for this to be a positive factor, the log produced must not contain sensitive information nor be a potential vector for denial of service.

A Security Model For Interconnected Devices

If we accept the postulates above, we can devise a evaluation model based on the following questions. The questions have been worded so that “yes” answers are indicative of a more secure product. At the risk of initiating great debate (and potentially fisticuffs), we then group the questions into three categories of importance:

Critical

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

Important

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

Valuable

17) Does the product verify downloaded software updates via digital signature?  Yes / No
18) Does the product support any Denial of Service resistance features?  Yes / No
19) Does the product resist physical tampering?  Yes / No

We will assign points to the questions in each category as follows: Critical = 5, Important =2, Valuable = 1, to ensure that each category maintain its ranking despite the quantity of questions it contains.  We find that the maximum possible score is 41, so we can calculate the relative risk for any specific product using the following equation:

Round (Sum of Weighted Answers / 41.0 x 10)

In other words, sum up the weighted answers for a particular product, normalize it, and then adjust it to the nearest integer value between 0 and 10. (Since our product is considered more secure the greater the score, we term the result the product’s “Security Factor”).

The Meaning of a “Security Factor”

The value of having a standard means of measuring product security is that it allows for the relative comparison of similar products. While similar and close valuations may spur debate, there is clearly value in being able to compare similar products with significantly divergent scores. We might even be so bold as to assign an overall security rating to products based on their score:

Security Factor Rating
0-3 Insecure
4-7 Secure
8-10 Highly Secure

Examining the relative weight of the questions in each category, the above will deliver a “Medium” rating if all critical factors are present, while reserving “Strong” for products that are rich in security features.

Our security model can be used as a standard calculation to compare the relative security of comparable devices.

The Aggregate Security of Interconnected Devices

Now that we have have a standard means to measure and express the security hardness of a single device, we can move into considering the security of networks containing such devices.

Using the metaphor that a chain is only as strong as its weakest link, we propose that a network of interconnected devices is only as strong as the Security Rating of its least secure device. That is, a network of interconnected devices exhibits a Security Rating equal to the weakest of those devices.

Security_Rating(Network) = Min (Security_Rating(Device1)… Security_Rating(Devicen) )

The Proliferation of IoT Devices

While you may be comfortable with this measure of your network security profile from the outside, the internal view might be discomforting when we consider the future proliferation of IoT devices.

To facilitate the discussion, it is useful to distinguish “externally exposed” devices from internal ones. Externally exposed devices are understood to be those that are directly accessible through the public network, whereas internal devices are LAN nodes protected from outside view and access by one or more firewalls.

It is reasonable to expect that the number of IoT devices deployed inside the organization (i.e. not “externally exposed”) is likely to be orders of magnitude greater than the number of externally exposed devices, AND that these devices may very well be visible from anywhere within the internal network. Our approach up to this point would suggest that the overall security rating of internal network is a direct function of the (potentially) thousands of IoT devices that will be attached to it.

This should be a “wake-up call” that serves to raise the consciousness of IoT security within the organization, prioritize the consistent purchase of secure IoT equipment, and highlight the critical need to routinely scan the internal network for rogue devices.

Summary

We have presented a security model that can be used to measure and express the relative security of IoT devices and the networks that host them. Widespread adoption of such a standardized model would serve the industry well, as both consumers and vendors will benefit from a common means to compare the security of comparable devices.

Our analysis also is a call to arms regarding the overall security posture networks hosting large numbers of IoT devices, and we have highlighted the need to view network security in a aggregate fashion.

About Affinity IT Security

We hope you found this article to be useful. Affinity IT Security wants to help you strengthen your security testing, and  train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.

Contact us to learn how we can help protect your enterprise with a long term risk-based cybersecurity plan.