Security, et al

Defense-in-depth pretty much backs up the thought that every security technology has a place. But are they all created equal? Security is not a democratic process and no one is going to complain about security inequality if you are successful in stopping breaches. So I think we need to acknowledge a few things. Right now the bad guys are winning on the endpoint – in particular the workstation. One way or another they are getting users to execute bad code on their workstation. Having achieved a beach head, they work their way out across our network following a horizontal kill chain until they reach “the goods”. Next generation firewalls, identity and access control and privileged account management all have a part to play in detecting and slowing down this process. But we are not doing enough on the endpoint to recognize malicious code and key changes in user and application behavior. The strength of NGFWs is their eye in the sky ability to watch network traffic as a whole. But they can’t see inside encrypted packets and they don’t know which program inside the endpoint is sending or receiving observed packets. Much less can an NGFW tell you when that program appeared on the endpoint, how it got there, who executed it and so on.

So am I arguing for collecting endpoint security logs? Including workstations? Well that’s a start. But getting all your workstation security logs is challenging and may not meet your requirements because native logs do lack important information. 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. If you stick with native logs you need implement Windows native Event Forwarding which is a great technology but right now lacks management tools. So for most organizations that means 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. And I have to agree that going to the trouble of installing and maintaining an agent on every workstation when all you get is it’s native logs is a tough proposition.

That’s why I like what EventTracker has done with EventTracker 8 and the powerful detection, behavior analysis and prevention capabilities in their new agent. Basically it 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. Perhaps 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. Here’s what EventTracker 8 does every time a process is launched. It takes the process’s signature, pathname and md5 hash. It compares that information against:

• A local whitelist
• National Software Reference Library
• VirusTotal

This is stuff you can only do if you have your own bits (i.e. an agent) running on the endpoint. You can’t do it with native logs and or with an NGFW. Here’s an example “synthetic” event generated by EventTracker that says it all:

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. We can analyze 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.

If you are up on malware techniques, though, 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 way ahead of the game.

To be even better, your SIEM needs more intelligence without noise. Like the universe we live in, the area that must be monitored for APTs constantly expands. It is hard to focus on the significant security events when the field of view keeps getting larger.

The key to information security is what you focus on must be worth catching. Enforcing systemic, organizational proficiency to focus on the narrower relevant field is absolutely crucial to organizations’ security practice.

Focus on the Top 3 Blind Spots

A lot of the organizations we talk to are finding a way to address that challenge of making their SIEM better, not burdened. They do it by dedicating their primary effort to solving the SIEM’s top 3 blind spots:

1. Applications,
2. the cloud, and
3. failure to monitor all the Windows endpoints

We believe in this so much it’s where we are putting all our money. Here’s how:

LOGbinder provides the market-leading solution for SIEM’s to have visibility into what’s happening inside Exchange, SharePoint and SQL Server. Soon after the public availability of Exchange 2016, SharePoint 2016 and SQL Server 2016 (expected mid-2016), LOGbinder intends to release compatible updates to its core products. We already have these versions in development and are excited about their potential to help make your SIEM better. Our SIEM integrations help you isolate and monitor only what’s important.

Microsoft’s cloud-based products, especially Office 365 and Azure are hugely attractive to organizations of all sizes. Their limitation has been a lack of audit capability, but that is soon to change. Microsoft expects to release (also mid-2016) a completely new and very good audit function to both Office 365 and Azure’s Active Directory. LOGbinder is poised to deliver a matching solution to put cloud-based application security intelligence where it belongs – your SIEM. We are investing significant resources with the plan to deliver the solution 30 days after public availability.

By the way (and this is important), it is going to require special effort on the part of all of us in the IT security business to pitch in and make cloud security audit and monitoring possible. LOGbinder will provide the audit data from cloud, as well as guidance about what to watch. But… you should talk to your SIEM product development team today to make sure they are talking to LOGbinder and working on their integration for LOGbinder’s cloud-based solutions.

The 3^rd problem area for SIEM security intelligence is monitoring all Windows endpoints. If you don’t know which endpoint is installing a new program...

Your SIEM is perhaps your greatest bandwidth hog as it is, adding all that traffic from the endpoints isn’t feasible, right? But that’s not a good enough reason; nobody wants to have to explain a data breach because of it. The real reason is probably a financial one. LOGbinder has developed a solution and is devoting significant money to bring that solution to market early in 2016. We discussed it at length at the recent HP Protect conference. We call it SuperCharger for Windows Event Collection. It is software that – with no agents and no polling – uses the native Windows event functionality to deliver only the relevant security events to the SIEM from all the Windows endpoints with no noise! It’s really cool and we’re super-excited. So are our SIEM partners who’ve taken the time to talk to us about it.

We are very excited about the opportunities now (and soon to be) available for SIEM security analysts. Putting meaningful security event logs in the SIEM where they belong is our passion.

LOGbinder is committed to making your SIEM even more powerful by feeding it more intelligence without the noise.

Note: The statements in this post about our new product delivery dates are “forward-looking”. We can’t predict the future with certainty. Our plans are presented here, and we expect to be able to make those plans a reality. But like all future plans, they are vulnerable to unanticipated events.