Advanced Endpoint and Server Protection: Prevention
As we return to our Advanced Endpoint and Server Protection series, we are back working our way through the reimagined threat management process. After discussing assessment you know what you have and what risk those devices present to the organization. Now you can design a control set to prevent compromise from happening in the first place. Prevention: Next you try to stop an attack from being successful. This is where most of the effort in security has gone for the past decade, with mixed (okay, lousy) results. A number of new tactics and techniques are modestly increasing effectiveness, but the simple fact is that you cannot prevent every attack. It has become a question of reducing your attack surface as much as practical. If you can stop the simplistic attacks you can focus on more advanced ones. Obviously there are many layers you can and should bring to bear to protect endpoints and servers. Our PCI-centric brethren call these compensating controls. But we aren’t talking about network or application stuff in this series, so we will restrict our discussion to technologies and tactics focused on preventing compromise on endpoints and servers themselves. As we described in 2014 Endpoint Security Buyer’s Guide, there are a number of alternative approaches to protecting endpoints and servers that need to be discussed, compared, and contrasted. Traditional File Signatures You cannot really discuss endpoint prevention without at least mentioning signatures. You remember those, right? They are all about maintaining a huge blacklist of known malicious files to prevent from executing. The Free AV products on the market now typically only use this approach, but the broader endpoint protection suites have been supplementing traditional signature engines with additional heuristics and cloud-based file reputation for years. To expand a bit on file reputation, AV vendors realized a long time ago that it wasn’t efficient to download hashes for every single known malware file to every single protected endpoint. So they took a cloud-based approach which involves keeping a small subset of frequently-seen malware signatures on each device, and if the file cannot be found locally the endpoint agent consults the cloud for a determination on the file. If the file isn’t known by the cloud either it may be uploaded for analysis. This is similar to how cloud-based network-based malware detection works. But detection of advanced attacks is still problematic if detection is restricted to matching files at runtime. You have no chance to detect zero-day or polymorphic malware attacks, which are both very common. So the focus has moved to other approaches. Advanced Heuristics You cannot rely on matching what a file looks like, so you need to pay much more attention to what it does. This is the concept behind the advanced heuristics used to detect malware in recent years. The issue with early heuristics was having enough context to know whether an executable was taking a legitimate action. Malicious actions were defined generically for each device based on operating system characteristics, so false positives (blocking a legitimate action) and false negatives (failing to block an attack) were both common: a lose/lose scenario. Heuristics have evolved to also recognize normal application behavior. This advance has dramatically improved accuracy because rules are built and maintained at a specific application-level. This requires understanding all the legitimate functions within a constrained universe of frequently targeted applications, and developing a detailed profile of each covered application. Any unapproved application action is blocked. Vendors basically build a positive security model for each application – which is a tremendous amount of work. That means you won’t see every application profiled with true advanced heuristics, but that would be overkill. As long as you can protect the “big 7” applications targeted most often by attackers (browsers, Java, Adobe Reader, Word, Excel, PowerPoint, and Outlook), you have dramatically reduced the attack surface of each endpoint and server. To use a simple example, there aren’t really any good reasons for a keylogger to capture keystrokes while filling out a form on a banking website. And it is decidedly fishy to take a screen grab of a form with PII on it at the time of submission. These activities would have been missed previously – both screen grabs and reading keyboard input are legitimate operating system functions in specific scenarios – but context enables us to recognize these actions as attacks and stop them. To dig a little deeper let’s list some of the specific types of behavior the advanced heuristics would be looking for: Executables/dependencies Injected threads Process creation System file/configuration/registry changes File system changes OS level functions including print screen, network stack changes, key logging, etc. Turning off protections Account creation and privilege escalation Vendors’ ongoing research ensures their profiles of authorized activities for protected applications remain current. For more detail on these kinds of advanced heuristics check out our Evolving Endpoint Malware Detection research. Of course this doesn’t mean attackers won’t continue to target operating system vulnerabilities, applications (including the big 7), or the weakest link in your environment (employees) with social engineering attacks. But advanced heuristics makes a big difference in the efficacy of anti-malware technology for profiled applications. Application Control Application control entails a default deny posture on devices. You define a set of authorized executables that can run on a device, and block everything else. This provides true device lockdown – no executables (either malicious or legitimate) can execute without being explicitly authorized. We took a deep dive into application control in a recent series (The Double-Edged Sword & Use Cases and Selection Criteria), so we will just highlight some key aspects. Candidly, application control has suffered significant perception issues, mostly because early versions of the technology were thrust into a general-purpose use case, where they significantly impacted user experience. If employees think a security control prevents them from doing their jobs, it will not last. But over the past few years application control has found success in a few use cases where devices can and should be totally locked down. That typically means fixed-function devices such as kiosks and ATMs, as well as servers. Devices where a flexible user experience isn’t an issue. It is possible