Creating security controls for IoT devices at Microsoft

|

A businesswoman using a phone in a family room.
The Internet of Things (IoT) is a network of cloud-connected devices that collect and exchange data. At Microsoft, we’re addressing the unique challenges of securely managing Internet of Things devices by performing comprehensive risk assessments and creating mitigation strategies.

Microsoft Digital technical storiesMicrosoft Digital Employee Experience (MDEE) is building an integrated security controls strategy for Internet of Things (IoT) devices that interact with corporate data or that help ensure human life safety. The IoT consists of all the connected devices that can collect and process data. It represents a new and evolving landscape, in which technology is further integrated into our personal and work environments, driving productivity, efficiency, and convenience.

As technology continues to evolve, groups across Microsoft are using the IoT to automate monitoring, work tasks, and accessing information. The IoT provides efficiency and convenience at Microsoft campuses by automating conference room devices, monitoring datacenters, monitoring and controlling smart building systems, and interacting with HoloLens devices. Other segments at Microsoft, including manufacturing, sales, and retail, use solutions that are built on IoT devices. Many employees regularly use the IoT outside of work for home appliances and smart vehicles.

Our cloud-only future has new rules, including anything that can be connected, will be connected. We are designing security controls and practices to address the sheer number of devices and security paradigm shifts that come with moving our business assets to the intelligent cloud, using the intelligent edge and its millions of IoT devices.

Circular illustration of the many devices on outer edge circle, Intelligent edge; Intelligent cloud in center of circle.
Millions of devices make up the intelligent edge and interact with the intelligent cloud.

Business challenge

Things are moving fast; the IoT industry is growing and evolving. There are thousands of different devices and manufacturers, which causes some industry-wide concerns about whether IoT devices can be managed securely and reliably. Our traditional methods for securing devices and data were based on the assumptions that devices can be monitored, information can be encrypted, and the flow of data could be monitored by human oversight. IoT devices often have no intelligence of their own and constantly collect and process small amounts of data, which makes them difficult to monitor.

Implementing IoT security controls

We have not yet implemented a dedicated tracking system for all IoT efforts at Microsoft, but we are working closely with known IoT initiatives, including:

  • Automated meetings with Microsoft Graph and Surface Hub.
  • Beacon devices in Microsoft facilities that offer peer geolocation information.
  • Proximity-based meeting booking.
  • Beacon-based asset tracking.
  • Smart parking.
  • Facility monitoring and optimization.

We are creating comprehensive use cases that define the risks, impacts, and probability for each threat.

Defining enterprise scenario risk levels

We define and document threats and risks for each type of device, and we use the scope of impact to define the enterprise risk level for each enterprise scenario. A simple IoT sensor that can detect a person might be used to turn up the lighting in a walkway—it could also be used by a rescue and response team to find people in a disaster. Even the simplest sensor can be used in a critical scenario, so we needed to develop a strategy to help us define high-risk scenarios and how we can implement controls and policies to help mitigate risks. Appendix A contains a more comprehensive list of some known threats and our mitigation strategies.

High-risk enterprise scenarios

We decided to focus on establishing a standard and baseline set of controls high-risk enterprise scenarios first. These scenarios represent our core business functions. Any loss of these systems would have a substantial impact on the daily operation and business interest of the company. Other high-risk enterprise scenarios include the loss or misuse of devices that could result in physical harm to people, property, or equipment. For high-risk scenarios, we use the highest level of controls, including:

  • IoT sensors that monitor or manipulate Highly Confidential resources should be classified as Highly Confidential and be treated appropriately.
  • If the resource can affect the physical environment in a way that could harm a person, that resource should be classified as Highly Confidential and be treated appropriately.
  • Information about the health and status of critical infrastructure, including employee health and welfare, should be trustworthy and reliable.
  • Devices should be registered in a central location so that they can be assessed for security vulnerabilities, updated, tracked, and placed in a controlled physical environment to minimize the potential for tampering.
  • These devices need a device management solution, via a gateway device, in the event a sensor is unable to function.
  • Sensor integrity should be ensured by encrypted communications and verified by redundant backup sensors or other nearby devices, if possible.
  • All devices must be linked to an owner to help assure accountability.
  • Business needs and risks must be evaluated to decide if a device should connect via the internet or be segregated in a separate network.
  • Devices should be logically separated to prevent device vulnerabilities from affecting the company’s main data processing services and information.
  • All network communication should be device-initiated and outbound to minimize potential malicious interference.

Medium-risk enterprise scenarios

We are developing more medium-risk enterprise scenarios as we become more reliant on IoT data for planning, modeling, and developing app features. Compromise or loss of this type of data can lead to tangible business impacts. For medium-risk scenarios, we established recommendations for information security, including:

  • Many of these devices have limited processing power and the ability to authenticate, monitor, patch, and control them directly is severely limited.
  • No high-risk data should be generated, moved, or stored on these IoT solutions.
  • These devices should connect to resources via Azure.
  • IoT devices should be regulated via a trusted gateway device that can be managed in a traditional sense and connect to Azure IoT for data storage and access to corporate resources.
  • Extra care needs to be taken to calibrate and validate data from medium-risk devices to ensure that interference (malicious or accidental) can be detected and remediated.

Low-risk enterprise solutions

While controls and mechanisms should be put in place for low-risk scenarios, they are not the focus of our IoT security standards. These items present minimal risk if they are rendered unusable. Low-risk IoT devices should not have substantial business efforts built upon their availability or data. For low-risk scenarios, we established recommendations for information security, including:

  • At Microsoft, any IoT scenario that falls into this category should connect to corporate resources (with appropriate control mechanism) via Azure.
  • No Microsoft classified data (Highly Confidential, Confidential, or General) should be generated, moved, or stored on these devices.
  • The ability to encrypt, wipe, or revoke security certificates should be applied to all devices that are deployed in areas where physical security is not ensured.

Classifying IoT devices

To help us manage the diversity of IoT devices, we have settled on a few different ways to classify them, starting with how much we know about the device and how it works.

  • Black box. The function of the device is understood. We can view the device in terms of its inputs and outputs (or transfer characteristics), and its function is understood, without any knowledge of its internal workings The OS, software, and security features are also unknown. One example in our enterprise scenario includes datacenter sensors and conference room devices.
  • White box. We know how the devices is built, what operating system and software it is running, and its security features are known. Examples include HoloLens, a Surface Hub, or a Raspberry Pi running an operating system.

Based on hardware capabilities, we identify the “smartness” of each device and classify it into one of four categories:

  • Sensors. Sensors alone do not have computing capacity. These are basic units that provide data to a smarter device that can process the data.
  • Devices with firmware. These devices have firmware and can provide basic computing power. They aggregate data from sensors and pass it on to smarter devices. These devices act as gateways.
  • Devices with firmware and an operating system. These are smart devices that have computing power. These devices typically run an operating system, have storage, and connect to other network services.
  • Field gateways. These are software-based components that reside on devices with firmware and an operating system. They act as gateways for the sensors by collecting data from sensors and sending that data to services, such as Azure IoT.

Designing security standards and control procedures

We are working to help ensure that developers follow best practices or guidance for building secure solutions while we work on developing specific guidance for securing IoT devices or management consoles. We are developing security standards and control procedures that will be embedded into current and future IoT projects. Until the efforts to publish our IoT standards and policies are complete, we are using additional baseline activities, including:

  • Least functionality. Reduce the device’s attack surface by reducing the number of applications, daemons, and services or ports that operate on a device to only those that are required for basic operation.
  • Least privilege. Grant only the minimum required access for people accomplish their tasks—and no more. Administrative access (root) must only be granted on a just-in-time
  • Authorization and access control. Configure all systems to ensure that only authorized personnel can access the system. Configure all systems to ensure that only authorized personnel can access assets according to their permissions level.
  • Auditing. Ensure all important systems events are securely logged into an authorized log collection system.
  • Network security. Eliminate unnecessary network protocols or restrict server networking functionality to eliminate possible attack vectors. Systems must not route to and from the corporate network or connect any private network to a public network for inbound or outbound packets. Devices must not provide network relay or proxy services to other devices using technologies such as dual homing or connection sharing.
  • Data handling. All data must be classified and handled appropriately. IoT devices must comply with privacy requirements and controls for the collection, use, and sharing of personal information. Data collected should only have a business purpose and be limited in scope and be necessary for solution functionality.
  • Device hardening. To ensure firmware integrity, devices should be updated, encrypted, and have intrusion detection and antimalware configured.
  • Management: A management solution should be used to centrally manage IoT devices

Key Takeaways

As the importance of the IoT expands in the corporate environment, so does the need to expand and improve our security mechanisms. At Microsoft, we’re continuing to work internally and with our partners to develop better controls that will help address some of the risks that the IoT presents. Ongoing efforts to expand and improve our IoT baselines will ensure adherence to the practices outlined above.

Internally, we’re expanding our efforts to generate and maintain a comprehensive asset inventory of IoT devices. We are coupling this effort with work related to our Supplier Solution Security Program that will help us manage the onboarding and procurement of secure IoT devices. This data will help us better understand the impact IoT has on our network and allow us to better respond to future incidents or risks.

Additionally, network segmentation efforts are underway to help protect high-risk IoT implementations from informational works and non-critical devices.  This network management ability can help is better monitor critical resources and turn off non-essential connections and protocols.

As the IoT continues to accelerate and businesses realize the immense benefits, the next breakthrough capability from Microsoft will enable IoT devices to evolve—bringing intelligence to the edge. While the benefits of edge intelligence are exciting, it will pose new challenges in the way we develop, deploy, and manage IoT devices in a secure and scalable way.

Microsoft Azure IoT Edge was introduced recently, and it brings together ways to help us extend our existing IoT gateway offering. Azure IoT Edge will help make the secure distribution of cloud intelligence easier.

Related links

Appendix A: Known threats and mitigations

 

Resource Threat Mitigations
Sensor Firmware Firmware + OS, Field Gateways
On device data, asset loss Lost or stolen device Physical security Encryption of data-at-rest, physical security, password/pin policy Encryption of data-at-rest, screen lockout policy, password policy, physical security
On device data Lost or stolen hard drive Physical security Encryption of data-at-rest Encryption of data-at-rest
Removable media Lost and stolen media Physical security Encryption of data-at-rest Encryption of data-at-rest
Removable media Malware transport N/A N/A AM/AV, Disable Autorun
Corporate credentials Malware N/A DNS/URL/IP blacklisting AM/AV, device hardening
Corporate credentials App spoofing N/A DNS/URL/IP blacklisting App whitelisting
Device ransom, online ad theft, credential theft, data theft Malware N/A Patching, DNS/URL/IP blacklisting Anti-malware,
jail break detection and reversal, patching,
application black listing,
DNS/URL/IP blacklisting
Accidental data exfiltration User saves to insecure site N/A Data-in-transit DLP Data-in-transit DLP
Accidental data deletion Delete of network master  N/A N/A Backup where applicable
Terminated employee Credentials not terminated upon end of employment N/A N/A Domain credentials required, blocking inbound remote access tools (such as LogMeIn, TeamViewer), application blacklisting, 802.1x (Wireless Auth), JIT access where applicable
Terminated employee 48-hour delay before credentials are invalid N/A N/A Remove where supported: Email sync, O365 access, remote access, RMS protected docs access,
Domain logins to devices disabled in AD/AAD
Malicious SDK/firmware Bad code in dev base Evaluation of device/firmware Evaluation of device/firmware Hardware rooted trust, evaluation of firmware/device, code signing, secure boot
Device Tampering of device Physical security Capability to detect new sensors/devices that are connected Capability to detect new sensors/devices that are connected
Data Loss of data in transit between sensor and controller Encryption of data-in-transit Capability to detect new sensors/devices that are connected Capability to detect new sensors/devices that are connected
Data Loss of data in transit between controller and services N/A Encryption of data-in-transit Encryption of data-in-transit
Device Fake sensor Physical security Capability to detect new sensors/devices that are connected Capability to detect new sensors/devices that are connected
Device Fake device N/A Physical security Physical security
Data External factors contributing to falsified sensor readings Physical security, quality control  N/A N/A

 

Recent