A security policy states the acceptable actions of an information system, as the actions bear on security. There is a pressing need for organizations to declare their security policies, even informal statements would be better than the current practice. But, formal policy statements are preferable to support (1) reasoning about policies, e.g., for consistency and completeness, (2) automated enforcement of the policy, e.g., using wrappers around legacy systems or after the fact with an intrusion detection system, and (3) other formal manipulation of policies, e.g., the composition of policies. We present LaSCO, the Language for Security Constraints on Objects, in which a policy consists of two parts: the domain (assumptions about the system) and the requirement (what is allowed assuming the domain is satisfied). Thus policies defined in LaSCO have the appearance of conditional access control statements. LaSCO policies are specified as expressions in logic and as directed graphs, giving a visual view of policy. LaSCO has a simple semantics in first order logic (which we provide), thus permitting policies we write, even for complex policies, to be very perspicuous. LaSCO has syntax to express many of the situations we have found to be useful on policies or, more interesting, the composition of policies. LaSCO has an object-oriented structure, permitting it to be useful to describe policies on the objects and methods of an application written in an object-oriented language, in addition to the traditional policies on operating system objects. A LaSCO specification can be automatically translated into executable code that checks an invocation of a program with respect to a policy. The implementation of LaSCO is in Java, and generates wrappers to check Java programs with respect to a policy. Security forms a core component of any system. What is meant by security has been described in general terms such as confidentiality, integrity, and availability. However, what is precisely meant by security (or for something to be secure) for a particular system 1 varies from system to system and possibly depending on the situation. The military would likely have a different definition of what the appropriate security is for their system than a bank, a university, or a home user would. They each have their own needs that should be reflected when securing their systems. In addition, one can describe security at various system levels. A security policy is a description of the security goals for a system and how a system should behave in order to meet these goals. An example policy is that the request for a purchase and its approval must be from different users. Since the security goals for a system effect how the security mechanisms on the system are configured, it is important for the security policy to be stated clearly. Additional benefit is obtained if the policy can be directly used to configure the security mechanisms or can be used to formally reason about the effect of the policy. A common security need is to restrict access to the resources on a system. This is reflected in a constraint security policy, which states constraints on the system 2 . We focus on constraint security policies in this paper. 1. We use "system" generally here. It can be almost anything on a computer that contains some sort of entities and can be interacted with or can be seen as executing. Some examples are: a program executing, a file system, an operating system, a workgroup, and a network of hosts. 2. Other types of security policies are ones that describe how trust is managed, describe how to choose the security options in setting up a network connection, and ones that describe how to respond to a security violation.
Hoagland et al. REF use a graphical language to describe security policies.
Security Policy Specification Using a Graphical Approach
ArXiv
ArXiv
Computer Science