IDsec Limited / About Us / Briefing Papers / The Placement of IDS Sensors

About Us > Briefing Papers

Feel Good About Your Network

IDsec Limited
31-33 College Road
Harrow, Middlesex
HA1 1EJ
United Kingdom
(London: Map)

T: 020 8861 2001
F: 020 8861 3433
www.idsec.co.uk

		This paper provides some basic guidelines for the placing of sensors used by intrusion detection systems, given that security monitoring requires an appreciation of the assumptions made in the underlying operational security model. Further points are made on the purpose of intrusion detection and the value obtained from it. By Kevin Graham

Organisational Security in Perspective

The security of networks should follow a zoned approach, much like the layered skin of an onion. This enables a concentration of limited security resources into more tightly defined areas, in order to maximise the return on the security investment. This is based on the premise that quite broad network areas can be defined in a single zone, and the zone treated consistently with other zones of similar classification. The most highly skilled and least available resources can then be pointed at the borders between security zones, which are quite limited areas of higher risk.

Inner security zones are expected to feature individually approved and appropriate implementation of components and processes for the level of consequential exposure. Appropriate security mechanisms include technologies such as layered firewalls with staggered proxies, direct attack mitigation through web filtering and intrusion prevention systems (IPS), indirect attack mitigation through virus protection systems, and authentication of source authority.

This layered security approach depends on trust. Trust that other parties with the necessary authority do not unwittingly allow an inner security zone with an inappropriate security defence to face the exposures of an outer zone by approving or implementing mechanisms not suited to that environment. Trust that the implementation of security systems is consistent across security zones of equivalent class.

This paper is concerned with the detection of security threat agents, from external sources attempting to break through the layered defences, and from internal sources using a wider variety of trusted access mechanisms. This relies on monitoring, carried out through the implementation of IDS. The guidelines presented at the end of this paper focus on trying to get IDS sensors deployed in the correct areas, to be able to perform this role effectively.

Intrusion Detection Systems (IDS)

The purpose and exposures faced by computer networks vary. Using the security zone model above, outer security zones face wider exposure and greater consequential risk of compromise. Inner security zones normally contain assets of greater value, which have limited direct exposures through the implementation of other security components. Inner zones may be better understood, but often pose more challenges in designing security mechanisms to detect trusted misuse.

Network security components can be grouped into several classes by function; but the domain of security mechanisms and components, other than IDS, is more often enforcement than monitoring. As with any other enforcement mechanism, this sharply limits their scope of action. Monitoring is different from enforcement. Monitoring has a wider theatre of operation, with significant factors from a much wider range of operational services, which includes enforcement systems, and is more concerned with damage limitation, liability, audit trails and evidence. The role of IDS is in the uncovering of anomalous traffic or behaviour in the monitored area.

Intrusion detection systems gather the necessary clues, automatically, that enable the most productive use of security analysts in what is often a forensic capacity.

Designing Intrusion Detection Systems

Monitoring security through IDS requires a combination of: good sensor placement, well defined sensor behaviour, appropriate sensor configuration, regular tuning and a sound strategy for event response.

Network Sensor (NIDS) Placement

NIDS require access to network traffic, typically provided by network taps situated at points of network restriction such as firewall and router interfaces. These taps allow the IDS to see network traffic without being connected to the monitored network. To be useful, the network traffic should be complete. For most purposes this requires little thought, however, the designers of “high- availability” network solutions often allow network traffic to flow over several alternate routes to prevent single points of failure in their solutions. This introduces a little more complexity in the IDS design, as network taps may now be required in several places, and their outputs combined in order to see all of the traffic.

The network traffic seen by the NIDS should be anticipated, classified for risks, and documented. The sensor policy will be based on an alert strategy that recognises the exposure of the monitored area, and takes into account this network traffic and the event alerting requirements of the event response process.

In general, network taps for NIDS should be placed where:

security zones meet; especially for external zones. It is normal to tap both sides of firewalls with direct external exposure, and on the internal interface for all firewalls connecting to internal networks (exposure)

the network traffic of third parties, or network access to sensitive resources presents undesirable consequential risk of exposure to virus, trojans or fairly general malicious intent (threat)

the consequential exposure of a well defined information asset is clearly defined in terms of threat-agents and mechanisms, and the risk is deemed suitably unacceptable (risk)

Host Sensor (HIDS) Placement

HIDS are installed on application servers, but, unlike NIDS, these components are not in general wholly controlled by the security function. To be useful, this software must be configured to its environment. To do this, the nature and purpose of the application host must be understood, and the location, logging, and modes of failure of each application documented. The sensor policy will be based on an alert strategy that defines the platform's risk and exposures, and the event alerting requirements of the event response process. This would include the placement and permitted change of operating system and application files, normal expected network traffic, and the purpose and utility of operating system and application log files in the recording of security significant events, and any other opportunity for detecting evidence of inappropriate or anomalous behaviour.

In general, HIDS should be placed where:

log files from applications and operating system services facing direct Internet exposure are present. This would include front-line hosts and those systems used to gather log files from front-line components (exposure)

administrative and maintenance access occurs, including emergency routes, third- party provisions and systems with time-limited or temporary status. This will resolve individual responsibility for authentication and authorisation auditing (threat)

an escalation in user or application process privilege to generic accounts with overriding access occur, whether of the operating system or application domains. This would generate a wider consequential exposure. This would include systems enabling access though a generic super-user account (with su, sudo, set-uid or set-gid equivalent systems) or application identity tokens. These systems must be shown to keep adequate audit information to map privileged activities to the originating user or process (threat)

a system of trusted remote access relies on single factor authentication, whether network distant or from a lower local security zone. This would include secure-shell without passwords, telnet, ftp, rcp and other remote shell, copy, or procedure call services (threat)

significant retention of information with consequential value occurs, especially in the outer security zones. This would include databases holding DPA sensitive material for normal portal processing, and those systems used for data-integration, forecasting or data mining where the aggregate exposure is higher (risk)