Skip to content ↓ | Skip to navigation ↓

I heard some interesting the other day—but not surprising—about an organization that is trying to maintain a “known state” of security configurations on thousands of servers. They currently use scan-based technology to periodically check configurations against security policies. They are having trouble—again, no surprise—because of the time it takes, the volume of data that is transferred across the network with each scan, and the overwhelming amount of pass/fail data produced by each scan.

You would think that the periodic pass/fail data would be of tremendous value but it often is not, especially in larger implementations. The reason is simple—it is hard to make sense of the data because there is little or no context on what is different from the last scan and why. This makes it very difficult for security analysts to know “when” failing configurations started failing and “what” caused the failure. Without the “when” and “what” context the scan data is just, well, mega-data.

Using scan-based technology to maintain a known and trusted state of security configurations is somewhat akin to checking a surgery patient’s vital signs before an operation and again after. Blood pressure may have been normal before the 4-hour surgery but dangerously low in post-op. By then permanent damage to the patient may have already been done. Of course we know that patient vital signs are continuously monitored for change throughout the operation. The instant any vital sign drifts to a high-risk and unacceptable state the medical team is alerted. Knowing “when” the risk was introduced also allows the medical team to know “what” might have caused it. In other words, “what changed to cause the problem?”

Security configuration solutions must work in a similar fashion to this medical example in order to be effective. In today’s increasingly complex, and hostile, IT security environment it is not enough to “periodically” learn about configuration failures. By the time you know something is failing it is often too late—the damage has already been done. A better approach is to baseline all security configurations and then continuously monitor them for change. When change is detected, immediately and automatically retest the affected configuration against security policy and alert on the failure as well as the change that caused the failure. This gives the security team the opportunity, and time, to correct the vulnerability and to correct the activity that led to the vulnerability.

Tripwire’s Security Configuration Management solution captures a baseline of all configurations to create a “known” state. It then proactively monitors each configuration for change. If change is detected the affected configuration is re-tested to policy and the baseline state is updated with the new “state”. Based on tunable criteria, an alert is generated when change causes a configuration (or configurations) to fail policy testing. Forensics data about the failure-causing-change is immediately available providing the critical context of “when” the failure happened and “why”.

There is a significant difference between Tripwire’s configuration management solution and scan-based solutions:

  • Tripwire tests all configuration settings once to create a baseline of the “known state”. Scan-based solutions test all configuration settings on every scan.
  • Tripwire monitors configuration settings for change and retests only when a setting is changed. Scan-based solutions retest all configuration settings on every scan.
  • Tripwire knows when a configuration setting begins failing because policy retesting is triggered when a change is detected. Scan-based solutions retest all configuration settings based on a schedule; they have no way to trigger a scan based on change to specific settings. As a result, scan-based solutions do not know “when” a setting begins failing nor “what changed” to cause the failure.

The larger the environment is the more these differences matter. If, for example, the configurations of thousands of servers are being managed, scan-based solutions must retest all settings on all servers on every scheduled scan; they have no way of knowing to retest only those settings that have changed. With Tripwire’s Security Configuration Management solution, only settings that change are retested immediately. If 2 settings change across thousands of servers, Tripwire knows to only manage those 2 settings. Scan-based solutions would copy and test all settings on all servers. This means that Tripwire would only need to process and investigate less than 1%—and typically far less—of the data of scan-based solutions. This can mean the difference between thwarting an attack vs. suffering an attack.

When trying to maintain a known state of configurations there is a clear difference in how best to accomplish that security task. The best approach—and for larger enterprise configurations maybe the only viable approach—is to continuously monitor the known state of configurations for change and immediately retest to determine if a security risk has been introduced. Tripwire’s Security Configuration Management solution does exactly that.