I recently had a chance to get some soak time with some of FireEye’s suite of cyber security hardware at a customer site. They deployed NX, HX and CM appliances into their network. DTI (Dynamic Threat Intelligence) was also purchased, I’ll go into that more in a later post. Following is an eye chart of FireEye’s comprehensive suite of products as well as a more in depth description of the products that were deployed at this particular customer site:
The NX appliance is responsible for monitoring and stopping web based attacks, zero day web exploits and multi-protocol callbacks. What this means is that the appliance is constantly monitoring traffic coming into your network. It looks for suspicious activity based on known exploits and how they work (i.e. modify the registry to turn off the firewall, turn off anti-virus or spawn multiple processes and delete the original executable to hide itself). Once it finds something suspicious, it can analyze the behavior of the potential threat using it’s Multi-Vector Virtual Execution (MVX) engine. The MVX engine will detonate the payload in an isolated and heavily instrumented VM environment where it can log exactly what the exploit does and how it does it. Once it has this information and it has identified the exploit, it can automatically block it from getting into your network.
The HX/HXD appliances are used to monitor endpoints (windows desktops/laptops, servers or even cellphones and tablets) for compromises. It monitors all endpoints across the entire organization at once and is able to correlate suspicious activity. Once a threat is identified, you then have the option of downloading a triage package that consists of detailed information about what the system was doing or even isolating or containing an endpoint from the network so it can’t cause any additional harm to the environment. The appliances are typically deployed both in the internal network and the DMZ. This gives the additional ability to protect remote endpoints that connect externally as well as internal ones.
The CM appliance is basically the command center for FireEye that is able to communicate with all other appliances and provide a comprehensive view of what is going on. It has the ability to reach into email, file storage, endpoint, network and mobile platforms and correlate activities in a single pane of glass. One of the big benefits of this product is it’s ability to stop multi-vector attacks that span multiple platforms. By deploying the FireEye NX, EX, FX, HX and AX series together with the FireEye CM series, the analysis of blended threats, such as pinpointing a spear-phishing email used to distribute malicious URLs, and correlating a perimeter alert to the endpoint, becomes possible.
The vast majority of customers that purchase HX appliances also purchase DTI for its obvious advantages. The MVX engine is the really cool part of what FireEye has to offer. Below is a description of MVX:
The FireEye Malware Protection System features dynamic, real-time analysis for advanced malware using our patent-pending, multi-flow Multi-Vector Virtual Execution (MVX) engine. The MVX engine captures and confirms zero-day, and targeted APT attacks by detonating suspicious files, Web objects, and email attachments within instrumented virtual machine environments.
The MVX engine performs multi-flow analysis to understand the full context of an advanced targeted attack. Stateful attack analysis is critical to trigger analysis of the entire attack lifecycle, from initial exploit to data exfiltration. This is why point products that focus on a single attack object (e.g., malware executable (EXE), dynamic linked library (DLL), or portable document format (PDF) file types) will miss the vast majority of advanced attacks as they are blind to the full attack lifecycle.
The customer was able to deploy the endpoint software to hundreds of agents automatically by using Group Policy profiles to push out the installer and run it silently. Once that was done, we tested containment which essentially takes the machine off the network until you can decide how you want to react. If the endpoint has been determined to be safe, you can then un-contain it through the GUI.
We did run into what seems to be a rather interesting glitch during testing of the containment process. We contained a machine that was originally on the internal network. We then placed it on the VPN and due to some initial configuration issues, it was unable to contact the HXD appliance to receive the un-contain instruction. The result left the machine unable to communicate on the network and no way to fix it. Surprisingly, we were able to revert to a previous system restore point when the agent hadn’t been installed yet. Thus we circumvented the whole containment process.
I’ve not yet decided if this truly is a bad thing since by reverting back to a point before the agent install, it would essentially rid the machine of the exploit as well. Regardless, I was a bit dismayed at how easy it was to bypass containment. Assuming the end user was not malicious (they wouldn’t have infected their own machine) I’m not sure this is a really viable scenario. One potential would be an exploit that was aware of the mechanics of how the agent works and communicates- in which case it could theoretically block communication to the HX. This would manifest as an endpoint that hasn’t checked in for awhile and would probably arouse suspicion as well.
In summary- I’m extremely impressed with FireEye’s ability to detect and block very complex and coordinated attacks where other products fall down completely. The MVX engine in particular is something to behold- the level of instrumentation of an exploit is truly incredible. To take this a step further, if you purchase the AX appliance, this also gives you the ability to do forensics against the exploit including a video of the exploit during detonation (along with all the other telemetry that is captured). This could prove to be invaluable to root cause analysis in situations where it’s required to determine exactly how an exploit works.