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: