Last updated at Wed, 27 Sep 2017 17:44:47 GMT
This blog post was written by Bob Rudis, Chief Security Data Scientist and Deral Heiland, Research Lead.
Organizations have been participating in the “Internet of Things” (IoT) for years, long before marketers put this new three-letter acronym together. HVAC monitoring/control, badge access, video surveillance systems and more all have had IP connectivity for ages. Today, more systems, processes and (for lack of a more precise word) gizmos are being connected to enterprise networks that fit into this IoT category. Some deliberately; some not.
As organizations continue down the path of adoption of IoT solutions into their environments they are faced with a number of hard questions, and in some ways they may not always know what those questions are. In an attempt to help them avoid falling into a potentially deep and hazardous IoT pit, we've put together a few key questions that may help adopters better embrace and secure IoT technology within their organizations.
- What's already there?
- Do we really need this? (i.e. making the business case for IoT)
- How does it connect and communicate (both internally and externally)?
- How is it accessed and controlled? (i.e. is there an “app for that” and who has access)
- What is the classification of the data? ( i.e. data handled and processed by IoT)
- Can we monitor and maintain these IoT devices?
- What are the failure modes? (i.e. what breaks if it breaks?)
- How does it fit in our threat models? (i.e. what is the impact if compromised?)
What's already there?
This should be the first question. If you can't answer it right now, you need to work with your teams to inventory what's out there. By default, these devices are on your network, so you should be able to use your network scanner to find and inventory them. Work with your vendor to ensure they have support for identifying IoT devices.
Short of that, work with your procurement teams to see what products have been purchased that may have an IoT component. You should be able to do this by vendor or device name (you may need to look on the itemized purchase orders). Put out a call to action to your department peers to see what they may have deployed without your knowing that may not have shown on the books. Building/campus maintenance and security, app development, and system/app/network architecture departments are good places to start.
Do we really need this?
Let's face it, these “things” are pretty cool and many of them are highly useful. It's much more efficient being able to deploy cameras or control environmental systems within a building or campus by using modern network protocols and spiffy apps. But, do you really need internet-enabled lights, televisions, and desktop assistants? Yeah, we're looking at you, Alexa. The novelty effect of IoT should make “why” the first question you ask when considering investing in new “things," quickly followed by “what value does this bring to our organization”. If the answers do not meet the standards your organization has identified, then you should probably curb your IoT enthusiasm for a bit or consider deploying the technology in an isolated environment, with strong access controls to limit or prevent connectivity to the organizations internal systems.
There are good business cases for IoT: increased efficiency, cost reduction, service/feature enhancements and more. You may even be in a situation where the “cool factor” is needed to attract new employees or customers. Only you know what meets the threshold of “need."
How does it connect and communicate?
There are many aspects to the concept of “communication” in IoT. Does it connect to the LAN, Wi-Fi network and/or 3G/4G for access/control? Does it employ ZigBee, Bluetooth or other low-power and/or mesh network features for distributed or direct communications? Does it use encryption for all, some or any communications? Can it work behind an authenticated proxy server or does it require a direct internet connection? What protocols does it use for communication?
Most of these are standard questions on any new technology adoption within an organization. One issue with communications and IoT devices is that their makers tend to not have enterprise deployments in mind and the vast majority require direct internet connections, communicate without encryption and use new, low-power communication technologies to transmit data and control commands in clear text.
An advertised feature of many IoT devices is that they store your data in “the cloud." Every question you currently ask about cloud deployments in your organization apply to IoT devices. The cloud connection and internal connection effectively make these “things” a custom data router from your network to some other network. Once you enable that connection, there's almost nothing stopping it from going the other way. Be wary of sacrificing control for “cool."
To get answers to these questions, don't just trust the manufacturer. Hold your own Proof of Concept deployment in controlled environments and monitor all communications as you change settings. Your regulatory requirements or just internal policy requirements may make the use of many IoT devices impossible without filing an exception and accepting the risks associated with the deployment.
How is it accessed and controlled?
IoT is often advertised as a plug-and-play technology. This means the builders tried to remove as much friction as possible from deployments to drive up adoption. This focus on ease-of-use is aimed at casual consumers but many IoT devices have no “enterprise” counterpart. That is, you deploy the same exact devices in the same exact way both “at home” and “at work”. This means many devices will have no password or use only a simple static password versus more detailed or elaborate controls that you are used to in an enterprise. The vast majority have no concept of or support for two-factor or multi-factor authentication. If you think access control is weak, most have no concept of encryption when it comes to any communication channel. If the built-in controls do not conform with your standard requirements consider isolating the “management” side within a separate network - if that's possible.
IoT device access is often done through a mobile app or web (internet) console. How are these mechanisms secured? How is the authentication and/or data secured in transit and on disk? Again, all the cloud service questions you already ask are valid here and you should be wary of relaxing standards without significant benefits.
What is the classification of the data?
Another key action to perform when deciding on implementing an IoT solution is to examine the data that is gathered and stored by these devices. By reviewing the data and properly classifying it within defined categories, we can better approach how the data gathered, transmitted, and stored within our environment. This will also help us make better informed decisions when we are faced with IoT technologies that store data in the cloud, or ones that also transmit voice and video information to the cloud. Data classification policy and procedures are important to all businesses to assure that all data is being properly handled within the organization. If you do not have such a practice it is highly recommended that one is developed and that IoT data is included in those policy and procedures.
The Department of Energy—in conjunction with Sandia National Labs—has put together a guide to developing a Security Framework for Control System Data Classification and Protection[1] that can help you get started when applying data classification strategies to your own Internet of Things.
Can we monitor and maintain these IoT devices?
Unlike servers, routers, switches and firewalls, IoT makers tend to sacrifice manageability for the ability to pack in cool features. The idea of monitoring is a notice when a device fails to phone home or fails to upload data in a preset time interval. Expecting to use SNMP or an ssh connection to gain management telemetry should not be an assumption you make lightly. Verify and test management options before committing to a solution.
Patch management is also a critical concern when dealing with IoT technology. In this case we have to consider the full ecosystem of the IoT solution deployed, which could include the control hardware firmware, sensor hardware firmware, server software, and associated mobile application software. Ensuring that all segments are included in a comprehensive patch management solution can be difficult. Based on the IoT technology deployed, there may not be vendor automation patching available. If this is the case then a self-managed solution will need to be implemented.
What are the failure modes?
Often overlooked when considering the deployment of any technology but specially with IoT, what happens if the technology fails to operate correctly? Can the business proceed without these services when failure leads to security breakdown or loss of critical data? If so, then it is important that we identify methods to mitigate or reduce the impact of these failures, which may include introducing needed redundancies.
If you have no current process in place to analyze failure modes, a great place to start is by using a cyber-oriented failure mode and effect analysis (FMEA) framework[2] or something like Open FAIR[3] (factor analysis of information risk). Both enable you to quantify outcomes of scenarios and helps combat the urge to “make a gut call” on when considering the possible negative outcomes from IoT deployments.
How does it fit within our threat models?
This question needs to be asked in tandem with the failure modes investigation. No system or device sits in isolation on your network, and attackers use the interconnectedness of systems to move laterally and find points of exposure to work from. You should be threat modeling your proposed IoT deployments the same way you do everything else. Look at where it lives, what lives around it and what it does (including the data it transmits and what else it connects to, especially externally). Map out this graph to make sure it fits in within the parameters of your current threat models and expand them only if you absolutely have to.
The Internet of Things holds much promise, profit, and progress but with that comes real risk and tangible exposure. We should not be afraid to embrace this technology, but should do so in the safest and most secure ways possible. We hope these questions help you better risk assess IoT you already have and will be adopting.
[1] Security Framework for Control System Data Classification and Protection: http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/21-Security_Framewor k_for_Data_Class.pdf
[2] Christoph Schmittner, Thomas Gruber, Peter Puschner, and Erwin Schoitsch. 2014. Security Application of Failure Mode and Effect Analysis (FMEA). In Proceedings of the 33rd International Conference on Computer Safety, Reliability, and Security - Volume 8666 (SAFECOMP 2014), Andrea Bondavalli and Felicita Di Giandomenico (Eds.), Vol. 8666. Springer-Verlag New York, Inc., New York, NY, USA, 310-325. DOI=http://dx.doi.org/10.1007/978-3-319-10506-2_21
[3] The OpenFAIR body of knowledge: http://www.opengroup.org/subjectareas/security/risk