Security managers and their organizations are just starting to understand what it takes to keep traditional network-attached devices secure. Servers, desktops, laptops, switches, routers, and even smartphones fall under IT’s security policies and are protected by layered controls. IT’s management of data security naturally extended to writing and enforcing policy on them. Further, there are a plethora of best practices to choose from when constructing a security framework in which traditional devices reside. And so just as we get our balance, a new challenge arises—devices that fall outside our data security policies and existing best practices.
The number of non-IT network-connected devices is rapidly increasing. As organizations find it easier to achieve compliance with non-data related regulations by using automation, and as they learn that they can squeeze a few more dollars into EBIT by automatically adjusting utility use, for example, the demand for these devices is accelerating. However, many security managers may find themselves in conversations in which they either have no idea about the security risks associated with these devices, or in which they are forced to stop money-saving projects because they are not ready to handle the additional controls. In either case, they may find themselves updating their resumes.
What are Non-IT Devices?
Non-IT devices fall into two categories: sensor and control. Sensor devices collect, aggregate, and report status of key elements of the real world. Examples include:
- Security cameras
- Devices that monitor key production events
- Energy meters
Control devices not only monitor real world status, they can also affect it by automatically making changes to it. Examples include:
- Environmental control systems
- Security systems that react to events in real-time
- Temperature controls that maintain heat or cold within acceptable ranges
Devices in these categories are not new to the workplace. What is new is the increasing demand to connect them to the network. The traffic resulting from this connectivity is known as machine to machine (M2M) networking.
Security Concerns
When I first encountered M2M networking, the most obvious security challenge was vendor access to the systems. Access for support is important to ensure continued operation, and sometimes outsourced monitoring, of sensor input. In many cases, vendors will also make adjustments via control devices to maintain environmental or production tolerances within limits defined by the customer.
For example, there are government health regulations covering the temperature of water in dishwashers used in skilled nursing facilities. The long term health care company for which I worked decided that compliance was more probable if the water temperature was monitored at all times. So it contracted with a vendor that specialized in this. The vendor supplied all connections to the dishwashers and to the vendor-supplied PC used to collect the temperature information. However, vendor staff needed access to the system 24/7. This required them having access to our network. We eventually figured this out, but it required weeks of planning, testing, and implementation of a vendor-specific VLAN to allow access to the control systems while blocking access to the rest of the network.
Although the monitoring of water temperature lacks sensitive data, this is not the case with security cameras. At the same health care organization, facility administrators increasingly demanded implementation of network-connected security cameras. In addition to vendor access for maintenance, a new challenge was introduced; the output from cameras had to be stored on the local facility server.
Two major issues immediately arise when taking and storing video. First, HIPAA requires that patient information, including pictures, must be tightly controlled. Second, legal discovery would require searching through or providing all video to the requesting party. We had to work through these issues before allowing implementation.
The Final Word
We can’t stop the increasing use of non-IT devices. Instead, we must prepare to protect them and our network. I recommend starting by writing a policy that governs implementation and use of vendor- or operations-managed, non-IT devices. I found that this helped people understand what they could or could or could not do when selecting a solution. The policy should include management’s expectations regarding anti-malware protection and patch management for the M2M systems.
I also recommend taking another look at your network and security architectures. Make sure you have the necessary walls built between M2M network segments and the rest of the network. For example, non-IT devices and IT devices may have to share the same wires and network components, but they don’t have to ride on the same VLANs.
Tom Olzak on Security 