Gartner has been the most vocal about the need for a process shift, advocating what it calls an “adaptive security architecture.” The idea is to balance efforts among attempting to predict when a breach will occur, preventing the ones you can, detecting what a successful attacker has done on the endpoint, and ultimately responding to the attack in some way. You need to be doing all of these, all the time, with a variety of technologies, so you can respond appropriately.
“How you protect yourself from a shotgun blast is very different than how you protect yourself from a sniper’s bullet,” says Neal MacDonald, VP distinguished analyst at Gartner.
Let’s look at a real-world example of why you need change now, before you get stuck in the quicksand of a disastrous endpoint breach your prevention tools missed.
Zeus is one of the most common malware instances active today in the wild. Generally, attackers use Zeus to steal people’s banking credentials as they check their account balances and pay bills online. So when an IT security team gets an alert from a next-generation firewall or sandbox product that Zeus has infected a workstation, the usual response is to dispatch an IT help-desk ticket to get the machine rebuilt. It’s the standard “nuke and pave” approach that users and help-desk teams have come to loathe.
But what if, in this case, the attacker is using Zeus not to steal a bank account number but to exfiltrate data from your company or install other malicious software? Zeus has those capabilities, too. If you re-imaged the machine, you would never know that data was stolen. Prevention tools have put us in the mindset that we can receive an alert, know the type of threat we are handling, and block the attack. This approach to categorizing and remediating threats not only doesn’t work anymore, it can be damaging.
The keys are context and visibility into what the attacker actually did. A knife can be used to cut fruit or to stab someone. Conventional prevention tools simply look for the presence of a knife, and if it’s there, generate an alert. It’s left to the security engineer to figure out if the knife was used maliciously. Yet most organizations have significantly underinvested in training their security staffers. Can everyone on your team evaluate if an alert is a false positive, and if it’s not, launch the process to analyze the attack, perform forensics, and ultimately make a solid response decision? This is where new tools can help. Let’s look at some places you might choose to spend security budget for 2015.
Refocus On Endpoints And Data
Tools to do real-time forensics, attack reconstruction, and malware analysis are becoming easier to use and more cost-effective; they bring clarity to security processes and prioritization of threats.
There’s no excuse for not having at least one staffer with forensic expertise. Start with free tools, such as Volatility or Cuckoo Sandbox, or spring for Guidance EnCase or AccessData’s FTK, and catch some tutorials on YouTube. These tools deliver deep, granular information, such as what processes, files, and network connections were involved in an attack. Budget for training, and have a process for IT to get physical access to the endpoint in question.
Forensics is complex, no doubt. For example, there are over 20 different registry keys a piece of malware can use to make sure it executes when a machine is rebooted. How the heck do you keep track of those reg keys when Microsoft makes a change in the next service pack? Endpoint threat detection and response systems, such as the open source El Jefe and offerings from CarbonBlack, CounterTack (which is where I work), and FireEye, aim to help IT efficiently and accurately prioritize their efforts. Instead of just alerting IT to a piece of malware, these tools tell you what files were accessed, what process connected to what IP addresses, and other information. If the Zeus malware really was just trying to steal banking info, maybe you don’t even need to rebuild the workstation, because you know the five process and eight files the malware installed on the machine. You can just kill those processes and remove those files, while the user is still working, and get back to dealing with other threats.
When considering any endpoint threat detection and response system, ensure it provides real-time forensic-like data that you can comb through and analyze. Ideally, look for the ability to automatically apply machine learning and behavioral algorithms to this data, to help your team become more efficient at data analysis. Look also for the ability to apply behavioral analysis to look for trends, anomalies, and other indicators or predictors of malicious behavior. For example, consider malware that launches a program from a hidden folder. Think about that for a second — how can a user launch a program from a folder she can’t even see? Amazingly, many types of malware exhibit this behavior. Other clues are AV tools being disabled or a Microsoft Word document spawning a process. Systems that see all interactions between files, processes, and network connections can quickly reveal the origin of the attack — the website, document, or application that caused the problem — and determine if this malware is anywhere else on your network by searching all systems for the same information. Since they deal with behaviors, not always hashes or other signatures, they can also analyze insider threats. This puts IT back in control of responding to the attacker.
Once you have context and visibility into the threat, ensure the system enables you to respond via such actions as killing a process, deleting a file, or quarantining a machine so that only certain IP addresses can access the system.
Whenever possible, do a coordinated cleanup on all endpoints at the same time. This reduces the likelihood attackers will change their behavior after being alerted that you’ve found them.
When selecting new security tools, keep in mind the principle of security information collaboration, where sharing data among systems makes them all more effective.
Imagine your network devices becoming smarter because of your endpoint devices, or your SIEM system being able to correlate what seem like disparate events on different machines across the network. Look for context awareness, such as around an endpoint’s IP address, operating system, and software versions. Look for APIs that enable security systems to be queried, and export options where they can send information to other systems in real time.
Let’s look at some scenarios. A network-based sandbox device generates an alert that Steve in accounting downloaded malware. IT gets an alarm, and your security team drops everything and rushes to Steve’s desk to see the extent of the infection.
What if, instead of sending the alert right away, the sandbox could query the endpoint and validate that the malware executed before sounding the alarm? If it identifies that the malware is present but inactive, the alert can be sent as a lower priority. Furthermore, the SIEM system receiving the alert from the network sandbox can pinpoint every system that also downloaded the file and didn’t execute, enabling remediation across the enterprise quickly. This becomes an invaluable tool when receiving mass phishing attempts like those coming during the upcoming holiday season.
Another example involves threat intelligence services, such as those from RedSky, Threat Connect, Recorded Future, Emerging Threats, or Cisco’s ThreatGrid. The challenge IT has with these services is fully leveraging all the incoming data for endpoint protection. Usually, it involves a lot of manual lookups to find indictors of compromise, such as a domain name, IP address, or MD5 hash; automated integration only works for network-based indicators. Endpoint detection and response tools can consume various threat feeds and automate the detection of indicators of compromise in real time, without performance-intensive scanning.
Incorporate existing signature-based systems into the collaboration system by generating a signature from your analysis and thus preventing the attack in the future.
Process Is King
Other industries have survived the transition from “prevent only” to “detect and respond.” The cyber-security community should learn from what banks have done in automating fraud prevention. Banks responded to increasingly successful fraud attacks with prevention measures, but ultimately had to make fraud monitoring part of their core business practices and move to a model where every transaction is analyzed for fraud automatically, behind the scenes, with banks anticipating, and budgeting for, some theft.
We anticipate that, like banking industry fraud teams, IT security architects will move into a continuous cycle of predict, prevent, detect, and respond while ultimately modifying their networks and systems so that, like the crumple zones of a modern car, certain parts of the network can be taken over by an attacker without harming the integrity, availability, and confidentially of the data within the organization. It’s time to get started.