The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / general / auditool.txt < prev next >

Wrap

Text File | 2003-06-11 | 12.4 KB | 290 lines

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.