My title at Tripwire is “Evangelist”. I evangelize about Tripwire solutions for security, compliance and IT operations. My goal is always to explain how we do what we do and why that is important to a particular IT business problem. Sometimes I try to contrast our approach to competing solutions and let the audience draw their own conclusions. After attending a competing vendor’s webcast on their security solutions—and Security Configuration Auditing in particular—I realized I needed to go beyond basic evangelism and deliver an out-and-out mini-sermon on the topic of security effectiveness using an agentless vs. agent-based architecture.
My mini-sermon title: Agentless architectures can tell you that you died, just not why or when. Agent-based architectures can tell you when you are sick, what is causing your illness and what it will take to bring you back to full health. Which architecture will you choose to save your data?
It’s a long title for a short sermon but I hope it causes you to read on; this won’t take long.
In the vendor’s webcast part of the discussion was on their Secure Configuration Auditing solution. Tripwire has a competing solution called Security Configuration Management. The difference between agentless and agent-based products begins right here—Auditing vs. Management. About the only thing you can do with agentless security products is check the then-current state of configurations at the time of the audit. That’s the part about finding out you are already dead, or so badly damaged there is little hope of a full recovery. I know, I know, this kind of talk is a bit aggressive….but it’s true, and I know large organizations that can testify to this fact. Here’s why.
Agentless means you do not install any of the security configuration software—the stuff with the secret sauce—on the devices where you are trying to maintain a secure state of configurations. Instead, a request is periodically made to a device-resident utility to collect a copy of every configuration. All of those configurations—whether they have changed or not since the last check—are sent across the network to where the secret sauce security application can do its work.
With an agentless architecture you have to make this request for “all” configuration data and repeat this process for “every” device you are trying to secure. Each request for the configuration data consumes device resources, especially since the utility doing the harvesting work is not purpose-built for this task. In a typical organization less than 1% of configurations change over short intervals so this random, mega-copy-and-compare approach is not only incredibly inefficient, it is, frankly, a massive waste of time and resources. So much so that the larger the environment being managed the longer interval between configuration checks and the greater the odds that security-risks are introduced into the environment. In other words, the larger the environment the less security value the agentless architecture provides when trying to maintain—continuously maintain—configurations in a secure state.
The agentless architecture is the typical approach to security configuration solutions from a majority of solution providers. Not so with Tripwire; we do it completely different. For starters, our solution is called Security Configuration Management. Our purpose is to help organizations “continuously maintain” a known and trusted state of configurations, regardless of the size of their environment. Referring to my previous medical analogy, Tripwire wants to notify the patient when they are in a susceptible state to getting ill rather than letting their next-of-kin know they have died from a preventable illness. We are able to do this because Tripwire employs an agent-based architecture that places critical intelligence at the device. Here is how it works and why that is important.
The Tripwire agent is purpose-built to detect change to configuration settings. The change information can be sent to the Tripwire application server as it is detected—in real time—or at any desired interval based on business need. The agent has a very small footprint and consumes negligible device resources. The power of this architecture comes from the fact that the “intelligent” agent only sends the data that matters—configurations that have been changed—to the Tripwire application server where it is immediately retested against policy and alerts are issued upon test failures. Since there is typically less than 1% of configuration change over short intervals, there is minimal data being transferred across the network. And when data is transferred it is done as the change occurs rather than all at once from all devices. If there are no changes, no data is transferred and no testing is required.
Tripwire’s intelligent agent-based approach is incredibly efficient and it consumes negligible time or resources allowing the solution to scale to any size environment. And equally, if not more, important, the Tripwire agent only sends and tests configuration data that is already suspect because it has been changed. In addition to the test results and immediate notification on test failures against policy, Tripwire provides deep and detailed forensics data about the offending change. This information allows failing configurations to be quickly restored to their known and trusted.
So that’s my mini-sermon—short, sweet, and hopefully to the point. And the point is — to move the security needle when managing security configurations an intelligent, device-based agent is required. It is the only architecture that supports seamless scaling to virtually any size environment because it is the only architecture that focuses only on configurations that change rather than every configuration, on every device, every time you want to audit their state.
How products work really makes a difference.