** About Us > Briefing Papers > The Placement of IDS Sensors

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)

* About Us

IDsec is an independent company specialising in network security,
and has provided penetration tests and intrusion detection
systems since 1997. We can assess the security of your enterprise
and advise on long-term protection: as we have for a range of
blue-chip clients in the banking, telecoms, manufacturing and
utility sectors.

IDsec Limited 31-33 College Road, Harrow, Middlesex HA1 1EJ,
United Kingdom

T: +44 20 8861 2001 F: +44 20 8861 3433 W: www.idsec.co.uk

All prices exclude VAT and are subject to confirmation.

Copyright (C) 2012 IDsec Limited

about/briefings/ids-sensor-placement.txt 20120510     (5.11)