IDS Placement on the network

[OverdueSpy]

Vikram7000 Just an FYI here - If you are new to the IDS arena, one of the challanges I have seen many organizations face, is that most IDS platforms do not have a reliable backup plan. Most of the IDS companies claim that their products are recoverable if you will simply back-up the database. In reality this is normally far from the truth. For instance if you loose the HDD that the, I'll say "event collector" for lack of a better term, ... that the event collector is stored on, your first challange will be with the encryption scheme that allows the database on the event collector to communicate with your remote detectors. Normally this is not a big challange, but most of the IDS platforms tie the encryption key into an "instance per installation" type of schema. This means that while you still have your database and can get to the information, you will be unable to integrate it with any new data going forward.

The second challange is with the custom policies that you build to reduce displaying false positives, e-mail or text notifications, etc. Most of these polices have flags that are tied to the old database, which are once again tied to the encryption key installation instance, even though the policy is in essence a flat file. Typically this requires the administrator to rebuild any custom policies from scratch, because the expected pointers become no longer valid.

The third challenge I have seen, is that after you have brought up a new database, you will have to reinstall all of you remote detectors to make the encryption schemes match.

This is all based on my personal experience with different products, and may not be applicable to what you are running, but it is definantly something to look at before a failure occurs. If anybody else has experience playing with backup availavbility for IDS, pleas post your thoughts. I look forward any info on an easily recoverable IDS solution.

[di0strb]

Thanks OverdueSpy for the heads up i am new to the ids scene and in the process of testing some ids system for future deployment. Your post gave me a lot to think about and ad to my tests.

PS i think you just saved me from a lot of late nights kicking and screaming at my ids.

[Mykol]

Guys, with all due respect, you're getting off the subject. I agree with whtabtbill about his observation, and the poster didn't ask about the best way to create an "enterprise IDS implimentation."

The original question was "where is the best place for an IDS?" Sounds like a single to me. So far, I've read responses about using multiple IDSs, Snort, user policies, etc., etc.. After the first couple of posts, the thread went haywire (no pun intended).

So, "where IS the best place for an IDS?" If you only have one, I would put it on the inside of both routers, closest to the servers, workstations, etc.. I do pen-testing for a living. I see these things "all the time":

- open VPN access (right through or past the firewall and IDS),
- modem access (that never goes through the routers),
- router compromise (and access through the IDS),
- IDS compromise (game over),
- Trojan action from inside,
- malicious insider,
- workstation comrpomise (exploit from the inside).

Wouldn't placing the IDS on the inside router help prevent most of these? Oh, and have it face both ways...

my $.02.

[thehorse13]

Excellent responses by OverDueSpy...

IDS/IPS "solutions" are/can be very tricky indeed. Taking what was said a step farther, be *sure* that if you do run an IDS/IPS in-line that it fails open. I have seen some major IDS/IPS vendors with appliance based IDS/IPS solutions that failed closed in line. This means that *all* trafffic stops. Can you imagine cutting off 10,000 users simultaniously? Also, if you go an extra step and buy an IPS solution, my advice is to run it in "log only" mode for at least a week. This will allow you to understand how it would have reacted if you had full IPS turned on.

Now, different vendors make different claims when it comes to the actual quality of data you receive. Here is what I can tell you about the vendors I have dealt with.

Cisco 4235 series on the 4.x platform - Many false positives. Signatures are kinda clunky to update. Console is too many layers deep (have to click about 10 things before seeing what you really want). Reporting is awful.

ISS Proventia G series - False positives are minimal. Configuration is easy. Management console is clean and uses common language to give you the info you want (EX: Show me the source of this event). Signature updates are easy to get but the HUGE pain in the ass is that whenver you get a new signature you have to reconfigure all of the signatures. I have bitched to ISS about this and perhaps they will modify the bahavior down the road.

I have also heard that NAI has finally gotten their act together in the IDS/IPS arena but I have yet to demo their product.

The bottom line here is that you may want to take the layered approach but you also may want to go a little bit deeper with a multi-vendor layered approach. You can argue for or against this but in my experience, this has proven to be the best overall approach.

And finally, you are going to have to do some serious traffic analysis and aggregate data at different layers as to not be overwhelmed with meaningless security data. I could write a book on this but just be aware of it from the start.

Wouldn't placing the IDS on the inside router help prevent most of these? Oh, and have it face both ways...

If I only had one device, and I trusted my firewall, then yes, an internal IDS would serve you better overall but placement on the inside is just as important. I would pop it off a management interface of the core internal router but that's just me.
--TH13

[Tiger Shark]

Mykol:

You seem to be forgetting two things.

1. Most environments are switched and many, especially smaller shops don't use managed switches so viewing internal traffic with a "single" IDS is very difficult.

2. Let's be a little creative. A single IDS can monitor many parts of a network at relatively low cost. Just keep adding NIC's till you fill up the slots..... I have a single box that monitors inside and outside my firewall, it has two NICs. If I wanted to monitor somewhere deeper in the core of my network with the same box I add a NIC, cable it to an appropriate point to capture the traffic and configure another instance of Snort. Total cost: $20 for the NIC and a few dollars maybe for a new cable - I might be able to patch it in though existing cabling. I kept all my old hubs when I moved to switches.... What can I say.... Packrat....

The examples of things you see are common I'm sure but they fall into two categories really. Improper configuration, (VPN, modem, router, IDS compromise), and the rest are a question of "acceptable risk of doing business" and fall into that "balance of security versus usability" area that makes our jobs so much more interesting......

The initial question was, IMO, a little "over simple", (no offense to Vikram), but to be able to properly monitor anything outside a single collision domain you need, at a minimum, multiple interfaces otherwise Murphy's Law clearly states that the traffic you _need_ to alert on will never enter the collision domain you are monitoring. So, unless Vikram intends to only monitor a single collision domain he's going to need more than one interface or IDS depending on the capabilities of his IDS solution.

In Vikram's case he uses the word "enterprise" which to me implies a multiple collision domain architecture and the use of a single IDS placed just inside the firewall. IMO, in a single IDS/interface environment he is placing it optimally insofar as he is placing it at the point of greatest risk. Having said that he will miss all the traffic that remains internal to his network unless the network is _entirely_ hubbed. That precludes him from monitoring much of the risk posed by malicious users, open modems, worms traversing the network via shares etc. etc. etc unless he can wire the network in such a way to ensure that all traffic passes through the IDS which, in an existing network, can be harder than one may think... I recently discovered that I was omitting a whole subnet because the wiring wasn't quite the same as I thought I had.....

Vikram: I would suggest looking into secondary sensors appropriately placed in order to more thoroughly monitor the network. Snort is good and the price is right and can be run from multi-use servers or workstations in many cases without significant overhead or risk of packet loss which will help to keep the additional costs down.

[vikram7000]

As Tiger Shark rightly put it, I am now leaning on placing the main IDS just inside the main firewall and placing some more secondary sensors inside of the network to monitor the intranet traffic. I am gonna have to do this in all the locations on the network. Yes it is gonna be a multiple collision domain. Thats why I in consultation of my colleagues have decided as you rightly put it, to place some sort of secondary sensors for the internal traffic and the traffic between our various locations.
The deployment might start off sometime next week hopefully(keeping fingers crossed).

[Highlander]

IDS works best if it is at the Border Router to your network.
This is not to say you may need more than 1 IDS to protect
your network.
The IDS I am somewhat familiar with is the Cisco line.