Intrusion Detection Systems (IDS) are an integral part of many technology ecosystems. Quite often though the approach of having these systems in place come into the purview of a refresh in architecture or in many cases, such systems have not been implemented yet in a given environment, for a number of reasons. Understanding what this technology and its role to the security posture of an organization is the first step in evaluating this technology for a given environment. Simply put, it is a program or appliance that detects unusual occurrences and patterns in your network traffic and overall system usage. It may be host-based or network-based, and can be described to work in general terms utilizing the following two techniques:
- Monitoring system usage. For instance, it can monitor Central Processing Unit (CPU) usage, logins, workstation usage and other system events to spot unusual events and usage when compared to established patterns. Say, if a group of workstations are typically idle after midnight, you IDS can alert you to unexpected logins or CPU activity
- Signature recognition. In this technique a signature recognition database is used to monitor traffic passing over a network. In the case of commercial IDS systems, it typically relies on a database of attack signatures and applies a system of comparing packets traveling across the network to known attack signatures. IDS’s may have limitations on how many packets can be effectively monitored, therefore it is a good idea to know what your needs are, the capacity in terms of volume the system can process and definition of overload conditions.
IDS systems run the gambit. Some are physical thin appliances, some are dedicated servers, and some emerging platforms are virtual appliances. There are even many that are free to implement. These are typically open-source and carry an operation risk as training, support, and reliability of such a freely distributed tool needs to be considered before bringing into the enterprise environment.
It has often come into question what an IDS does for the security posture of an organization when investment and infrastructure has already been put into place with an enterprise-grade firewall. Note that under a number of regulations, the requirements therein often include systems that employ alarms that sense abnormal conditions within your network. From a more practical perspective, an IDS is a very effective tool that has the capability of signaling when someone is misusing a system, or launching suspicious processes, attacks or exploits to gain access to protected information.
Deploying an IDS requires proper planning and preparation. Doing so also requires a deep understanding of the organization’s environment and goals. Once in production IDS operation also bears the consideration of continued monitoring and process refinement.
The following framework is designed to help with the IDS selection process.
Tackling Risk
A proper risk assessment is a part of the earliest steps of any technology initiative. Additionally, assigning value to risks to the organization in the case of an IDS system framework will help an organization decide on the complexity, features, and operational functionality that will meet their needs. A good strategic starting point might be the most critical information to be protected, such as financial information systems. Perform an evaluation and analysis on the locations where such systems store and transmit information. Protecting other parts of the network that are linked to the Internet would be a logical next step to evaluate. Work towards addressing a select to a complete collection of organizational assets where valuable records, internal documents, email and so forth will need to be prioritized.
With this index of protectable asses, matrix of network protection needs should be clear. If you have a CMDB, spreadsheet, or other indexed inventory of systems, hardware and networks you have a great start. Along with any network diagrams, you can use these to further flesh out a basis for IDS strategy. If you don’t have these tools available, you really need to get there.
At this point, you can begin comparing IDS systems. With the knowledge of the architecture, topology and identification of network segments storing the organization’s most sensitive information, you can begin laying out a plan for your IDS. By the way, this exercise can be valuable even if you have an IDS already in place, since it may help you discover vulnerabilities that you are not aware of.
Many solutions have two-level approach where a mix of network IDS and host IDS are implemented for targeted systems. It is important not to dismiss this construct as it is done for the reason that network IDS systems have been known to be fallible to overflows, false header information, 0-day exploit and other subterfuge that has the potential to break that first line of defense. Encrypted traffic also creates a potential impact on a network IDS device. IDS devices are typically single-homed, causing a strategic element due to such possible limitations. Complex network configurations can also have performance or capability effects on a network IDS system. So consider these elements, ask questions and vet the technology you are considering.
IDS systems that have a presence on the host are advisable despite a number of setbacks. First of all, they present a remote management point, adding to overall operational effort. They also could be considered to affect system performance, though this may be negligible on modern high-powered systems. Basically their value is in that they provide a presence at the point of data protection desired. Though nothing is infallible, knowledge of that presence in combination with network protection combine for the best posture possible.
Depending on a company’s needs, the presence of an IDS outside the company firewall to monitor all attacks could be something to consider. IDS systems inside the perimeter may be dedicated to monitor all attacks as well. Some organizations may even have a second brand of platform IDS to gauge the effectiveness of the primary IDS device and provide an additional layer that protects against platform vulnerabilities, device failure and so on. Again, it all depends on your needs, and budgets are another major factor.
A layered IDS infrastructure offers the benefit of having more flexibility and deeper level of protection. This also comes with the pitfalls of device monitoring and management that need to be tempered in an appropriate deployment. During evaluation, a product bake-off could be implemented to setup up separate IDS products side by side and evaluation the logs of all the alarms they receive. Note whether they are both able to stop the same exploits.
Regardless, you should be setting up and testing an IDS in a test environment way before production. The goal is to check for any software conflicts and allow for the opportunity to identify the need for any specialized signatures that may be required before installing it in production.
Action Item: Wrap up
The ultimate truth is that there is no one ideal security solution, whether you have a simple network, a complex multi-site super-regional network, or any number of specialized environments, the bottom line is that this is a process that bears evaluation and careful consideration. Look for products that have good support, minimal maintenance needs, and a known presence for the type of solution you are looking for. References in your own industry can be extremely beneficial.
It is also important that the planning process starts early and establishes your goals from the beginning in a formal, written and shared plan with all stakeholders. Doing so will eliminate the all too common problem of project creep that can lead to costly overruns.
Looking ahead, it is also important to consider that IDS systems require continual tweaking and process development. Centralized maintenance and access offerings can benefit more complex multi-point systems as well. Process development will mean training and documentation as well. These final elements will help to reduce operational factors such as false alarms and minimize the maintenance required overall.
Footnotes:
