Integrated Framework for Intrusion Management

Integrated Framework for Intrusion Management

Status

This project has ended.

Researchers

Prof. Dr. Bernhard Plattner, Communications Systems Group, ETH
Stefan Frei, Communications Systems Group, ETH
Dr. Marc Rennhard, Communications Systems Group, ETH

Background

During the past years, Intrusion Management (IM) has developed by enhancing traditional, standalone Intrusion Detection Systems (IDSes) with additional functionality. Today, IM usually means the integration and collaboration of different components, including network and host-based IDSes, firewalls, routers, and anti-virus software. Integrating these components means that the events generated by the different components are no longer analysed in isolation, but are first sent to a centralised correlation engine, which correlates the events and decides to raise an alert or not. These alerts are then displayed at a centralised management console for further processing by humans. One advantage of this integration of components compared to standalone IDSes is increased accuracy, especially with regard to false positives. For example, if a network-based IDS detects an attack against a host but the attack traffic is blocked by a firewall, there is no need to raise an alert. A second advantage is better manageability, because all alerts of the entire security infrastructure are collected and displayed at a single place.

Beyond integrating different components, IM also makes use of additional information about the systems that must be protected to further increase the accuracy of the alerts. This is also known as target-based ID and involves (1) prioritisation of alerts because some hosts are more important than others and consequently, some alerts should be handled more quickly than others; (2) host context, which means periodical scanning of the hosts for known vulnerabilities and using this information in the correlation engine to determine if an attacked host is indeed vulnerable to an attack or not; and (3) network context, which means including the topology to decide which segments of the network need more attention with regard to attacks than others. As a simple example of including host context, one can imagine an attack exploiting a known vulnerability of the Internet Information Server (IIS): if the correlation engine “knows” that all IISes within the company are correctly patched or if the company does only run Apache web servers, there is no need to raise an alert.

Motivation

The main motivation for this project is that although IM has matured significantly over time, several open issues remain. At this time, we identify three major problems:

Today, Intrusion Management Systems (IMSes) are usually limited to a single corporate network. While this has advantages from the point of view of management, such an IMS has only a very limited view of all activities going on in the Internet. In particular, it is not well suited to detect suspicious activities below a certain threshold. For instance, a hacker carrying out slow port scans to probe different networks is likely to remain undetected unless information collected by the different networks is aggregated. In general, if we move from isolated IMSes to a more global approach, we can imagine several attack scenarios which we could detect and defend against much better than we can today.

During the past years, a lot of research has been going on to improve the accuracy of the results generated by the correlation engine. However, there remains a fundamental problem with the approach of using data from all these components in the sense that these data are mainly produced by legitimate network traffic or user actions. Consequently and from the point of view of detecting malicious activities, these data include vast amounts of noise, which greatly impacts the accuracy of the results generated by the correlation engine and therefore the overall usefulness of such IMSes. Honeypots could be one possible source to get more accurate information. The motivation is that since honeypots are not publicly known and do not provide real services, all data sent to and from honeypots is considered suspicious. Therefore, the data collected by a honeypot may be used to identify the true risk of attacks, which could provide better results than simply analysing vast amounts of information produced by the individual components of an IMS.

IM is still a very technical issue that is not well integrated into the business processes of the company it protects. As a result, although the IMS per se may provide good protection from attacks in general, it may well be the case that some critical business processes are not adequately protected while less important assets receive “too much” attention and therefore protection. In addition, even if the IMS was correctly designed and configured when it was installed, businesses and their processes tend to change over time and assets that were previously not so important may suddenly become mission-critical. To overcome these limitations, one could imagine an integrated framework for IM that covers all aspects of IM, which including (1) the requirements analysis, which should be driven by the business processes; (2) the design of an IMS that optimally serves a specific company environment; (3) the implementation and operation of the system; and (4) the change management required during operation. Ideally, such a framework should provide as much security for the operation of the business processes as needed, but no more, thereby minimising the cost incurred for information security in relation to the risk of business interruption.

Current Status and Outlook

The project is still in its very early stage and we are currently analysing which of the three problems we identified above is the most interesting and promising to be attacked within the context of this project. As soon we have a more detailed project description, this page will be updated.