Get documents about "5. Introduction to IT intrusion detection
Document Sample
2321
ISO/IEC JTC 1/SC 27 N
ISO/IEC JTC 1/SC 27/WG 1 N 923
REPLACES: N 2142
Information technology - Security techniques
Secretariat: DIN, Germany
DOC TYPE: Working Draft
TITLE: ISO/IEC WD 15947, Information technology - Security techniques
– IT intrusion detection framework
SOURCE: Project Editor (L. Nelson)
DATE : 1999-08-20
PROJECT: 1.27.25
STATUS: In accordance with standing Document No 5, clause 5.2 (SC 27 N 1773)
this document is being circulated FOR STUDY AND COMMENT.
The National Body contributions should be submitted to the SC 27
Secretariat by the 1st of October 1999.
ACTION: COM
DUE DATE: 1999-10-01
DISTRIBUTION: P, O and L-Members
L. Rajchel, Secretariat JTC 1
K. Brannon, ITTF
W. Fumy, SC 27 Chairman
M. De Soete, T. Humphreys, S. Knapskog, WG-Conveners
L. Nelson, Project Editor
MEDIUM: Server
NO. OF PAGES: 12
Secretariat ISO/IEC JTC 1/SC 27, DIN Deutsches Institut für Normung e.V., 10772 Berlin, Germany
Telephone: + 49 30 2601-2652; Facsimile: + 49 30 2601-1723; E-mail: passia@ni.din.de
TITLE: IT INTRUSION DETECTION FRAMEWORK
Table of contents
Forward
Introduction
1. Scope
This Technical Report (TR) defines a framework for detection of intrusions into IT systems. A
wide range of intrusions are considered. These include intrusions that are intentional or
unintentional, legal or illegal, harmful or harmless. The TR focuses on:
• establishing common definitions for probes, sensors, monitors, attacks, intrusion, intrusion
detection, indication, events and other IT intrusion detection terms;
• defining events that can be used to characterize indications of intrusion activity;
• describing the kinds of data needed to implement and intrusion detection capability;
• discussing different methods (e.g., attack pattern recognition, statistical anomaly detection)
or combinations of methods intrusion detection analysis to achieve reliable results;
• describing the kinds of output that intrusion detection systems may produce;
• describing activities/actions in response to indications of intrusions
This framework explains the intrusion detection terms and concepts and describes the
relationship among them. Further, the framework addresses possible ordering of intrusion
detection tasks and related activities. It attempts to relate these tasks and processes to an
organization’s or enterprise’s procedures to demonstrate the practical integration of intrusion
detection within an organization or enterprise security policy.
This TR will develop an architectural reference model which will allow diverse intrusion
detection modules, such as data (event) collection modules, event analysis modules, and data
storage modules, to interact and work together.
(What it doesn’t cover.) This framework document is not intended to cover every possible detail
involved in intrusion detection, such as the detailed attack patterns, or statistical anomalies, or
the many configurations that a system could have. Nor does it intend to provide specific
intrusion detection system specification. (What the document doesn’t cover will be expanded.)
2. Normative references
ISO/IEC JTC1 ”Guidelines for the Management of IT Security (GMITS)’ TR 13335 Parts 1 to 5
ISO/IEC JTC1 SC21 TC68 N1106 ”Security Audits and Alarms Framework”
ISO/IEC 10181-7: 1996(E) ”Information technology – Open Systems Interconnection – Security
frameworks for open systems: Security audit and alarms framework”
ISO/IEC 15408-2 ”Information technology – Security Techniques – Evaluation criteria for IT
security – Part 2: Security functionality requirements”
3. Terms and definitions
(proposed definitions follow:)
3.1 intrusion: an intrusion is a deliberate or accidental unauthorized access to, and/or activity in,
an information technology (IT) system.
1
3.2 intrusion detection: the process of identifying that an intrusion has been attempted, is
occurring, or has occurred.
3.3 probe: an activity initiated with the intent of verifying an instance with either malicious or
non-malicious intent. A probe might be initiated to check for an available port by 1) a malicious
user for purposes of exploiting vulnerability or 2) a system administrator for purposes of
mitigating vulnerabilities; or, an entity used to perform the above activity.
3.4 event: an occurrence of some specific data, situation, or activity; an event could be quite
simple or it could be very complex.
3.5 sensor: an entity monitoring data (about the system targeted for intrusion detection) and
actively reporting to a central system on the data monitored.
3.6 monitor: a passive entity monitoring (observing and processing) data (usually to display
events to a central correlation and analysis engine or to a Security Officer).
3.7 attack: an intrusion event or sequence of events specifically initiated with malicious intent;
attack intents may include a desire to steal information, to intrude on an individual’s privacy, to
compromise a system or information in any way.
3.8 indication: information, such as about suspicious activity, events, or event patterns,
unexplained problems in an IT system, or out-of-band knowledge of an intrusion attempt, that
would lead one to expect an intrusion.
3.9 warning: notification of an event(or events) or of an indication(or indications) that an
intrusion is likely to occur or is occurring.
3.10 profiling: determination of a specific event pattern, usually related to a sequence of events,
which may indicate ”normal” or ”abnormal” behavior.
4. Structure of the document
5. Introduction to IT intrusion detection
Introduction (Include here a general discussion of intrusions, why they need to be detected, what
intrusion detection is, model(s) of the intrusion detection process, etc.; in general, give the reader
enough background and reason to continue reading. The intended target audience is security
management people.)
6. Need for intrusion detection
For justification for intrusion detection, reference is made back for security policy, risk
management, etc. to other SC27 documents, in particular GMITS and Common Criteria
documents. In particular, two areas should be covered as part of the need for intrusion
detection: 1) The role of intrusion detection in IT risk management, and 2) the relationship
between security policies and intrusion detection.
6.1 GMITS and Intrusion Detection - Introduction
The Guidelines for the Management of IT Security (GMITS), TR 13335-3, provide guidance on
the management aspects of IT security. This guidance is structured such that individuals within
organizations that are responsible for IT security can adapt the material to meet the specific
needs of their organizations, and indeed of inter- organization connection through both private
and public networks.
The principles of the management of IT security are set out in GMITS Parts 1 and 2 (TR 13335-1
and TR 13335-2). Part 3 (TR 13335-3) develops these principles by describing techniques for
addressing all aspects of the management of IT security, including on how to identify and justify
the need for safeguards (including such as intrusion detection). Part 4 (TR 13335-4) provides
guidance for the selection of safeguards, and Part 5 (TR 13335-5) for the selection of safeguards
with particular regard to external connections (in each case this could, as justified by the risks,
include intrusion detection facilities). In the following paragraphs, the links between GMITS Parts
3, 4 and 5, and intrusion detection, are highlighted.
2
6.1.1 GMITS Part 3
TR 13335-3 develops on the guidance provided in TR 13335-2 to describe the overall process any
organization should follow to:
• develop corporate IT security objectives, strategy and policy,
• institute an appropriate security management infrastructure,
• properly identify and assess the risks to the organization, and to individual systems and
networks,
• justify and effectively implement the safeguards needed commensurate with the assessed
risks,
• ensure that the safeguards continue to be implemented, used and where relevant tested
correctly,
• ensure that if security incidents do occur that they are managed effectively,
• identify the need for, and securely implement, adjustments to safeguard profiles as the
environment, technology, and risks change over time.
It describes in some detail how an organization should determine the approach to security risk
analysis and management that is most appropriate for it, and then sets out the preferred
approach. In summary, this approach requires that:
• the assets of a system or network, particularly information, are valued in terms of the
potential adverse business impact were breaches of confidentiality, integrity, non-
repudiation or availability to occur,
• the threats that might cause the potential adverse business impact are identified and their
likelihood of occurrence assessed,
• the vulnerabilities that might be exploited by the identified threats and their degree of
seriousness be assessed,
• the asset values and assessed levels of threats and vulnerabilities are assessed together to
determine the risks,
• the determined risks are used to identify and justify the safeguards that are required to
properly manage the risks.
It is recommended that the safeguards selected should be documented in a system security policy,
together with a summary of the justification, i.e. the assessed risks. Guidance on this is also
provided in TR 13335-3.
An Annex to TR 13335-3 provides a list of possible threat types to assist during the threat
assessment process. This list indicates for each threat type whether it can be caused by deliberate,
accidental or environmental events. The deliberate ‘category’ includes such as masquerading of
user identity, network access by unauthorised users, use of network facilities in an unauthorized
way, rerouting of messages and malicious software; i.e., it covers all types of unauthorised
intrusion. Another Annex provides a list of examples of common vulnerabilities, including those
that could be exploited by intrusion. In other words, risk analysis will encompass the likelihood
of, and thence the risks from, different types of intrusion.
Then safeguards will be selected to manage those risks of intrusion. These safeguards will include
those:
3
• to minimise the chances of intrusions occurring, or occurring and being successful,
• recognising that intrusions still might occur, to detect and recover effectively from them.
In the latter situation, if the risks were deemed sufficient, an intrusion detection facility could be
selected. Further, if the risks to a number of systems and networks were deemed sufficient, an
incident-handling scheme could be utilised linked to an intrusion detection facility.
It is worth noting at this point that there is another link to risk analysis. If intrusion detection
and incident handling facilities were used, there would be benefit from feedback to refine the
information on threats and vulnerabilities in risk analysis support ‘databases’, to in turn improve
the quality of risk analysis reviews.
Incident handling is introduced in TR 13335-3, at clause 11.5, with comment on its relativity to
risk analysis.
6.1.2 GMITS Parts 4 and 5
As a follow-on to the introduction to incident handling in TR 13335-3, in the detailed guidance on
the selection of safeguards provided in TR 13335-4, the topic is further developed, at clause 8.1.3.
Then guidance on the selection of safeguards for external connections in TR 13335-5 includes
considerably more detail at clause 11.2.5 and Annex B. Of particular note is that TR 13335-5 also
specifically introduces the topic of intrusion detection as a safeguard category, at clause 11.6 *
6.1.2.1 Extract from TR 13335-5 on Intrusion Detection
As external connections between organizations increase, it will become increasingly easier for
intruders to:
• find multiple ways to penetrate an organization’s IT systems and networks,
• disguise their initial point of access, and
• access through external networks and target internal IT systems.
Further, intruders are becoming more sophisticated, and more advanced methods of attack and
tools are easily available on the Internet or in the open literature. Indeed, many of these tools are
automated, easy to use and can be very effective even in the hands of a novice.
For most organizations it is economically impossible to prevent all potential penetrations.
Consequently, some intrusions are likely to occur. The risks associated with most of these
penetrations can be addressed through the implementation of good identification and
authentication, logical access control and accounting and audit safeguards, together with an
intrusion detection capability. Such a capability provides the means by which to predict
intrusions, and identify intrusions in real-time and raise appropriate alarms. It also enables local
collection of information on intrusions, and subsequent consolidation and analysis, as well as
analysis of an organization’s normal IT patterns of behavior/usage. In many situations it may be
clear that some unauthorized or unwanted event is happening. It could be a slight degradation in
services for apparently unknown reasons, or it could be an unexpected number of accesses at
unusual times, or it could be the denial of specific services. In most situations it is important to
know the cause, severity and scope of the intrusion as soon as possible.
It should be noted that this capability is more sophisticated than the audit trail analysis tools and
methods that are reflected in clause 11.5 above and the related clause of Part 4 of TR 13335. The
more effective intrusion detection capabilities use special post-processors that are designed to use
rules to automatically analyze past activities recorded in audit trails and other logs to predict
4
intrusions, and to analyze audit trails for known patterns of malicious behavior or behavior
which is not typical of normal usage.
For more detail the reader should refer to TR 15947 - IT Intrusion Detection Framework.”
6.2 Common Criteria and Intrusion Detection
The Common Criteria (CC) part 2 provides the Functional class Security Audit (FAU). This
class includes functionality to provide:
1. response taken in case of a security violation (FAU_ARP.1 Security alarms)
2. recording of the occurrence of security relevant events (FAU_GEN.1 Audit
data generation, FAU_GEN.2 User identity association)
3. automated means that analyse sytem activity and audit data looking for
potential or real security violations (FAU_SAA.1 Potential violation
analysis, FAU_SAA.2 Profile based anomaly detection, FAU_SAA.3 Simple
heuristics, FAU_SAA.4 Complex attack heuristics)
4. audit tools that should be available to authorized users to assist in the
review of audit data (FAU_SAR.1 Audit review, FAU_SAR.2 Restricted
audit review, FAU_SAR.3 Selectable audit review)
5. selection of the events to be audited (FAU_SEL.1 Selective audit)
6. creation and maintenance of a secure audit trail (FAU_STG.1 Protected
audit trail storage, FAU_STG.2 Guarantees of audit data availability,
FAU_STG.3 Action in case of possible audit data loss, FAU_STG.4
Prevention of audit data loss).
7. Architecture of Intrusion Detection Systems
(Gives an introduction to the generic model of intrusion detection systems and to the
characterization of intrusion detection systems with some discussion as to their relationship.)
8. The Generic Model of Intrusion Detection
[PICTURE GOES HERE -- ELEMENTS DESCRIBED IN FOLLOWING SUBPARAGRAPHS]
(This is a model similar to the CIDF model composed of components, not the
characteristics.)
8.1 Targets
8.2 Monitoring and Filtering
8.3 Data Storage
(as per previous discussions of the model.)
8.4 Analysis and Processing
(includes real-time and delayed, need for data archiving)
(also include use of response feedback to improve detection process; discussion of
centralized versus distributed aspects of IDS’s collection and analyses.)
8.5 Response
(This is the intrusion detection system ‘response’ section.)
a. Decision Points
5
(this is about the decision points within the ID System.)
8.7 Intrusion Detection System Internal Security
(assurance – Common Criteria relationship to th internal security of an IDS.)
8.8 Intrusion Documentation and Reporting
8.9 Management of IDS
i. Profile Management
ii. Xx
iii. Yy
iv. Etc.
8.10 Collateral Information Input
(from outside systems)
8.11 Intrusion Detection System Interfaces
8.11.1 External interfaces
(connections to systems/components outside the IDS.)
8.11.2 Internal interfaces
(connection to systems/components within the IDS.)
9 Characterization of Intrusion Detection Systems
(as per the CIDS-like diagram)
10 Intrusion Detection Methods
(include here a discussion of the relation between intrusions and attacks)
10.1 Introduction to Intrusion Detection Methods
(This section introduces the methods used to identify malicious behavior and activities; it should
be rewritten to be consistent with a framework that discusses these topics at a high level.)
10.1.1 Audit trail analysis
This method is probably the most commonly known way to analyze the status of a computer
system. It is also the standard way of gathering information on a users behavior or misbehavior.
Audit trail analysis usually makes use of a systems built-in audit log or event log. The assumption
is that any security-relevant action initiated on a computer system will lead to an according audit
log entry. The analysis process itself interprets the according entries off-line, e.g. timely
uncoupled to the event itself, to identify security violations or system attacks.
Audit trail information is typically offered by the operating system (for UNIX syslog, for
Windows NT event log) of a computer, by router software (audit info), firewalls, switches,
applications, etc. An optimal audit trail analysis should make use of information available on
different levels (application, network, and system) and from different sources. This could lead to
a major problem for generally these local audit trails do not have a common audit format.
10.1.2 Pattern matching methods
The pattern matching approach is an important approach used to identify those events known to
be security related and leading to breaches or failures. This approach is mainly used in those
intrusion detection systems that examine constantly any actions.
6
Such a system monitors, for example, network communication traffic and identifies those packets
known to cause problems by comparing the packet(s) to well-known attack patterns (e.g. ping-of-
death ICMP packet). The advantage of this approach is that it detects dangerous packets that
pass by. The disadvantage is that an experienced attacker will escape those systems as soon as he
slightly modifies the attack patterns.
(expand to include other pattern matching methods such as host-based patterns)
10.1.3 Frequency or threshold crossing
Some specific denial-of-service attacks make use of weaknesses in the Internet protocol suite. One
example is the so-called SYN flood where an attacker sends many connection requests with a
faked IP address and requires the attacked system to acknowledge these requests without finally
receiving a confirmation. This may lead to a system stop. Though the attacker seems to behave
according to the communications protocol, the attack can only be detected by the amount of
connection requests within a certain period of time. This repetition of requests together with the
configured number of allowed open connections in the attacked system define the threshold for
this type of attack.
Denial-of-service attacks are not easy to detect for they always use common protocol features and
known implementation weaknesses such as restricted amount of space.
10.1.4 Statistical anomaly
10.1.5 Correlation of lesser events
An attack made up of a sequence of seemingly unrelated events is quite difficult to detect for each
single event within a sequence of separated events is by its very nature harmless. Only the
sequential combination of the events in a certain period of time lead to an attack. An intrusion
detection system that has to identify these patterns not only has to concentrate on the individual
patterns but also on the correlation of these patterns.
(Some discussion of the following topics should occur in this section:
• Combination of intrusion detection methods
• Incorporation of new methods and technologies
• Use of reaction and feedback to resolve indications and/or improve the reliability of the
detection process)
10.2 Host-based detection systems
Host-based intrusion detection systems monitor and analyze either the direct behavior of users
and processes on a system or they evaluate all information kept in different audit logs.
Host-based IDSs have many advantages. They offer a high degree of the attackers information
and see the results of an attack on a system for they can use the syslog, accounting data, system
resources, and a security audit-trail. They will detect those attacks that are directed at the
operating system or at specific applications. They are independent of networking techniques.
They also work also in high-security environments where network traffic may be encrypted and
therefore not analyzed by network-based IDSs. Host-based IDSs usually utilize processes
running on a system, therefore, they are operating system dependant but do not necessarily need
additional hardware. Therefore they may not be as expensive as network-based IDSs.
However, there are some disadvantages as well. Host-based IDSs may have real-time constraints
on processing of the security audit trail. To get the degree of information desired and to process
it real-time may require heavy use of the system resources. Other drawbacks of the standard
security audit are parameterization of the audit system, heterogeneous formatting amongst the
subsystems, and difficulties in exploiting the complexity of the information. It is noted that the
normal accounting system is lacking in information and capability to perform a full security
audit.
a. Network-based detection systems
7
Network-based intrusion detection systems examine raw network data packets in order to
identify either correct behavior or misbehavior. To gain access to all network traffic the IDS
utilizes the network adapter to monitor and analyze all traffic in real-time as it travels across the
network. Therefore it has either to be located on a central point of the network or it has to make
use of agents in different segments of the network. The network-based approach should be
directed to these network segments – if the system does not offer agents – that contain the most
important and therefore most valuable systems.
Network-based IDS offer the advantages that they can be positioned in a segment of a network
independent of the operating systems of the systems to be protected. A single monitor can protect
many hosts. They have little or no impact of the host performance. They can identify network-
specific attacks (e.g., IP-based attacks such as Ping-of-Death or denial-of-service) but also can
identify host-directed attacks by examining the payload of the packets. They are less easy to
manipulate by successful intruders for they not only keep the method of attack but also
information on the origin of that attack. They also may allow for faster reaction on attacks (e.g.,
in answering an attack with the according network command to disconnect the attacking system).
These systems can keep evidence even of unsuccessful attacks.
There are some disadvantages, as well. It may be difficult to identify the attacker. Encryption
can make it impossible to analyze packets or packet contents depending upon the type of
encryption used. In switched networks, the switching itself may cause some difficulties, such as
the requirement for more sensors or determining the best location for sensors. In networks using
commercial operating systems for their operation, the network itself could be vulnerable to
denial-of-service attacks.
b. Combined intrusion detection
As a result of the advantages and disadvantages of both approaches the most promising way for
intrusion detection may be a combined approach for it will cover both the network specific
attacks and the host-specific attacks. This allows the detection of the kind of attack that uses
network and host weaknesses simultaneously where each separate IDS approach would not have
succeeded. Combined intrusion detection must therefore get information on the network level
and on the application and operating system level.
10.5 Off-line (non-real-time) processing
10.6 On-line (real-time) processing
Real-time IDS are not necessarily ”real-time” in a strict computing sense. Depending upon the
parameters such as the source of audit data and the detection method, a time lag may exist
between the occurrence of an event and the time at which it is detected and reported. Moreover,
the elapsed time between when an attack is initiated and when the target system is penetrated
may vary depending upon the nature of the attack. Therefore, in some cases, the attack may be
completed before it is detected and reported to the proper authority. These delays between the
attack and its corresponding detection may or may not impose a threat depending upon the
resilience of the IDS and the targets it is protecting.
10.7 Selection Criteria
10.8 Useability Issues
(This section discusses information that needs to be considered when examining intrusion
detection systems, such as that which may impact system performance and make intrusion
detection useful. A discussion of false positives and false negatives would naturally be
discussed here and how the IDSs classify, discriminate and reduce the data collected to
interpret the event(s) as an intrusion. The response may be automated or manual or both
depending upon the reliability of the infrastructure and IDS and the philosophy of the
organization.)
8
i. Intrusion detection/performance trade-offs
ii. Etc.
(Give examples within appropriate paragraphs.)
• Audit trail analysis
• Pattern, expression, or bytecode matching
• Frequency or threshold crossing
• Correlation of lesser events
• Statistical anomaly detection
• Other
11. IT System Impacts
12. Other Intrusion Detection Issues:
a. Intrusion detection and privacy
Privacy has become an issue for the use of intrusion detection systems. Recognizing or deflecting
intrusions it is necessary to analyze network traffic and/or audit trails of operating systems, while
looking for attack signatures or specific patterns that usually indicate malicious or suspicious
intent.
The collected network traffic or audit data contain some personnel data or data, which can be set
into relation to a specific person. Especially the IP-address is such a data. Further on intrusion
detection can be used as an instrument of monitoring user and their behavior. The last aspect
should be considered, if intrusion detection is applied for detecting ”internal” intruders resp. own
employees
Two principles which reflects the privacy challenges should be considered if intrusion detection is
employed:
• Intrusion detection has to serve the purpose of data protection.
• The data collection (network packets, audit logs) has to be adequate to the purpose of
protection.
The first aspect means that intrusion detection should not be used as an instrument of supervision
of the behavior of employees.
The second aspect points out, that only those data should be gathered and analyzed which are
necessary to recognize attacks. After the comparison with the attack signatures of the intrusion
detection system data no longer needed or with no indication for an attack should be deleted; the
data relevant to indicating an attack should be stored in a secure way.
In the long run the introduction of pseudonyms should be taken into consideration. Then user-
identifying data are encrypted and only decrypted in the case of an intrusion representing a
match with an attack signature.
At the moment there is no special legal regulation (concerning European Union and North
America) of privacy issues on the field of intrusion detection or the audit problem as a whole.
Some national regulations in Europe reflect the audit problem indirectly, while they introduce
the criteria of adequacy and the related purpose of the use of personal data.
Further, some European nations have some regulations concerning the protection of workers´
personal data and the right of workers´ participation.
a. Relationship of security policy and Intrusion detection systems
9
12.3 Need for data on intrusions. [1]
Developers of tools for intrusion detection and diagnosis have a need for data on intrusions.
Typically, they would like to have a collection of reliable, detailed records that include exploit
instructions and data on vulnerable system configurations to make the intrusions repeatable in
laboratory environments.
They would like to be able to add various types of information, such as what signs of the
intrusion they are able to observe in the system. Legitimate concerns about distributing
information on intrusion schemes have hampered the growth of such databases. Ironically, this
has led to the current situation where security professionals find their best sources for intrusion
data on underground Internet sites.
Experience from detailed intrusion analyses indicates that a vast amount of information is needed
about the particular intrusion sample to make correct statements about an intrusion type in
terms of prerequisites, impact, traces, difficulty, remedies, etc. Also because systems are
continually patched to block known intrusions, it can be difficult to recreate a vulnerable system
configuration for each intrusion sample when detailed vulnerability information is missing.
Typically, intrusion-handling systems need to be updated when new types of intrusions are
discovered. A major problem facing intrusion detection system (IDS) developers is that the
intrusion databases utilized provide little leverage for automating extensions to their systems. In
many systems it is assumed that the users will collect intrusion descriptions from various sources
and write new rules or change parameters as new intrusions are discovered. This could be
compared to modern virus detection systems, which often have automatic network-based update
functionality.
A standard format is needed that will facilitate rapid distribution of information among IDS
developers and related groups in order to achieve ”critical mass” in the coverage. This should
include information that ensures automated repeatability, detection, and diagnosis of each
intrusion sample.
An intrusion database should be designed to serve the IDS community by coordinating detailed
information on vulnerable configurations and exploit instructions with documented observable
dynamic and static traces (signs) of intrusion types. The trace information should be structured
in a format that will support an IDS downloading a new description and extracting the
information needed to automatically generate new rules (signatures, parameters, etc.) to identify
the new intrusion. The intrusion database should be designed to store technical data about
intrusion types, share the primary distinction between two types if their observable traces differ
in a significant way. The intrusion database is not meant to be a database of intrusion incidents
where evidence concerning attack cases should be stored.
13. Recommendations
APPENDIX A Taxonomy of Intrusions and Intrusion Detection
(Items to be discussed here include:
- Classes of intrusions
- Event definition, i.e., what elements are needed to define an event in general
and specifically.)
References
1. Ulf Lindqvist, Chalmers and SRI CSL; Douglas Moran, SRI AIC; Phillip Porras, SRI
CSL; and Mabry Tyson, SRI AIC, ”Designing IDLE, The Intrusion Data Library
Enterprise,” RAID ’98, 1998
2. ISO/IEC JTC1/SD27 N1992 ”US National Body Contribution on NP 15947 Intrusion
Detection Framework,”1998
10
3. Edward Amoroso, AT&T Laboratories, Intrusion Detection: An Introduction to Internet
Surveillance, Correlation, Traps, Trace Back, and Response, Intrusion.Net Books,
Sparta, New Jersey, USA, 1999
4. Herve’ Debar, Marc Dacier and Andreas Wespi, IBM Research Division, Zurich
Research Laboratory, ”Towards a Taxonomy of Intrusion-Detection Systems,” Preprint
submitted to Elsevier Preprint, 1998
5. Thomas H. Ptacek, Timothy N. Newsham, Secure Networks, Inc., ”Insertion, Evasion,
and Denial of Service: Eluding Network Intrusion Detection,” paper available on the
web at http://www.securenetworks.com/papers/ids.html, 1998
11
