Tuesday 19 February 2013

Agentless FIM – Why File Integrity Monitoring Without Agents Is The Same, and Better, and Worse than using Agents

Introduction
Agentless FIMAgent versus Agentless is a perennial debate for any monitoring requirements and is something that has been written about previously.
The summary of the previous assessment was that agent-based FIM is usually better due to the real-time detection of changes, negating the need for repeated full baseline operations, and due to the agent providing file hashing, even though there is an additional management overhead for the installation and maintenance of agent software.
But what about Agentless systems that purport to provide hashing? Seemingly being able to encircle all requirements and deliver functionality of an agent-based FIM solution but still without using an agent?

What Is So Scary About Agents Anyway?
The problem with all agents is one of maintenance. First the agent itself needs to be deployed and installed on the endpoint. Usually this will also require other components like Java or Mono to be enabled at the endpoint too, and these all have their own requirements for maintenance too.
WSUS/Windows Update Services and Update Manager functions in Ubuntu all make life much easier now to maintain packaged programs but it is accepted than introducing more components to any system will only ever increase the range of ‘things that can go wrong’.
So we’ll make that 1-0 to Agentless for ease of implementation and maintenance, even though both functions can be automated to a greater or lesser degree – good FIM solutions will automatically update their agent components if new versions are released.

System Resources – Which Option Is More Efficient?
No agent means the agentless system must operate on a polled basis, and operating on a polled basis means the monitoring system is blind to any security events or configuration changes that occur until the next poll. This could mean that security threats go undetected for hours, and in the case of rootkit malware, irreparable damage could have been done before anybody knows that there is a problem.
Poll intervals can be reduced, but the nature of an agentless system is that every attribute for every object or file being monitored must be gathered for every poll because, unlike there is with an agent-based FIM solution, there is no means of tracking and recording changes as they happen.
The consequence of this is that agentless polls are as heavy in terms of system resources as the initial baselining operation of an agent-based system. Every single file and attribute must be recorded for every poll, regardless of whether changes have occurred or not.
Worse still, all the data collected must be dragged across the network to be analyzed centrally, and again, this load is repeated for every single poll. This also makes agentless scans slow to operate.
By contrast, an agent-based FIM solution will work through the full baseline process once only, and then use its vantage point on the endpoint host to record changes to the baseline in real-time as they occur. Being host-based also gives the agent access to the OS as changes are made, thereby enabling capture of ‘Who made the Change’ data too.
The agent gives a much more host-resource and network efficient solution, operating a changes-only function. If there are no changes to record, no host resources are used and no network capacity used either. The agentless poll will always use a full baseline’s worth of resource for every scheduled scan. Furthermore this makes running a report significantly slower than using an agent that already has up to date baselines of the information needed in the report.
This easily levels the scores up at 1-1.

Security Considerations of Agentless versus Agent-Based FIM Solutions
Finally, there is a further consideration for the agentless solution that doesn’t apply to the agent-based FIM option. By requiring the agentless solution to login and execute commands on the server to gather baseline information, the agentless solution server needs an Account with network access to the host. The Account provisioned will need sufficiently high privileges to access folders and files that need to be tracked and by definition, these are typically the most sensitive objects on the server in terms of security governance. Use of Private Keys can be used to help restrict access to a degree, but an agentless solution will always carry with it an additional inherent security risk over and above that posed by agent-based technology.
I would call that a clear 2-1 to the Agent, being more efficient, faster and more effective in reporting threats in real-time.

File Hashing – What is the Advantage?
The classic approach to file integrity monitoring is to record all the file attributes for a file, then perform a comparison of the same data to see if any have changed.
For more detail of how the file make-up or contents has changed, mainly relevant to Linux/Unix text-based configuration files or web application configuration files, then the contents may be compared side-by-side to show changes.
Using a file hash (more accurately a cryptographic file hash) is an elegant and very neat way of summarizing a file’s composition in a single, simple, unique code. This provides several key benefits -
  • Regardless of the size and complexity (text or binary) of the file being tracked, a fixed length but unique code can be created for any file – comparing hash values for files is a simple but highly sensitive way to check whether there have been any changes or not
  • The hash is unique for each file and, due to the algorithms used to generate cryptographic hashes, even tiny changes result in significant variations in the hash values returned, making changes obvious
  • The hash is portable so the same file held on different servers will return the same identical hash value, providing a forensic-level ‘DNA Fingerprint’ for the file and version
Therefore cryptographic hashing is an important dimension to file integrity monitoring, however, the standard Windows OS programs and components do not offer a readily useable mechanism for delivering this function.
So a further big advantage of using an agent-based FIM solution is that cryptographic hashing can be provided on a all platforms, unlike a pure agentless solution.
3-1 to the Agent and it looks like it is going to be hard for the agentless solution to get back in the game!

When is Agentless FIM Really the Same as an Agent-Based FIM Solution?
Most vendors like Tripwire provide a clear-cut agent-based and Agentless option with the pros and cons of each option understood.
The third option is where the best of the agentless and agent-based solutions come together to encircle all capabilities. This kind of solution is positioned as agentless, and yet delivers the agent-based features . The solution behaves like an agentless solution, in as much as it functions on a scheduled full-scan basis, logging in to devices to track file characteristics. However there is no need to pre-install an agent to run FIM, so the solution feels like it is agentless.
In practice the solution requires an Administrator logon to the servers to be scanned. The system then logs on and executes a whole sequence of command line scripted commands to check file integrity, but will also pipe across a program to help perform file hashing. This program – some say agent - will then be deleted after the scan.
So is this solution agentless? No, although it does remove the major hassle with an agent-based solution in that it automates the initial deployment of the agent.
What are the other benefits of this approach? None really. It is less secure than an installed agent - providing an Admin logon that can be used across the whole network is arguably weakening security before you even start.
It is massively less efficient than a local agent - piping programs across the network, then executing a bunch of scripts, then dragging all the results back across the network is hugely inefficient compared to an agent that runs locally, does its baselines and compares locally and then only if it needs to, sends results back.
It is also fundamentally not a very effective way to keep your estate secure - which kind of misses the point of doing it in the first place! Reason being you only get to know that security is weakened or actually compromised when you next run a scan - always too late! An agent-based FIM solution will detect config drift and FIM changes in real-time - you know you have a potential risk within seconds of it arising, complete with details of who made the change.

Summary
So in summary, agentless is less efficient, less secure and less able to keep your estate secure (and the most effective Agentless solutions still use a temporary agent anyway). The ease of deployment of Agentless is tempting, but this can always be automated using any one of a number of software distribution solutions. Perhaps the best solution still is to reserve the option on both and choose the best approach on balance? For example, Firewall appliances will always need to be handled using scripted, Agentless interrogation, while Windows servers can only truly be audited for vulnerabilities using a cryptographic hashing, real-time change detection agent.