Written by: Mike Parkin, Technical Marketing Engineer – Malware targeting IoT devices is nothing new. There have been some reasonably famous, or infamous, depending on your perspective, IoT targeted malware incidents. An April article on ZDNetby Danny Palmer, on the Triton malware attack in late 2017, highlights the lessons organizations should take away from the incident. He makes some good points, and there are lessons there that apply to securing more than just the IoT space.
For some systems, there are simple process and procedure changes that can significantly reduce exposure and make compromise a lot less likely. That was the case with Triton. A few key security failures made the compromise possible. Also, the Triton attack was going after some highly specific targets.
Unfortunately, IoT devices can be notoriously difficult to secure, and simple fixes won’t be available for every potential threat. You can’t always isolate them or keep them safely locked away. Fortunately, there is a technique that can help secure IoT and SCADA devices in a diverse and connected environment and that technique relies on deception.
One of the challenges with putting security on IoT devices, namely their limited capabilities and computing power, makes them an ideal candidate to defend with deception. In practice, most attacks targeting IoT devices start at the controller rather than the devices themselves. However, most controllers are built on Linux or Windows servers, so creating decoys for them is straightforward. But even when attacks go after the IoT devices themselves, which several high-profile attacks have, they are easy to protect with decoys.
When an attacker engages with the decoy controllers or devices, the deception platform sends an alert, and the incident response team can start to contain the attack and remediate affected devices. That allows a response time that’s far better than the FireEye estimated year of dwell time the Triton attackers had at another site.
With rare exceptions, the final target is not an attacker’s first stop. Realistically, they will have to get into the environment and move laterally across it to reach their targets. This applies whether they are going after IoT or SCADA devices as they were in Triton case, or they’re trying to reach intellectual property, financial records, source code, or something else entirely. The fact that an attacker will need to move laterally is another reason to add deception to the security stack.
With deception in place, an organization is much more likely to detect and stop an attacker long before they reach that final goal. The adversaries have repeatedly shown that they can bypass perimeter security controls to enter the environment, and this is why detecting and disrupting their lateral movement so important. Whether it’s early in the cycle while they look for targets, or when they’re homing in on the final goal, a way to reliably see and disrupt their activity is vital. That’s what deception does. It clouds an attacker’s vision making their job much more difficult. When they can’t tell whether devices, services, or even stolen credentials, are real, their chances of reaching their goal goes down dramatically while the defender’s chances of seeing and stopping them go up.
Attacks like Triton are only going to get more frequent and more sophisticated. Changing the rules with deception shifts the advantage back to the defender, so when the bad guys get more devious and sophisticated, the good guys are already a step ahead.