Search

Automated analysis tools offer potential solutions to many of the difficult inference problems found in multilevel database applications. The work described here brings together two interactive tools to assist the designer in creating a multilevel database application that is free of known inference problems. One tool, the SRI inference tool (Stickel, 1994b), is a research prototype developed under contract to Air Force Rome Laboratory. The other tool is a commercial product, Software Through Pictures (StP), developed and marketed by Interactive Development Environments, Inc. The integration of these two tools provides a robust and modem development environment that is tailored to address multilevel database security.

This report contains the papers written for the Fourth RADC Database Security Workshop, held in Little Compton, Rhode Island, 22-25 April 1991. The papers reflect a range of research topics, from the semantics of polyinstantiation to the problems of actually building trusted database management systems. The goal of this workshop was to provide a forum for the discussion of the work in progress, to clarify and amplify ideas, and to advance the multilevel database security research agenda. Multilevel secure database management systems.

Any multilevel-secure (MLS) database management system (DBMS) requires a security policy that is sufficiently flexible to support the security requirements of a range of database applications. In general, the currently proposed DBMS security policies do not provide the types of features that are required by typical database applications. This paper discusses four major problems with current DBMS security policies: 1. Automatic polyinstantiation 2. Simplistic Bell-LaPadula interpretation 3. View-based controls and constraints 4. Lack of transaction authorization controls.

One evening during the workshop, the participants divided up into three small groups to discuss and analyze a database security “homework problem”. The questions focused on the security requirements of an example database application. While the example itself is not particularly realistic, it exhibits a fairly typical database design and a set of security requirements that are characteristic of commercial and DoD applications. Its primary advantage over the examples that have been used in the security literature to date is that it represents a more complete application, and not just a single file or relation.