Strengthen your defenses where the battle is actually being fought – the endpoint

By: Randy Franklin Smith

Defense-in-depth pretty much secures and confirms the thought that every security technology has a place but are they really all created equal?

Security is not a democratic process and no one is going to complain about security inequality if you are successful at halting breaches. So I think we need to acknowledge a few things. Right now the bad guys are winning on the endpoint – in particular on the workstations. One way or another the attackers are getting users to execute bad code on their workstation allowing attackers to achieve a beach head, work their way across our networks following a horizontal kill chain until they reach “the goods”. Next generation firewalls, identity/access control and privileged account management all have a part to play in detecting and slowing down this process. However, we are not doing enough on the endpoint to recognize malicious code and key changes in user and application behavior. Though the strength of NGFWs is their eye in the sky ability to watch network traffic as a whole, they don’t see inside encrypted packets, nor do they know which program inside the endpoint is sending or receiving observed packets. NGFWs also cannot tell you when that program appeared on the endpoint, how it got there or who executed it.

So am I arguing in favor of collecting endpoint security logs? Including workstations?

If you have more than a handful of workstations, forget trying to collect their logs using any kind of pull/polling method; it just isn’t going to work. Getting all your workstation security logs is challenging, noisy and may not meet your requirements as most native logs lack important information. If you stick with native logs you need to implement Windows native Event Forwarding which is a great technology but right now lacks management tools. What does that mean for most organizations? Agents.

Historically there’s been a lot of push back to deploying YAA (yet another agent) on workstations simply for the purpose of collecting logs. Like most, I’d have to agree that going through the trouble of installing and maintaining an agent on every workstation when the return is native logs is a tough proposition.

This is why I like what EventTracker has done with its latest update, EventTracker 8 and the powerful detection, behavior analysis and prevention capabilities in their new agent. Basically goes like this:
1. We are losing the war on the endpoint front
2. Ergo, we need to beef up defenses on the endpoint
3. But native logs aren’t valuable enough alone to justify installing an agent
4. Conclusion: increase the value of the agent by doing more than just efficiently forwarding logs

EventTracker 8’s Windows agent does much more than just forward logs. In fact, maybe we shouldn’t call it an agent but perhaps a sensor would be a better term.

One of the key things we need to do on endpoints is analyze the programs executing and identify new, suspect and known-bad programs. With native logs all you can get is the name of the program, who ran it and when (event ID 4688). The native log can’t tell you anything about the contents (i.e. the “bits”) of the program, whether it’s been signed, etc.

Every time a process is launched, EventTracker 8 takes the process’s signature, pathname, md5 hash and compares that information against
• A local whitelist
• National Software Reference Library
• VirusTotal

This is something you can only do if you have your own bits (i.e. an agent) running on the endpoint. This cannot be done with native logs or even with a NGFW. Below is an example of a “synthetic” event generated by EventTracker that says it all:

screenshot

I wish Windows had that event.
“But, wait. There’s more!”

Visibility inside the programs running on your endpoints and being able to compare them against internal and external reputation data is extremely valuable to detecting and stopping attacks. But if we have a good agent on the endpoint we can do even more by analyzing what that program is doing on the network. What other systems is trying to access internally and where is it sending data out on the Internet?

Here’s an example of what EventTracker 8 does with that information. How would you like to know whenever a non-browser application connects to a standard port on some unnamed system on the Internet? Check out the event below.

screenshot2

If you are cultured in malware techniques, you realize that discreet EXEs are not the only way attackers get arbitrary code to run on target systems. They have developed many different ways to hide bad guy code inside legit processes. One thing EventTracker does to detect this is by looking for suspicious threads injected into commonly abused processes like svchost.exe. EventTracker also does sophisticated analysis of the user too – not just programs – and alerts you when it sees suspicious combinations of user account, destination and source IP addresses.

EventTracker combines all the data that can only be obtained with an endpoint agent with general blacklist data from outside security organizations and specific whitelist data automatically built from internal activity. This is a great example of what you can do once you have your own code running on the endpoint. Combine native logs from each endpoint with all this other information and you are ahead of the game.

Highlights of the Month





captcha