16 violations, whether they are initiated by outsiders who attempt to break into a system or by insiders who attempt to misuse their privileges. NIDES is designed to be independent of any particular target system, application environment, level of audit data (e.g., user level or network level), system vulnerability, or type of intrusion, thereby providing a framework for a general-purpose intrusion-detection system using real-time analysis of audit data. Each target system must install an agen facility (see section 4.1) to collect audit data and put them into NIDES's generic audit record format. We have developed a exible audit record format and a protocol for the transmission of audit records from the target system. The NIDES protocol and its audit record format are system-independent; our intent is that NIDES can be used to monitor diierent systems (even simultaneously) without fundamental alteration. 5 Conclusions Intrusions can be detected by detecting departures from users' normal behavior patterns. In addition, a rule-based approach in which rules characterizing intrusive behavior are constructed for evaluation against observed user behavior can be used. The strength of the rst approach is that intrusive behavior that shows up in unforeseen ways can potentially be detected; the weakness is that certain behaviors generally agreed to be abusive or suspicious are not easily monitored for. The strength of the second approach is the ease of stating exactly that behavior that is considered intrusive or undesirable; conversely, its weakness is that only behavior that has been foreseen to be intrusive will be caught: novel or highly sophisticated attacks may go undetected. In addition, the use of other approaches, such as model-based reasoning and neural networks, appears to be promising. In order to eeectively address the various intrusion threats, a system should combine several intrusion-detection approaches. We should begin to see intrusion-detection systems that can intelligently make use of audit data gathered at several diierent levels from the monitored system (e.g., system call level, command line level, and application level). Prool-ing les and programs will give us another dimension along which to characterize expected behavior on a system. And there still remains a signiicant amount of research to be done in determining exactly which aspects of behavior are most indicative of intrusions. To obtain meaningful indicators of intrusive behavior, such research needs to have available many examples of actual intrusions. A library of such examples does not currently exist and is needed. As …

The Defense Intelligence Agency (DIA) recognized that commercially available workstations could significantly enhance the capabilities of today's Intelligence Data Handling Systems (IDHS) if they could be integrated with the IDHS systems in a secure manner. The Compartmented Mode Workstation (CMW) project was started at the request of the DIA to further the state-of-the-art of computer security in general and workstation security in particular. The prototype effort had two major purposes. The first purpose was to demonstrate that operationally useful implementations of each requirement could be designed and developed. The second, more general, purpose was to gain insight into what measures could be taken to augment commercially available workstations with meaningful security. Therefore, as the Security Requirements for System High and Compartmented Mode Workstations [CMWREQS] were stated, a development team attempted to implement thereon the CMW prototype. Viable approaches were found for all requirements thereby verifying the premise that a workstation and its associated operating system could be modified such that off-the-shelf software (distributed in binary form) could execute with adequate security .This paper describes compartmented mode operation, how the prototype satisfied each requirement, and the level of effort involved in the prototype implementation.