[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ISSForum] Proventia Devices (Fiber packet captures)



Eric,

Maybe I do not understand the versions of the sensor you are using or
maybe I do not understand the exact scenario you are experiencing, but
many signatures do provide an indication of success/failure. Certainly,
in the case of most HTTP attacks, our 7.0 sensors do report the server
result code.

Currently, you can configure the sensors to log all packets and you can
configure the newer ones to capture the packet that triggered an event.
It sounds like your concern is that our network sensors do not allow you
to log a subset of the traffic, such as all packets from one IP for
example. Is that correct?

Paul

-----Original Message-----
From: issforum-admin@xxxxxxxxxxxxxxxx On Behalf Of HACKER, ERIC W
Sent: Wednesday, January 28, 2004 5:28 PM
To: King, Bob (ISSAtlanta); issforum@xxxxxxxxxxxxxxxx
Subject: RE: [ISSForum] Proventia Devices (Fiber packet captures)

It is going to be very hard for me to explain this in a nice way since I
am
so used to ISS not understanding how their product gets used in the
field,
especially in a large enterprise. Log evidence is mostly worthless for
much
of what a packet trace is used for.

For starters, one will need packet captures outside of the IDS engine to
determine why false positives or false negatives are occurring. This is
even
more critical in a closed signature sensor.

When one is installing a sensor, one must test to be sure that the
sensor is
properly hooked up to the network. In a large enterprise, there are many
times when the IDS engineer is not physically hooking up the device
and/or
configuring the devices that are sending the traffic to the sensor. ISS
support suggests turning on an HTTP signature and sending an HTTP
request.
This is inadequate. There are many instances where:
	1) There are firewalls in the way that would block sending an
HTTP
request from a convenient system.
	2) There is not web server available on the other side for
testing
(especially as we build the network ahead of the servers).
	3) One must test for bidirectional packet captures, as
specifically
on the 604 and 1204 when using taps to send the traffic. This is
especially
a problem on the 1204F where there is a high opportunity for the person
connecting the fiber from the tap to plug it in to the sensor wrong.
	4) One must check to see that a switch span is set up correctly.
This can involve multiple VLANs. It is simple to start a snoop/tcpdump
and
watch all the VLANs. It will be a pain to send multiple attacks out each
time for validation and match them up to multiple events in the console.
[1]

ISS is currently incapable of providing signatures that can determine if
an
attack is successful. ISS Scanner is woefully inadequate for enterprise
work. [2] Fusion is two to three years behind the SIM competition and
mostly
disappointing. Why can't Network Sensor look for a simple 404 on a
simple
web query? Since ISS can't do it, there are some people who have
scripted
their own packet capture responses to do it themselves. An analyst can
then
quickly eliminate the failures. Having no multiple packet captures
eliminates this very effective method to make scale RealSecure to
hundreds
of sensors.

There are times when one may want to watch all the activity of an
attacker,
not just what is triggering alerts. It would be difficult to quickly
coordinate with the network team to have someone set up a sniffer to do
that. Sometimes the sniffer requires the SPAN port that the network
sensor
is using. The sensor should be able to do this.

If some of these needs sound new and haven't been asked for by customers
before, perhaps it is do to the fact that network sensors previously
could
do this. It is difficult to imagine that one could build a sensor
without
thinking about capturing packets as a requirement, especially given the
backgrounds of some of the engineers there.

Eric Hacker, Enterprise Security Information Architect, FleetBoston
Financial

[1] Nevermind cluttering up all the 'real' attack data with a bunch of
events that are only for testing. 

[2] Try having discussions with a data-center manager that you have to
deploy this software on a workstation class box and he's just going to
have
to buy a shelf for the rack and waste several rack units. Then try
securing
the OS install.

> -----Original Message-----
> From: King, Bob (ISSAtlanta) [mailto:BKing@xxxxxxx]
> Sent: Wednesday, January 28, 2004 2:01 PM
> To: HACKER, ERIC W; Reeves, Mike; issforum@xxxxxxxxxxxxxxxx
> Subject: RE: [ISSForum] Proventia Devices (Fiber packet captures)
> 
> Actually both the A604 and A1204 support Log Evidence.  This feature
was
> added to the higher-end Proventias last year, and it provides for raw
> packet capture and display of the packet on the SiteProtector Console.
> You don't have to use any additional software such as tcpdump.
> 
> It is the packet that triggered the event that gets forwarded to
> SiteProtector.  The only possible drawback is that only one packet is
> captured.  I have had several customers ask for multiple packet
capture,
> and we are researching that implementation, but right now a single
packet
> is captured.
> 
> So unless I missed something you should be OK.  Hopefully this is good
> news.
> 
> Bob
> 

_______________________________________________
ISSForum mailing list
ISSForum@xxxxxxx

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo

_______________________________________________
ISSForum mailing list
ISSForum@xxxxxxx

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo