Prospect on security paradigms

This paper examines some of the beginnings of paradigm shifts in computer security. It focuses on formal models of computer security from an historical perspective. Surprisingly perhaps, the historical perspective reveals dramatic shifts. These shifts take the form of extensions, in several directions, to early formal modeling. From them we believe we can learn much and discern new growth directions that have a solid basis in the current technology of trusted computer systems. We do not present a complete list of formal computer security models; for example, the formal model for the Multinet Gateway [l] is not discussed. It may be that the framework we use is applicable to them, or at least partly applicable. More likely, though, the framework would be enriched by a careful study of these other models. Viewing a number of models within the same framework can give us insights into a particular model’s characteristics that may not be discernible when viewing a model in isolation. 1 What is this Paper About? The workshop call for papers refered to shifts in computer security paradigms. The shifts, as we see them, are taking place along various “axes” of interest, among which are functionality, assurance, verification, and modeling. Functionality. A shift from one kind of security policy to many kinds, from single-policy systems to multiple-policy systems Assurance. A shift from bundled to unbundled functionality and assurance; a shift away from equating high assurance with formal verification toward developing assurance by a combination of various methods. 01993 ACM O-89791-635-2 $1.50 Verification. A shift from using only verification tools approved by the National Computer Security Center to vendor-developed tools and methods. Modeling. A shift from sta.te-ma.chine representation of internal rules of operation toward new forms and wider scope of modeling for secure systems. Two questions focus our discussion of several formal models. l Have we modeled th,e policies we should model? l Have we extended th.e uses of modeling? Following the historical perspective based on t.hese two questions, we offer comments on where we ca.n go from here. 2 Have We Modeled The Policies We Should Model? People make assumptions a.bout the context of the Trusted Computer Systems Evalua.tion Criteria. (TCSEC) [2] when they ask this; they frequently ask it rhetorically, assuming that the answer is “No.” A ca,se can be made for the claim tha.t the TCSEC’s proper business is to protect classified informa.tion, so tl1a.t modeling non-disclosure, to the pra.ctical exclusion of all other policies, seems appropriate for it. Nevertheless, many people feel that a “richer” set of policies for trusted systems would better serve the needs of military and chassified government a.ctivities. Informa.tion labeling in the Compartmented Mode Workst,ation [3] is one worked example of this. The security literature [4, 51 offers improved schemes using a.ccess cont,rol lists to provide stronger need-to-know controls t,han does current DAC. In the larger context of the new Federa. Crit,eria. project, a number of people seem to be saying t,hat, 62 Permission to copy without fee all or part of this material is granted. provided that the copies arc not made cn distributed for direct commercial advantage. the ACM copyright notice and the title of the publication and its date appear, and notice is given Hal copying is by permission of the Association for Computing Machinery. To copy otherwise, or 10 republish, requires * fee and/or specific permission. the answer is “No, we are not modeling the policies we should be modeling. ” We do not think this is unanimous by any means, but enough opinion favors new ways of doing business that we should take seriously the challenge to apply formal modeling technology to a wide range of policies. In the largest context of users and vendors, there can be no question that their answer is “No.” Yet, there are specific cases where people have modeled the policies that were appropriate to their interests. In doing this they have broken new ground in trusted systems and given us examples to study and, in some instances, to emulate. We know of four such efforts: in chronological order, secure military message system model [6], labeling policy for compartmented mode workstations [3], Clark-Wilson policy for integrity in commercial systems [7], and the ORGCON policy [8]. SECURE MILITARY MESSSAGE SYSTEM MODEL This was the first major departure from the TCSEC’s style for trusted systems. First, it is application oriented. It takes advantage of this fact to enrich its model semantics by defining the type of object called “message,” in addition to distinguishing between “objects” and “containers” as information entities. Second, it expresses its security policy as a set of secure transforms* rather than a set of secure rules of operation. This avoids choosing a particular implementation, so the model can be applied to trusted message systems built on various platforms. Contrast this with the Multics-oriented Bell-LaPadula model, whose rules of operation represent kernel calls. Finally, the model deals with both internal and external interface requirements. This makes clear what the relationship is between the trusted message system and its users. LABELING POLICY FOR COMPARTMENTED MODE WORKSTATIONS This is an interesting non-access-control policy for dynamic assignment of labels to information, where the labels include dissemination control, handling markings, and code words-generally the components needed for appropriate external labeling of information products. It gets its requirements from an application environment-an ‘A transform is a system function from UI x I x S into S, Ul is a set of userIDs, Z is the set of well-formed system requests, and S is the set of possible system states. A transform is secure when it is access secure, copy secure, CCR (container clearance required) secure, translation secure, set secure, downgrade secure, and release secure. intelligence analyst receiving, correlating, fusing, and disseminating information using a workstation. Its corresponding formal model is a. direct descendant of the BLM-class of models. It demonstrates the feasibility of including an a.uxiliary policy to TCSEC MAC and DAC. CLARK-WILSON POLICY FOR INTEGRITY IN COMMERCIAL SYSTEMS The Clark-Wilson integrity model (CWIM) gives a new view of how a trusted computer system a.nd people could cooperate to maintain an accurate computer-based model of a real-world enterprise. Clark-Wilson integrity requirements derive from objectives such as separation of duty and correspondence of computer data to real-world information. The model directly dea.ls with ext.ernal consistency issues. Although it does not explicitly articulate an external model (i.e., one that shows the relationship of the computer to its users), it does describe an internal model-one that, shows how the computer system meets t,he ester& requirements allocated to it-tl1a.t. can support a. class of external models. This class is exemplified by an accounting enterprise. The CWIM, like t,he SMMSM, takes advantage of its application orientation by distinguishing integrity-controlled objects (constrained data items CDIs) from ordinary objects (unconstrained dat.a. items-UDIs). We developed a rule-set model of Clark-Wilson integrity policy for a UNIX System V/MLS system [9]. This model carries the elaboration of requirement,s into greater detail, giving implementa.tion-dependent. rules of operation and functional specifica.tion. Like the Bell-LaPadula model, though, it does not, explicitly give an external model. The SMMSM a.ppreach, however, appears suited to this need. Using the SMMSM modeling paradigm, we might be able to articulate a.n explicit, ext,ernal model for Cla.rk-Wilson integrity. ORGCON POLICY This ORCON-like policyt was defined, prototyped, and modeled in the GFAC resea.rch project [8]. The model for this policy uses a. policy rule set and a separate finite state machine representation of the ta.rget system. The finit.e sta.te machine representation is a. BLM-t,ype construct while the rule set provides a separate definition of tThe ORCON policy, defined in Director of Central Intelligence Directive l/7, describes controlled disseminat.ion of information belonging to an organizat.ion.