Best practice for creating an initial IPS policy

Question

I see that most IPS available in the market comes with a basic pre-defined policy which administrators can base on when creating their initial IPS policy. However, these policy may be insufficient and the administrator may need to dig deeper. As such what is the best practice when creating an initial policy and making sure nothing gets missed out.

Of course we will be given a list of applications, OS, known ports, etc in a network and we can create a policy from there; but do we keep it strict and limited to the list given to us or do we loosen up a bit for wider protection coverage.

For example, if a web server is running Microsoft IIS but not FrontPage, do we enable rules / signature for both IIS and FrontPage Extensions to ensure that the IPS will be able to pick up FrontPage exploit / probing attempts?

Also, how do we ensure that the usability, functionality and security as well as the performance of the IPS itself is not affected by the IPS policy we've created as some of the rules / signature in certain IPS solutions that I know have overhead / performance impact.

Answer 1

I would normally advice to deploy your IPS in non-blocking mode to start off with running the default policy, plus any other signatures\policies that specifically apply to whats running on your network.

Once that policy has been up and running for a while and you are happy with the following

1. The false positive rate
2. The performance stats (packet drop etc), especially under high load (pps,throughput)
3. The tunning you have done to eliminate false positives

Then you need to consider whether to broaden the set of policies enabled. In doing so you need to consider the following.

• Have you full control over applications\nodes deployed on your network ?
• Will you be alerted if new applications\nodes appear on your network ?

In an ideal scenario your IPS will only have signatures enabled which cover the applications running on your network. The advantage of doing this are as follows.

1. Lowers the possibility of a false positive blocking legitimate traffic, the less signatures enabled the lower the false positives.

2. In general the lower the number of signatures enabled means better performance reducing the chances of malicious traffic going undetected due to performance problems.

Once you have this done you should consider enabling blocking mode on your IPS.

Answer 2

Unless you have a performance or other problems I like to start with the largest most all inclusive policy I can. I then remove/edit rules on a case by case basis. I would recommend keeping rules that don't necessarily cover products you have, like the Frontpage Extensions ruleset, unless you have a procedure in place where IF someone does start developing some awesome Frontpage app then you add the appropriate rules. Even if there is no way you will ever install a product/technology on your network you can still be alerted when some script kid fires off an exploit for a product you don't own.

So I like to start with the default ruleset, watch the logs, remove or edit rules that produce false positives, add another ruleset or two, rinse and repeat.

Answer 3

I would suggest when implementing an IPS in an environment to first put in passive mode. You need to see what traffic is coming through first to identify what is valid traffic and what is not. Since you are already going to have gathered a list of known ports and protocols that need to have traffic entering the network it will make it easier.

It takes time to tweak an IPS. You really need to start broad and narrow it down to make sure you will not affect any of the business. You want to protect your network but you need to keep the business functional too.

I would say this would be true before you implement any new device on the network that you are going to create rules for that could affect traffic on your network and in turn affect the business of your company.