Specifying and Implementing Security Policies Using LaSCO, the Language for
Security Constraints on Objects

James A. Hoagland
(Ph.D. Dissertation, UC Davis, Computer Science, March 2000)

Abstract

     Security policies define the security requirements for a system (an
executing entity).  Thus, they are statement about how a system should
behave.  What is meant by security, and therefore what the behavior should
be, varies from environment to environment and system to system.  Some
models for security have been formalized, but in other cases there is no
standard model so policies must be created for use on a particular system. 
In current practice, policies (when stated at all) are stated in English. 
The limitation of this is that policies expressed this way may be ambiguous
and does not lend itself towards mechanization nor formal analysis.  We
believe that the primary impediment to more specific and mechanizable
security policies is the unavailability of a formal language that supports
the creation, analysis, understanding, and mechanization of real security
policies.

     In this dissertation, we present LaSCO, the Language for Security
Constraints on Objects.  This language is a new approach to security policy
specification and enforcement.  Through this language, users may write
constraint policies (policies that impose constraints on the events and the
state of a system, including traditional access control) for many
applications and systems.  The systems for which it can express policies is
limited only by what can fit its rather general system model.  This model
views a system as consisting of objects and events.  Objects have attributes
representing their state.  Events occur between a pair of objects and have
attributes representing the event parameters.  Types of systems that have
been described in this manner include executing programs, file systems,
operating systems, distributed systems, and networks of hosts.  Often the
system can be modeled in multiple ways.  Thoughtful construction of a system
description (a particular way a system is modeled) provides the policy
writer appropriate primitives for his application.

     Policies in LaSCO are stated as policy graphs, which are annotated
directed graphs.   LaSCO policies separate into two components:  the domain
and and requirement.  The domain of a policy matches when objects and events
in a systemıs execution correspond to nodes and edges in the policy graph,
given their domain predicate.  Predicates are expressions on the attributes
of a object or event.  Variables may be present in predicates to impose
relationships between the objects and events matching a policy.   The
requirement part of a policy consists of a set of requirement predicates.  A
policy is deemed to be violated if any requirement predicate is not
satisfied wherever the domain matches in the system.   A formal operational
semantics has been defined for LaSCO.  Especially notable features about its
expressability are that it can express policies that are dependent on system
historical context and ones that restrict the state of objects.  Many
example LaSCO policies are found in this dissertation.

     LaSCO possesses characteristics which support it in attaining some
desirable properties of a security policy language:   Policy statements in
LaSCO are clear and unambiguous.  Its policies can be be readily
implemented.  It may be used for different systems.  LaSCO is expressive
enough to represent the precise policy the writer wanted.  It can state
policies at the level of detail appropriate for an application.  It has
characteristics that promote its user friendliness in creating, modifying,
and understanding policies represented in it, for both casual and expert
users.  In addition, it is believed to be amenable to formal reasoning.

     A useful approach we have developed to enforcing LaSCO policies for any
system is to divide the enforcement mechanism into two parts.  The generic
policy engine receives notices about system events and state changes from
which it reports whether there is any violations of a set of policies.  This
is system independent as it operates at the level of the system model.  The
interface layer, which translates the execution of a system into events and
objects in the system description for communication to the generic policy
engine, is the second part of the architecture.  Through this approach, only
one implementation of the details of policy representation and
interpretation is needed.  Our implementation of the generic policy engine
can enforce any LaSCO policy, regardless of system.  Policy violations can
be checked incrementally against an executing system or against an entire
system history at once.

     We have implemented LaSCO for Java programs.  The model we use is that
method and constructor invocations correspond to events and their parameters
the event attributes.  The objects are both instances of Java classes and
the classes themselves.  An objectıs attributes correspond to data members
of the class.  A graphical user interface for creating and editing policies
displays an abstract view of a Java program.  This presentation (among other
features) may be used to facilitate writing policies for the program, both
purely as reference and using automated means.  A policy compiler adds code
to Java programs to enforce a set of user selected policies.  The result of
these modifications is that a method invocation that was about to run is
checked using the generic policy engine as to whether it will violate policy
or not.  If it will, an exception is thrown.

     An analysis of implementing LaSCO policies on Java has been conducted,
using both quantitative (experimental) and qualitative means.  Some of the
more major results are mentioned here:  The time taken by a method
invocation increases dramatically if the policy compiler believes it might
match some policy edge, so an implementation should limit this to necessary
cases.  As it does not involve history, a single edge policyıs cost of
checking the policy remains steady regardless of the number of method
invocations that have matched it previously, which establishes scalability
for this case. The less often a policy check forms a match to part of a
policy, the lower the average cost per check.  For a policy applied to a
program execution in which there is a large number of matches formed in
comparison to the number of policy edges being checked against a method
invocation, the number of matches dominates the time per check.  As the
number of system nodes present in an executing program increases, the number
of matches against a multi-edge policy can drop significantly, thus reducing
execution time. Writing policies that match less often and reimplementing
the run time checking mechansism more optimally are two ways to improve the
run time efficiency of policy checking.  LaSCO can state useful policies for
Java and has some advantages in policy expression and implementation over
the Java Security Architecture.

     We have studied applying LaSCO to a network as viewed by GrIDS.  GrIDS
is a distributed intrusion detection system (IDS) for large networks.  It
correlates reports of network activity through a hierarchy of aggregation
engines.  In addition to network connections, GrIDS receives reports from
various data sources (such as host-based intrusion detection systems) that
inform it as to activity on the network and state changes on a host.  As we
describe a GrIDS network using the LaSCO system model, hosts are the system
objects and reports of network activity are the system events.  We propose a
modification to the GrIDS engine to allow it to enforce LaSCO policies
natively using the generic policy engine.  Partial matches of a policy to
network activity are passed along the hierarchy as needed to form complete
matches of the policy domain.  If the requirement is violated, an alert is
sent.

     A consequence of this study is the conclusion that an IDS can benefit
from enforcing policies in a policy language and it can be beneficial to
enforce policies using an IDS.  To reap these benefits though, an IDS must
have a practical means of interpreting policies in its native methods, the
policy language must be able to state policies for the system of the IDS,
and the policy language should be amenable to decomposition of policies for
incremental enforcement.