Educause Security Discussion mailing list archives
Re: FireEye appliance
From: Jay Krous <jekrous () LBL GOV>
Date: Wed, 22 Dec 2010 11:52:56 -0800
Hi Peter:
I am looking for information from any of you that own one of the FireEye appliances (or know someone who has one). We are looking to purchase one of these appliances, but the 7000 series is priced too high, in my opinion.
We own a 4000 and really like it. Excellent http malware detection. We tested a 7000, 4000, and 2000. We too struggled with the pricing of the 7000 and settled for a 4000. We only send it 80/tcp traffic.
I am wondering if any of you own an appliance, what model, what are you pushing thru it, and what was your decision making process, if any?
See attached for a summary of our decision process and the pricing we we offered. Below, also please see a summary we shared on another list. Feel free to contact us at cppm () lbl gov if you have any other questions. -Jay Partha wrote: The security group at LBL [Lawrence Berkeley National Lab] has been using various models/releases of the FireEye product for about 6mos. Overall, we feel it is earning its daily bread, in terms of money cost, implementation time and on-going operational effort. SOME DATA: We are monitoring our wireless network as well as the wired network with a the 4000 Series appliance http://fireeye.com/products/products_page.php?id=15&keywords=Technical_Specifications The wired network is 10gb, so we've "stepped down" the traffic to a 1gb feed of just HTTP, so there may be some analysis/detections going missing but it's finding plenty of stuff. We are NOT using it as an inline device, but as a detect-and-notify device. The notification channels are, as you'd expect, an appliance console, email, and syslog (a few syslog formats avail). So that should fit in with different work environments ... from the operator in front of a console, to people working with arcsight/splunk, so using random unix tools to process and build "site policy" for fireeye data [right now i am processing with a mishmash of procmail, awk, perl, syslog-ng, shell]. It too is part of layered defense here ... many endpoints monitored do have AV software running, there is a border IDS/IPS etc. So we have not analyzed in great detail "what is the backstory of what it is finding" or in others words, trying to quantify the "marginal benefit" ... we already know the marginal benefit is worthwhile, and suspect the "backstories" are not going to be especially surprising [laptops infected offsite, no AV software installed, successful phish/driveby dl etc]. We've sort of settled on "act when it warns twice" as the FireEye SOP. There are a reasonable number of cases where it warns about a machine once and then never again. In our experience these multiple warnings happen within a pretty short time frame ... i.e. the machine is definitely compromises and is generating plenty of bad traffic in short order. We generally do not see a machine generates a single warning, then goes quiet for an extended period and then we see more warnings ... we have not investigated in detail what the backstory was. In a few cases it did seem to be a false positive, but in other cases it is likely the machine was a visitor machine left the internal network, in other cases the code may have been ephemeral rather than persistent and a browser restart/machine reboot etc "fixed" the problem. There are also a few alert flavors which we know to ignore [e.g. warnings about remote machine compromises based in inbound traffic]. This is clearly an area we plan to do some operational refinement. SOME OPINIONS: --there were some odd issues with the administration GUI. bugs? side effects not totally clear? etc no deal breakers here --the product is still evolving. mostly this means things are getting better. but it also may mean some feature you build on may go away or change format. [for example the syslog format flavor i was used to and was using for post-processing went away in a software upgrade]. --over all, i think these guys are pretty smart and they have set out to solve a fairly narrow problem [i.e. they dont seem to be moving into AV software, email appliances, web hosting, cloud computing etc] so there is good reason to believe they'll get better [false positives should come down more, richer feature set, better decision-making feedback etc]. for example, in the earlier release the "confidence" value was meaningless. it now seems to be something worth paying attention to. --one difference between our environment and a university is we dont really have the equivalent of "semester start" ... so i could see a large, overwhelming, spike of detects as a large number of "pre-infected" machines come into its sights. that may be a difficult situation to deal with. -- Jack (Jay) E. Krous III Cyber Security, Information Technology Division Lawrence Berkeley National Laboratory http://www.lbl.gov/cyber/pgp-krous.txt (510) 495-2522
Attachment:
FireEye Buy.docx
Description:
Current thread:
- FireEye appliance Peter Charbonneau (Dec 07)
- Re: FireEye appliance Jay Krous (Dec 22)