Have you ever heard of the Cullinan diamond? If you haven’t, it was the largest diamond ever discovered: a 3106 carat diamond found in 1905 in South Africa. What’s interesting about the Cullinan diamond (at least to me) isn’t so much the discovery of the stone itself but what happened afterward: specifically, the cutting of the diamond.
The Cullinan diamond was split into a number of smaller pieces — nine large pieces and dozens of smaller ones — by Joseph Asscher, a noted diamond cutter of the time. The story goes that the cutting of the diamond required six months of preparation and study, and that the first attempt actually caused the blade he was using to shatter. After more preparation, he attempted a second strike and sealed the deal, actually fainting with exhaustion and stress once the deed was accomplished.
The reason I’m bringing this up is that it’s a pretty good metaphor for what can sometimes happen in security: Diamond is one of the hardest materials on Earth, right? Yet if hit in exactly the right place with the right amount of force, it will splinter, like so much glass. Understanding ahead of time not only that it will splinter but exactly where and how is not only possible — it’s a necessary part of the diamond-cutting process. It’s arguably the primary skill that separates a skilled diamond cutter from an unskilled one.
Security programs are very similar in some respects. There are weak areas that any security program will have — this is true universally, even though the specifics vary from program to program and company to company. Like a diamond cutter, our ability to do our job well rests in part on understanding where those weak spots are, and being alert for the specific situations that will press against them.
This is one reason why it’s so important for security pros to pay attention to the Internet of Things. IoT represents an area of pressure — and the adoption dynamics are such that they may apply that pressure directly against a known weak point in many security programs. Understanding why this is the case — and preparing for it now — can make quite a bit of difference down the road.
IoT and the Field Office
To understand what’s going on, it’s important to consider some of the adoption dynamics of IoT. The first thing to note about it is that it’s moving very quickly. As a proof point of that, ISACA’s 2014 Risk/Reward Barometer found that 43 percent of enterprises either have or expect to create plans for IoT within the next 12 months. The second point is that it’s a source of security challenge: The same survey found that almost half (49 percent) of respondents cited “increased security threats” as the biggest challenge associated with IoT adoption.
So we have a widespread, fast-moving pattern of adoption with known security challenges. That’s interesting, but not exactly unprecedented. The same might be said about cloud, virtualization, big data, or any number of other technology trends. The difference is clear, though, when we start to think through how and where those things interact with our programs — specifically, when we start to unpack what happens when previously “dumb” devices start to come with network and computing elements built in.
Given the adoption dynamics, this is likely to happen quickly. For example, new vehicles that a sales office might purchase to support their sales people in the field increasingly will be IP-connected as they come with navigation and other smart features. In workplaces, things like fire alarms, smoke detectors, and thermostats will become network-aware. Appliances like refrigerators, coffee machines, and conference room TVs will more likely come stock with these features.
In large, geographically distributed enterprises, network management at remote locations has been challenging for a long time. Among them are brick-and-mortar retailer stores, organizations with regional field or sales offices, healthcare providers (smaller affiliated clinics), or any other operation that might have multiple smaller locations in play — potentially without an IT staff presence. Is it possible that users on those networks might attempt to attach a network-capable device? Would they tell you about it if they did?
All that said, there are shops out there that have processes or technologies in place to disallow unknown hosts from attaching to the network (e.g. 802.1X). However, as we all probably know from years of trying to prevent rogue access points, unauthorized cable modems and DSL routers, unauthorized personal equipment, etc. — keeping tabs on devices in remote locations is hard. That’s before we need to start worrying about whether the thermostat has been patched or whether the TV in the conference room has been taken over by an attacker.
Time to Prepare
A wave of smart devices coming into the environment en masse — impacting an area that we struggle with already — would lead us to intuit that a challenge is coming. Still, it’s not all doom and gloom: It also gives us some time to prepare. The first and most obvious step we can take is to revisit technologies, procedures and controls that we already have in place to prevent unauthorized devices from attaching to the network — both at our larger central locations and in far-flung ones. Do we have a technical mechanism in place to prevent rogue devices? Is it in place everywhere? Is there a way for people to bypass or circumvent it?
The second thing that we can do is to take stock of mechanisms that we have in place to discover devices. Do we do routine vulnerability scanning? If so, are we leveraging that data to detect and investigate unexpected devices? If not, do we have asset management, inventorying, network discovery, or other related tools that we can optionally use for this purpose? The point here isn’t to say that we must use any particular tool — just that we need to have some mechanism to identify unexpected devices should they appear on the network.
The last thing we can do is to build out a process for what to do with those devices when they’re found. What is the mechanism for establishing an inventory? Who will be responsible for ensuring that they’re patched and that they’re monitored by existing network controls? Who will track to see if there are security vulnerabilities that impact them, and remediate them if there are? These are all relevant questions that should be discussed beforehand.
At the end of the day, the goal isn’t to panic; instead, by recognizing that there could be challenges that haven’t materialized yet, we can take steps to minimize them and lay the groundwork so we have an answer. Like a diamond-cutter whose craft is at its peak, we can anticipate the blow that’s coming, evaluate the impact it will have, and — if we don’t like what we foresee — take steps now to change the outcome.
Loading ...
