An IoT Control Audit Methodology

Never has such an abstract concept of “things” taken to the consumer market so quickly. From printers to thermostats to washing machines and cars, devices are being rushed and fitted with wireless interfaces. Often, this is at the cost of limited quality assurance against real-world conditions. There are frequent reports of Internet of Things (IoT) devices proving to be quite insecure. In the midst of this consumer cycle sit industry professionals, wondering if a new IoT toothbrush follows the need-to-know principle.

A more thorough examination of the components of this interlinked environment yields two common themes for virtually all IoT use cases. First, there is the presence of a solid and simple networking stack on each IoT device. This networking stack is traditionally an implementation of Transmission Control Protocol/Internet Protocol (TCP/IP) and typically a wireless interface. Second, there is a specific consumer business context and purpose of the IoT device. This definition of a specific business process that the IoT device serves traditionally involves user enrollment and sign-up. Based on these two commonalities, this article presents a method for auditing IoT devices.

To capture the necessary business context and governance considerations, this article has augmented the TCP/IP suite model¹ with three additional layers, depicting further levels of abstraction. Those layers have been taken from the US National Institute of Standards and Technology (NIST) Special Publication (SP) 800-39 and focus on the “Organization, Mission and Information System View.” Figure 1 illustrates the augmentation model of TCP/IP with NIST SP 800-39, on which the control audit methodology in this article is based.

As with any control audit, careful consideration needs to be given to the process of selecting the relevant and applicable controls to audit against. With this augmentation model, not only is it possible to categorize each control to a specific layer, but it is possible to also focus on the purpose and environment of use of the actual IoT device. This provides the benefit of technology-specific controls being confined to a particular layer without crossing tier boundaries. There are also disadvantages in using this model for controls that require a more holistic view.

The Method

This method starts by investigating the complete end-to-end use case of the IoT device in question. This should be done while consulting a list of controls from NIST SP 800-53.² Instead of the complete list of more than a thousand controls, for the first step, controls are selected that have been assigned a high (P1) priority.

In reading the P1 control list, “Information System” is replaced with “IoT Device” and “Organization” with either “Environment of Use” or “Manufacturer.” Next, while remembering the purpose and environment of use for the actual IoT device, the controls are enumerated from the NIST SP 800-53, marking as “IoT applicable” as appropriate. This substitution of text also requires rewording specific clauses away from nouns such as “facility” and in and toward the IoT device. Grammar aside, the objective of step one is to obtain a list of IoT-specific controls. Any clauses that are not IoT-specific get dropped.

Step two aims to shorten the list of IoT-applicable controls identified in the previous step. It does so by assigning the respective layer of operation for each control in the augmentation model. This grouping of controls in specific layers means that it is possible to quickly check for overlap and duplication. An overlap between two controls occurs when a partially common control objective is identified, while duplication occurs when a fully common control objective is identified. Based on this layering, when checking for duplicates and overlap, patterns of controls appearing in each layer emerge.

From these patterns, independent of IoT use case, this method shortlists 12 controls. As the analysis of the case studies will demonstrate, two very different use cases yield as important the same set of 12 controls. The authors believe this to be a consequence of the fact that independent of IoT use case, each IoT device has two common things: a TCP/IP stack and a very specific business purpose. Based on substantial testing, figure 2 lists the IoT-applicable controls for any audit using this methodology.

In the third and final step, the lead auditor further customizes the control objective for each of the 12 controls based on the purpose and environment of use of the IoT device. This customization aims to capture any intricacies behind the control objective specific to the IoT use case in question. It also makes the method presented technology-agnostic.

From a control theory perspective, this redefinition, shortlisting and layering of 12 controls from a much larger set allows for the compartmentalization of the audit. For each IoT use case, constantly question the purpose of the IoT device, the manufacturer security requirements and the purpose of operation within the respective environment of use. This leads to a method for auditing IoT devices that differs from current methods.

Comparison to Existing IoT Audit Methods

Most of the present IoT research work for internal audits focuses on risk vs. business considerations.^{3, 4} The risk and value considerations are summarized through nine questions⁵ to ask to improve IoT risk management. This approach is similar to the audit methodology against 12 questions presented herein, but it does start with a wider set of controls from which to choose. What is more, the questions are not ordered in any particular way. Auditors are sometimes expected to be IoT advisers, providing assurance against new risk.⁶ This has similarity with the lead auditor in the methodology customizing the control objective based on the specific IoT use case in question.

Other techniques focus on IoT data usage.⁷ This article looks at data collection, data ownership, custodial responsibility, data retention. As much as the focus is administrative, physical and technical, there is no clear compartmentalization beyond the data to the actual linkage of the processes behind each data usage step.

Of note is also the Open Web Application Security Project (OWASP) IoT project,⁸ including the traditional OWASP list of top 10 technical risk factors related to IoT. Interestingly, the list roughly corresponds with the controls listed for the first four layers of the method presented herein. Little focus is given to the information system, the business process or environment of use of the IoT device.

Case Studies

Two very different case studies illustrate the wide range of application of this method. These are the use case of monitoring vitals of players during a stadium football match and the misuse by malicious attackers of IoT devices accrued in home networks for a distributed denial of service (DDoS) attack. What follows is a brief description of each use case, based on which the lead auditor is asked to customize the control objective for each control. Figure 3 summarizes for each respective use case what the 12 controls to audit against would be.

Monitoring Football Player Vitals

For the first use case, players of a football team, each equipped with a battery-powered IoT device in their clothing, are to play in a stadium match. Members of the medical staff of each team want to monitor the vital statistics for each player. The manufacturer providing the IoT devices has been given clear requirements that only the medical team on the ground inside the stadium should have access to the data from each IoT device. The medical team of the opposition, the manufacturer or any other party must not be able to access these data. Finally, the purpose of these data will be to answer any queries on performance and substitution decisions that the coaching staff might have. The coaching staff may ask questions of the medical team about player performance.

The column “Control for Monitoring Football Player Vitals” in figure 3 summarizes the 12 customized control objectives based on the purpose and environment of use for the players of the football team. Starting from IoT-1, not only is the importance of the device being tamper-resistant emphasized but so is the requirement of capturing physical access logs. For IoT-1, the subjective nature of the lead auditor can lead to slightly different control objectives in, for example, the statement, “The manufacturer has separate control access via a dedicated secret device component.” This could have also been customized to be, “The manufacturer has separate control access via an over-the-air dedicated channel,” or simply, “The manufacturer has separate control access.”

Despite being a criticism of the methodology discussed in later sections, such a control objective customization will not yield inconsistent results.

For IoT-1, the manufacturer would have to provide a separate control access mechanism to the IoT device. If the manufacturer cannot achieve this via the method specified in the previous customization, they would be asked to explain how they achieve this control objective for the physical access control layer.

For IoT-3, there is a new definition of boundary protection, specific for this audit: Each IoT device may only communicate with the devices of fellow team members and those of the medical team. Controls IoT-5, IoT-7 and IoT-9 affirm what is expected to happen when the device goes missing and how the actions of the manufacturer configuring the device differ from those of the medical team using it.

In terms of scope coverage, it is critical to question whether or not there are any specific gaps leading to the disclosure of vital statistics for each player. This is why this article uses the seven layers of the augmentation model of TCP/IP and NIST SP 800-53. It starts by trying to identify how well defined the security plan of the manufacturer is (IoT-12). Next, there are two controls around the business process definition (IoT-11) and system security plan (IoT-10). As one zooms in toward the physical IoT device, there is a minimum of a single control in each layer. Thus, it is this layering of controls that allows auditors to conclude that they have achieved sufficient scope coverage.

Misusing IoT Home Devices for DDoS Attacks

For the second use case, many consumers have purchased a number of IoT devices to use in their homes. Each IoT device requires an online user registration step, followed by an enrollment step. It also transmits data back to the manufacturer’s IoT cloud platform services. The manufacturer has been given clear requirements to limit the type of data gathered. For, say, light bulbs, only the on-off states with the respective hue, saturation and brightness data should be transmitted. For kettles, only the on-off states with the respective amount of water available to boil should be transmitted. Finally, the purpose of these data being transmitted is to provide feedback and allow consumer operations, e.g., from their mobile phone. In the same way that one consumer within the home can access these data, other members of the home could also register and enroll to operate each IoT device.

This case study assumes that a very specific threat has materialized. Malicious attackers have accrued command and control over IoT devices and are using them to launch DDoS attacks. The reason for choosing to examine the specific threat is to move the focus to how IoT devices can be further misused with or without the knowledge of the consumer. As with any audit, the materialization of this threat does not imply a change of approach in the audit. The column Control for Misusing IoT Home Devices for DDoS Attacks in figure 3 shows if it is possible to prevent this attack by setting accurate control objectives.

Starting from IoT-1, it is possible to see how the focus of the control objective has been customized for the home environment of use. As it is not cost-effective, a home IoT device would be handed back to the manufacturer not for maintenance but for recall. Changing the cryptographic keys would require an over-the-air update and, as such, a requirement that the manufacturer has an over-the-air separate control access channel.

Controls IoT-2 and IoT-3, if implemented correctly, would stop the malicious attacker from misusing IoT home devices for DDoS attacks. In the case of IoT-3, a simple requirement surfaces from the control objective: that the IoT device only communicates to the manufacturer’s IoT cloud platform/services. Configuring the IoT device to only connect to the manufacturer’s IoT cloud platform/services would stop any misuse for DDoS in its tracks.

Control IoT-4 would safeguard against IoT device impersonation and IoT device spoofing attacks. IoT-5 would define how any collaborative computing controls would be implemented in the case of, for example, other devices connecting directly to a phone when on the same home network.

IoT-6 and IoT-8 would prevent the planting of malware required for commanding and controlling a DDoS attack. IoT-7 would help control and manage the account used to set up vs. the account used to administer the device. While not interested in protecting data at rest in a home, IoT-9 would become very important in the event of recycling or selling the device.

Finally, IoT-10 to IoT-12 would give consumers a measure of the maturity that the manufacturer has toward protecting data. Above and beyond any marketing material for the IoT device, reviewing any information about how frequently a manufacturer releases patches to their devices reveals a great deal about how serious they are about their security program and business processes.

In the control objectives for the two use cases investigated, there are commonalities. These include ensuring in IoT-5 that connections are denied by default and in IoT-7 that threatening or unknown outgoing traffic is restricted. This can be done by making sure the IoT device only communicates with the manufacturer’s designated infrastructure. Figure 3 also shows the importance in both cases of IoT-8 implementing least functionality. The security processes and support the manufacturer is actively putting behind the end product, something of a common question mark in today’s consumer world, are the focus of IoT-11 and IoT-12.

Method Critique and Disadvantages

This audit method suffers when dealing with controls that span multiple layers. As an example, consider IoT devices that support Internet Protocol Security. Using such a network-based encryption protocol would imply a control objective similar, if not identical, across layers 1–4. Ultimately, this will not likely be a problem for the augmentation model, as it means fewer layers against which to audit. Still, controls that require a more holistic view would suffer from the compartmentalization and layering that this method offers.

A second critique is in the subjective process by which specific controls are customized based on the purpose and environment of use for the actual device. The first use case showed how lead auditors can describe how they expect the manufacturer to have a separate control access to the IoT device. If a manufacturer was not able to demonstrate the specific control access mechanism, a separate way in which they achieve that control would be expected.

A third critique looks at the number of controls shortlisted. Why not eight instead of 12 controls; why not 16? The number of specific controls (12) presents a mutually exclusive set for which nonoverlapping control objectives can be set. These 12 controls provide a collectively exhaustive set of controls that does not leave any gaps in the layers. Of course, more controls can be added to each of the layers, based on industry sector, data confidentiality or similar further deep-dives into the use case for the IoT device.

Conclusion

This article presented a method for setting the control objectives for 12 controls. Despite the very different use cases, there are commonalities in the objectives and importance of the selected controls. To derive these 12 controls, a much larger set has been used, namely that of NIST SP 800-53. A simple augmentation model was applied to layer these 12 controls. At this stage, further work is required to determine if the list of 12 controls can be considered complete.

Based on the use cases presented, this audit methodology serves as a sufficient baseline to perform a complete audit. An IoT device that would pass such an audit is yet to be identified, and the standard set is not particularly high. If, as the IoT industry evolves, gaps are identified, more controls can be added to the method as required.

Following further analysis, if this method were presented as consistent and complete, it could be used to standardize how a consumer would be expected to be informed on the risk posture of the IoT device they are purchasing. Imagine being interested in an IoT device and picking it up in a shop. On the back would be 12 rows with the equivalent of, say, “red-yellow-green” status. Each row would represent a control depicting how an independent third party has audited this IoT device and the processes the manufacturer has to support it. This would have a lot of similarities with energy consumption currently present for most household appliances.

Instead of measuring power consumed, such a labeling scheme for IoT devices would focus on controls present. Each control would be measured based on its defined control objective for the specific layer of operation. This could follow a scheme similar to the energy efficiency class labels currently used in domestic appliances. For IoT, try and hack that.

Endnotes

¹ Internet Engineering Task Force, “Requirements for Internet Hosts—Communication Layers,” October 1989, https://tools.ietf.org/html/rfc1122
² National Institute of Standards and Technology, “Security and Privacy Controls for Federal Information Systems and Organizations,” NIST SP 800-53 Revision 4, USA, April 2013, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
³ ISACA, “Internet of Things: Risk and Value Considerations,” January 2015
⁴ Salman, S.; “Auditing the Internet of Things,” Internal Auditor, 29 October 2015, https://iaonline.theiia.org/2015/auditing-the-internet-of-things
⁵ Op. cit, ISACA
⁶ Op. cit, Salman
⁷ Protiviti, The Internet of Things: What Is It and Why Should Internal Audit Care?, 2016, https://www.protiviti.com/sites/default/files/united_states/insights/internal-audit-and-the-internet-of-things-whitepaper-protiviti.pdf
⁸ Open Web Application Security Project, “OWASP Internet of Things Project,” https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project