Check out the new USENIX Web site.

next up previous
Next: Implementation Space Up: A Comparison of Methods Previous: Introduction

Motivating Examples for Adaptive Security

 

The first example of adaptive security consists of organizations that need to change their policies at regular intervals. For example, a bank may have one security policy enforced during business hours and another policy enforced after hours. The business hours policy would grant broad sets of permissions to various sets of employees in order complete normal banking transactions; however, a more restrictive policy would be in effect after hours to prevent system users from altering banking data in unintended ways.

Some organizations may need to release sensitive documents at specific times. For commercial organizations it may be a press release of new product information that must not be available from the webserver until a specified time. Military organizations may have similar needs to make information available to allies on a timed-release basis. Conversely, today's commercial partner or military ally may be an tomorrow's adversary, in which case they should not be allowed to receive various forms of information.

Other organizations may need to adapt their security policies based on the tasks performed by the users. For example, in the banking example cited above, some tasks may be critical to perform despite the more restrictive policy enforced after 5:00 PM. High-priority or urgent tasks may need to be granted special permissions to complete on-going operations despite the general change of policy. Other task-based policies may make use of an assured pipeline, like that proposed by Boebert and Kain [BK85]. Assured pipelines address situations in which a series of tasks must be performed in a particular order and the control flow must be restricted. An adaptive policy might change the set of permissions associated with a single process as it completes a series of operations. As the process completes one operation, the permission set changes to allow the process to complete the next operation but to prevent it from revisiting any objects that it needed for earlier operations. A related security policy would be the Chinese Wall introduced by Brewer and Nash [BN89], which is intended to prevent conflicts of interest in commercial settings. Briefly, under a Chinese Wall security policy a subject may initially be allowed permission to an entire class of objects, but as soon as the subject accesses one element of the class, permissions to access any other object of that class are denied.

Role-based security policies form another class of adaptive security policies. A role is distinguished from a task in that an individual has an on-going need to complete a set of tasks. (See [SC96], [FCK95], and [Hof97].) In commercial settings, roles may be used to enforce separation of duties [CW87]. For example one role may be granted authority to issue purchase orders while another has authority to pay for those purchases. However, for small companies it may be necessary for one individual to perform actions in more than one role, though not necessarily at one time to provide the proper controls and oversight. In military operations it may be necessary for an individual to perform actions in more than one role simultaneously. For example, in the Navy the role of the Watch Officer on a ship may be performed by the Chief Engineer. This person may need to fulfill both roles simultaneously. Similarly, the Command Duty Officer may need to perform actions reserved for the Commanding Officer in times of emergency. Privilege to invoke these dual roles should be reserved for extreme situations.

Multi-level security (MLS) rules as applied in the military and intelligence communities form a final class of examples of security policies that must be adaptive. Adaptive policies may allow either a relaxation or selective hardening of confidentiality restrictions. Under MLS rules all objects are labeled according to the sensitivity of the data they contain (e.g., Top Secret, Secret, Confidential, and Unclassified). By the simple security rule, users and subjects are allowed access to observe objects only if their clearance level is equal to or exceeds the sensitivity of the object (see [BL73]). During an emergency it may be necessary to consolidate levels into two levels: one for Secret and Top Secret files, and another for the remainder. Thus, under the relaxed rules, someone formerly cleared for Secret could access files formerly labeled as Top Secret. For example, military officers may only have clearance to the Secret level, but once their troops are under fire, they may need to access Top Secret information such as the location or capabilities of enemy forces. Conversely, confidentiality rules and other security measures could be ``hardened'' based on DEFCON alert status or following detection of a possible intrusion. There are a number of ways to ``harden'' a system. For example, one could increase internal controls, perform full audits rather than selective audits, or require additional authentication measures.



next up previous
Next: Implementation Space Up: A Comparison of Methods Previous: Introduction



Brian Loe
Tue Dec 9 09:16:53 CST 1997