I’ve been working with tools and products that nominally work with network security policy for over ten years now, and the term policy is still unclear and over-used in my mind. In his security text “Computer Security: Art and Science”, Matt Bishop describes security policy to be “a statement that partitions the states of a system into a set of secure states and a set of unsecure states”. In other words, the policy defines what is means for a system to be secure, but it doesn’t describe how the system should be made secure. The policy describes the goals or intent and the mechanism defines the how. Of course policies are used from very high level organization wide Engish documents of goals and intent down to very low level configuration details like SE Linux policies.
We first used the term policy to describe our multi-device management view of our Centri firewall. Our goal was to provide a management interface that was higher level than the per device configuration and hopefully closer to what the executives had in mind when they drafted their natural language organizational security policy. This morphed into Cisco Security Policy Manager after we were acquired by Cisco. The Centri firewall targets were dropped in favor of Cisco PIX and IOS enforcement points. This “global policy” view is also presented by the Solsoft management interface. In both management products, the “policy language” is graphical. While we did raise the abstraction level from individual devices, we didn’t nearly reach an abstraction layer that would be understandable by the executive writing the organization’s natural language policy.
Morris Sloman’s group at the Imperial College London has performed a lot of work on policy language specifications. One aspect of their work is formalizing a refinement hierarchy. The policy statements at the top of the refinement are very broad, and too ill defined to be formally analyzed, but perhaps intuitively understandable to the executive’s responsible for setting the organization’s policy. At each level of the refinement hierarchy, you formalize some aspect of the policy, potentially creating multiple versions from the previous level, e.g. refining the policy for one site vs another or refining the policy for one technology (firewall) vs another (operating system). At the lowest level of the refinement hierarchy, you have policy that could be used to directly control enforcing devices. At the higher levels of the hierarchy, you have more general policies that could be used to direct a global validation of a security implementation.
In his text, Bishop identifies three points in this refinement hierarchy. One is the English or natural language policy. The others are the high level and low level formal policies. He distinguishes between these two types of formal policies by determining whether a policy statement could be picked up and used to direct the operation of a different device or different vendor’s device. A high level policy could in theory be used to direct the operation of a different device. A low level policy statement is tied to a specific device and is really more configuration than policy. He gives the type enforcement language DTEL as an example of the high level policy. This language is the parent or the grandparent of the SE Linux type enforcement policy language. While DTEL is formal and fairly detailed it operates on general concepts of subjects (or processes) and objects (or files), so one could easily see how a specific DTEL policy could direct both firewall operation and operating system operation. He gives tripwire as an example of a low level policy. Tripwire uses a database of signatures of “good” versions of system binaries. Tripwire periodically checks the signatures against the binaries, and alerts the system administrator if there is a mismatch. One might want to build an organization wide database of good binaries and signatures and install that on all systems. However, due to how tripwire is implemented the database contains very low level information (timestamps and Inode #’s I believe) that prohibit such sharing.
This concept of policy as a system crossing configuration is consistent with how policy is used in the web services and identity management world. SAML statements are in essence policy that describe how individuals should be identified between administrative domains. Marianne Winslett’s group works on algorithms and frameworks to reason about formal policies that control trust. In these cases, the policies are like little contracts that are exchanged between entities that are trying to collaborate. Unlike the network security management case, the trust policies don’t control a single administrative domain. Rather the trust policies control how the base infrastructure evolves.
One concept that recurs in most uses of the term policy is that of conflict. In any non-trivial scenario there will be multiple, conflicting goals. An organization may want to provide a easy to use web interface to encourage new customers, but the organization must also ensure that their infrastructure has sufficient authentication and auditing to avoid fraudulent customers. These two goals are necessarily conflicting. At the implementation level, one group may require http communication with a particular server, but another group may need to prohibit all communication with that server to avoid potential conflict of interest contanimation.
The policy language could force the user to clarify all conflicts through ordered lists or policy priorities. Others try to implement more intelligent systems that deduce the correct conflict resolution. A lot of the autonomic management work involves creating greater intelligence and reasoning to save the user from the error prone work of detailed conflict resolution.