• security usability;
  • authorization;
  • policy override;
  • privilege escalation;
  • break-glass;
  • decision support


  1. Top of page

The predominant strategy in restricting permissions in information systems is to limit users on the basis of the ‘need-to-know’ principle. Although appropriate in highly security-sensitive contexts, this culture of protection will, in other contexts, often reduce users' productivity and is seen as a hassle because the everyday exceptions to the routine tasks can be severely hindered. This paper proposes a more flexible authorization model, policy override, which allows end users to override authorization in a controlled manner. In this article, I describe the authorization model and its implementation in a medium enterprise's business application. I evaluated policy override use over a period of 1 year through quantitative and qualitative analysis to identify challenges and offer advice on the implementation of policy override in practice. One important challenge is the setting of adequate bounds for policy override. To overcome this obstacle, I propose and evaluate a qualitative risk-based calculus that offers decision support to balance additional risks of policy override with the benefits of more flexible authorization. Copyright © 2012 John Wiley & Sons, Ltd.


  1. Top of page

In The Use of Knowledge in Society, Hayek [1] argues that, in economies, the information for making choices is present decentrally on the spot and not centrally where the plans usually are made. Similarly, many decisions about authorization restrictions are made far from the end users' workplaces where those decisions impact usability: the effectiveness, efficiency, and satisfaction. More specifically, usability is affected from a functional perspective on authorization, that is, for example, from the primary tasks to be completed in an organization.

Even if the functional stakeholders participate in the authoring of authorization policies, the stakeholders typically only take common procedures into account and cannot anticipate exceptions to the rule or future organizational changes. In practice, every once in a while, users need privileges that are not assigned by default to complete the work at hand. According to Sinclair et al. [2], the reasons for this are the more dynamic organizational processes and the increased organizational complexities that cause frequently changing authorization requirements. Inadequate permissions often occur with respect to completing a task or for functional stakeholders to cooperate with other users, for example, by sharing information. Depending on the authorization change procedures and organizational security policies, inadequate permissions can bring functional stakeholders into uncomfortable situations, often burdening them with the decision to comply with the security policy [3] or not. Complying with typical security policies leaves them, for example, with the following options.

  • Follow the organizational procedures to have the privileges extended. Although appropriate for longer-term changes in organizational processes, the lead time for the permission change may be too long for time-critical tasks. The effort for the change process may be overly high for one-time requirements, and secondary security risks arise from the accumulation of over entitlements [2].
  • Turn to coworkers with the necessary privileges who can then conduct the task in their name. This is inefficient because identifying permitted users can be time-consuming and the identified user needs to switch context to validate and complete the task.
  • Ignore the task, for example, because of the level of frustration with long-running change procedures, thereby possibly causing a severe impact on the organization's business goals.

As Beautement et al. [3] show, with the compliance budget model, the decision of whether to comply is, among others, governed by the security motivation and previous effort to comply. Accordingly, the recurring stakeholder compliance in these kinds of cases will require additional motivational measures, such as awareness campaigns, or will result in less compliant personnel in the long run. For authorization usability issues, the affected stakeholders typically have several options of noncompliance with drawbacks from the organization's point of view. Two frequent examples, of the several that can be observed in practice, are the following.

  • Socially circumvent the security measure and request the credentials of a permitted user to impersonate that user in the system—a practice that undermines the traceability of activities. This may affect the organization's compliance to regulations and can have uncontrollable consequences.
  • Evade the restrictions by technically circumventing the information system, for example, by using e-mail rather than a document management system to share information. This is often inefficient because it causes redundant copies of documents and incurs additional risks from the loss of control of data.

In order to overcome inefficiencies and improve security effectiveness, one approach is to reconsider the authorization paradigm and take both the least-privilege principle [4], as known from conventional authorization schemes, and the most-tolerable privilege into account. To these ends, Sikkel and Stiemerling [5] describe a physical approach that allows users to cope with exceptional situations by placing an enveloped super-user password in a safe. Similarly, the flexibility of authorization in information systems can also be increased by not entirely defining restrictions a priori. Jones and Rastogi [6] name four forms of controls (corrective, deterrent, detective, and preventive) that may be used to support the practice of informal delegation with formal bounds and safeguards. For example, a speeding ticket analogy can be employed to reduce the improper use of authorization [7]. Povey [8] calls these flexible approaches optimistic security. According to Stevens and Wulf [9], authorization approaches can be categorized as the traditional ex ante, defined in advance, as well as ex post, decided after the activity, and uno tempore, deciding just in time. Ex post authorization can be implemented through system activity auditing [10-12]. The prohibitively high auditing effort prevents a wide-spread usage of audit-only authorization. However, in combination with explicit authorization override, the optimistic authorization approach may be viable. The override models establish a soft boundary at the normal least-privilege privilege extent and a hard boundary at the most-tolerable privilege extent, thus, implementing both the need-to-know and the must-not-know principle [13-15]. Specific models are called at times policy override, authorization escalation or break-glass mechanisms.

In health care, policy override mechanisms are already in use [16-18]. However, policy override inhibits additional risks, and it remains difficult for organizations from other sectors to decide which risks are adequate for the estimated gains. This decision is rather straightforward for hospital health care information systems with the high potential gain of saving lives. For other environments, the decision is not as clear-cut because organizations need to balance a possibly increased insider threat against potential gains. We thus need to better understand how policy override helps in practice. When the authorization override model allows fine-grained settings of who may override to which extent, a considerable amount of effort needs to be spent to analyze risks and gains for each case.

This paper addresses both challenges, the exploration of the usage patterns of policy override and the balancing of risks and benefits. First, I describe a model and an implementation of policy override and evaluate both in the context of a medium-sized business application for insights of how policy override is employed in practice. Second, I propose a calculus to support the decision making of which override extent to assign to which users. The policy override calculus estimates the override adequacy by employees' roles and override extent. I implemented the calculus in an override risk management tool, which I evaluated briefly.


  1. Top of page

When creating an application's authorization policy, security stakeholders conduct interviews as well as task and process analysis to identify functional needs. Figure 1 shows an abstract example of a role's requirements, lightly shaded on the left side. Depending on the effort and the analysis approach, the resulting authorization requirements may or may not be accurate. In the figure, the actual needs are shown with a dotted line.


Figure 1. An example of a role's hard and soft boundary.

Download figure to PowerPoint

The next step for security stakeholders is to formalize permissions from the authorization requirements. In most cases, the permissions will not exactly match the requirements because authorization models are typically coarse compared to the identified requirements, which is due to the abstract model for manageable complexity. The default permissions are shown as the white area in Figure 6. In conventional authorization models, the employee has to cope with these permissions. As stated in Section 1, for any missing permissions in daily routines or exceptional situations, the employee needs to circumvent authorization with potential drawbacks.

When using an application that supports policy override, the employee may have the additional option of overriding denied permission. As proposed by Cheng et al. [15], I introduce a soft boundary as an addition to the hard boundary in conventional authorization models. As shown in Figure 1, the soft boundary separates the default permissions from those that can be gained by overriding the policy. Any activity in override will be subject to more intense control than standard activities, for example, through logging and auditing. The hard boundary marks the limit of privileges attainable through policy override. Anything beyond the hard boundary is thought to be too high risk to allow the specific role to have access to it. Note that it may be appropriate to disallow any override for certain roles so that the hard boundary and soft boundary are identical.

Authorization model

In order to implement policy override, the authorization model needs to be adapted. I base the authorization model on a conventional role-based access control (RBAC) model with hierarchies, RBAC1, proposed by Sandhu et al. [19], which is comprised of the following elements.

  • User, representing the principal requesting access; Role, grouping specific functions of users; and Permission, allowing access to objects.
  • Assignments of permissions to roles:
  • display math
  • Assignments of users to roles: UA ⊆ User × Role.
  • Role hierarchy, that is roles inheriting permissions from ancestor roles, as a partial order RH ⊆ Role × Role with role dominance, denoted by the symbol ≥.
  • Junior roles, that is all roles transitively inheriting from a given role:
  • display math


  • display math
  • SessionUser : Session[RIGHTWARDS ARROW]User, returning the session's user
  • The session's activated roles
  • display math


  • display math
  • The permissions of the user in the current session
  • display math


  • display math

In order to implement policy override, an additional role relation is introduced to define to which roles a user may extend his privileges. This override roles relation is then used to modify the available roles that can be activated when the session is in override mode:

  • Override roles: OR ⊆ Role × Role is a relation that defines to which role the holder of the first role may extend his or her privilege in case of an override.
  • IsOverrideMode : Session[RIGHTWARDS ARROW]bool is a predicate that indicates whether a user has activated the override mode on a specific session.
  • JuniorRoles is redefined to return roles in the override hierarchy if the override mode is active for the current session:
  • display math

The policy override modifications do not affect authorization constraints, which are enforced as usual and are, for brevity, not included in the definition.


For an evaluation of the policy override authorization model, the model was implemented as part of the existing authorization framework, declarative_authorization, a widely used open source authorization framework for the Web development platform Ruby on Rails [20]. The framework aims to support authorization policy management with a comprehensible and maintainable authorization model. The authorization model, depicted in Figure 2, is similar to the classical RBAC [21] in that roles are assigned to users and permissions to roles with role and permission hierarchies. Instead of composing permissions of object and activity, the framework combines object types (contexts) and activities with constraints to increase the maintainability. Authorization policies are defined using a textual domain-specific language that, although based on Ruby syntax, is aimed to be human-readable and intuitively comprehensible.


Figure 2. The declarative_authorization model.

Download figure to PowerPoint

In order to implement the policy override model in declarative_authorization, two steps are necessary. First, the authorization model and policy language need to support the override options. Second, the decisioning needs to take the override options into account. For the model modification, the original authorization model, shown in Figure 2, was only slightly extended. As depicted in Figure 3, override roles may now be assigned to the roles. Users that are assigned to a role can thus override any override role of the originally assigned role, including the role inheritance. The override option is not transitive so that, when the policy is represented as a graph, only one override edge can be on any path from the user to permissions.


Figure 3. Modified model for policy override.

Download figure to PowerPoint

In the declarative_authorization policy language, the keyword overridable_to is added to the available statements in the role block. This statement represents the override edge between the role that is to be extended and the override role. In the example in Listing 1, conference organizers can override to the permissions of the administrator role, which allows them to modify system users. This might, for example, be useful to allow quick modification of speakers in urgent cases.

In decisioning, the main modification is to have an override status for the session, which is honored in each decision. In the override case, overridable roles of directly assigned roles, as well as of inherited roles, are added to the available roles and are handled as if assigned to the current user.

Listing 1. Policy override example in authorization rules



  1. Top of page

In case of innovative security measures, such as optimistic security and policy override authorization, practical experience with the technology in actual organizational contexts is crucial to judge the approaches' appropriateness and guide further research. However, the existing publications on the experience with policy override mechanisms and auditing is still limited to only a few domains [12], as discussed in Section 5. The aim of the evaluation in this section is twofold. First, the evaluation should enhance the understanding of employing policy override in small and medium enterprises' (SME) business Web applications and, second, show the viability of the previously described policy override model. In order to pursue both aims, policy override was deployed in a business Web application of a medium-sized enterprise from the automotive sector. The company conducts quality management measures with branches at several locations. The business application supports these quality management processes through a broad spectrum of functionality, including data collection, analysis, and report generation. The data held in the system is commercially sensitive because it is foremost comprised of customer quality data.

For the implementation of policy override in this application, I deployed policy override as an extension to declarative_authorization, implementing the changes in the decisioning and the policy that were described in Section 2.2. Apart from these generic changes, three application-specific implementation tasks had to be completed.

  • Implementation of an override activation mechanism. We opted to place a visible button with the German label ‘Ausnahme-Modus’ (‘Exception mode’) at the top navigation area of the Web application. When in override mode, the background of the header bar is colored red to signal the exceptional state.
  • Implementation of an auditing mechanism. We extended the existing application log viewer to describe the data read and changes made in the override mode and, thus, support the task of auditing override occurrences. An additional filter option allows the supervisor to limit the displayed actions to those in the override mode.
  • Signaling the override occurrences to the supervisor for review. The task management infrastructure in the application displays a symbol for pending tasks at the top area of the Web application. We add a task for each override case to users with a specific role in the branch of the user who entered the override mode.


I conducted a practical evaluation and implementation of the model on the basis of two sources. First, I analyzed the application log that records the activities on the Web application and specifically marks the override activities. The analyzed log spans the calendar year 2010. The override options were implemented at different times for different roles but all well before the start of 2010. Its implementation was communicated to end users, together with other functionality changes. From this source, I derive quantitative results on the affected users and actions, together with the proportion in policy override mode. Because each HTTP request causes a raw action entry, the action quantities may be skewed from the different counts of HTTP requests that depend on the individual task in the application. As a consequence, I grouped the raw actions into activities by user and day, providing an alternative representation of how frequently override is used. The quantitative results should provide a good overview of the usage of policy override. Because policy override should only be necessary for temporary authorization inadequacies or exceptional situations, the hypothesis is that individual users employ policy override in a few occasions only (H1).

The second source is qualitative. I interviewed five affected stakeholders about their experience, both users employing override and a superior responsible for acknowledging the use of policy override. The sampling is based on the quantitative results and includes the different kinds of users, as identified by their assigned roles and override usage profiles. The short, semi-structured interviews of about 15 min were analyzed from audio recordings and notes on each interviewee. The interviews with end users focus on (i) the reasons for employing policy override and (ii) the consequences derived from using it. The hypotheses are that users employ override for temporary authorization inadequacies and exceptional situations (H2) and that users strive to have authorization inadequacies changed and exceptional situations better handled in the application if they recur (H3).

For the superior, the questions involve (i) the practice of acknowledging override situations and (ii) consequences from their perspective. For this perspective, the hypotheses are that the superiors can adequately judge whether employing override is reasonable in most cases (H4) and that they will try and reduce the number of override occurrences through discussions with the users, changes to the business process, or modifications of the authorization policy or functionality of the application (H5).

Quantitative analysis

The quantitative analysis should provide an answer to the questions who used policy override, how often, and when. Table 1 shows the quantities of usage by users, activities, and actions. Of the 46 total active users in the period, 26 had the option of using override, of which a large proportion of one third actually used the override. Even more surprising, of the activities and actions by users with the option to enact override, 7% and 10% were conducted in override mode, respectively. The proportions roughly double when only considering the second half of 2010. In contrast to H1, these results indicate that override was used not only in singular cases but as a convenient option to complete the daily tasks.

Table 1. Quantitative analysis of the activity and action log.
 TotalActions by users with override optionIn override modeThose without override optionSecond half with override optionSecond half in overrideThose without override option
Active users4626934.6%22836.4%
Actions534 735488 37347 8309.8%249 48347 78719.2%

The results of concentrated use in the second half require further analysis. In Figure 4, the weekly use of the override is compared to the normal use with lines for proportions and points for action quantities. The chart shows that, indeed, all significant override activities occurred in the second half of the year, although the total usage of the system remained similar to the first half. Moreover, from week 26 onwards, the proportion of override use is, apart from a few spikes, constantly hovering around 20% of actions.


Figure 4. Override use in comparison to normal use over time.

Download figure to PowerPoint

The last approach to the quantitative analysis is a closer look at the distribution among the users who employed the override mode, as shown in Table 2. Secretary F and Operator A can be excluded from the analysis because the action counts indicate that they entered it accidentally or only tested the override mode. From the other users, we can make out one project manager (B) and four secretaries with significant proportions of override activity. Another secretary and project manager sporadically used policy override. The users' reasons will be further analyzed qualitatively in the following section.

Table 2. Override activities and actions by the user.
PseudonymTotal activitiesActionsOverride activitiesActions
  • *

    Interviewees who were override users from different branches.

Project manager A*75363311.3%431.2%
Project manager B115164554.3%603.6%
Secretary A*23777 49520.8%120.0%
Secretary B*24699 509228.9%61336.2%
Secretary C3412 050514.7%5734.8%
Secretary D*24654 3587028.5%26 00847.8%
Secretary E13445 1614332.1%14 99433.2%
Secretary F23626014.3%20.0%
Operator A26150.0%583.3%

Qualitative analysis

For further analysis of the reasons behind the partly surprisingly intensive usage of policy override by individual users and how the superiors judged the override usage, I conducted interviews with five of the stakeholders. Four of the interviewees were override users from different branches, marked with an asterisk in Table 2, and one was a superior, responsible for acknowledging the override use in one branch.

Secretary D stated that her override usage began with a short-term vacation replacement on short notice for colleagues at a different branch. Normally, she would not have the necessary permissions for the tasks at the other branch, so she used the override mode. Although the vacation replacement ended, she continued to fill in for the other branch because of the high workload there. Because no appropriate role for access to multiple branches existed, an alternative would have been for her to use multiple logins. Switching logins is quite a hassle, so she preferred the override mode for quickly completing tasks at different branches. Other exceptional situations for her to use the override mode are, for example, when the responsible project manager is not in the branch and certain tasks need to be completed quickly. Interestingly, she uses secondary credentials of project managers for these tasks despite the possibility of using override for those. She did not know that the override mode would also apply there and did ‘not have the time to experiment to find that out’. She also stated that she ‘just used it and it's OK’, fearing that any consequences from the recurring override usage would impact her productivity.

For Secretary B, the reasons are similar, generally using the override mode ‘as fill-in’ for other branches and to not ‘log out and in again’ for cases for which she has a secondary login. Although she did not remember to have explicitly discussed the override usage, she had, in fact, indicated to a superior that it would make sense to receive permissions for all branches. But policy override is ‘an alternative to that’ so that she did not further pursue the request.

Secretary A's override usage is closer to the original intention of policy override. As the quantitative analysis shows, she only used policy override on two occasions. She says that normally, she is ‘not missing any permissions’ in daily work and only used policy override for convenience to create a new user for which she would else have needed to turn to her superior. From her perspective, many ‘normal’ users should not have all permissions to override and ‘rummage wildly around the system or change things’. For her, it is difficult to assess the risks. Project manager A has a similar override usage pattern with only one activity in the studied period. In his case, the application would not allow task assignments to arbitrary users but only to those with specific roles and adding roles to users is only allowed for administrators. By using the override mode, he was able to assign the role. Subsequently, the functionality was changed to not require the additional role to be assigned. For him, the positive side is that the override mode allows more flexibility without generally loosening the restrictions.

In an interview with one branch manager who was in charge of acknowledging the override activities, he could largely recall who used the override mode and for what reasons. He was aware that some end users already employed the override over a long time regularly and stated that with ‘so many actions, it is difficult to relate them and evaluate whether the actions are OK’. This also pertained to the difficulty of estimating the risks. Although acknowledging that it works fine generally, it is difficult for him to review the specific actions that are taken in the override mode. The review tool would be needed to better summarize the activities to allow effective reasoning. Moreover, he said that the original aim was to ‘look at the override usage and draw consequences from it’, but with the large number of acknowledgments, he became accustomed and did not ‘pay attention to it anymore’.


From the quantitative and qualitative analysis, I identified two ways of how policy override was used in the studied application. One was for exceptional situations when, for example, the responsible user was not present and a task needed to be completed quickly, in line with H2. For these cases, the main challenge for the users was to understand which activities they can conduct in override mode. In other cases, the application functionality was not prepared for changes in the workflow so that the override mode helped until the functionality was changed. The second general way of employing override was the intensive and regular usage over a long period without modifications being pursued to remedy the situation, contradicting H2, H3, and H5. Superiors became accustomed to the acknowledgments. End users did not have any incentives to require changes either, even fearing that their productivity could be impacted by any changes. Also, no harm was seen in using override, although superiors invested significant efforts in acknowledging override activities. Acknowledging the specifics of override activities was difficult, partly contradicting H4. Superiors need a good review tool that summarizes override activities for better evaluation. Similarly, responsible stakeholders need to be able to estimate the risks and benefits from override.

Overall, the study shows a mixed result on the use of policy override. The mechanism certainly came in handy for functional staff to complete work in exceptional situations, thereby, increasing productivity of the staff and resulting in less need for policy changes. However, because of the organizational inadequacies surrounding the mechanism, it was used far too often and in ways not originally foreseen, potentially increasing the risk to the system at an unexpected level.

There are a few threats to the validity of this study. The number of interviewees was comparatively small, although care was taken to represent the different kinds of override users in the case study. Also, the setting of the case study was specific to business Web applications and the domain of SMEs so that it is difficult to judge transferability to other domains. However, even if specific, the results can support the development of better policy override implementations. As for the validity of the quantitative results, the high usage numbers may not be representative because this is a single case study. Although the specific quantities may not apply to other environments, the main contribution of this study is exploratory in nature, and the organizational challenges will be similar in other contexts.

Advice on the implementation of policy override

From the results on the policy override evaluation, I derive four pieces of advice on details to pay attention to when deploying policy override in information systems.

  • Support users' understanding of which additional activities are available in override mode, for example, through training or by visualization in the application.
  • Provide an adequate override review tool that summarizes the actions taken in an override session in a comprehensible manner.
  • Make the provisions to guarantee that changes are enacted when override use is recurring. There are multiple options to achieve this goal, including the following:
  • Technologically, through indications on which override reasons recur and, thus, require consequences;
  • Technologically, through further measures that raise the awareness of hidden costs incurred from repeated override use, such as an override budget that needs to be explicitly increased by superiors when used up;
  • Organizationally, through procedures and responsibilities for reactions to recurrences; or
  • Organizationally, through incentives for users to remove the need of override usage.

The consequences of recurring override usage can involve the modification either of the application functionality, the authorization policy, or the business processes.

  • Provide support for the estimation of benefits and risks from a specific override policy to simplify the decisions on the policies.


  1. Top of page

When defining an authorization policy with override options, security and domain experts not only need to assign the normal privileges of each role. For the normal privileges, experts usually evaluate the authorization requirements from a need-to-know perspective. In policies that consider an override, a second, hard boundary needs to be defined in addition to the soft boundary, which is derived from the need-to-know evaluation. The hard boundary is a result of the balancing of risks and benefits. The risks arise from access to additional, not routinely needed knowledge and abilities of each role. Benefits are the potential advantages of policy override from the higher flexibility. This task is difficult for functional stakeholders, as also stated in the policy override evaluation in Section 3, because various threats and risks, as well as several factors relating to the benefits, need to be considered. In order to help with this decision, the policy override calculus gives an estimate of how appropriate specific hard boundaries for individual roles are. The calculus employs formulae on the basis of qualitative risk management principles.

Generally, it is difficult to precisely assess the risks in complex systems, such as information systems [22]. With several, often speculative factors affecting the risk, policy makers are heavily burdened with the overall assessment. Instead, risk factors can be collected systematically and aggregated manually to formalize the risk assessment process [23]. To further support the risk assessment, manual aggregation can be converted into calculations. There are primarily two options for risk assessment: either quantitatively, through calculations of values at risks and probabilities of incidents, or qualitatively [24]. In the policy override calculus, the adequacy of override by role and override extent is derived from qualitative data collected from domain and security experts for several inputs of the calculus. I decided against a quantitative assessment because quantitative estimations suggest a precision that is not realistic [25, 26]. For example, humans are very imprecise when estimating frequencies of occurrences [27], and risk estimations depend on the context [28, 29]. Also, many aspects, such as attacker motivation in case of insider threats, are difficult to quantify. As a result, quantitative results need to be interpreted. For the policy override calculus, a qualitative and relative risk, which allows one to rank the risks, should suffice as decision support. The calculus estimates the additional risk for specific extents when compared to the default authorization of a specific role.

The primary factors of the override adequacy calculus are the risk and benefit associated with specific override extents. As depicted in Figure 5, both risk and benefit are derived from a number of inputs that are combined through the formulae. In risk management, the implementation of possible mitigations is often decided on the basis of a risk/cost relationship [30]. Similarly, the risks are balanced against potential benefits for the policy override calculus, thus, replacing costs with the benefits of policy override. The reasoning is that the lost benefit from not allowing override is analogous to the costs of mitigating the risk caused by policy override. By not allowing policy override, the potential override benefits are lost, but, equally, the risks mitigated. First, I discuss the risks that an organization is exposed to when granting override options to users. The qualitative values that are collected for the input components are either Normal, High or Very High, abbreviated as ‘N’, ‘H’ and ‘V’ in the tables.


Figure 5. The calculus formula overview.

Download figure to PowerPoint


In information security, it is common to aggregate the individual risks for the security objectives confidentiality, integrity, and availability into a single risk value, as suggested by the National Institute of Standards and Technology (NIST) risk management guide [25] and ISO/IEC 27005 [31]. The policy override calculus follows this approach. The Risk is a function of a system user's role and a specific privilege extent, for example permitting access to only individual objects of a type or all related to an organization's branch.

  • display math

Following Lenstra and Voss [32], the aggregation operator (∝) is defined as the maximum of the individual risks. The individual risks do not need to be weighted in this aggregation, as weights are implicitly present in each individual risk's value through the protection need, as described next.

Specific risk

For each security objective, confidentiality, integrity, and availability, the Specific Risk is calculated for each user role and override privilege extent. In risk models, risk is typically defined as the expected loss resulting from a threat as calculated from the product of an incident's potential damage and its likelihood [33]. Following this approach for the calculus, the Specific Risk is derived as the individual risk to the security objective from the Protection Need as the expected impact and the Threat Likelihood as the likelihood of the incidents.

  • display math

The ⊗ operator is defined as a look-up matrix shown in Table 3 that follows the Risk-Level Matrix proposed in the NIST 800–30 guidelines, in which the risk levels are determined through multiplication [25].

Table 3. Specific risk: (protection need)  (threat likelihood).
  Protection need
NormalHighVery high
  1. N, normal; H, high; V, very high.

  2. , this operator is defined as a look-up matrix.

Very HighNHV

One operand for the calculation of the Specific Risk is the impact of incidents that is approximated through the Protection Need as defined in BSI IT-Grundschutz, the German information security standard for baseline protection [34]. In the standard, the protection levels are defined as follows:

  • Normal, the impact of any loss or damage is limited and calculable.
  • High, the impact of any loss or damage may be considerable.
  • Very high, the impact of any loss or damage could be of catastrophic proportions threatening the survival of the organization.

The IT-Grundschutz standard defines the protection need levels for the impacts regarding the violation of laws, regulations or contracts, privacy rights, physical injury, the ability to complete tasks at hand, internal and external effects, and financial consequences [34].

The protection need values are differentiated according to the exposure extent. A company with several branches may be able to absorb the losses of a single incident at one branch. On the other hand, if the whole company is affected, the damage might be disastrous. The potential damage, thus, depends on the extent of data exposed. An example for the different risk levels by privilege extent is shown in Figure 6. In the example, the disclosure of only some contracts' quality data has a much smaller impact than the disclosure of all of the company's contracts.


Figure 6. Example of risk varying according to the privileges of a role.

Download figure to PowerPoint

Threat likelihood

The second operand for the Specific Risk is the Threat Likelihood, defined as the likelihood of the occurrence of an incident. The threat likelihood is calculated for a given security objective and role in the case wherein a specific policy override extent has been assigned to that role:

  • display math

Two aspects are taken into consideration to arrive at an estimation of the threat likelihood: the threat induced by the personal factors of users in specific roles (Role Threat) and the differences in the threat caused by different privileges (Opportunity Threat). This separation is based on criminological models on insider threat. The insider threat models in literature separate the aspects of the capability of users, the motivation, and the opportunity in the information systems (CMO model) [35-38]. The capability is of minor interest for the risk in the case of policy override because the risks are expected to originate from ordinary activities similar to an insider's daily routine rather than sophisticated attacks. On the other hand, motivation and opportunity of users are of high importance. To facilitate the collection of input data for opportunity and motivational factors with a reasonable effort, these factors are collected by the two separate input types, role threat and opportunity threat. This separation can also be found with Magklaras and Furnell [39], who suggest a similar insider threat model that depends on reasons and system role. Schultz [35] also uses the privilege of users as attributes of insiders in his CMO model, further supporting the modeling of the opportunity threat in the calculus.

Role threat

As described above, the role threat captures the threat likelihood aspects that differ regarding the system roles. Intuitively, for personal factors, experts need to evaluate how trustworthy a group of employees in a specific role is [40]. Magklaras and Furnell [39] define a taxonomy for insider threat considering the user's system role, reasons of attack, and the attacks' consequences. We follow their approach on the reasons of attack and differentiate accidental from intentional threats. On the intentional side, following the CMO model, the role threat foremost relates to the motivation that causes insiders to harm the employer. The NIST 800–30 risk management guide lists human threat sources [25]. From practice, Randazzo et al. [41] assembled a detailed study on insider threat incidents in the banking and financial sector and describe different motivations. Further motivations are described in a United States Computer Emergency Readiness Team report on critical infrastructure sabotage, including disgruntled employees, previous sanctions, and personal predispositions that may be mapped to users in roles [42]. According to Cappelli et al. [43], insiders tend to occupy foremost lower-level, nontechnical positions, another factor that supports the correlation between the system roles and threat likelihood. Similarly, a study by the Association of Certified Fraud Examiners [44] on 1134 fraud and abuse incidents, not limited to computer system activities, shows that the perpetrator's position and department affects incident frequencies.

In addition to motivational factors, threats from accidental incidents need to be considered. Accidental aspects can be derived from previous incidents for specific roles, the training level of employees in a role, and similar aspects [45, 46]. A selection of aspects and typical incidents relating to the system role that security experts need to take into account for the role threat estimation is listed in Table 4. The qualitative threat values for the role threat correspond to an estimation of the likelihood of incidents. The input value Normal stands for highly unlikely, high for unlikely, and very high for likely that an incident occurs.

Table 4. Likelihood factors and threats related to the role threat likelihood.
Threat likelihood factorsTrust in employees; employee satisfaction; seniority; previous issues with employees of specific roles; deterrentsFrequency of application usage; application usability; work environment; training level
Threats to confidentialitySelling of dataInappropriate data handling
Threats to availability, integrityIntentional data manipulationAccidental removal, modification of data
Opportunity threat

The second dimension of the insider threat likelihood is the opportunity that is caused by the extent of privilege in override cases. The opportunity threat is differentiated by privilege because the differences of data exposure and of possible actions in the system influence the threat likelihood. In the criminological CMO model, opportunity is one of the three primary categories. According to the Rational Choice Perspective from the Situational Crime Prevention theory, crimes are deliberate and purposive even though the decisioning of perpetrators may be imperfect [38]. Thus, the motivation might be higher with increased opportunity that causes, for example, higher interests in the data for espionage and higher impact in case of sabotage. Financial gain motivates most perpetrators [41]. In an insider threat prevention guide, Cappelli et al. [43] list motivations for theft and modification for financial gain and business advantage, stating that insiders acted mostly for financial gain by stealing and selling data or modifying data for their own or friends' profit. Another insider threat aspect is that ‘opportunity makes a thief’, as described for insider threats in the Audit Commission report [47].

The opportunity threat is estimated independently from personal factors, which are already considered for the role threat. Moreover, the opportunity threat likelihood depends only on the motivational factors for harmful actions so that only intentional aspects are taken into account. The varying impacts from accidental incidents caused by different privileges are already taken into account for the protection need. A selection of relevant aspects of threats to confidentiality, integrity, and availability are given in Table 5.

Table 5. Likelihood factors and threats related to the opportunity threat likelihood.
 ThreatLikelihood factors
ConfidentialitySelling data for industry espionageData value to competitor; risks in selling
Integrity, availabilityData manipulationGain from fraud; value of sabotage to competitor
Threat likelihood aggregation

Automatically aggregating the role threat and opportunity threat values is a key challenge. The aim is to aggregate the different input dimensions of the threat likelihood for specific roles with the values for the specific privileges. The proposal of the look-up operator ⊙ is shown in Table 6. It is based on the assumption that ‘opportunity makes a thief’ [47]. The operator result starts out from the threat estimation for the specific role, which is then modified according to opportunity effects. For very high opportunities, even solid employees might be tempted to commit a malicious insider act so that the aggregated threat is high. For high and very high role threats, the aggregated threat increases with higher opportunities.

Table 6. Threat likelihood: (role threat) ⊙ (opportunity threat).
 Role threat
NormalHighVery high
  1. N, normal; H, high; V, very high.

Very highHVV


While there are potential risks related to allowing policy override, an organization may significantly benefit from the increased flexibility. The benefits are estimated with the following formula for users of a role with a specific override extent configuration:

  • display math

The benefit is calculated from the frequency of override incidents and an estimate of the benefit that may be achieved on average from each override incident. Following quantitative calculations, the × operator acts similar to the multiplication operator, as shown in Table 7.

Table 7. Benefit: (benefit per override) × (override frequency).
 ×Override frequency
NormalHighVery high
  1. N, normal; H, high; V, very high.

  2. ×, this operator acts similar to the multiplication operator.

Very highHVV

The daily routine of system users often varies significantly according to the role. In the same way, each role may have different frequencies of situations where quick responses are needed. Thus, domain experts estimate the frequency of override cases by role. Aspects to consider should include the structuredness of daily routine, the frequency of unforeseeable incidents, and whether there is direct customer contact. Existing application log data and interviews can provide the basis for this factor.

Benefit per override

The second component for the calculation of the benefit is the benefit that may be gained in each override incident:

  • display math

Benefit per override follows the intuition that each case of policy override brings benefit but also causes auditing effort for the superior who is responsible for auditing the case. Depending on the auditing implementation, auditing effort may reduce the benefit from policy override cases, particularly with high numbers of policy override cases. Accordingly, benefit per override derives the net gain that is achieved in each override case from the efficiency gain in each case and the auditing effort per case (−). Efforts estimated as high and very high reduce the net gain similar to subtraction, as shown in Table 8.

Table 8. Net gain per override: (gain per override) − (effort per override).
 Effort per Override
NormalHighVery high
  1. N, normal; H, high; V, very high.

Very highVHN
Efficiency gain per override

The efficiency gain per override action is estimated separately for each role and permission extent. Benefit scenarios help with this step. In the example of a quality operator in Figure 6, domain experts may foresee cases in that the company may profit to a larger extent from the access of data of the whole assigned branch because the operator might jump without any bureaucracy from one local contract to another. On the other hand, the experts may find it unlikely that the same employee would need to switch branches quickly. Aspects to be considered are the company gain per override, the time saved by not requiring a formal delegation of permissions, and the likelihood of work in the context of a specific extent. The qualitative input values should only be above normal if there is additional gain when compared to the original privilege extent of a role. In addition to benefits from the end user perspective, it is also necessary to consider the effort from saved administrative tasks, which is often significant [48]. Instead of assigning new permissions for temporarily required authorization, the end user may resort to policy override, reducing the administrative overhead.

Effort per override

The additional effort that the company needs to invest per override is foremost caused by the need to audit override actions afterwards. For the policy override calculus, domain experts estimate the typical effort that is spent on auditing the actions per override.

Override adequacy

From the risk and benefit estimations, the policy override adequacy is determined as decision support for the policy override authorization configuration for each role with a specific override extent assigned:

  • display math

The ⊳ ​ ⊲ operator balances risks with benefits. The interpretation of the outcome of this operator depends on the company policy with regard to acceptable risks. The United States Federal Information Processing Standard (US FIPS) 191 guideline suggests calculating the risk/cost relationships to balance the security mechanism costs against risks on the basis of qualitative data [49]. Similarly, the look-up table for the operator definition, given in Table 9, is derived from the risk/benefit relationship. In this case, the costs are the lost benefits from not employing override as a way to mitigate the risks from override actions. The adequacy values are calculated by quantifying normal as 1, high as 2, and very high as 3. The result from the ratio a = Gain/Risk is interpreted as low for values a < 1, normal for 1 ≤ a < 1.5, high for 1.5 ≤ a < 2.5, and very high for values a ≥ 2.5. Results from this operator do not offer an absolute estimation of the override adequacy. Rather, the results help by providing an order of the most suitable role/privilege extent combinations.

Table 9. Override adequacy: (aggregated risks) ⊳ ​ ⊲ (net gains).
 ⊳ ​ ⊲Aggregated risk
NormalHighVery high
  1. N, normal; H, high; V, very high.

  2. ⊳ ​ ⊲, this operator balances risks with benefits.

Very highVHN

Calculus case studies

For the evaluation of the proposed calculus, I developed the Web-based Override Risk Assessment tool, depicted in Figure 7 (note, the results in the screenshot are given in Table 10), to facilitate the collection of input data and calculation of the override adequacy. In the override risk tool, input tables are provided for each of the input types. If necessary, even the operator tables may be modified here. The resulting override adequacy is continuously calculated and displayed in the bottom area, so that stakeholders who provide the input for the evaluation can directly see the consequences of inputs. Inputs and results are colored according to the qualitative value to ease the collection of data and interpretation of results.


Figure 7. Override Risk Assessment tool

Download figure to PowerPoint

Table 10. Example result for the override adequacy by role and privilege extent.
Override adequacyPrivilege extent
LogisticsContractsQuality data
BranchCompanyBranchCompanySpecific contractsBranchCompany
  1. N, normal; H, high; V, very high.

Inventory NNNNNL
Logistician   H HN
OperatorNLHL HL
SecretaryHH H  N
Project manager V H VH

I evaluated the proposed override calculus in two distinct environments as case studies. The context of the first evaluation is the medium-sized enterprise from the policy override study described in Section 3. With the policy override in place, the employees have already built up experience with the policy override concepts. To evaluate the developed calculus, I worked together with the company's managing director to collect the necessary data. Parts of the results from the analysis with the Override Risk Assessment tool are shown in Table 10 by role and privilege extent. The privileges correspond to application areas in the authorization policy. Five roles of employees from the authorization policy are shown. Employees with the inventory role manage stock in the warehouse. Logisticians are office workers concerned with logistics coordination. Operators perform the quality control tasks. Secretaries and project managers fulfill administrative and project-specific management duties, respectively. Because of space considerations, the individual input values are not shown.

As shown in the result table, the calculus only outputs values for permissions not already assigned for the conventional need-to-know permission. The results are very heterogeneous. For example, the results strongly suggest policy override for project managers with two very high and two high results. Operators, on the other hand, should only receive override privileges to some extent, as indicated by the low values. After the data collection, I interviewed the managing director from the studied company on the plausibility and relevance of the results. The managing director agreed with the results and decided to adapt the original override policy. The override calculus thus supported the domain experts' intuition in the complex evaluation of risks and gains.

The second evaluation context is a large enterprise from the food industry with about 1000 employees. In this case, an IT management individual used the Override Risk Assessment tool with assistance. Whereas the first evaluation focused on usefulness of the adequacy results, the second case was aimed at the usability of the calculus. Primarily, the evaluation looked at the necessary effort and the comprehensibility of the involved risk and benefit concepts. For that reason, the policy override calculus was only collected for part of the company's roles, and an interview was conducted on the studied context and the participant's impressions. In the studied environment, no explicit risk assessment had been conducted for authorization policy decisions before. Thus, the estimation of protection needs and threat likelihoods were initially perceived as a challenge. Still, the concepts that are used in the calculus could be applied. One minor issue was that the available levels to choose from are abstract, and natural-language categories, instead of ‘normal’ and ‘high’, could improve the process. In the company's enterprise resource planning system, only a flat role structure has been implemented, resulting in a large number of roles. The participant thus saw an increased amount of effort required to fully analyze the company with the policy override calculus. Here, similar to the initial role engineering, external support might be necessary. On the other hand, he was unsure whether the role-based distinction was fine-grained enough to estimate personal threat likelihoods.

From the two small-scale evaluations, I draw the conclusion that the current design of the calculus and implementation of the Override Risk Assessment tool may be helpful in small to medium enterprises. For large enterprises, the effort may be increased, at least when there is no structured risk assessment data available. Still, further research and larger-scale evaluations are necessary to show the broader validity of the proposed method.


  1. Top of page
Policy override

Policy override is an authorization mechanism that is already in use in health care applications. Accordingly, most literature on practical experience with override and its implementation is from health care environments. Denley and Smith [16] report on the experience of implementing override as an addition to other authorization mechanisms in clinical information system. Medical personnel not previously connected to a patient are presented with a warning that an override action is possible but will be logged. They report about 50 override actions a day, mostly from less computerized staff. Røstad and Edsberg [12] analyzed the audit logs of a clinical information system's policy override. The system has predefined reasons for an override, and the user may access the document for set periods. The study states a very high usage frequency of override mechanisms with records of over 50% of patients in contact in the study time span being accessed in the override mode. The high count of override accesses suggests that no appropriate auditing is possible. There also is a US Health Insurance Portability and Accountability Act document on the usage of policy override in health care [50].

Longstaff et al. [17] describe a complex Unified Modeling Language (UML) electronic health record model as an enhancement of UK's Healthcare Model with an RBAC3-styled authorization, as defined by Sandhu et al. [19]. For the case of patients not able to communicate or not willing to cooperate in a risky treatment, policy override is available to access confidential information with logging and automatic notification of clinical governance and the patients' general practitioner. Two different types of override are described: specific override, which allows access only to the parts that the user would have been able to read in his role if the user had a connection to the patient. The second type is general override, permitting access to all information in a patient's electronic record.

Outside of healthcare institutions, Stevens and Wulf [9] report on an authorization case study at a steel mill that analyzes interorganizational cooperation and competition from a computer-supported cooperative work perspective. From the results of the study, they implemented an authorization scheme that allows authorizing access manually or in retrospect.

Further literature on policy override discusses specific models and mechanisms. Badger [13] proposed a formalism for the recovery of a system from the state of override in a mandatory access control system. The mechanism allows relaxing constraints of the policy and reports in detail which parts of the policy was violated while in the state of override. Povey [8] introduces the policy override as Optimistic Security and formulates requirements. One of those requirements is a mechanism for reverting illegitimate actions in retrospect. His approach is a formal database model of transactions based on the Clark–Wilson integrity model for guaranteeing system integrity. Jajodia et al. [11] suggest a formal model for auditing transactions in databases.

Ferreira et al. [51] propose an obligation-based policy override approach. Brucker and Petritsch [52] model policy override for eXtensible Access Control Markup Language (XACML) with SecureUML, including a low and high emergency mode. Cheng et al. [15] analyze the economic aspects of access governance to propose an adaptive, risk-based authorization mechanism. They use risk quantification for risk/benefit analysis with ‘risk credit lines.’ On the basis of the Multi Layer Security (MLS), the Fuzzy MLS system has hard and soft authorization boundaries to enact the appropriate amount of authorization. Instead of quantifying risk, Zhao and Johnson [7] employ a game-theoretical approach to model incentives in policy override authorization. They discuss information governance and a speeding ticket analogy to enforce the proper employment of override possibilities by users. The details of the game theory model are described in [53].

Johnson et al. [54] take on an economic perspective as well and compare the effects of strict and centrally managed file access control with the failures of centrally planned economies. They give a comprehensive overview of possible consequences of strict policies and argue that some control over authorization should be left with the individual document owner. They defined the requirements ownership, freedom of delegation, transparency, dependability, and minimization of friction. As a natural user interface, Johnson et al. designed the delegation by the e-mail-sending metaphor but have problems when implementing it in the Windows-shared folder domain. Their approach differs in that they simplify delegation, which is sufficient for file sharing as there is at least one person involved who already possesses read permissions. However, authorization override is more global in its application scope and is not limited to file sharing.

Rissanen et al. [14] also propose adding override to authorization mechanisms and offer an algorithm to identify users responsible for auditing policy overrides. Lastly, Cederquist et al. [10] describe a formal audit-based authorization mechanism that requires justifications from users. The domain of their approach is similar to that of Johnson et al. in that users directly interact with each other. Cederquist et al. give a formal proof of their framework and show the framework's viability through an example from a consultancy firm.

In contrast to the previously cited works on policy override, the model and implementation described in this paper is intentionally kept simple, only adding one additional relation to the RBAC model. Thus, the threshold is reduced for the systems development and operations stakeholders to employ policy override. Moreover, most of the cited works focus on the override models and algorithms, without evaluating their practical implications, a key contribution of this paper.

Override calculus

To the best of our knowledge, there have been no prior publications on decision support for the configuration of policy override. However, risk assessment has been included in override authorization models by Cheng et al. [15] in their optimistic authorization model, as discussed previously. Without explicitly offering override functionality, the risk-based access control model RAdAC balances operational needs versus security risks [55]. Britton and Brown [56] analyzed risk factors to be used in the RAdAC model. Similarly, Diep et al. [57] described an authorization model with context-based decisions that includes a quantitative risk assessment on each action. For a similar mechanism, Dimmock et al. [58] suggest a Prolog-based risk and trust decision-making mechanism, in which each action is checked against a risk function for the current state, ensuring that it is below a certain threshold. Molloy et al. [59] implement authorization through a trading or auction metaphor, employing a risk calculation function. These models use quantitative methods to automatically judge the risk of actions and, thus, authorization. In practice, quantitative risk assessment is missing the necessary reliability for automatic decision making in many contexts because of insufficient input data quality. Qualitative methods are also more common in practice. Therefore, the qualitative decision-support approach as suggested in this paper should be more practical.

In the broader realm of information security, other decision support approaches have been proposed. For example, in the Quality of Security Service, the end user chooses a variable amount of security according to the current needs and balances with respect to performance, fidelity, etc. [60]. Beresnevichiene et al. [61] use a utility function to model the economic benefit from security investments. Taking security usability into account, Parkin et al. [62] suggest a tool to allow information security officers to choose an adequate password policy.

Risk assessment for information security decisions is the second major building block of the policy override calculus. Systematic evaluation of system security through threats and security features is not a new concept [30]. The underlying risk assessment approaches can be categorized according to their quantitative or qualitative nature. Quantitative approaches, on the basis of numerical calculations of values and probabilities, have, for example, been proposed for information security by Guarro [63]. Post and Diltz [64] suggest a stochastic dominance approach to quantitative risk analysis to more precisely compare different mitigation options. Jaisingh and Rees [65] describe the value-at-risk methodology, which results in a monetary evaluation of the current risk. More common in practice is qualitative risk assessment, such as the example given in ISO/IEC 27005 [31], which results in a relative risk estimation. It is also common to combine qualitative and quantitative approaches, for example, by combining several risk assessment methods and only using quantitative calculations in the last step, as discussed by Rainer et al. [66]. Karabacak and Sogukpinar [67] use questionnaires to collect qualitative inputs, which are then combined with quantitative methods to normalize responses.

On general risk management, there is a wealth of publications available [68, 69]. First of all, there are national and international standards on risk management. ISO/IEC 27005 [31] provides a general framework for risk management in IT systems. The US FIPS-65 standard, withdrawn in 1995, applied the well-known Annualized Loss Expectancy quantitative approach [70]. The most widely used management approaches are of qualitative nature. The NIST Special Publication 800–30 [25] is a well-known document that supersedes the quantitative FIPS-65 standard. Other widespread approaches are CCTA Risk Analysis and Management Method (CRAMM) [71] and Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) [72]. These standard methods enact very similar processes: They start with a qualitative valuation of assets or impacts of incidents. Then, threats and vulnerabilities are identified and categorized with likelihood estimations, again by way of qualitative values. In a risk assessment step, the inputs are combined into risk estimations, and in the risk management part, mitigations are chosen. The risk management processes are very powerful methods for general assessment of risks. In order to derive the appropriate override privileges, the objective of the calculus presented in this paper, the standard processes operate at a high level and are too coarse. For the calculus, we need to differentiate between different roles and privilege extents. Moreover, the override calculus focuses on relevant threats, thus, reducing the effort. Still, outputs from the standard risk assessment processes may be a good basis for the input values of the proposed override calculus.


  1. Top of page

Authorization flexibility is one of the more obvious ways of increasing authorization usability. The security stakeholders benefit from a reduced workload from unnecessary policy changes for exceptional cases, and the functional stakeholders are less often hindered in their daily tasks by overly strict policies. This paper presents two contributions to authorization flexibility. First, I describe a policy override model and an implementation for the authorization framework declarative_authorization. I evaluated one year usage of the model and implementation in the context of a business Web application at a medium-sized enterprise. Although policy override was generally seen as positive, the evaluation indicated a mixed overall result because of shortcomings of the implementation, including integration in organizational processes of policy changes, lack of awareness for which tasks override is an option, and the necessity to support the definition of the override policies. Future research needs to address the organizational and awareness aspects. One research challenge is how to visualize the additional possibilities through override as part of the default user interface, which could, for example, be added through explanations of denials [73-75].

The second contribution of this paper addresses the challenge of formulating the override policy. Because not only the need-to-know is considered but also the two levels of risks need to be balanced against the benefits, the task is more complex than defining the default policy. To support this task, I propose a novel calculus that estimates the adequacy of policy override for specific roles and extents. The qualitative result is derived from indicator inputs, including the protection needs, threats, and benefits.

The evaluations of the calculus show that it may be viable for small to medium enterprises for insights into the adequate extent of policy override. Domain experts of the medium-sized company could improve the policy override configuration from the calculus results, and they have also given positive feedback on the usefulness of the results. In large enterprises, the implementation of an override risk assessment is more challenging. Still, with policy override concepts gaining traction in the research community, the calculus helps to overcome a major obstacle that hinders wider adoption outside of health care environments. Future work involves evaluation of the calculus on a larger scale. Then, I would like to evaluate adapting the calculus in the creation of conventional policies, use different levels of abstraction for input collection, and experiment with directly employing the calculus result in override permissions without expert intervention. Lastly, I consider reusing data from Information Security Management Systems and existing risk assessments to reduce the effort of collecting the input data.


  1. Top of page

I would like to thank the stakeholders of the medium-sized enterprise for making the evaluations of this research possible. Moreover, I thank the participants of the policy override case study for taking part in the interviews, as well as the stakeholders involved in the calculus evaluation for investing the necessary effort.


  1. Top of page
  • 1
    Hayek FA. The use of knowledge in society. American Economic Review 1945; 35: 519530. Reprinted in F.A. Hayek (ed.), Individualism and Economic Order. London: Routledge and Kegan Paul.
  • 2
    Sinclair S, Smith SW, Trudeau S, Johnson ME, Portera A. Information risk in financial institutions: field study and research roadmap. In Proceedings for the 3 rd International Workshop on Enterprise Applications and Services in the Finance Industry. 2008; 165180. doi:10.1007/978-3-540-78550-7_11.
  • 3
    Beautement A, Sasse MA, Wonham M. The compliance budget: managing security behaviour in organisations. In New Security Paradigms Workshop 2008. ACM, 2008; 4758. doi:10.1145/1595676.1595684.
  • 4
    Saltzer JH, Schroeder MD. The protection of information in computer systems. Proceedings of the IEEE 1975; 63(9):12781308. doi:10.1109/PROC.1975.9939.
  • 5
    Sikkel K, Stiemerling O. User-oriented authorization in collaborative environments. Proceedings of COOP '98, 1998.
  • 6
    Jones RL, Rastogi A. Secure coding: building security into the software development life cycle. Information Systems Security 2004; 13(5):2939. doi:10.1201/1086/44797.13.5.20041101/84907.5.
  • 7
    Zhao X, Johnson ME. The value of escalation and incentives in managing information access. In Managing Information Risk and the Economics of Security. Springer-Verlag: New York, Inc., 2009; 165177. doi:10.1007/978-0-387-09762-6_8.
  • 8
    Povey D. Optimistic security: a new access control paradigm. In NSPW '99: Proceedings of the 1999 Workshop on New Security Paradigms. ACM: New York, NY, USA, 2000; 4045.
  • 9
    Stevens G, Wulf V. A new dimension in access control: studying maintenance engineering across organizational boundaries. In CSCW '02: Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work. ACM: New York, NY, USA, 2002; 196205.
  • 10
    Cederquist JG, Corin R, Dekker MAC, Etalle S, den Hartog JI, Lenzini G. Audit-based compliance control. International Journal of Information Security 2007; 6(2–3):133151.
  • 11
    Jajodia S, Gadia SK, Bhargava G. Logical design of audit information in relational databases. Information Security: An Integrated Collection of Essays, Abrams MD, Jajodia S, Podell HJ (eds). IEEE Computer Society Press: Los Alamitos, CA, 1995.
  • 12
    Røstad L, Edsberg O. A study of access control requirements for healthcare systems based on audit trails from access logs. In ACSAC. IEEE Computer Society, 2006; 175186.
  • 13
    Badger L. Providing a flexible security override for trusted systems. In CSFW. 1990; 115121.
  • 14
    Rissanen E, Firozabadi BS, Sergot MJ. Towards a mechanism for discretionary overriding of access control. Security Protocols Workshop, Lecture Notes in Computer Science, Vol. 3957, Christianson B, Crispo B, Malcolm JA, Roe M (eds). Springer, 2004; 312319.
  • 15
    Cheng PC, Rohatgi P, Keser C, Karger PA, Wagner GM, Reninger AS. Fuzzy multi-level security: an experiment on quantified risk-adaptive access control. In SP '07: Proceedings of the 2007 IEEE Symposium on Security and Privacy. IEEE Computer Society: Washington, DC, USA, 2007; 222230.
  • 16
    Denley I, Smith SW. Privacy in clinical information systems in secondary care. BMJ 1999; 318(7194):13281331.
  • 17
    Longstaff JJ, Lockyer MA, Thick MG. A model of accountability, confidentiality and override for healthcare and other applications. In RBAC '00: Proceedings of the fifth ACM workshop on Role-based access control. ACM: New York, NY, USA, 2000; 7176.
  • 18
    Miller JA, Fan M, Wu S, Arpinar IB, Sheth AP, Kochut KJ. Security for the METEOR workflow management system. Technical Report, UGA-CS-LDIS, University of Georgia 1999.
  • 19
    Sandhu RS, Coyne EJ, Feinstein HL, Youman CE. Role-based access control models. IEEE Computer 1996; 29(2):3847.
  • 20
    Bartsch S, Sohr K, Bormann C. Supporting agile development of authorization rules for SME applications. In 3rd International Workshop on Trusted Collaboration (TrustCol-2008). Springer: Berlin, Heidelberg, 2009; 461471. doi:10.1007/978-3-642-03354-4_35.
  • 21
    Ferraiolo D, Kuhn R. Role-based access controls. In 15th NIST-NCSC National Computer Security Conference. 1992; 554563.
  • 22
    Straub DW, Welke RJ. Coping with system risk: security planning models for management decision-making. MIS Quarterly 1998; 22(4):441469.
  • 23
    GAO. Information security risk assessment: practices of leading organizations. Technical Report AIMD-00-33, GAO 1999.
  • 24
    Alter S, Sherer SA. A general. but readily adaptable model of information system risk. Communications of the AIS 2004; 14: 128.
  • 25
    Stoneburner G, Goguen A, Feringa A. Risk management guide for information technology systems—NIST special publication 800–30. Technical Report, National Institute of Standards and Technology 2002.
  • 26
    Peltier TR. Information Security Risk Analysis. CRC press: Boca Raton, FL, 2005.
  • 27
    Gilovich T, Griffin DW, Kahneman D (eds). Heuristics and Biases: The Psychology of Intuitive Judgement. Cambridge University Press: Cambridge, UK, 2002.
  • 28
    Borge D. The Book of Risk. Wiley, 2001.
  • 29
    Adams J. Cars, cholera and cows: the management of risk and uncertainty. Policy Analysis 1999; (335).
  • 30
    Hoffman LJ, Michelman EH, Clements D. SECURATE—security evaluation and analysis using fuzzy metrics. In International Workshop on Managing Requirements Knowledge. IEEE Computer Society: Los Alamitos, CA, USA, 1978; 531540. doi:10.1109/AFIPS.1978.169.
  • 31
    ISO/IEC 27005:2008. Information Technology—Security Techniques—Information Security Risk Management. ISO: Geneva, Switzerland, 2008.
  • 32
    Lenstra AK, Voss T. Information security risk assessment, aggregation, and mitigation. ACISP, Lecture Notes in Computer Science, Vol. 3108, Wang H, Pieprzyk J, Varadharajan V (eds). Springer: Berlin Heidelberg, 2004; 391401.
  • 33
    Stallings W, Brown L. Computer Security: Principles and Practice. Pearson Prentice Hall: Upper Saddle River, NJ, 2008.
  • 34
    Bundesamt für Sicherheit in der Informationstechnik (BSI). BSI-Standard 100–2: IT-Grundschutz-Vorgehensweise.Version 2.0 2008.
  • 35
    Schultz EE. A framework for understanding and predicting insider attacks. Computers & Security 2002; 21(6):526531.
  • 36
    Wood B. An insider threat model for adversary simulation. Research on Mitigating the Insider Threat to Information Systems #2, Anderson RH, Bozek T, Longstaff T, Meitzler W, Skroch M, Van Wyk K (eds). RAND: Santa Monica, CA, 2000.
  • 37
    Willison R. Understanding the perpetration of employee computer crime in the organisational context. Information and Organization 2006; 16(4):304324.
  • 38
    Willison R, Backhouse J. Opportunities for computer crime: considering systems risk from a criminological perspective. European Journal 2006; 15(4):403414. doi:10.1057/palgrave.ejis.3000592.
  • 39
    Magklaras G, Furnell S. Insider threat prediction tool: evaluating the probability of it misuse. Computers & Security 2002; 21(1):6273.
  • 40
    Shaw E, Ruby KG, Post JM. The insider threat to information systems—the psychology of the dangerous insider. Security Awareness Bulletin 1998; (2).
  • 41
    Randazzo MR, Keeney M, Kowalski E, Cappelli D, Moore A. Insider threat study: illicit cyber activity in the banking and finance sector. Technical Report CMU/SEI-2004-TR-021, CarnegieMellon June 2005.
  • 42
    Moore A, Cappelli D, Trzeciak RF. The ‘big picture’ of insider IT sabotage across U.S. critical infrastructures. Technical Report CMU/SEI-2008-TR-009, CarnegieMellon May 2008.
  • 43
    Cappelli D, Moore A, Trzeciak RF, Shimeall TJ. Common sense guide to prevention and detection of insider threats 3 rd edition—version 3.1. Technical Report, CarnegieMellon January 2009.
  • 44
    Association of Certified Fraud Examiners (ACFE). Report to the nation on occupational fraud & abuse 2006.
  • 45
    Bedny G, Meister D. Theory of activity and situation awareness. International Journal of Cognitive Ergonomics 1999; 1(3):6372.
  • 46
    Endsley MR. Toward a theory of situation awareness in dynamic systems. Human Factors: The Journal of the Human Factors and Ergonomics Society 1995; 37(1):3264. doi:10.1518/001872095779049543.
  • 47
    Audit Commission. Opportunity Makes a Thief: An Analysis of Computer Abuse. Audit Commission Publication: London, UK, 1994.
  • 48
    Gallaher MP, O'Connor AC, Kropp B. The economic impact of role-based access control. Planning Report 02–1 for the NIST March 2002.
  • 49
    NIST. Fips 191: guideline for the analysis local area network security. Technical Report, NIST 1994.
  • 50
    HIPAA. Break glass procedure: granting emergency access to critical ePHI systems, 2009. Retrieved on Jan, 11 2009.
  • 51
    Ferreira A, Chadwick D, Farinha P, Correia R, Zao G, Chilro R, Antunes L. How to securely break into RBAC: the BTG-RBAC model. In Annual Computer Security Applications Conference (ACSAC 2009). 2009; 2331. doi:10.1109/ACSAC.2009.12.
  • 52
    Brucker AD, Petritsch H. Extending access control models with break-glass. In SACMAT '09: Proceedings of the 14th ACM Symposium on Access Control Models and Technologies. ACM: New York, NY, USA, 2009; 197206.
  • 53
    Zhao X, Johnson ME. Access flexibility with escalation and audit. WISE 2008: Twentieth Workshop on Information Systems and Economics, 2008.
  • 54
    Johnson M, Bellovin S, Reeder R, Schechter S. Laissez-faire file sharing: access control designed for individuals at the endpoints. In New Security Paradigms Workshop 2009. 2009; 110. doi:10.1145/1719030.1719032.
  • 55
    Choudhary R. A policy based architecture for NSA RAdAC model. In Information Assurance Workshop (IAW 05). 2005; 294301.
  • 56
    Britton DW, Brown IA. A security risk measurement for the RAdAC model. Master's Thesis, Naval Postgraduate School Monterey, CA March 2007.
  • 57
    Diep NN, Hung LX, Zhung Y, Lee S, Lee YK, Lee H. Enforcing access control using risk assessment. In Universal Multiservice Networks, 2007. ECUMN '07. Fourth European Conference on. 2007; 419424. doi:10.1109/ECUMN.2007.19.
  • 58
    Dimmock N, Belokosztolszki A, Eyers D, Bacon J, Moody K. Using trust and risk in role-based access control policies. In SACMAT '04: Proceedings of the Ninth ACM Symposium on Access Control Models and Technologies. ACM: New York, NY, USA, 2004; 156162. doi:10.1145/990036.990062.
  • 59
    Molloy I, Cheng PC, Rohatgi P. Trading in risk: using markets to improve access control. In New Security Paradigms Workshop 2008. 2008; 107125. doi:10.1145/1595676.1595694.
  • 60
    Irvine C, Levin T. Quality of security service. In NSPW '00: Proceedings of the 2000 Workshop on New Security Paradigms. ACM: New York, NY, USA, 2000; 9199. doi:10.1145/366173.366195.
  • 61
    Beresnevichiene Y, Pym D, Shiu S. Decision support for systems security investment. In Network Operations and Management Symposium Workshops (NOMS Wksps), 2010 IEEE/IFIP. 2010; 118125. doi:10.1109/NOMSW.2010.5486590.
  • 62
    Parkin S, van Moorsel A, Inglesant P, Sasse MA. A stealth approach to usable security: helping it security managers to identify workable security solutions. In Proceedings of the 2010 Workshop on New Security Paradigms (NSPW '10). ACM: New York, NY, USA, 2010; 3350. doi:10.1145/1900546.1900553.
  • 63
    Guarro SB. Principles and procedures of the Lram approach to information systems risk analysis and management. Computer Security 1987; 6:493504. doi:10.1016/0167-4048(87)90030-7.
  • 64
    Post GV, Diltz DJ. A stochastic dominance approach to risk analysis of computer systems. MIS Quarterly 1986; 10:363376. doi:10.2307/249191.
  • 65
    Jaisingh J, Rees J. Value at risk: a methodology for information security risk assessment. In Proceedings of the INFORMS Conference on Information Systems and Technology. 2001.
  • 66
    Rainer RK, Snyder CA, Carr HH. Risk analysis for information technology. Journal of Management Information System 1991; 8(1):129147.
  • 67
    Karabacak B, Sogukpinar I. Isram: information security risk analysis method. Computers and Security 2005; 24(2):147159.
  • 68
    Baskerville R. Information systems security design methods: implications for information systems development. ACM Computing Surveys 1993; 25(4):375414. doi:10.1145/162124.162127.
  • 69
    Campbell PL, Stamp JE. A classification scheme for risk assessment methods. Technical Report SAND2004-4233, Sandia National Laboratories 2004.
  • 70
    NIST. Fips 65: guidelines for automatic data processing risk analysis. Technical Report, NIST 1975.
  • 71
    The CRAMM Manager. Cramm user guide issue 5.1. Technical Report, Insight Consulting 2005.
  • 72
    Alberts C, Dorofee A, Stevens J, Woody C. Introduction to the OCTAVE Approach. CarnegieMellon: Pittsburgh, PA, USA, 2003.
  • 73
    Kapadia A, Sampemane G, Campbell RH. Know why your access was denied: regulating feedback for usable security. In CCS '04: Proceedings of the 11th ACM Conference on Computer and Communications Security. ACM: New York, NY, USA, 2004; 5261.
  • 74
    Bonatti P, Olmedilla D, Peer J. Advanced policy explanations on the web. In Proceedings of the European Conference on Artificial Intelligence (ECAI). 2006; 200204.
  • 75
    Becker MY, Nanz S. The role of abduction in declarative authorization policies. Symposium on Practical Aspects of Declarative Languages (PADL 2008), Lecture Notes in Computer Science, Vol. 4902, Hudak P, Warren DS (eds). Springer, 2008; 8499.