In incident response, chaos is your biggest enemy. You’re encountering an adversary in real time, and it’s almost like a chess match. The best way to combat your attacker is to be prepared.
Create an incident response team in your organization, and provide them with training for different scenarios. Document hierarchies, processes, and the tools/equipment you’ll use to identify, contain, and eradicate bad actors. Finally, create checklists to ensure that you don’t miss important steps — which is easy to do when you’re tackling complex problems in a time crunch.
“The thing (check)lists solve for - the beast they tame - is complexity.” – Adam Savage, co-host of every skeptic’s favorite show, “Mythbusters.”
For IoT specifically, preparation is the most important point. Once a device is released into the wild it should, in most cases, be very difficult to monitor, as most means of monitoring on-device activity could also double as attack vectors. The primary point of contact will be where messages are coming into the cloud via the edge, and that is where you need to be prepared to assess and identify attacks/issues and possibly begin taking steps to contain issues.
Know that any plan you build, however, will never be perfect. After every event, incident, or “almost” incident, adjust your plan with the new information you’ve learned. You should also keep an eye on the headlines for new security vulnerabilities and breaches to prevent potential incidents from occurring.
The first step to identifying a threat is to actually look for it. This can present a challenge in embedded systems security, however, because in most cases, you won't have monitoring visibility into what's going on at the edge (either for practical reasons or for security/privacy reasons). You'll be reliant on the reports that come back to the cloud from the edge.
In this case, it's again imperative to be well-prepared beforehand: to know what type of communications and at what cadence you expect to be communicating with the edge (from the cloud) and be able to identify aberrations in those communications.
After identifying the impacted systems during an event, your next step will be to keep the contamination from spreading. Isolation at the edge is critical to contain attacks. Methods of communication should be as limited as possible to reduce your attack surface. All communication should go through the cloud when possible so that you can monitor it.
In addition to these internal actions, you can reduce the incentive for the attacker by sharing your newfound threat intelligence with the IoT community. In all likelihood, you’re not the only victim of this attack. The bad actor is probably creating one piece of code and attacking multiple systems with it. If the attack works on just 5% of those systems, the hacker still gets a huge return. But if the threat is quickly identified and publicized, more companies will block the attack, and it’s no longer economically viable to be “the bad guy.”
You’ve identified the problem and contained it — now, it’s time to get rid of it. In this stage, be sure that you’re targeting the root cause of the problem to avoid causing unnecessary damage to important data and files in your system. In IoT, you might release a patch via OTA, revoke a device’s permission to connect to the cloud, and in some cases going out into the field and collecting devices may be appropriate.
Recovery is an important step to minimize current and future disruption for users and business units. In this phase, you’ll restore your data, reestablish your systems, and return to normal operations.
6. Lessons Learned
At this point, you might be breathlessly taking a seat and wiping the sweat from your forehead. But you’re not quite done yet. Using the documentation you’ve been collecting along the way, go back and do a risk assessment of your environment to understand what can be improved. Additionally, evaluate your response. How does your incident response need to change? What mistakes were made? What went well? Though you always hope there won’t be a next time, being prepared costs less than the alternative.
Incident response in IoT is really all about anticipating what kinds of attacks are going to be possible from your edge Things, and then being prepared to diagnose when an attack is occurring and take appropriate actions.
While the framework provided above is not comprehensive, it provides a solid starting point for responding to IoT security incidents in a way that’s efficient and repeatable, minimizes risk, and doesn’t drive up costs unnecessarily.
Looking for a team that cares about IoT security as much as you do to help you create secure devices and IoT applications? Tell us about your project today.