Enterprise IDS - Deployment & Uses

Question

I am investigating deploying the Snort IDS for an enterprise environment. This environment consists of a NOC that manages several servers, mainly internal but some internet facing. There are several paths to the internet from the NOC and the server's, as well as several paths to the DC from the NOC. My question is:

Should the IDS be deployed to primarily monitor inter-LAN traffic (a NOC employee inadvertently brings a compromised computer onto the network) or to monitor internet facing traffic (exploits against the web server).

Most of the network is heavily segmented and firewalled. The only things remotely reachable from the outside are VPN appliances and a web server cluster. Everything else is internal. Is an IDS necessary? What types of attacks do they block? For a web server wouldn't it make more sense to port block at the firewall and deploy a good application layer firewall such as ModSec to filter SQL injection\XSS. I don't think an IDS is used for that

Answer 1

I'm going to answer both your questions in a kinda non-specific way, but bear with me.

Your first question is "I'm putting in an IDS, what should I tell it to do?"

Well, you're doing it backwards, but don't worry - this is a common security confusion.

An IDS, like any security system, is not a magic wand. You don't just install it and everything's hunky dory. It's a tool, that you use to treat a specific risk.

So you have to start with a risk analysis. Identify all the threats you face, and the vulnerabilities in your setup that those threats might use to harm your assets. Those are the risks. Identify the likelihood of those risks happening, and the harm they could cause. Those are the risk levels. Now you can tell which risks you are happy with, and which you need to treat.

For example, if you decide that "a NOC employee inadvertently brings a compromised computer onto the network" is a risk that is currently at an unacceptable level, then you sit and figure out a way to fix it. Part of that fix might be to have an IDS sitting inside the NOC looking at all the traffic going by. Not all of it though - you'll probably also be looking at improved scanning of machines before they get in, better processes for employees, etc. etc. You pick the control based on how well it reduces the risk.

Then you do the same process again for "exploits against the web server" and all the other risks your analysis found.

The key is: Identify and understand the risk first, and then put treatments in place to reduce it.

Your second question is "I have a strong perimeter, do I need an IDS behind it?"

There's an important security principle called "defence in depth". Basically, don't rely on one control to protect you. Layer controls, and think about what happens if one fails.

Sure, you have a strong perimeter, and little is going to get through, and thats good. But if something does, wouldn't it be nice to have an IDS there that sees it?

Of course, the question is if it is worth the expense. Snort's free, sure, but your time isn't. That's something for you to work out, based on the risk level - how likely is something to get through, how much harm could it do? Maybe it's worth it, maybe not. That's a pure business decision.

Answer 2

Sensor placement can be very tricky as there are loads of variables to consider. At minimum, you should take into account

• Classification level of monitored resource
• Network design
• System throughput
• Personnel time (for management and analysis)
• Resource availability

Throwing all of those into a blender and turning on high for a few minutes will give you some nice data to start with for determining your deployment. Deployment planning is a multiphase process, and while they are not intrinsically separated, it is beneficial to remember that they are different parts of the same plan.

Data Collection and Planning

More likely than not, what you're going to want to do is construct a list of all of the systems that you want to monitor, then rate them based on importance or risk. That should give you a prioritization of what systems you really need to be watching now. In a perfect world, we would have a sensor monitoring the link connected to each and every system. However, that would be scary expensive, difficult to maintain, and noisy. Instead, talk to your network team and take a good hard look at your network design. Figure out on the network map where your prioritized systems live and figure out where the choke points are. Look at what hardware you have available to turn into sensors. In an awesome environment, you could have one big box with a few 10Gbps interfaces and do all of your monitoring for an entire enterprise using a single sensor. However, more likely, you're going to have a few surplus systems that used to be used by department secretaries and will need to spread the load.

Array Design and Deployment

Now is the time to think long and hard about what risk acceptance threshold is. How close to the sensitive data do you feel like you need to have a sensor, and how far away do you feel comfortable placing it? In some cases you may really need to monitor the switch port that a server is directly connected to. In other cases placing a single sensor on a building or floor uplink, and ignoring any intra-switch traffic, is sufficient. In another case you may feel as if mirroring a specific port is not good enough, and instead mirror an entire VLAN.

Workload and Other Considerations

As you're building our your sensor deployment strategy keep in mind that it can get very complicated. As you decide where to place your sensors, make sure to account for all of the other issues that arise. For every sensor you deploy there will be management overhead for an employee to actually maintain the system (apply patches, hardware replacement, etc), application management overhead (updating signatures, tweaking rulesets, making sure snortd stays running), and analyst time (interpreting the alerts and taking action). Depending on your design, and how much time you're willing to front-load, these numbers can vary wildly. For example, using the right configuration management/automation tools, it's not that difficult to manage several dozen snort sensors using a fraction of an FTE.

For full disclosure this was originally posted as answer to this question. We're not sure it's worth merging them, but the answer definitely works here too.