Security, et al

There’s plenty of interest in all kinds of advanced security technologies like threat intelligence, strong/dynamic authentication, data loss prevention and information rights management. But so many organizations still don’t know one of the basic indicators of compromise on their network – new processes and modified executables. This is so important because in every high profile case of data breaches over the past few years a common thread has been the presence of a malicious program that provided the attackers with persistent access to the internal network of the victim organization.

Moreover, some security technologies – such as strong authentication – are no defense if you have malicious code running on the endpoint of a strongly authenticated user.

So rapid detection of malicious code is paramount. The importance can’t be over-stated. Detecting malicious code isn’t easy and traditional signature-based AV is only going to catch comparatively “old” and widely distributed malware. It isn’t likely to catch the targeted attacks we are up against today in which the bad guy uses shrink wrapped tools to build and package unique malicious agent to use against your organization.

How do you detect and even prevent malware like this? Like everything it takes a defense-in-depth approach. Advanced 3^rd party application white- and advanced memory protection are very effective. But whether you have such technologies deployed or on the radar, your SIEM solution can provide you early warning when new software is observed on your network.

The key thing is to look for Event ID 4688 in the Windows security log. Compare the executable name in that event to a list of whitelisted EXEs you expect to see –or better yet a list of executables that automatically builds from past events.

You want these events from every possible system – including workstations. If you are concerned about the amount of log data involved, I should mention that the sponsor of this article, EventTracker, provides an agent that can efficiently forward just the relevant events you want from thousands of endpoints.

Will there be false positives? Yes – especially until you refine your rules to take into account patches. Will this catch every malicious agent? Of course not. After all, there are multiple ways to insert malicious code on an endpoint and some are completely in-memory with no new executable involved. 3^rd party advanced memory protection products or Microsoft’s EMET can provide some help with detecting memory exploits though and using your SIEM to collect and monitor those events is the obvious thing to do if you use EMET or another memory protection technology.

Some malware embeds itself in the existing, trusted EXEs and DLLs so it makes sense to monitor for modifications to such files. Again you want this from your workstations – not just server endpoints. Getting EXE/DLL modification events requires either Windows file monitoring or a file integrity monitoring (FIM) solution. Enabling auditing of just EXE and DLL files with Windows file auditing though is not that easy. You can’t configure audit policy on files with Group Policy without also impacting permssions. So widely distributed scripts would be required. FIM is definitely and easier route. Again, it’s worth mentioning that EventTracker’s agent includes FIM monitoring making it easy to catch changes to existing software as soon as it happens.

This article by Randy Smith was originally published by EventTracker”

http://www.eventtracker.com/newsletters/are-you-listening-to-your-endpoints/