** About Us > Briefing Papers > IDS Sensor Information Gathering

The configuration of intrusion detection sensors requires the
understanding of many aspects of their environment.  This paper
presents a "strategy document" that is created for each sensor,
combining the understanding of the monitored platform owners,
the IDS designers and the event response function, as to the
objectives for each sensor.  This document then becomes the basis
of sensor policy and tuning.

By Kevin Graham

* Organisational Security and Intrusion Detection

As stated in the paper The Placement of IDS Sensors for Security
Monitoring, the security of networks should follow a zoned
approach, allowing concentration of security resources into key
areas. An assumption is made that other authorised parties do
not breach the separation of zones with inappropriate technical
solutions, and that implementation of security systems is
consistent between zones of equivalent class.

This paper is concerned with the documentation of the operating
environment, objectives and purpose of sensors used in Intrusion
Detection Systems. The approach used is based on the collection of
relevant information, cooperation with relevant development and
integration specialists, and the review and incremental tuning
of IDS sensor behaviour.

The process is concerned with the detection of security threat
agents, from external sources attempting to break through layered
defences, and from internal sources using a wider variety of
trusted access mechanisms. This requires a balance between
prediction of likely attack vectors, and detection of anomalous
behaviour in normal systems operation.

The structure presented at the end of this paper focuses on a
solid foundation for creating the requisite policy for the IDS
sensors consistent with performing this task effectively.

* Information Gathering

The most important part of the IDS tuning process is the collection
and consolidation of appropriate documentation for the purpose,
exposures and mechanisms involved in the monitored systems. This
documentation forms the heart of the sensor strategy document,
and should be sufficient to ground value judgements on sensor
policy. The best attempts to produce a policy based on in situ
observation will never be as effective as a properly researched
solution.

The strategy document is an important milestone in the
implementation of an IDS sensor. This document records the shared
understanding of monitored platform owners, intrusion detection
system designers, and the event response function, as to the
security objectives for this sensor.

* Understanding Network IDS Sensors

Network sensors work at uncovering potential security threats at
a number of levels. The basic observation of network traffic in
a particular direction, to an address or network, or involving
a specific service, is based on information that would have been
available for the configuration of firewall technology.

The detection of application failure, authentication or
authorisation errors, or misbehaviour of accepted component
connection logic, are possible with more information on which to
base sensor configuration. Most varieties of network sensor work
through the matching of real life network traffic to a selection of
stored signatures, which are examples of application or protocol
misuse.  Signature creation is also possible for well-defined
exposures and systems, which then become an addition to the
signature base that underpins the intrusion detection logic.

Network sensors are best able to detect attempts to attack
the whole of a platform, or the reconnaissance carried out by
manipulation and probing through network traffic. The common
mechanisms used to automatically attack particular software
platforms will be covered using signatures provided by the IDS
manufacturer. These sensors are not able to model the operation of
the platform's business logic, and so regular review and tuning
is required, to ensure that relevant signatures and appropriate
event reporting continue to provide a level of threat detection.

* Understanding Host IDS Sensors

The deployment of host IDS sensors is more about operational
compromise than any other aspect of intrusion detection system
integration. These sensors are installed in the same manner as any
other software, and generally fit into the class of applications
labelled as "three tier". The sensor communicates security events,
in line with its policy, to an IDS event-gathering component.
Different products have a variety of mechanisms for detecting
events: file change detection and log file signature matching
are common; SNMP handling, system audit handling and platform
protection are less common. Products are generally moving towards
a combination of detection and protection, carried out at the
network or application proxy level.

Platform owners are rightfully concerned with loading and
utilisation by applications not core to business function. One
of the goals of the strategy document for host sensors is the
specification of detection activity sustainable with acceptable
impact to normal service delivery.

Host sensors are best able to automate regular checking to
detect platform compromise. This includes file change monitoring
and signature pattern matching in log file activity, such as
failures to authenticate or gain authorisation. This process
retains the forensic value of the recovered information due to
regular and consistent monitoring and alerting. One particular
application of host sensors is for log monitoring for network
components such as switches, routers and firewalls.  By using a
host sensor to process the log patterns of these devices against
its signature base, it is possible to uncover privilege misuse
and the application of a variety of common methods to gain more
control of the hardware. This can also help provide an audit
trail for configuration changes, whether authorised or not.

* The Sensor Strategy Document

The presentation of the strategy document becomes important when
managing a network of sensors. The structure presented here gathers
the information that differs between platforms into one section,
coverage. This is information that is generally only available
to those with specialist knowledge of that one area.

The sensor strategy would be presented in sections such as:

- Physical. Appropriate documentation of location, management and
access to the platform.  Information required to find and manage
the sensor. The implementation specifics.

- Business case. The investment in sensor technology, configuration
and maintenance is substantial. The motivation for this investment
should be recorded here.

- Function. What will this sensor deliver to the event response
function. The expectations set with the event response function as
to priority, thresholds, and the relationship between events raised
and those expected to be significant. This should provide some
ongoing guidance in the operational aspects of policy maintenance.

- Tuning. The updating, exceptions, exclusions or clipping required
for recalibrating and maintaining IDS alerting.

- Coverage. The underlying detail required from the specialists
who understand that area.

* Network Sensor Coverage

The following information will be requested of the specialists
who are implementing services that cross the network segment that
is to be monitored by the sensor:

- Network traffic flow. To understand the content, direction
and purpose of network traffic on the monitored segment, and
be able to identify the best applicable signatures to detect
relevant threat-agents. Similar information would be required
for firewall configuration.

- Application data flow. To understand how the application is
exposed with regard to network traffic availability. Particular
emphasis should be placed on potential attack vectors, exposures
and opportunities for detection of anomalous behaviour.

- Exceptions. Sensor behaviour that should be excluded from
reporting, such as noisy signatures, or expected traffic flows
that should or could not be monitored by this sensor.

- Value. An understanding of the magnitude of business risk
involved, to better identify alert priority, and appropriate
resource commitments to regular activities such as tuning.

* Host Sensor Coverage

The following information will be requested of the specialists
who are implementing services on the platform to be covered by
a host sensor:

- Operating system. The base system on which the platform is
installed, and any infrastructure on which it is dependent. The
host sensor will monitor system log files, detect key system file
changes, and alert on evidence of privilege escalation or change.

- Service applications. Applications that are exposed, but not
generally with a user interface.  Often these applications are
involved in authentication or file transfer.

- Middleware. Applications principally involved in the managing of
interactions between other services. Messaging and web transaction
management are both examples.

- End-user. Applications that have a direct interface with the
end-user. An understanding of how components interact and use
other services, in order to identify anomalous behaviour and the
mechanisms by which this would be logged or otherwise recorded.

Data flow and business logic maps for application behaviour are
useful when looking to detect anomalous behaviour.  Parameter
manipulation is a favoured attack in penetration testing, which
may go unnoticed by sensors using only a simple policy with the
manufacturers attack signatures.

The host sensor provides a convenient central collating point
for events raised by other point- solutions on the host. Simple
scripts that check for process continuity or provide for a level
of correlation can be executed and reported into the IDS. Better
understanding of the services provided to end-users will always
help, especially those provided across untrusted networks.

Historically, many host sensors have been configured to cover only
operating system and service applications. This is mostly due
to the effort required to Analise and access the risks involved
in application logic, and to configure the controls provided by
the application manufacturers for an appropriate level of access
control and logging. After deploying host sensors, it is possible
to revisit this configuration, later in the platforms life-cycle,
and make good some of this work.

* 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-info.txt 20120510     (5.11)