A set of criteria is introduced for comparing and assessing intrusion detection systems. The theory, requirements classes, metrics and practical application of the criteria are discussed. 15 specific requirements are described and broken down into Class A, Class B and Class C compliance. A questionnaire for obtaining vendor information is shown; advice and experiences from test evaluations are given, based on our use of the criteria with several commercially available systems.

Two techniques for functional detection of local area incoming war dial are described. One technique employs a dedicated workstation looking for evidence of incoming war dial. We describe our experimental implementation of this technique, including alarm generation to a Cisco NetRanger(R) intrusion detection system. The second technique involves simple parsing of private branch exchange (PBX) call records for characteristic patterns of war dial. Baseline heuristics driving our algorithms are discussed. The non-terminated call detection limitations of this parsing technique for our Lucent Definity G3 PBX are discussed.

The I/O automata model of Lynch and Turtle (1987) is summarized and used to formalize several types of system integrity based on the control of transitions to invalid starts. Type-A integrity is exhibited by systems with no invalid initial states and that disallow transitions from valid reachable to invalid states. Type-B integrity is exhibited by systems that disallow externally-controlled transitions from valid reachable to invalid states, Type-C integrity is exhibited by systems that allow locally-controlled or externally-controlled transitions from reachable to invalid states. Strict-B integrity is exhibited by systems that are Type-B but not Type-A. Strict-C integrity is exhibited by systems that are Type-C but not Type-B. Basic results on the closure properties that hold under composition of systems exhibiting these types of integrity are presented in I/O automata-theoretic terms. Specifically, Type-A, Type-B, and Type-C integrity are shown to be composable, whereas Strict-B and Strict-C integrity are shown to not be generally composable. The integrity definitions and compositional results are illustrated using the familiar vending machine example specified as an I/O automaton and composed with a customer environment. The implications of the integrity definitions and compositional results on practical system design are discussed and a research plan for future work is outlined.>

A high-level, technical summary of the Trusted Software Methodology (TSM) is provided in this paper. The trust principles and trust classes that comprise the TSM are presented and several engineering investigations and case studies surrounding the TSM are outlined. Appendices are included that highlight important areas of the TSM.

computing security technology that has evolved during the past three years in the Computer Science Department at the Stevens Institute and the Software Engineering

The authors have been involved in the development of an approach to measuring the trust of software, at some state in the software development life cycle. The primary emphasis has been on the use of well-known and generally accepted security and software engineering principles as a means for establishing software trust. A description of the critical issues related to software trust is provided here. A set of criteria classes consisting of various trust principle combinations is shown to provide a scale for measuring and comparing trust. The System V/MLS secure operating system development approach is used to demonstrate the effect of trust principles in a practical setting.>

A service model that is framed on the notions of subject priority and object criticality is introduced. The prevent (p, c) denial of service policy is expressed with respect to the service model. The author demonstrates an approach to arguing compliance with the policy by interpreting the System V/MLS secure operating system in terms of the service model, and then providing a sketch of an evaluation with respect to the prevent (2, 2) policy.>