|
|
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
Copyright © 2012
IDsec Ltd
5.11
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
