If a tree falls in a forest with no-one to hear it, does it make a sound? So goes a typical zen-like philosophical question. While it’s thought-provoking, what does it have to do with Intrusion Detection Systems (IDS)?
Simple – if you're not there to watch the tree fall, do you need to know whether it fell or not? The same principle applies with IDS.
There's a forest of threats to your network out there. Do you set the IDS to watch every tree, and risk getting lost in the detail? Or do you focus only on the trees you think represent the biggest threats, and risk missing an attack?
There's no easy answer. What's more, IDS are known for producing false positives. They can miss new attacks. They need regular care and maintenance. But IT's plate is usually full with other issues, like software management, backups, AV issues, VPNs, firewalls, spam filtering and more.
So IDS can be something of a handful for IT. It's no wonder that outsourcing IDS activity to a trusted third party is a popular choice.
But how do you ensure that a third party delivers the right managed service? Which IDS configuration will suit your network best? Should you be doing internal detection of potential attacks, or perimeter detection? Here's a guide to identifying your network's needs, the questions you should ask of a third-party IDS provider – and to the shortest route to inner network calm.
Configuration matters
Usually, IDS are configured either for internal detection, or perimeter protection. For internal detection, sensors are placed to protect key servers, connecting back to a centralised database.
These sensors will have two network interface cards. One will be placed in promiscuous mode, gathering data; the second will be configured with an IP address to send data from the sensor back to the database.
For perimeter protection, sensors can be placed inside or outside the perimeter firewall. If outside, the sensor sees all attacks on the network, including those stopped by the firewall – giving an overall threat level. This would demand a firewall to protect the sensor.
The management network includes a database which each sensor writes to, and a front end enabling managed service staff to view and respond to alerts in real time.
Internal affairs
If sensors are placed inside the firewall, the IDS only sees attacks passing through the firewall – which also prevents viewing of threats blocked by the firewall. This solution is intrinsically safer, as both the customer's firewall and the sensor's firewall need to be defeated before the attacker can hit the sensor.
To avoid overwhelming sensors, the solution should have multiple sensors, each protecting a single server or group of servers.
Questions, questions
When it comes to choosing a third-party IDS provider, it's vital to ask the right questions to ensure you get the right service.
First, what IDS solution does the provider use? Is it open source or proprietary? From a technical and commercial standpoint open-source solutions such as Snort are often preferred. Snort signatures for major new alerts are usually available faster than for commercial solutions – giving earlier protection.
Second, how does the provider link to the sensors on your network? It should be done via an encrypted tunnel to avoid external sniffing.
Third, what service level options are available to you? How fast can the provider update the managed IDS? What's the speed of response? The provider should sit down with you and assess threats, risk levels, and responses.
Finally, what reporting can the provider offer? You should get quick, pro-active alerts of major issues, backed by regular reports outlining the attack profile on your networks.
All of these points should be enshrined in a SLA covering the activities done by the managed service organisation, the level of reporting and alerting.
With the right approach to a managed IDS service, you can save the costs of buying your own IDS solution, and spare yourself the stresses of managing the solution – leading to inner calm in both mind and budget.
The author is the director of Network Defence
