So that should solve the problem, right? The host log says software was installed and then you’ll know malware has been installed, act decisively and be the hero. Well, not so much. Do you know how many times a day a typical enterprise installs software on it’s managed devices. Hundreds? Thousands? More? It’s very likely too much for human analysis to figure out. What about those fancy correlation engines that will look for bad software? Hmm. For that to work, it needs to have a list of “good” software – which is always changing. I hope you are good with coding and regular expressions, because you’ll need to build a number of custom rules to make that work in a SIEM product.

The key is to be able to ENFORCE POLICY. As we discussed in Reason #3 about configuration data, the key to reacting faster to emerging threats is to detect something different, anomalous, and not normal. By establishing a set of policies for what software is allowed and then detecting when a device violates that policy, you can reduce the noise of watching every software install.

All of the anti-virus companies are talking about their shiny new, white-listing widget, and justifiably so. Taking a positive security approach (only allowing authorized software to run on managed devices) will definitely reduce the likelihood of infection. So this idea of monitoring for new software installs is sort of a poor-man’s white-listing.

Which is really the point of this entire series. There are many defensive techniques that are required to keep pace with today’s attackers. Just relying on a log management toaster or a SIEM “in a box” is not going to get the results you are looking for. Aggregating, parsing and even correlating on log data is just not enough.

Most security organizations don’t have the pull to really lock-down desktops. Sure they can mandate a standard build, but in most cases users can install software that they want, and sometimes that software becomes a problem. The reality is you can’t avoid these issues, but you need to figure out how to react faster and appropriately when an issue crops up.

The first step is to know what’s out there. A lot of organizations rely on asset management tools to assemble information on who is using what. You can also figure out what software is out of policy and decide whether to do anything about it. Sometimes it’s the better answer to turn the other cheek, in terms of getting rid of unauthorized software. But it’s not OK to not know it’s there.

Just as important as understanding what’s out there, you need to understand what’s changing. That’s why constantly revisiting the asset base and the device configurations are critical. And just doing one or the other isn’t enough. New software can (and usually does) change configurations and that can create security exposures.

To bring the point home, it’s probably unreasonable to expect that your users will allow you to totally control what software they are running. But you CAN and SHOULD know what they are running and be able to pinpoint when something changes to evaluate the security risk to your environment. That’s just good security practice.