US20040128537A1

US20040128537A1 - Retrospective policy safety net

Info

Publication number: US20040128537A1
Application number: US10/331,742
Authority: US
Inventors: Mary Zurko; George Blakley
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-12-30
Filing date: 2002-12-30
Publication date: 2004-07-01
Also published as: US20150350216A1; US9503458B2; US8474006B2; US20100115580A1; US20130205368A1; US8904476B2; US9148433B2; US20150046972A1

Abstract

These and other objectives are attained with a method and system for evaluating an access policy change. The method comprises the step of providing an access control mechanism having a first policy, and an audit log having entries of accesses made under that first policy. The method comprises the further steps of submitting a second policy to the access control mechanism, comparing the log entries to the second policy, and based on the results of the comparing step, taking one of a predetermined number of actions.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention generally relates to methods and systems for evaluating access policy changes, and more specifically, to methods and systems for determining how a policy change would have influenced past actions as a predictor for future problems.

2. Background Art

It is often difficult for computer network administrators to be sure they are doing something both secure and efficient when they change policy information that controls user behavior. Prior art procedures for changing policy information generally focus on controlling access to information but do not apply to all potentially restrictive policy information.

An administrator may discover that some resource, like a discussion database, has its Access Control List (ACL) set to allow anyone to read it. To tighten security, they will remove that entry. Now, they need to be concerned with a surge of help desk calls from the people who were relying on that access to get their job done, who are not explicitly listed in the remaining ACL.

The concept of one active policy and several latent policies is known. Latent policies can be queried against before becoming active, to understand the impact of changes. However, most administrators who change policies do not know what to check, and what to ask about, and do not have the time to think about it.

SUMMARY OF THE INVENTION

An object of this invention is to improve methods and systems for evaluating access policy changes.

Another object of the invention is to determine how a policy change would have influenced past actions.

A further object of the present invention is to compare a policy change against some history of past actions and to tell a computer network administrator what happened in the past that could not happen in the future because of this change.

A further object of the invention is to make changes to a policy based on a comparison with a past policy and a prediction about how important that change will be going forward.

For example, these predetermined actions may be (i) making the change with a warning, (ii) rejecting the change, (iii) making a different change so that the things that happened in the log are still allowed, but some other things are not allowed (newly disallowed), and (iv) displaying the problem to the administrator and let them decide what to do. The choice among these actions might be configured in a number of ways. For instance, sites can configure which of those actions are appropriate. Alternatively, which actions the system takes can be based on information in the policies, in the changes, in the users that would be denied or their attributes, or in the actions that would be denied and their attributes. For example, a configuration could say that if the users who would be denied an access are listed in the corporate directory as active employees and the action that they took that would be denied is less than one week old, alter the policy to continue to allow the action and log the warning to an administrator.

Also, the invention may be embodied in a live system. In one embodiment, further steps may include submitting either or both of the second policy or the changes to the first policy that produce that second policy. In addition, in a preferred procedure, the present invention can tell someone changing a policy how that policy change would have influenced past (retrospective) actions. It compares the policy change against some history of past actions, and tells the administrator what happened in the past that could not happen in the future because of this change. The administrator can consider whether that is going to be desirable or not. The preferred procedure includes configuring which of a set of four courses of action to take.

Further benefits and advantages of the invention will become apparent from a consideration of the following detailed description, given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a flow chart illustrating a preferred procedure embodying this invention. [0015]
FIG. 2 illustrates the operation of this invention. [0016]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

This invention, generally, relates to a method and system for evaluating access policy changes. With references to FIGS. 1 and 2, the method comprises the [0017] step 12 of providing an access control mechanism 14 having a first policy 16, and an audit log 20 having entries 22 of accesses made under that first policy. The method comprises the further steps, represented at 24, 26 and 30, respectively, of submitting a second policy 32 to the access control mechanism, comparing at 34 the log entries to the second policy, and based on the results of the comparing step, taking one of a predetermined number of actions.
For example, these predetermined actions may be (i) making the change with a warning, (ii) rejecting the change, (iii) making a different change so that the things that happened in the log are still allowed, but some other things are not allowed (newly disallowed), and (iv) displaying, as represented at [0018] 36, the problem to the administrator and let them decide what to do. The choice among these actions might be configured in a number of ways. For instance, sites can configure which of those actions are appropriate. Alternatively, which actions the system takes can be based on information in the policies, in the changes, in the users that would be denied or their attributes, or in the actions that would be denied and their attributes. For example, a configuration could say that if the users who would be denied an access are listed in the corporate directory as active employees and the action that they took that would be denied is less than one week old, alter the policy to continue to allow the action and log the warning to an administrator.
The present invention, it may be noted, may be embodied in a live system. In addition, in a preferred procedure, the present invention can tell someone changing a policy how that policy change would have influenced past (retrospective) actions. It compares the policy change against some history of past actions, and tells the administrator what happened in the past that could not happen in the future because of this change. The administrator can consider whether that is going to be desirable or not. The preferred procedure includes configuring which of a set of four courses of action to take. [0019]
The most straightforward implementation of this invention involves a simple access control mechanism (say an ACL) and a log or audit history of actions that were controlled by the access control mechanism. For example, take a Domino ACL with the ability to compute a person's current effective access, and an audit log of accesses to a Domino database that includes the identity of the person taking the action and the particular action. The actions that can be taken are directly mapped to permissions in the ACL via a table. For example, the read action is mapped to the reader level. [0020]
When a change to the ACL is being made or proposed, with any suitable algorithm, some number of audit entries are compared against the new ACL. The effective access of the person in the audit entry is calculated, and that access is compared to the action in the audit record. If the action in the audit record is no longer allowed, it is displayed for the administrator in some form that allows the administrator to understand what it was and why it would be no longer allowed by the new ACL. [0021]
The system of this invention can be configured to take a number of actions, depending on site policy. For instance, the change can be made (and a warning logged) or the change can be rejected (with notification). As another example, the system can modify the change to “fix” it, so that the past event in the audit log would still be allowed, but other events covered by the original change would be newly disallowed. This is possible for policy modifications that target a group of users, a group of actions, a group of objects, or a number of contextual constraints. [0022]
For example, if the change to an ACL is to deny an action to a group of users (or to remove a group of users from an ACL such that actions previously allowed would be denied), then a companion “fix up” change would add an entry for the single user in the conflicting audit event to allow that action, such that it would take precedence over the new group disallowed entry, or it would maintain the ability to take the action that removing an entry would disallow. Similar examples are possible for the other types of groupings. [0023]
Any suitable hardware may be used to practice the present invention. For example, any suitable computer or computer network may be used to implement the [0024] access control mechanism 14, and any suitable monitor or display 36 may be used to display the results of comparing the log entries to the second policy.
While it is apparent that the invention herein disclosed is well calculated to fulfill the objects stated above, it will be appreciated that numerous modifications and embodiments may be devised by those skilled in the art, and it is intended that the appended claims cover all such modifications and embodiments as fall within the true spirit and scope of the present invention. [0025]

Claims

What is claimed is:

1. A method of evaluating an access policy change, comprising the steps of:

providing an access control mechanism having a first policy, and an audit log having entries of accesses made under said first policy;

submitting a second policy to said access control mechanism;

comparing said entries to said second policy; and

based on the results of the comparing step, taking one of a predetermined number of actions.

2. A method according to claim 1, wherein:

each entry in the log identifies a person and an associated action; and

the comparing step includes the step of, for each of a group of the entries, determining whether the person identified in the action has access under the second policy to the associated action.

3. A method according to claim 1, wherein the taking step includes the step of displaying any of said entries which do not have access under said second policy.

4. A method according to claim 1, wherein the taking step includes the step of modifying the second policy, using one of a group of predefined procedures, based on the results of the comparing step.

5. A method according to claim 4, wherein a defined group of users has access to a specified action under the first policy and do not have access to the specified action under the second policy, and wherein the modifying step includes the step of altering the second policy so that said second policy provides a subset of said group of users with access to the specified action.

6. A method according to claim 1, wherein the comparing step includes the step of comparing said entries to the second policy before the second policy becomes active.

7. A system for evaluating an access policy change, comprising:

means providing an access control mechanism having a first policy, and an audit log having entries of accesses made under said first policy, said access control mechanism including

means for receiving a second policy;

means for comparing said entries to said second policy; and

comprises means for taking one of a predetermined number of actions based on the results of the comparing means.

8. A system according to claim 7, wherein:

each entry in the log identifies a person and an associated action; and

the means for comparing includes means for determining, for each of a group of the entries,

action.

9. A system according to claim 7, wherein the means for taking includes means for displaying any of said entries which do not have access under said second policy.

10. A system according to claim 7, wherein the means for taking includes means for modifying the second policy, using one of a group of predefined procedures, based on the results of the comparing means.

11. A system according to claim 9, wherein a defined group of users has access to a specified action under the first policy and do not have access to the specified action under the second policy, and wherein the modifying means includes means for altering the second policy so that said second policy provides a subset of said group of users with access to the specified action.

12. A system according to claim 11, wherein the comparing means compares said entries to the second policy before the second policy becomes active.

13. A program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for evaluating an access policy change, said method steps comprising:

submitting a second policy to said access control mechanism;

comparing said entries to said second policy; and

14. A program storage device according to claim 13, wherein:

each entry in the log identifies a person and an associated action; and

the comparing step includes the step of, for each of a group of the entries, determining whether

the person identified in the action has access under the second policy to the associated action.

15. A program storage device according to claim 13, wherein the taking step includes the step of displaying any of said entries which do not have access under said second policy

16. A program storage device according to claim 15, wherein the taking step includes the step of modifying the second policy, using one of a group of predefined procedures, based on the results of the taking step.

17. A program storage device according to claim 16, wherein a defined group of users has access to a specified action under the first policy and do not have access to the specified action under the second policy, and wherein the modifying step includes the step of altering the second policy so that said second policy provides a subset of said group of users with access to the specified action.

18. A method according to claim 13, wherein the comparing step includes the step of comparing said entries to the second policy before the second policy becomes active.