TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
majordomoiss.net Contact issforum-owneriss.net for help with any problems!
----------------------------------------------------------------------------

Guys,

Carl said "If you can afford them it doesn't make sense not to have them both".

John highlighted the need to do "risk assessments" and identify your key assets
and the threats against them, then deploy technology accordingly.

Chris mentioned "defense in depth".

I think everybody was right in their own way. I used to argue for layers and
layers of security in every environment, but in those days I was driven by
security and paranoia rather than practical business risk mitigation. These days
I think it's important to understand how you get the most "bang for your buck"
in terms of security - and IDS - deployment. Thats "bang for your buck" in terms
of risk mitigation.

HIDS and NIDS both have their own particular strengths, and newer hybrid systems
add to the list of considerations. I would be worried that a NIDS-free system
would not detect attacks against my comms kit, or people probing for
non-existent hosts, or stray traffic traversing my network; it would offer
little protection to HIDS-free servers. However concentrating on NIDS means that
I can't check for local (keyboard-access) attacks against servers, I struggle
more with checking encrypted traffic, I have less granularity of control. The
list goes on...

I think I would go for HIDS and NIDS before dual NIDS, but that would depend
very much on the perceived threat levels and asset values of what I'm
protecting; I can see that dual NIDS could make sense in some cases (am I
sitting on the fence here, or am I sitting on the fence?).

However I think that I would struggle to convince many businesses of the cost
benefit of having dual NIDS, especially commercial ones, where we would need to
have engineers skilled in each (unless we out-sourced them). When I sometimes
have to justify any form of IDS, let alone HIDS and NIDS, then putting forward a
cost case of dual NIDs would be pretty tough in some of the places I've worked.

I'd be most interested if anybody could share how they've convinced people to
stump up the money for their intrusion detection deployments.

Jason

On Thu, 23 May 2002 09:34:39 -0400, you wrote:

>
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>majordomoiss.net Contact issforum-owneriss.net for help with any problems!
>----------------------------------------------------------------------------
>
> John,
>
> Ok, I'll bite on this one.
>
> First, I would like to say that your idea doesn't seem to employ two
>different brands of IDS, which I think is what this discussion is all
>about. The reason for using two different IDS's was already stated. Using
>one type of IDS, and I'm sure the company that it comes from will tell you
>up and down that they see all the traffic, will cause you to miss some
>traffic. Just like AV software, two different AV packages on your desktop
>will detect a broader range of viruses than one will. That's just the
>facts. So your idea of protecting the network with one brand of IDS does
>not catch as broad a range of traffic.
>
> Second, your method of two network sensors, I'm just labelling them that
>since they seem to be functioning in that manner, on the internet
>connection as the only network protection I guess could work on a small
>network. One in which you had a network segment behind the firewall with a
>couple of users and that was it. Now, I don't know if this is the size of
>your network or not, but if it is anything larger than that, than I don't
>think you're seeing all the traffic. I guess I am talking about defense in
>depth. What if you have multiple router hops and dozens of network segments
>from your workstation to the firewall, and the only piece of protection you
>have is a network sensor way out on the other end? While this sounds good
>on paper, I say that it is an idea that comes from small networks or people
>who have not actually had to tune policies on network sensors in a large
>network environment. This is why, with thousands of users using the
>internet everyday sending millions of packets with a high bandwidth
>utilization, your false positive rate goes through the roof, it becomes
>impossible to monitor. That's one thing, so what to do about that? You
>would have to tune the policies for the engines on the outside differently
>then engines on the inside taking into account the broad range and amount
>of traffic. It's like a funnel, with the engines on the outside being the
>wide end and the further you go inside the tighter the noose, if you will,
>gets around the traffic. Another point along those lines is that there are
>certain types of traffic which can be monitored on the outside that are not
>supposed to be there, whereas if you tried to monitor for it on the inside
>you would overload the engines. Again, if you only have one set of engines
>that are monitoring only internet traffic, you're only seeing a small set
>of the events out of all the events you should be seeing due to the need of
>tuning a policy on the outside loosely or differently. That's not bad
>tuning, it's just the limits of the software.
>
> I know what you're saying is that if you have an engine monitoring
>incoming traffic, and internal hosts accounted for with desktop protection
>that you should be covered. But in my experience, I haven't been able to
>make it work out that way. One thing I did not understand is when you said
>"....and server sensors on the host.", I am assuming that you meant on your
>servers. But what about the desktops? End users are what the whole network
>was created for. Unless the only users you have are using laptops and
>coming in via VPN.
>
> One reason for the defense in depth is that you are not relying on just
>one point for your protection. Any number of things can go wrong with that.
>You didn't get an update for that product to see a new type of attack, or a
>vulnerability of that product exists that has not been published yet and
>your engines, for instance, aren't really working at all because of the
>vulnerability that the hackers discovered that they are using to full
>effect. I think the difference in opinion, after having looked over this,
>is the size of the network you are trying to protect. In smaller networks,
>this type of plan works fine, but I'm not getting the warm fuzzies with
>this type of plan for a large network. This is of course just my opinion.
>Please, fire at will.
>
>Chris Mahn
>
>
>
>
> John Taylor
> <john.taylortoler To: "Moore, Carl, Mr., PEC-ARNG" <Carl.Moorepec.ngb.army.mil>,
> ant.co.uk> "'sixty seven'" <ssixtyhotmail.com>, issforumiss.net
> Sent by: cc:
> owner-issforumiss bcc:
> .net Subject: RE: Cisco IDS + RS IDS
>
>
> 05/22/2002 05:23
> AM
>
>
>
>
>
>
>
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>majordomoiss.net Contact issforum-owneriss.net for help with any
>problems!
>----------------------------------------------------------------------------
>
>
>Guys,
>
>to be frank I think you are doing it all wrong, using late 90,s ideas and
>the "same old stuff"!
>
>If I was building a solution I would not look at the network topology and
>methodologies employed but look to the real issues and risk assessments. In
>Europe we have provided a structured approach which has yielded superb
>results for large multinationals by looking at what you need to protect and
>how best to achieve it rather than looking at network pipes and older
>methodologies. A recent solution we put together was based purely on what
>was needed rather than what had been previously employed.
>
>The client already had Cisco Netranger and some Realsecure Network Sensors
>and it was simply not able to handle the bandwidth or the VLAN issues. The
>question was whay are you doing it that way? A risk asessment identified
>the
>true areas of risk which were actually quite simple: Access to the internet
>and from the internet to both web servers and users desktops, possibilities
>of internal abuse to corporate servers and a major risk from VPN Notebook
>PC's out in the field. The solution was simple, two RealSecure Guard on the
>internet links, (thus protecting all Company resources from attack there),
>Realsecure Desktop Protection on the remote notebook P.C.'s and Server
>Sensor's on the host.
>
>The entire network protected with not a single network sensor! (could argue
>the Guards are sensors but they are in-line!) Standard Network Sensors
>were,
>in my humble opinion, great in the days bvefore switched networks and VPN's
>but times have changed and simpler more manageable solutions are required.
>We see such a solution as above with ICECap Manager looking after the
>Guards
>and Desktop protectionb and feeding alerts to Site Protector which is
>managing the server Sensors and controlling an automated Internet Scanner
>as
>the best that can be achieved today.
>
>Any comments anyone?
>
>John Taylor
>
>-----Original Message-----
>From: Moore, Carl, Mr., PEC-ARNG [mailto:Carl.Moorepec.ngb.army.mil]
>Sent: Monday, May 20, 2002 6:52 PM
>To: 'sixty seven'; issforumiss.net
>Subject: RE: Cisco IDS + RS IDS
>
>
>
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>majordomoiss.net Contact issforum-owneriss.net for help with any
>problems!
>----------------------------------------------------------------------------
>
>
>ALCON,
>I am currently running both the RealSecure sensors and the Cisco IDSM
>modules on my 6500s. This solution gives you the best of both worlds. What
>one system doesn't catch, the other one does. When you find a signature
>that
>is firing off on one and not the other, you write a custom signature. Due
>to
>equipment limitations, I run RealSecure sensors on the outside of my
>firewalls, on my DMZ's, and on my server vlan. I have three IDSM's covering
>the other vlans. The server vlan ends up getting double coverage. I am also
>running about 50 vlans and have never oversubscribed my IDSM's, but
>sometimes the RealSecure sensors miss traffic. I don't have any of the
>Cisco
>IDS appliances yet but I plan on purchasing a couple of 4210's later this
>year. If you get the 4230, it can handle multiple vlans. This is just like
>running McAfee and Norton on the same network. If you can afford them it
>doesn't make sense not to have them both.
>
>Carl W. Moore
>Network Engineer
>National Guard Professional Education Center
>
>
>-----Original Message-----
>From: sixty seven [mailto:ssixtyhotmail.com]
>Sent: Monday, May 20, 2002 10:48 AM
>To: issforumiss.net
>Subject: Cisco IDS + RS IDS
>
>
>
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>majordomoiss.net Contact issforum-owneriss.net for help with any
>problems!
>----------------------------------------------------------------------------
>
>
>All,
>
>Due to problems with switched LANs and VLANs, we are considering a Hybrid
>solution with ISS Real Secure and Cisco 6500 based Cisco Secure Poloicy
>Manager for IDS. Has anybody tried this b4.
>The network in Q? has more than 50 VLANs with Cisco 2900, 3500 and 5500
>upward of 600 in total. Spanning seems a bit unrealistic.
>Any Ideas? GURUs out there!
>
>
>
>
>_________________________________________________________________
>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
>
>
>
>
>
>
>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]