💾 Archived View for spam.works › mirrors › textfiles › hacking › auditool.txt captured on 2023-11-04 at 13:16:45.
View Raw
More Information
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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.