Build your network as if the endpoint is owned.
Build your endpoint as if the network is owned.
— SecuriTay (@SwiftOnSecurity) November 21, 2015
Employees with laptops and phones wander the globe, outside the fictitious “secure” perimeter. We need to protect their devices. Not only do they often store sensitive files, but if compromised, can provide a foothold for infiltrating an entire network.
Protection from what?
Endpoint security is traditionally about preventing harmful executables from running and doing damage. There are other endpoint concerns, such as a hacker inserting a USB Rubber Ducky, but it’s mainly all about users running harmful programs.
We don’t want them to run malicious executables (viruses, malware) because they can:
- Steal, encrypt, or destroy data on the machine (and connected network drives)
- Make the machine behave badly, crash, etc.
- Capture your keystrokes and steal your passwords
- Create a backdoor for attackers to get in/out whenever they want
And probably a hundred other things that I haven’t thought about. So what are the things we can do to mitigate endpoint issues?
- Encrypt local data (e.g., BitLocker full-disk encryption)
- Auto-backup and restore local data (e.g., CrashPlan)
- Control which applications can be installed and executed (e.g., AppLocker)
- Deploy patches to the OS and applications (e.g., Group Policy)
- Scan files for malware (e.g., anti-virus, anti-malware)
Regarding the last bullet, many have claimed that anti-virus is dead because it largely relies on comparing a file’s signature to a database of known-bad signatures and today’s malware is polymorphic and can bypass signature checks or flat-out kill your endpoint’s AV process.
This has given rise to a new breed of, dare I say “next-gen”, endpoint protection that relies on:
Sandboxing is a technique whereby a program is run in an isolated virtual environment that mimics your typical endpoint. Once the file is “detonated” the environment is examined for ill-effects.
Sandboxing can be useful, but malware is also written to detect whether it’s in a sandbox. If it is, it knows to behave itself.
Instead of scanning a file to determine whether it’s a known-bad application, a whitelist approach only lets known-good applications run (e.g., AppLocker, as mentioned above). Whitelisting takes a “default deny” approach, which can be more effective than a blacklist.
There are gnarly cases of malware escalating privileges and writing itself to an application whitelist. Also, code injection techniques have been known to bypass whitelists since the malicious code lives inside an approved app’s process.
Regsvr32.exe (a command-line utility built into Windows) can execute scripts on a remote host, thus bypassing of AppLocker restrictions! It is important to block Regsvr32.exe’s access to the network through a software firewall as Microsoft has not decided whether or not it will patch this vulnerability in the near future. More on this here.
Instead of scanning files and doing signature comparisons, exploit prevention is a technique that examines the endpoint for behavior that’s indicative of a successful exploit. For example, it looks for evidence of buffer overflow and code injection.
Rule-based exploit prevention suffers from the same drawbacks as signature-based scanning: you have to know what you’re looking for. Also, attackers don’t always need to rely on common exploit techniques that exploit prevention would detect.