290 lines
12 KiB
Plaintext
290 lines
12 KiB
Plaintext
|
|
Summary of the Trusted Information Systems (TIS) Report on Intrusion
|
|
Detection Systems - prepared by Victor H. Marshall
|
|
********************************************************************
|
|
INTRUSION DETECTION IN COMPUTERS
|
|
January 29, 1991
|
|
|
|
|
|
1. EXECUTIVE SUMMARY. Computer system security officials
|
|
typically have very few, if any, good automated tools to gather
|
|
and process auditing information on potential computer system
|
|
intruders. It is most challenging to determine just what actions
|
|
constitute potential intrusion in a complex mainframe computer
|
|
environment. Trusted Information Systems (TIS), Inc. recently
|
|
completed a survey to determine what auditing tools are available
|
|
and what further research is needed to develop automated systems
|
|
that will reliably detect intruders on mainframe computer
|
|
systems. Their report #348 was done for the Air Force and
|
|
includes details on nine specific software tools for intrusion
|
|
detection.
|
|
|
|
|
|
2. BACKGROUND. Computer security officials at the system level
|
|
have always had a challenging task when it comes to day-to-day
|
|
mainframe auditing. Typically the auditing options/features are
|
|
limited by the mainframe operating system and other system
|
|
software provided by the hardware vendor. Also, since security
|
|
auditing is a logical subset of management auditing, some of the
|
|
available auditing options/features may be of little value to
|
|
computer security officials. Finally, the relevant auditing
|
|
information is probably far too voluminous to process manually
|
|
and the availability of automated data reduction/analysis tools
|
|
is very limited. Typically, 95% of the audit data is of no
|
|
security significance. The trick is determining which 95% to
|
|
ignore.
|
|
|
|
|
|
3. SPECIAL TOOLS NEEDED. A partial solution to this problem
|
|
could be to procure or develop special automated tools for doing
|
|
security auditing. For example, in the IBM mainframe
|
|
environment, programs such as RACF, CA-ACF2, and CA-TOP SECRET
|
|
are commonly used to control data access and programs such as CA-
|
|
EXAMINE are used to supplement standard systems auditing.
|
|
Nevertheless, most of these generally-available software systems
|
|
do not comprehensively address the problem of intrusion
|
|
detection. In fact, intrusion detection is one of the most
|
|
challenging (security) auditing functions. There are, in fact,
|
|
few existing systems designed to do this, and they must be
|
|
tailored to specific operating systems. Also, they do not
|
|
generally gather auditing information on activities within
|
|
database management systems or application software. Much
|
|
research and development needs to be done before intrusion
|
|
detection will be generally available.
|
|
|
|
|
|
4. REPORT AVAILABLE. In the meantime, however, it would be wise
|
|
to stay abreast of the state-of-the-art in automated auditing
|
|
tools for helping security managers detect intruders. TIS, Inc.
|
|
recently completed a very comprehensive report on the tools
|
|
currently available for intrusion detection and the recommended
|
|
directions for future research. TIS report #348 is entitled
|
|
"Computer System Intrusion Detection, E002: Final Technical
|
|
Report" and is dated September 11, 1990. It was done under
|
|
contract to the Rome Air Development Center at Griffiss Air Force
|
|
Base in New York. TIS report #348 comprehensively covers the
|
|
known intrusion detection techniques. It also reviews the nine
|
|
comprehensive intrusion detection tools currently available or
|
|
under development.
|
|
|
|
|
|
a. Intrusion Detection Techniques. Although intrusion
|
|
detection is normally accomplished using software tools, hardware
|
|
tools are potentially more secure because they cannot be easily
|
|
altered. In either case, intrusion detection requires that
|
|
security-related auditing data be collected, stored, and
|
|
analyzed.
|
|
|
|
(1) Data Collection. Specific events or sequences of
|
|
events must be defined as important enough to cause generation of
|
|
an audit record. Potentially every event has security
|
|
significance, but logging the details of every event would
|
|
probably eliminate any hope of processing efficiency (or even
|
|
effectiveness). Thus, someone must decide which events to log
|
|
and when. Also, as noted earlier, the events logged tend to be
|
|
exclusively operating system events. It would be useful to be
|
|
able to log some events internal to database management systems
|
|
and/or application systems.
|
|
|
|
(2) Data Storage. Some auditing data can be processed
|
|
in real-time, but most of it will go to an audit log for later
|
|
review. Security is concerned with the extent to which:
|
|
|
|
- The storage medium for the audit log is
|
|
READ-only and non-volatile,
|
|
|
|
- The computer system used to store the audit
|
|
log is connected/linked to the one from which
|
|
the auditing data was gathered, and
|
|
|
|
- The electronic (or manual) data paths are
|
|
protected.
|
|
|
|
(3) Data Analysis. By far, the most difficult task is
|
|
to analyze the auditing data. A comprehensive audit log will
|
|
certainly be too voluminous for reasonable human processing.
|
|
Thus, the following techniques (in addition to other techniques)
|
|
must be used in some ethical/legal combination to reduce the
|
|
security-relevant audit data to meaningful conclusions:
|
|
|
|
- User Profiles
|
|
- Anomalies
|
|
- Historical Norms
|
|
- Trend Analyses
|
|
- Probable Scenarios
|
|
- Known System Flaws
|
|
- Threat Probabilities
|
|
- Simulated Intrusions
|
|
- Statistical Sampling
|
|
- Expert System Rules
|
|
- ArtificIal Intelligence
|
|
- Hierarchies of Concern (Levels of Security)
|
|
- Heuristics
|
|
- Neural Networking
|
|
|
|
(4) User Interface. Finally, the data analysis
|
|
process should have a "friendly" user (i.e., security manager)
|
|
interface that supports rapid learning, minimal frustration, and
|
|
effective results.
|
|
|
|
|
|
b. Nine Tools Reviewed. The nine automated tools reviewed
|
|
in some depth in TIS report #348 are:
|
|
|
|
(1) ComputerWatch Audit Reduction Tool. AT&T Bell
|
|
Laboratories developed ComputerWatch in 1989 to summarize their
|
|
internal audit files produced by System V/MLS, a version of UNIX.
|
|
ComputerWatch could be used on other systems if the appropriate
|
|
changes were made to the format/filter module.
|
|
|
|
(2) Discovery. TRW Information Systems Division
|
|
developed Discovery in 1986 to analyze access data from their
|
|
credit database housed in a dial-up network of IBM 3090s running
|
|
under the MVS operating system. Because it is application-
|
|
specific, Discovery could not be easily implemented in other
|
|
environments. However, Discovery does process auditing data
|
|
produced by IBM's standard System Management Facility (SMF).
|
|
|
|
(3) Haystack. Haystack was developed by Haystack
|
|
Laboratories, Inc. for the Air Force Cryptologic Support Center
|
|
in 1988 to analyze data from Unisys 1100/2200 mainframes running
|
|
under the OS/1100 operating system. The actual analysis is done
|
|
on a personal computer (such as the Zenith Z-248) running under
|
|
MS-DOS. Haystack could not be easily implemented in other
|
|
environments.
|
|
|
|
(4) Intrusion-Detection Expert System (IDES). The
|
|
IDES model was developed by SRI International in 1985 and has
|
|
been implemented on Sun workstations as a research prototype
|
|
under a contract with the U.S. Navy (SPAWAR). A version of IDES
|
|
for IBM mainframes (using the MVS operating system) will soon be
|
|
implemented under a contract with the Federal Bureau of
|
|
Investigation (FBI). IDES is designed to be easily implemented
|
|
in many different environments. The IDES model has been the
|
|
basis for most intrusion detection research to date and it forms
|
|
the conceptual basis for Haystack, MIDAS, and W&S. (NOTE:
|
|
Haystack was covered above. MIDAS and W&S are covered below.)
|
|
|
|
(5) Information Security Officer's Assistant (ISOA).
|
|
ISOA is an R&D prototype system developed by Planning Research
|
|
Corporation (PRC) in 1989 to analyze data from two types of
|
|
system - the UNIX SunOS and the IBM AT Xenix. The actual
|
|
analysis is done on a Sun 3/260 color workstation. ISOA is table
|
|
driven, so it can easily be used to monitor many different
|
|
environments.
|
|
|
|
(6) Multics Intrusion Detection and Alerting System
|
|
(MIDAS). MIDAS was developed by the National Security Agency's
|
|
(NSA's) National Computer Security Center (NCSC) in 1988 to
|
|
analyze data from a Honeywell DPS-8/70 computer running the
|
|
Multics operating system (in support of NSA's Dockmaster system).
|
|
NCSC intends to further develop MIDAS so it can process audit
|
|
data from Sun and Apple systems.
|
|
|
|
(7) Network Anomaly Detection and Intrusion Reporter
|
|
(NADIR). NADIR was developed by the Department of Energy"s Los
|
|
Alamos National Laboratory (LANL) in 1989 to analyze data from a
|
|
unique LANL Network Security Controller (NSC). There are no
|
|
plans to modify NADIR for use in other systems.
|
|
|
|
(8) Network Security Monitor (NSM). An NSM prototype
|
|
was recently developed by the University of California Davis
|
|
(UCD) and is currently running on a Sun 3/50. NMS was designed
|
|
to analyze data from an Ethernet local area network (LAN) and the
|
|
hosts connected to it. NSM is a research system, but UCD hopes
|
|
to eventually expand it's scope to include real environments,
|
|
real attacks, and perhaps wide area networks.
|
|
|
|
(9) W&S. W&S is an anomaly detection system that has
|
|
been under development at LANL for the NCSC and DOE since 1984.
|
|
W&S runs on a UNIX workstation and can analyze data from several
|
|
different systems.
|
|
|
|
|
|
c. More Research Needed. The specific TIS recommendations
|
|
for further research include the following near-term (1 to 5
|
|
year) and long-term (over 5 year) recommendations.
|
|
|
|
(1) Near Term Recommendation. The main near-term
|
|
recommendation is to develop and commercially market an audit
|
|
analysis "tool kit" flexible enough to meet the needs of a wide
|
|
variety of security users and of a very dynamic environment.
|
|
This would require that, among other things, someone:
|
|
|
|
- Study the techniques for coordinating data from
|
|
multiple levels of system abstraction.
|
|
|
|
- Explore methods for integrating components of
|
|
existing intrusion detection systems into a
|
|
single prototype system.
|
|
|
|
- Study the uses of neural networks and how they
|
|
might be employed in audit analysis tools.
|
|
|
|
- Develop the initial design for a proof-of-
|
|
concept prototype to include a statistical tool
|
|
(to develop user profiles), an expert system
|
|
tool (to analyze the data based on predefined
|
|
and consistent rules), and a neural network
|
|
tool.
|
|
|
|
- Determine the typical level of security
|
|
expertise and perceived needs of a security
|
|
manager who will use these auditing tools.
|
|
|
|
- Test the prototype tool kit using real/live
|
|
penetration techniques and data.
|
|
|
|
(2) Long Term Recommendation. The main long term
|
|
recommendation of TIS report #348 is that studies of the issues
|
|
surrounding intrusion detection technology be conducted. These
|
|
issues include:
|
|
|
|
- Risk Management
|
|
|
|
- Advanced Tools
|
|
|
|
- Network Monitoring
|
|
|
|
- Distributed Processing (of Audit Data)
|
|
|
|
- Statistical Analysis
|
|
|
|
- Detection Sensitivity Analysis
|
|
|
|
- Collusion Among Computer Users
|
|
|
|
- Distributed Network Attacks
|
|
|
|
- Intrusion Response (Counterattack)
|
|
|
|
- Computer User Responses to Intrusion Detection
|
|
|
|
- Recognition (to Reduce False Positive
|
|
Identifications)
|
|
|
|
|
|
5. TIS REPORT CONCLUSION. TIS report #348 concludes that there
|
|
has been much good scientific study done on intrusion detection
|
|
technologies, but insufficient time has been spent:
|
|
|
|
- Analyzing precise user needs,
|
|
|
|
- Determining the most appropriate technologies to use in
|
|
specific situations, and
|
|
|
|
- Cooperatively sharing the lessons learned from actual
|
|
intrusions.
|
|
|
|
|
|
|
|
|
|
VICTOR H. MARSHALL
|
|
Systems Assurance Team Leader
|
|
Booz, Allen & Hamilton Inc.
|
|
|
|
|
|
|
|
|
|
|