Traditional security policies largely focus on access control requirements, which specify what resources can be accessed by whom and under what circumstances. Though essential, access control is only one aspect of security policies. The correct behavior and reliable operation of a software or information system relies not only on what users are permitted to do, but oftentimes on what users are required to do. Such obligatory actions are integral to the security procedures of many enterprises. For instance, when an employee leaves an organization, it is usually very important that the employee’s access to the organization’s software or information systems be deactivated.

Though the details of obligations in specific systems may be quite different, conceptually, an obligation can always be viewed as being associated with the occurrence of certain events. For example, if a user subscribes to a service, then he or she is obligated to pay a monthly fee. Or a system administrator may be obligated to restore a file system within 12 hours following a system crash. In these examples, an obligation handles the impact of an event; in other situations, obligations reflect responsibilities associated with certain privileges or actions.

The growing trend has been to express obligations explicitly as part of security policies. Since traditional access control policies are only concerned with permitting or denying subjects the ability to take certain actions, they cannot be used directly to express obligation requirements. This has led to a number of new security policy languages being proposed to support the specification of obligation policies. Research on the monitoring and fulfillment of obligations has also begun to appear in the literature.

The introduction of obligations inevitably complicates the management of security policies. Because individual users are autonomous entities, a system cannot prevent a subject from failing to fulfill his or her obligations. However, in the event that an obligation is violated, the system should be able to conduct the necessary actions to compensate for failure as well as identify clearly who is responsible. The interaction between obligations and access controls is also important, since access to the actions required by an obligation are often restricted by access control policy. A system should only allow obligations to be assigned when the obligated user will have sufficient privileges in the system and access to the resources necessary to successfully fulfill the obligation.

From the readings in this module, you will learn about recent advances in the management of obligations in security policies, including the modeling, specification, analysis and maintenance of obligations.