Retrospective 1In the late 1970's and early 1980's, the military conducted an experiment (the Military Message Experiment, or MME) to investigate replacing existing message systems in use at CINCPAC that were based on the AUTODIN system, with local distribution of copies via a pneumatic tube system, with a new system based on the ARPANET and e-mail that provided a simulated multilevel secure (MLS) interface. At the same time, research was underway to develop multilevel secure operating systems. Experiences with both the MME and with prototype MLS systems led to research conducted at the Naval Research Laboratory to specify and prototype a family of military message systems (MMS) based on software engineering principles and on specifying the desired security behavior at the application level, rather than at the operating system level. The resulting security model was published as an NRL technical report and subsequently in ACM Transactions on Computer Systems in August, 1984.The approach to developing informal security models presented here remains quite relevant. Efforts to develop assurance arguments for today's systems can in many cases be related to the approach taken in this work [25].This paper was the first in an archival journal to present a security model based on application requirements as opposed to operating system structure. It argues that this is the appropriate orientation for a security model that is to be understood by users, and it presents a framework for developing and expressing security models informally, using natural language, and then formalizing the result. The informal model is accessible to users, while the formal model provides the precision needed for designing a system and determining whether an implementation enforces the model.The example presented, developed in the context of military message systems, includes a number of concepts that are appropriate for other applications as well. Among 1 This retrospective was written by the first author in August, 2001. It draws on an introduction written when the paper was anthologized in about 1990.these are the concepts of roles-job-related sets of permissions-and of multilevel object-an object (here termed a container) that has a security level of its own and also encloses other objects that retain their own security levels.Each user had an allowed set of roles, and the access controls on objects in the system could include roles as well as userIDs. A user could occupy one or more roles at a time, and some roles could be occupied only by a single user at a given time. These constraints were based on the observed needs of operational message systems to support one person acting for another as shifts and watches change, and for a single point of control (though not necessarily a single individual) for operations like message release.The approach to multilevel objects exploits an analogy with the physical world of safes, file folders, and documents to provide a model that application users can understand, and in which they can apply their in...