Illustrative embodiments of the invention are illustrated in the drawings, in which:
In the past, duress codes have been used to trigger an alarm, slow access to a computer system, or trigger other simple, hard-coded actions. Also, in an enterprise having many authorized users, each user's duress code (if they have one) triggers the same action (e.g., the issuance of an alarm).
The method 100 continues with the configuration of different response policies for different ones of the duress codes (block 104). Depending on which user is assigned which duress code(s), this may result in different duress responses being associated with different users' duress codes, or different duress responses being associated with different duress codes known by a single user.
After duress codes have been assigned to users, and response policies have been associated with the duress codes, access to the response policies is provided via an interface of a policy engine. The response policies may then be retrieved from the policy engine as users enter ones of the duress codes into ones of a number of computer systems (block 106).
Of note, the steps of the method 100 are not critical. For example, the different response policies could be configured first, with the duress codes being assigned to one or more of the users based on the manner in which their corresponding response policies have been configured. Also, and in an ongoing enterprise, various of the method's steps could be repeated in various orders (or at the same time).
By enabling the configuration of different response policies for different duress codes, the method 100 enables a system administrator or other party to tailor duress responses to different situations. For example, there may some situations that do not warrant alarm, or there may be different situations that warrant different types of alarm (e.g., a silent alarm versus an audible alarm). Also, consider a situation where many of a company's employees have limited access rights, but others have substantial access rights. Using the method 100, a system administrator could provide the employees with limited access rights a duress code that simply 1) triggers a silent alarm, or 2) causes an unauthorized user's actions to be logged. On the other hand, an employee with substantial rights might be provided with a duress code that 1) causes an unauthorized user to be given access to honeypot applications, or 2) triggers procedures that cause the unauthorized user to believe that some or all of his actions are being carried out, when in fact, some or all of his actions are being prevented from being carried out.
In one embodiment of the method 100, the interface of the policy engine is accessed via an access authentication system that authorizes user-access to ones of the number of computer systems. By way of example, the authentication system could be a Lightweight Directory Access Protocol (LDAP) authentication system, a Windows® Directory Service authentication system, or a Hewlett-Packard (HP) Select Access authentication system.
The different response policies provided by the method 100 may be variously configured. For example, a response policy could trigger procedures for activating alarm; procedures for slowing down access to a device (e.g., a computer system or database); or procedures for mimicking a normal-mode of a device. A response policy may also be more involved, and may include multiple actions. For example, a response policy could trigger procedures for 1) representing to a user that at least some of their actions have been carried out, but 2) preventing the actions from being carried out. Or, a response policy could trigger procedures for logging and undoing at least some of the actions that are taken by a user. Response policies could also take other forms, including combinations of the above response policies.
In some cases, a response policy may be configured to take one or more actions in response to 1) the entry of a given duress code, and 2) the existence of one or more conditions. In this manner, a single duress code could trigger the invocation of different response policies. Conditions that could be assessed include: the time of entry of a given duress code, the site at which a given duress code is entered (e.g., the identity of a particular computer system, or the current location of a portable computer system); the type of action that is requested following the entry of a given duress code; or the receipt of a particular input (e.g., biometrics or a credit card) via an auxiliary input device. Alternately (or additionally), a user's actions could be monitored following his entry of a duress code into a computer system. A duress response policy could then be configured to take different actions in response to different user actions.
The method 100 may be implemented within or between one or more computer systems, by executing computer-readable program code stored on computer-readable media. The computer-readable media may include, for example, any number or mixture of fixed or removable media (such as one or more fixed disks, random access memories (RAMs), read-only memories (ROMs), or compact discs), at either a single location or distributed over a network. The computer-readable program code may include, for example, instructions embodied in software or firmware.
The computer-readable program code used to implement the method 100 (
An exemplary embodiment of the user interface 300 is shown in
As with the method 100, the method 400 may be implemented within or between one or more computer systems, by executing computer-readable program code stored on computer-readable media.
In addition to providing a system administrator or similar party with greater flexibility in responding to a duress code, the methods and apparatus described herein can mitigate or eliminate the need to modify a particular application to respond to a duress situation. For example, a duress response policy may be configured to capitalize on different capabilities that are already provided by an application (e.g., the ability to open different databases). The use of a policy engine, in lieu of tying a duress response to a particular application, also enables a duress response to be reconfigured when conditions warrant.