FireEye - Part 4. Drawbacks of FireEye (current!)

September 20th, 2014

Currently, there are 2 drawbacks that I can think of:

  • HTTP and SMTP only. FireEye only does the malware code detection on HTTP and SMTP today.  Malware that used SSL for the exploit and callbacks would only potentially be caught by C&C traffic signatures.
  • Malware authors may fool FireEye: As FireEye gets more popular, there is a chance malware writers will begin to modify their malware to detect and fool the FireEye similar to the way malware authors try to detect and fool VMWare Honeynets today

I might add, these drawbacks existed when Vontu (Symantec DLP) evolved and they (as well as WebSense) crossed SSL hurdle.

As for the second drawback, this remains to be seen as it is true statement even for a large company such as Symantec AntiVirus today (See NYTimes story on how Symantec could / could not stop chinese hackers)

Previous posts:

Part 1: Why FireEye? How it works?

Part 2: FireEye deployment practice

Part 3: Collection of articles on how FireEye brought (or attempted to bring) down botnets

FireEye - Part 3. Collection of articles on how FireEye brought (or attempted to bring) botnets down

September 18th, 2014

Previous part of FireEye deployment is here

I hope you will enjoy this part as I enjoyed reading through these articles - it sounds very similar to a spy stories how has infiltrated enemy front and contacts the command center. The only difference is, this spy (malware) is bad spy and the command center people are bad!

Let me point you to this article here. If you enjoyed this point, here is part 2. These come from FireEye themselves. I am passionated  with FireEye technology and I am not endorsing their technology because all technologies have their peak and plateau and I am not saying this is the best out there.

If this interested you, you should visit this 5 part series which got me hooked!

Killing the beast - Part 1

Killing the beast - Part 2

Killing the beast - Part 3

Killing the beast - Part 4

Killing the beast - Part 5

Personally, I envy these guys at FireEye - amazing experience.

Subsequent blog:

Part 4 : What are the downsides of FireEye

Previous parts:

Part 1: Why FireEye? How it works?

Part 2: FireEye deployment practice

FireEye - Part 2. FireEye deployment practice

September 17th, 2014

So, now that we know how FireEye works in theory (see part 1), how is it deployed? Is it inline? It is active or passive?

The following recommendation is an excerpt from FireEye themselves and the diagram shows a simple deployment.

FireEye has an implementation strategy much like a gateway Anti Virus product or an IDS. The deployment would be in a location that sees user traffic coming from and going to the internet. In order to prevent False Positives, we would want to be deployed behind all current defenses such as IPS, Web Filter, Gateway AV, etc, that might block attacks that we detect. In other words, we don’t want to alert on things that would later be blocked. For operational sake, we would also like to be deployed on the inside of a NAT or NAT-like device, such as a non-transparent proxy, so that we see the correct source IP of the infected system. From an analysis perspective it doesn’t affect fidelity, but from an operational standpoint this would be suggested.

We saw what FireEye ’simplified’ the deployment (they always say that, don’t they?) above. They also allude to best-practice of deploying inside NAT or similar.

Subsequent blogs follow

Part 3 : Collection of articles on how FireEye brought (or attempted to bring)  botnets down

Part 4 : What are the downsides of FireEye

You can find previous part here

Part 1: Why FireEye? How it works?

FireEye - Part 1. Why FireEye? How it works?

September 15th, 2014

FireEye makes a difference today because, like what the CEO of FireEye expressed this for Forbes magazine, “Much of the money you are spending on computer security is focused on fighting the previous generation of threats, not the current ones that are the most dangerous that compromise over 95% of organizations”.

The previous generation of threats were mostly ‘pattern’ attacks - attacking open ‘known ports’ as an example. However, today’s threats are leveraging irregular and unconventional ‘multi-faceted’  attacks.  Another way of looking at it is, in the diagram below, the attacks were simple and had 2-3 phases of attack and it was easy to block these.  However, it has now become complex.

If you think about it, the known and unknown ports, entry points (browser, emails etc.) have remained the same however, the threats have increased. There is a combination of phases of attack involving emails, browsers from the front, botnets, malwares, worms, virus etc. in the back, in addition to the attacks on other vulnerable computers. As it says in one of the SANS whitepaper “Over the past 10 years, computer attacks have shifted from operating systems to applications”. So, CEO of FireEye is right that the exposures has remained the same however, threats have increased today.

So, Why FireEye and how it works?  Rather than me explaining, here is the excerpt on how FireEye works from Forbes. See diagram from FireEye themselves.

Finding Threats that Don’t Want to Be Found

Finding threats that are expertly concealed and utilize multiple steps to take over a system, takes a three stage approach that combines aspects of machine learning and a cloud-based knowledge repository. Here’s how FireEye works from a high level:

  • On the way in to an environment, the initial attack malware is embedded inside ‘good’ traffic, such as within Web pages, emails, or in documents. But at some point it has to do something incriminating to kick off an attack. The challenge is separating unusual but harmless actions of a Web page or email attachment from embedded malware attempting to do dirty work. The first thing that the FireEye system does is scan for suspicious Web traffic, email attachments, and/or documents on file shares tag it for further analysis. In other words, FireEye starts with a bunch of weak signals that could or could not be pre-cursors of a problem.
  • For example, once a web page does something potentially suspicious, FireEye then sets up a virtual execution environment in which to safely execute, or ‘detonate’, that Web page in the safe confines of a virtual environment. Inside the virtualized environment, the suspicious Web objects are all run through its paces and observed. If it is a normal page, then FireEye learns that the potentially suspicious behavior wasn’t a problem. If the malware starts an attack, say by exploiting the PDF plug-in, the malware activities all happen inside the environment so no harm is done while full malware forensics and outbound communications are captured. At that point FireEye can say for certain that malware has been identified and stop the attack from exfiltrating data.
  • So, the malware forensics can then be shared by all FireEye systems through a ‘protection’ cloud network. The malware knowledge repository gets smarter at an increasing rate the more systems are involved. The sharing of machine learning enables the protection of the rest of the system before they get hit. Participants do not have to wait for an updated virus detection file to be installed to be protected. This reduces the window of vulnerability during day zero of an attack.

Subsequent blogs follow

Part 2 : FireEye deployment practice

Part 3 : Collection of articles on how FireEye brought (or attempted to bring)  botnets down

Part 4 : What are the downsides of FireEye