Enhancing IoT Security with DNS CQF

IoT devices are popping up every second, with many being on an organization’s network but not always under the control of I&O teams. These devices are required to be identified, inventoried, screened, managed and secured in order not to cause any problems to the rest of the IT ecosystem, the users or the organization itself. This requires tooling and processes where the DDI (DNS-DHCP-IPAM) certainly has an important role to play, in particular EfficientIP’s DNS Client Query Filtering (CQF) feature.

We are all using connected devices (generally called IoT) at home or at work. For some, even our watch or our car is an IoT device, and there’s no way to counter this trend. But as is often the case, this global innovation comes with drawbacks including security, data collection and personal life exposure. Whenever an IP device is connected to a network, at home or at the office, in the store or in the factory, data and command exchanges occur. We need to be aware of the criticality of these exchanges, which data is exposed, how it’s manipulated and how it’s stored. For IT people such as us, these are potentially all cause for concern.

IoT devices can be used as attack vectors

Security is an important topic when dealing with IoT. Most of the time the device is selected with unique choice criteria: its functional answer to the problem or the request. Price may not be a real problem since cost per unit can seem low with regards to the proposed service. The industry is now proposing easy platforms to develop IoT and take in charge all the “computer and communication” aspects – the remaining electronic and mechanical parts are being mastered by the various manufacturers. But the cost-effectiveness of these platforms is not only related to the cost of microcontrollers, it is also mostly linked to the low quality of the embedded software, its lack of continuous improvement, testing and maintenance. This is the main reason why an IoT device can be a real threat to the network, as it simplifies its usage as an attack vector or being taken advantage of well known flaws in the integrated software.

As a conservative measure any IoT device using IP as its communication channel should be isolated from the rest of the organization network (it is a bit more complex to do this at home). Applying the Zero Trust Security approach is obvious for IoT, but not always easy to implement. These devices generally do not register on the network, do not authenticate themselves or obtain authorization from an organization component. Their standard networking process is to get access to the network through Ethernet or Wi-Fi – it can also be through a gateway system like a LoRa concentrator – then they obtain an IP address through standard DHCP, resolve the few domain names to get access to their command and control service and they are live. As a user, you see them automatically connected to the service platform and providing data from the sensors or proposing actions to perform.

Security via NAC can be complex and costly

At the network level, we can enforce security with a NAC system (Network Access Control), if well applied with minimum exception this is probably the best approach and it can begin with standard 802.1X solution with a fully open source, internally built platform. But this approach is complex and only affordable to big corporations or security aware/obliged companies. Since most IoT devices are not able to authenticate themselves, this may cause issues with deployment and should be specifically handled.

However, for most organization’s networks security is not enforced with NAC at the network level, even Wi-Fi access still relies on standard pre-shared key authentication. Getting an IoT component plugged onto the corporate network is easy, no need to ask for an I&O operation or support, with a good chance it will work automatically. The next level to pass is obtaining an IP address, by default the IoT will try DHCP as it is standard, omnipresent, convenient and works very well. Once an IP address and related configuration are available, the next step is to start IP communication with the central service that can be inside the organization or on a cloud platform on the Internet. For this step, DNS is the most straightforward solution, and frequently the DNS servers provided in the IP networking configuration by the DHCP are available and able to perform recursion up to the Internet.

DDI automation improves security

As we can see, the DDI solution and especially the services facing the devices (DHCP and DNS) play an important role for any IoT to become online. The IPAM, when tightly coupled with both services, offers global visibility over all the devices connected to the network, the DHCP manages the IP addresses contained in the leases in the corresponding network of the IPAM and the DNS can bring visibility on the resolution through analytics. Therefore, the IPAM solution is also able to make some decisions and automate the network for improving security, this is what we call DDI automation.

Adding filtering and whitelisting via DNS CQF limits IoT exploits

With the DNS Client Query Filtering security solution (CQF), the SOLIDserver brings a new approach to network security. With its ability to apply various security policies to different groups of devices on the network it can greatly help with IoT management. Ideally, IoT requires to be separated from other kinds of devices on the network, the DNS with CQF can isolate these IoT devices into more strict policies of name resolution. To this extent, we recommend applying strict filtering based on an “allow list” (whitelist): any DNS resolution request needs to be for an explicitly known domain to be performed. Far easier to manage than deny lists (blacklists) that are never accurate or up-to-date through reputation management, the allow list is the most simple way to apply security, similar to how we have been performing IP filtering in firewalls for decades now.

By combining all DDI components into a rich automation process we can handle a first level of security for IoT. The DHCP service screens devices when attributing the IP address leases, and informs the IPAM through standard synchronization. The DDI can perform a specific automation to add the IoT device’s IP address into a specific DNS zone used as a client list of the CQF security process. Automatically, the IoT will then only be authorized to resolve names which are known to be safe for the organization’s IoT fleet.

This fully automated process proposed by the SOLIDserver solution limits attacks, exploits and bad behavior of the IoT software embedded in multiple components. With its ability to react quickly and scale up to millions of entries managed, it is capable of handling most IoT situations, even in high density networks such as smart cities, utilities and factories. And without doubt, it will also be useful in much smaller environments where IoTs are more recreational, like connected screens, weather or presence sensors and power relays.