Cooperative frameworks for intrusion detection and response exemplify a key area of today's computer research: automating defenses against malicious attacks that increasingly are taking place at grander speeds and scales to enhance the survivability of distributed systems and maintain mission critical functionality. At the individual host-level, intrusion response often includes security policy reconfiguration to reduce the risk of further penetrations. However, runtime policy changes may cause traditional software components, designed without (dynamic) security in mind, to fail in varying degrees, including termination of critical processes. This paper presents security agility, a strategy to provide software components with the security awareness and adaptability to address runtime security policy changes, describes how security agility is packaged in a prototype toolkit and illustrates how the toolkit can be integrated with intrusion detection and response frameworks to help automate flexible host-based response to intrusions.

Numerous techniques exist to augment the security functionality of commercial off-the-shelf (COTS) applications and operating systems, making them more suitable for use in mission-critical systems. Although individually useful, as a group these techniques present difficulties to system developers because they are not based on a common framework which might simplify integration and promote portability and reuse. The paper presents techniques for developing Generic Software Wrappers-protected, non-bypassable kernel-resident software extensions for augmenting security without modification of COTS source. We describe the key elements of our work: our high-level Wrapper Definition Language (WDL), and our framework for configuring, activating, and managing wrappers. We also discuss code reuse, automatic management of extensions, a framework for system-building through composition, platform-independence, and our experiences with our Solaris and FreeBSD prototypes.

Operating system kernels capable of simultaneously enforcing multiple security policies provide economic benefits over those that cannot: they allow a single kernel to concurrently provide its costly or unique resources to a number of projects, each with its own individual security requirements. The additional ability to dynamically reconfigure its policy during run time allows a kernel to take on new projects and their policies and to remove old ones without disturbing those that remain. Unfortunately, the policy added to govern a new project may conflict with the kernel's existing policy components, invalidating their security properties and negating the protection they pro vide. This danger is an obstacle to the practical operation of these kernels. The paper describes how the Domain and Type Enforcement (DTE) prototype kernel implements automatic safeguards to reject policy extensions which would invalidate BLP, Ring, Strict Integrity, Clark-Wilson, and Assured Pipeline security properties of its existing policy.

Internet connected organizations often employ an Internet firewall to mitigate risks of system penetration, data theft, data destruction, and other security breaches. Conventional Internet firewalls, however, impose an overly simple inside vs outside model of security that is incompatible with many business practices that require extending limited trust to external entities. The paper reports on our experience with an enhanced security firewall based on Domain and Type Enforcement (DTE), a strong but flexible form of access control. A DTE firewall provides several benefits. First, it runs application level proxies in restrictive domains, thereby increasing security, and runs network services such as HTTP and FTP under DTE controls, thereby reducing risks that network based attacks will compromise local resources. Second, a DTE firewall coordinates role based security policies that span networks by passing DTE security attributes between DTE clients and servers. These attributes allow security policies at the endpoints to be coordinated; such coordination adds defense in depth to the traditional firewall security perimeter: this permits safe exportation of normally risky services such as NFS. Finally, a DTE firewall interoperates with "non DTE" systems and associates DTE security attributes with these systems so their interaction with DTE clients or servers can be controlled. We describe the design of a prototype DTE firewall system and informally evaluate its security, compatibility, functionality, and performance.

Type enforcement is a table-oriented mandatory access control mechanism well-suited for confining applications and restricting information flows. Although both flexible and strong, type enforcement alone imposes significant administrative costs and has not been widely adopted. Domain and Type Enforcement (DTE) is an enhanced version of type enforcement designed to provide needed simplicity and compatibility. Two primary techniques distinguish DTE from simple type enforcement: DTE policies are expressed in a high-level language that includes file security attribute associations as well as other access control information; and during system execution, DTE file security attributes are maintained using a concise human-readable format in a runtime DTE policy database, thus removing the need for security-specific low-level data formats. Such formats are a major source of incompatibility for security-enhanced systems. A DTE UNIX prototype system has been implemented to evaluate these primary DTE concepts. This paper presents experiences gained and preliminary results indicating that DTE can provide cost effective security increases to UNIX systems while maintaining a high degree of compatibility with existing programs and media.>

A definition of security, relaxation security, which is expressed in terms of the guarantees that a trusted system may provide, is presented. Relaxation secure systems permit dynamic, incremental relaxation of security constraints by authorized users. The use of guarantees permits security damage sustained during a period of constraint relaxation to be expressed in terms of guarantees violated; the set of violated guarantees may then be used as input for security recovery. A definition of security using a state machine formulation is presented, the implications of relaxation security for security recovery are discussed, and the utility of the approach is demonstrated using an example application.>

Systems which provide integrity controls are presented in terms of a request-response paradigm. This paradigm involves modeling the manner in which valid requests are made, a system's method of deciding whether or not to service a request, and the manner in which a system state are performed only in authorized ways. A novel feature of the model is that integrity policies, which are restrictions on how data may be modified, are defined at multiple levels of granularity. At the finest and lowest level of granularity, restrictions are placed directly on how data items may be modified; at successive and more coarse levels of granularity, restrictions are defined in terms provided by lower levels. A hierarchical technique for organizing computations, nested transactions, is adapted for this purpose. Integrity policies expressed in this framework are properties of computations which can be specified and related to other desirable properties, such as concurrent execution and fault tolerance.>

In this paper we prove that Beth's property does not hold in L<ω. This answers a question posed by Magidor and Malitz in [8]. Beth's property is a natural closure condition on a language which says that everything implicitly definable in the language is also explicitly definable in the language. That the first-order predicate calculus (L0) has the property was first shown by Beth [4]. Lopez-Escobar proved that also has Beth's property [7]. Malitz [9] showed the Beth's property fails in Lκλ where κ ≥ λ ≥ ω1. Friedman and Silver showed that the property fails in Lκλ for κ > ω1. Also Friedman [5] showed that extensions of elementary logic using cardinality quantifiers (L)1κ do not have Beth's property. The undefined notation used here is standard. If further clarification is needed, we refer the reader to [3]. κ and λ denote infinite cardinals. cX and ȣX∣ denote the cardinality of X. cfμ will denote the cofinality of the order μ. All languages discussed are assumed to have no function or constant symbols. All structures are relational. The type of a formula is the set of relation symbols appearing in the formula (excluding equality). The type of a set of formulas is the set of all relation symbols appearing in some formula of the set of formulas. For purpose of this paper we will assume that to each n-ary relation in a structure there is associated an n-ary relation symbol and that in any given structure this association is one-to-one. Using this convention we can define the type of a structure to be the set of those relation symbols to which there is associated a relation in the structure. Sometimes we use the term predicate instead of relation.