In my last two blog posts, I covered what Botnet’s are, gave a recent history of Botnets, and talked about the three functions of Botnet’s including infection and propagation, command and control, and specific attack methods.  In today’s blog post, we will discuss why IoT is the next attack vector for Botnet’s and what you can do to mitigate the risk of an attack.

Why All the Focus on IoT?

After the 2016 Mirai attack, although most people realized it was primarily an IoT botnet, they did not consider the full impact of what had occurred. Users can easily conjure an image of ransomware, picturing a big red screen with a skull and cross bones symbol; this type of malware usually resonates more deeply due to the direct impact on users. But IoT threats, while they may not have the same reputation, can cause equal if not more damage.

Malicious cyber players quickly recognized that IoT devices were the perfect avenue for botnet development. IoT removes the need for attackers to trick victims into doing something; if the botnet can infect an IoT device on the network and that device is on the same segment or connected to users on the network, then it can hop from the IoT device to the user’s PC very much like a biological virus can hop from animal to human under the right circumstances. Well-designed botnets do not care about the end points or node specifics, and most have the ability to sit on Linux, a very common IoT operating system (OS), or any other OS such as Windows or even Android and IOS.

There are five broad reasons why IoT is such a high threat:

1. IoT devices are often unknown to the IT administration staff. Statistics show that up to 60% of IT administrators surveyed indicated that they had little or no confidence that they were aware of all IoT devices in their networks. You cannot secure what you are not aware of.
2. Many IoT devices have known vulnerabilities and can be difficult to patch or update. Also, in many instances, IoT devices have firmware levels that often are not addressed in patch or software upgrades.
3. Many IoT devices have default passwords that, even after being changed, will resurface upon reboot due to the issue noted above.
4. Often there is no clear understanding of an IoT device’s defined perimeters of behavior. This can be the case even when the device is known to IT staff. As a result, it becomes very difficult to pick out any unusual behaviors that might point to malware infection.
5. IoT systems are largely heterogenous and might include devices that we might not think of as IoT. For example, everyone would refer to building controls systems or video surveillance as IoT, but few would recognize the IP phone on their desk or the network printer in the corner of the office.

We could go on, but these serve as the major issues to the overall challenge of protecting the IoT environment. Now let’s take a quick look at methods that can be used to address these challenges.

1. Asset inventory and vulnerability assessment

The first step in getting a handle on the challenge is to do an exhaustive inventory of all devices on the network. Some cases may be straightforward, but other environments can require investigation and even manual walkthroughs to identify IoT devices that may have escaped notice. Having an audited Network Access Control (NAC) will give you a starting point, allowing IT administrators to use MAC addresses to get a rough idea of the device’s location. They can then follow up on the device, verify it, and identify it as an asset. This identification should include not only the device and type but the running software revision as well as ownership and purpose.

Once this information has been obtained, vulnerability assessments should be performed as well as investigation into the device software architecture and intended function. If possible, speak to the actual vendor to understand the device’s intention and the normal patterns of communication that should be expected. This will be important information moving forward.

It’s also important to provide awareness education to employees about the risk of bringing personal IoT devices into work. If possible, simply prohibit it or require a device registration process so that all devices can be properly audited.

2. Develop a micro-segmentation strategy for IoT

As pointed out earlier, having different types of IoT devices and users on the same network segment is a bad idea from a security perspective. IoT should always be segmented away from the normal user IT environment, and the least privilege logic should dictate the rule of segmentation design. Put simply, if a device does not require connectivity to a system, then it should not have the potential to connect. In many instances, IoT segments can be totally isolated with no connectivity to the user IT environment in any way. A good example of this is digital signage or television, which is only visual and does not need to be given access to the network otherwise. As a result, there is no need for this system to be directly connected to the enterprise IT environment. Many IoT and even Industrial Control System (ICS) fit into this category. They operate quite well in isolation or with very restricted communication.

In addition to segmentation, IT administrators should communicate with the vendor of the IoT device to understand the normal traffic behavior from the device, as well as a pattern of communication that will result in the required ‘footprint’ of connectivity. This footprint indicates the systems that the device needs to see and communicate with, allowing IT to create a traffic policy and a segmented design. These things can be the same or different. If they are the same, then the segment design is sufficient, and policy can be reduced to access only. In more complex examples, policies may be required to restrict allowed communications from the device in question. This policy must match the normalized communication patterns but deny all others. If this practice is followed diligently, then IoT systems can be effectively isolated from the normal enterprise IT environment and also from each other to prevent machine-to-machine attacks. If you have done everything correctly up to this point, you should have a series of microsegments, each with dedicated IoT systems and normalized known traffic behaviors and policies to match them.

3. Vigilance and analysis

Once a well-segmented, policy-based design is established, the next step is to maintain consistent vigilance of device behaviors within each segment. Remember that while you designed the segment, you took all required traffic patterns into account. As a result, you should have very ‘sanitary’ microsegments with normalized traffic patterns that can be monitored for anomalies or unusual behaviors. When you see unusual behaviors or anomalies, investigate them as soon as possible. Put simply, if you see an IoT device doing something that it has never done before, it is most likely not a good thing. Ideally, the device should be quarantined quickly until further investigation can take place. If an IoT device is mission-critical and always needs to be online, it requires micro-segmentation and established policies of normal behavior.

In Conclusion

While botnets are not new, they have become increasingly sophisticated at an alarming rate and there is no sign that this trend of software evolution will end. While IoT systems have become a new favorite target for ingress and propagation due to the relative weakness of these systems from a security perspective, there are methods to address these challenges. If performed with due diligence, these methods can contribute to the overall security posture of the enterprise in question.

The best advice I can give is to never assume that you are totally secure. While we can prove that a system is not secure by compromising it, we cannot totally prove that a system is not secure by failing in the same.