Intrusion detection systems (IDS) have been the subject of endless articles, conferences, and discussions.
Yet, one fact remains: only a very small number of large organizations have deployed IDS technology. That fact leads some to question whether the IDS products are ready for prime time. It leads others to ponder the apparent paradox: detecting security breaches is unarguably an essential capability but, for the most part, companies are not doing much about it.
Based on our experience in managing some of the largest IDS deployments to date, we offer an alternative reason for the small number of deployments. Simply, deploying IDS is harder than it looks and, once deployed, it requires an ongoing effort to monitor the resulting alerts.
There are three primary aspects to IDS. They are: deployment, monitoring, and integration of IDS into enterprise processes. This brief article focuses on deployment issues. It touches on a few of the lessons we've learned about making large-scale IDS deployments successful. While many of the lessons apply to any large technology deployment, for the purposes of this article we'll focus on deploying IDS on an organization's Internet points of presence.
Ready, Shoot, Aim: Setting Expectations
Successfully deploying an wide-wide IDS system is challenging. It is going to cost more and take longer than you first expect. Take the few weeks up front to do the planning properly. Use this time to figure out what is realistic for your organization. If you don't have the expertise in-house to plan the project well, this is the best time to get some outside help.
One of the main reasons that IDS projects fail is that organizations mis-set internal expectations and consequently undertake IDS projects with inadequate budgets and unrealistic schedules. Large organizations, in particular, often overlook the cost of complexity in planning their IDS projects. This leads to the ready, shoot, aim scenario where critical planning only occurs after the project is in trouble. Good planning pays off.
IDS Products
Another main reason that IDS deployments are so challenging is that while IDS products have come a long way in recent years, there are still no products that work effectively out-of-the box. This is a two-part challenge.
First you need to understand the characteristics of normal traffic on your network and Internet access points. You need to figure out what types of vulnerabilities you care about (e.g., port scans, IIS problems, and Web application vulnerabilities). Performing the necessary network studies often requires a significant investment of time and money but it enables you to put the sensors on your critical networks, systems, and applications.
One of the most common mistakes we've seen is that organizations omit this crucial analysis step. Simply, without understanding your normal traffic baseline, you won't be able to recognize anomalous traffic.
Second, you need to finetune the IDS monitors to look for the things that you care about. For many of the IDS products, this requires development skills that are in short supply within the organization.
Complexity
Large organizations are often complex. They often span the globe and have substantially different IT infrastructure in different geographic regions. IT management, while nominally under a single global reporting structure, is more often than not, in practice, fragmented and regionalized. In most global enterprises there is no single person who can answer the simple questions, "How many Internet points of presence do we have and who is responsible for each one?"
We have seen over and over again that individual regional managers or lines of business have established Internet points of presence (usually for perfectly valid business reasons) and that the central IT group knows nothing about them. Let's call these 'surprise POPs.' When a central IT group plans an IDS deployment, it often doesn't truly understand the scope of the problem it needs to solve.
Surprises
In developing the IDS project plan and budget, be sure to include adequate time and funding to compile an accurate inventory of Internet POPs (including the surprise POPs) and POP owners. Only then can you determine the actual size of the project and your real hardware and software compatibility constraints.
You may find that you have to replace some number of insecure surprise POPs with the organization's standard firewall configuration before you can even begin IDS deployment. This highlights a remedial lesson as well; organizations should have a practical and auditable process for introducing new POPs.
Borders and Local Support
Many organizations source equipment for a worldwide deployment from a single location, often the vendor's main location. While this ensures consistency of the product, it means that the project plan must deal with all of the issues of shipping technology across national borders. These issues include indeterminate customs delays and hidden costs like import taxes.
Remember, you will face this problem again if an IDS component fails and you have to replace it. If deploying your IDS on a predictable schedule is a priority, consider selecting an IDS vendor that has a local presence in the countries you need. It is often worth the price premium you will pay to source and support the IDS equipment locally.
To state the obvious, if you are a global company, you'll probably want to select an IDS vendor that is global as well.
Local Change Management
In many global companies, IT procedures vary by geography. Change management tends to be one of those areas that varies greatly. For example, within the same company, we've seen installation of a Cisco IDS sensor take one week in Hong Kong and two months in Japan.
In planning your IDS deployment, make sure you understand the process to accomplish changes in critical infrastructure in each of the geographies. Remember, where there is significant regional autonomy, your priorities may not be their priorities.
If your organization does have highly autonomous IT groups, deal with the issue of priority setting directly. Make sure that there is a clear statement from each of the senior IT executives involved that the IDS project is a top priority.
Organizing to Analyze the IDS Alerts
Many global companies organize their IDS monitoring along regional lines. This alignment makes sense from several perspectives: support in similar time zones, proximity to lines of business, consistent IT management chain. Unfortunately, it has the unintended consequence of masking attacks on the enterprise as a whole that may span multiple regions. Each regional IDS center would only see alerts that impact that region.
Even where IDS alerts are handled regionally, a centralized mechanism to correlate alerts across regions is needed. This centralized IDS facility should have software to automate the alert reduction, parsing, and correlation process. Many organizations inadvertently find themselves on an IDS alert-treadmill. They burn out their support staff chasing down often-tripped (noise) alerts.
We've noticed that many organizations misunderstand the nature of intrusion detection - they think of it as a solution rather than a tool. This has three consequences:
- They don't allocate sufficient resources to monitor the events.
- They don't automate the monitoring to enable events to be handled most effectively.
- They don't integrate intrusion detection into their design, administration, and crisis response processes.
Realistically, the cost of monitoring and responding to the IDS alerts will dwarf the initial licensing and deployment costs.
The Last Word
IDS remains a promising technology. The ability to quickly detect anomalous behavior is one of the cornerstones of effective security. Deploying IDS in very large enterprises is challenging. The overarching critical success factors are:
- Good project planning.
- Knowing the scope of the effort and setting realistic budgets and schedules.
- Characterizing normal traffic and behavior.
- Tuning the IDS to recognize what you consider to be important.
- Selecting an IDS vendor that meets your geographic as well as functional requirements.
- Avoiding foreseeable delays.
- Understanding local constraints.
- Organizing to make the most effective use of the IDS system's output.
Jason Reed is a consultant and Jonathan Gossels is president, SystemExperts Corporation, a provider of network security consulting services (www.systemexperts.co).
