The recent Intel AMT vulnerability announcement illustrates an important reason why Observable prefers to do monitoring at the network level instead of at the device level. I’ll try not to make this Yet Another Vulnerability of the Week post, and instead focus the principle: a monitoring agent installed on a device can’t always be trusted to report on itself.
An endpoint agent can only see what its host's hardware and operating system allow it to see. In some cases that’s not everything. The Intel AMT system is a good example of this: it intercepts network traffic on certain ports, directing it to the low level management system.
When AMT is enabled, traffic to those ports becomes invisible to the OS. This means that software agents (anti-virus, host IDS, etc.) can’t see that traffic, and therefore can’t monitor it for malicious behavior.
While Intel’s AMT is in the news, other systems can prevent software agents from seeing potentially malicious activity. Firmware and BIOS-provided services with access to the network hardware can do something similar, and OS-modifying rootkits can also keep software applications in the dark about their operations.
Endpoint agents also have to trust that what they can see from the host is accurate. An agent that analyzes log files has to trust that those logs haven’t been tampered with, for example. This can be an OK assumption to make for performance monitoring, but might not be for security monitoring: if a malicious user or program has root access, it can put approximately whatever it wants in the log files. Anti-forensic tools specialize in covering the tracks of malicious activity.
One way to mitigate this problem is to send log files to a remote location shortly after they’re generated. This prevents a malicious user from simply overwriting a compromised server’s logs. However, this scheme still relies on the processes that write the logs to be reporting accurate data.
When we monitor at the network level we can mostly avoid the issues above. Traffic destined for some low-level system (like Intel AMT) will be visible, because the network has to deliver it for it to work. When using a physical tap, we can trust that the packets the monitoring system sees are the same as what the destination host sees.
When using a mirror port or NetFlow log instead of a physical tap, we can imagine that malware could manipulate what’s in the data stream. As far as I know there’s not a real world example of that happening; at the moment this is a theoretical concern. An attacker would need to be able to exploit both the network element and the target system.
Using the network for monitoring has other virtues. For example, it’s difficult to install software agents on non-traditional devices - phones, printers, Internet of Things things. It’s often impossible to do so on managed cloud services (e.g. Amazon RDS or Lambda) - sometimes the network is all that’s available.
To wrap up, I’ll summarize the above points:
Software agents can be an important component of a security monitoring. However, administrators should be aware of their limitations, especially when people are paying attention to a new vulnerability.
Getting better visibility into your network and improving your security couldn’t be easier. Sign up for a free, no-risk trial of Observable’s Endpoint Modeling solution, and change the way you see security.
Detect Threats Faster – Start Your Free, No-Risk Trial