Traditional EDR solutions struggle to protect mobile devices due to network dependencies, OS limitations, and real-time detection gaps — requiring a shift to adaptive security models.
When it comes to endpoint detection and response, most enterprises think of desktop agents that monitor and quarantine endpoint activity. Because mobile devices constantly shift between Wi-Fi, cellular data, and other networks, they are tricky to monitor and protect. If malware or a virus attacks a mobile device or any other wireless device used within the organisation while it isn't connected to the same network as a desktop computer, the risk becomes undetectable.
Having visibility into all endpoints is essential to any effective endpoint security strategy. If a device can't be seen, you can't protect it. And while numerous EDR vendors claim to offer the answers businesses need in this sphere, most of them fall short of their promises. Traditional EDR solutions often prove ineffective in protecting mobile devices due to the various limitations inherent in their solution architectures.
How traditional endpoint detection and response works
Traditional EDR solutions, built on the agent model, deploy a client application on each endpoint device — laptop, server or mobile. The agent continuously scans the device for malicious activity, sending the collected data to a central server via an outbound connection. If the agent doesn't find any suspicious activity, it sends a "no alarm" report to the server. The server then compares the "no alarm" reports from each device with its own "alarm" reports, looking for similarities. If the server finds an alarm report that matches a "no alarm" report from a device, it concludes the device is infected and proceeds to quarantine it.
Limitations in EDR solution architecture
The agent model architecture has inherent limitations that cause significant problems in detecting malicious mobile activity.
Traditional EDR solutions require all devices in the network to be connected to a central server. When a mobile device is not connected to the same network as a laptop or desktop, it cannot be detected or quarantined by the solution. This problem becomes apparent in environments where employees shift between networks — such as between office and home. A user may connect a mobile device to a home network the EDR solution cannot access. If malware is present on the mobile device, it will not be detected and will be able to replicate and spread within the organisation.
Network-based detection relies on IP address, port numbers, and protocol information to locate devices. This is problematic since mobile devices often switch between networks depending on their location, making them difficult to track. An agent on a mobile device might be utilising a cellular connection, which would appear as a different IP address than the one used by the Wi-Fi connection to the company's network. The EDR solution would see two different devices, making it unable to detect malicious behaviour.
Traditional EDR solutions also rely on the assumption that an operating system will behave in a certain way. This reliance on OS behaviours makes the solution unable to detect malicious behaviour that does not follow OS norms.
Lack of visibility into OS behaviour
Traditional EDR solutions are designed to detect malicious code on a device. If a device is already infected with malware, the solution would be able to detect it. If a device is not infected, the solution will not detect it. If a device contains malicious code that does not replicate and infect that device, the traditional EDR solution would be unable to detect the malicious code. This becomes a major concern in light of the rise of malicious code that does not replicate itself but is designed to steal information, disrupt operations, and cause damage.
Limitation of network assumptions
Network-based detection relies on assumptions that may not always be true:
- —The device is connected to the network.
- —The device has an IP address that the security solution can access.
- —The device uses the ports and protocols discovered by the security solution.
- —The OS running on the device is one the security solution has been programmed to identify.
Network-based detection limitations
If the device is offline, the security solution would assume the device is online — that is the assumption network-based detection relies on. Due to this reliance, network-based detection is unable to detect mobile devices that have shifted from a wireless network to a disconnected state. The solution assumes the device is online when, in fact, it is offline. This creates a blind spot in the organisation's ability to detect malicious activity.
Limitations in real-time detection
Real-time detection relies on the operating system running on a device to create alerts that would trigger a malicious behaviour detection alert on the server. If the OS does not produce the alerts the solution is programmed to look for, the malicious behaviour will not be detected. For example, some operating systems do not generate alerts when file system changes occur — something the traditional EDR solution would rely on. The malicious code that triggered the WannaCry ransomware attack in May 2017 was able to infect Windows devices because they did not send alerts when the malicious code made changes to the file system.
Fixing the problem: protecting mobile devices with EDR
Traditional EDR solutions that rely on the agent model assume the device being monitored is online while connected to the network. This renders the solution ineffective and unable to protect mobile devices that have shifted from a network to a disconnected state. To protect mobile devices with EDR, we must find a solution that does not rely on the agent model architecture.
Conclusion
Traditional EDR has become the go-to method for protecting computers from malware attacks in real time. However, this model has limitations that cause significant problems in detecting malicious mobile device activity. Organisations must change their approach and start testing solutions that don't rely on the agent model and have OS-specific security modules built in.