How to Respond to an IoT Security Incident on a Budget

In reality, embedded systems security is a necessary investment. As businesses collect more and more valuable data, they may unwittingly be placing targets on their backs for hackers. Anyone even remotely interested in IoT is sure to have heard of the many instances of security vulnerabilities being discovered in IoT devices. Sometimes, they’re discovered by researchers. But just as often, they’re discovered by malicious actors.

However, there are cost-effective ways to protect IoT devices and respond to security incidents. At Very, we place a lot of emphasis on prevention and reducing your attack surface. But hackers can be like superbugs – adapting quickly to subvert existing protections. Having an incident response plan in place, therefore, is critical.

At the Scenic City Summit 2019 Conference in Chattanooga, Tennessee, Shayne Champion, Chief Information Security Officer at Conversant Group, gave an awesome presentation about how you can prepare your organization to respond to security incidents, using the resources that you already have. Many of the point he examined also apply to IoT security. Check out these tips from his presentation:

Start with the OODA Loop

As you begin creating your incident response strategy, a good place to start is with the OODA loop. You can think of it as the Agile methodology for incident response. Developed by military strategist and United States Air Force Colonel John Boyd, the method outlines four steps to process and react to an adversary:

• Observe: Consider the available information to understand your situation.
• Orient: Seek new information and/or draw from your own experience to understand your options.
• Decide: Build a hypothesis about what you think is the best action with the information given, and make a decision.
• Act: Execute your response, trusting that while likely not perfect, it’s the best action you can take with the information you have in the time allotted. Some action now is frequently better than the “perfect” action later.

OODA is a feed-forward loop rather than a feedback loop, meaning it’s more proactive than reactive – which is exactly what you want during an IoT security breach. You want to minimize opportunities for the hacker to expand their attack, and acting quickly and responsibly is essential. The OODA loop also allows for rapid iteration. Once you’ve completed one loop in response to an incident, you start the loop again as you receive new information/responses from the attacker.

Building Your IoT Incident Response Plan

You’ll use the OODA loop to take you through each step of your incident response plan. Before we go through how to build this plan, though, here’s one important note: throughout this process, make sure you document what’s happening each step of the way – the actions you took, what worked, and what didn’t. This practice will help you stick to the OODA loop in each step so that you can move through the event with maximum efficiency.

Keep in mind that in some situations, where you’ve had to unplug everything from the wall to keep malicious code from spreading, this documentation may not be able to happen electronically. In these scenarios, you might invest a few dollars in a set of easel-sized Post-it Notes, so that your entire incident response team has access to an ongoing visual stream of information. For a slightly higher-tech solution, consider buying a few digital notebooks for situations like these.

Whichever documentation option you choose, designate a scribe ahead of time so that you don’t realize too late that you haven’t been taking important notes and aren’t sure about your next steps.

1. Preparation

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.

2. Identification

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.

3. Containment

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.”

4. Eradication

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.

5. Recovery

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.

Moving Forward

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.