Final-Connect-Image.jpg

Endpoint Security Makes Quantum Shift: Part IV - Resolution

Posted by Michael Davis   |   March 18, 2015

malware securityMalware Analysis Process Matters

Gartner has been the most vocal about the need for a process shift, advocating what it calls an “adaptive malware security architecture.” The idea is to balance efforts among attempting to predict when a breach will occur, prevent­ing the ones you can, detecting what a suc­cessful 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 Mac­Donald, 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 attacks instances active today in the wild. Generally, attackers use Zeus to steal people’s banking credentials as they check their account bal­ances and pay bills online. So when an IT se­curity team gets an alert from a next-genera­tion 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 ca­pabilities, 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 remediat­ing threats not only doesn’t work anymore, it can be damaging.

The keys are context and visibility into what the malware attack 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 malware security engineer to figure out if the knife was used maliciously. Yet most orga­nizations 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 malware attack, perform memory forensics, and ulti­mately 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 recon­struction, and malware analysis are becoming easier to use and more cost-effective; they bring clarity to malware security processes and prioriti­zation of malware 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.

Memory forensics is complex, no doubt. For example, there are over 20 different registry keys a piece of malware analysis can use to make sure it executes when a machine is rebooted. How the heck do you keep track of those reg keys when Mi­crosoft makes a change in the next service pack? Endpoint threat detection and response systems, such as the open source El Jefe and of­ferings from CarbonBlack, CounterTack (which is where I work), and FireEye, aim to help IT ef­ficiently and accurately prioritize their efforts. Instead of just alerting IT to a piece of malware attack , these tools tell you what files were accessed, what process connected to what IP addresses, and other information. If the Zeus malware re­ally 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 analysis 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 de­tection and response system, ensure it pro­vides real-time forensic-like data that you can comb through and analyze. Ideally, look for the ability to automatically apply machine learn­ing 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, anoma­lies, and other indicators or predictors of mali­cious behavior. For example, consider malware attack 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 inter­actions between files, processes, and network connections can quickly reveal the origin of the attack — the website, document, or appli­cation that caused the problem — and deter­mine 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 sys­tems 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 con­text 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 endpoint 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 net­work 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 intelli­gence 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; au­tomated integration only works for network-based indicators. Endpoint detection and response tools can consume various threat feeds and automate the detection of indi­cators of compromise in real time, without performance-intensive scanning.

Incorporate existing signature-based sys­tems into the collaboration system by gener­ating a signature from your analysis and thus preventing the attack in the future.

Process Is King

Other industries have survived the transi­tion from “prevent only” to “detect and re­spond.” The cyber-security community should learn from what banks have done in automat­ing fraud prevention. Banks responded to increasingly successful fraud attacks with pre­vention 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 automati­cally, behind the scenes, with banks anticipat­ing, 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 modify­ing 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, avail­ability, and confidentially of the data within the organization. It’s time to get started.

Topics: Cyber Security, malware analysis, endpoint security, malware attack, malware security

Subscribe to Email Updates

Posts by Topic

see all