Access Management

Go back to Tutorial

Access control mechanisms are a necessary and crucial design element to any application’s security. In general, a web application should protect front-end and back-end data and system resources by implementing access control restrictions on what users can do, which resources they have access to, and what functions they are allowed to perform on the data. Ideally, an access control scheme should protect against the unauthorized viewing, modification, or copying of data. Additionally, access control mechanisms can also help limit malicious code execution, or unauthorized actions through an attacker exploiting infrastructure dependencies (DNS server, ACE server, etc.).

Authorization and Access Control are terms often mistakenly interchanged. Authorization is the act of checking to see if a user has the proper permission to access a particular file or perform a particular action, assuming that user has successfully authenticated himself. Authorization is very much credential focused and dependent on specific rules and access control lists preset by the web application administrator(s) or data owners. Typical authorization checks involve querying for membership in a particular user group, possession of a particular clearance, or looking for that user on a resource’s approved access control list, akin to a bouncer at an exclusive nightclub. Any access control mechanism is clearly dependent on effective and forge-resistant authentication controls used for authorization.

Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication – as these terms and their definitions are frequently confused. Authentication is providing and validating identity. In a system that uses a simple username and password scheme, the authentication process collects the username and validates the identity using the password. Authorization is the execution of access control properties, ensuring the proper allocation of access rights once authentication is successful.

Access Control is the method or mechanism of authorization to enforce that requests to a system resource or functionality should be granted.

We need to know that entities that request access to resources are subjects and the resource is an object. Unless otherwise designed to, web applications need access controls to allow users (with varying privileges) to use the applications and administrators to manage the application. Various access control methodologies are available. To choose the most appropriate one, a risk assessment needs to be performed to identify threats and vulnerabilities, so that the identified methodology brings down the risk value to an acceptable level.

Access Control refers to the much more general way of controlling access to web resources, including restrictions based on things like the time of day, the IP address of the HTTP client browser, the domain of the HTTP client browser, the type of encryption the HTTP client can support, number of times the user has authenticated that day, the possession of any number of types of hardware/software tokens, or any other derived variables that can be extracted or calculated easily.

Before choosing the access control mechanisms, several preparatory steps can help expedite and clarify the design process;

• Try to quantify the relative value of information to be protected in terms of Confidentiality, Sensitivity, Classification, Privacy, and Integrity related to the organization as well as the individual users. Consider the worst case financial loss that unauthorized disclosure, modification, or denial of service of the information could cause. Designing elaborate and inconvenient access controls around unclassified or non-sensitive data can be counterproductive to the ultimate goal or purpose of the web application.
• Determine the relative interaction that data owners and creators will have within the web application. Some applications may restrict any and all creation or ownership of data to anyone but the administrative or built-in system users. Are specific roles required to further codify the interactions between different types of users and administrators?
• Specify the process for granting and revoking user access control rights on the system, whether it be a manual process, automatic upon registration or account creation, or through an administrative front-end tool.
• Clearly delineate the types of role driven functions the application will support. Try to determine which specific user functions should be built into the web application (logging in, viewing their information, modifying their information, sending a help request, etc.) as well as administrative functions (changing passwords, viewing any users data, performing maintenance on the application, viewing transaction logs, etc.).
• Try to align your access control mechanisms as closely as possible to your organization’s security policy. Many things from the policy can map very well over to the implementation side of access control (acceptable time of day of certain data access, types of users allowed to see certain data or perform certain tasks, etc.). These types of mappings usually work the best with Role Based Access Control.

There are a plethora of accepted access control models in the information security realm. Many of these contain aspects that translate very well into the web application space, while others do not. A successful access control protection mechanism will likely combine aspects of each of the following models and should be applied not only to user management, but code and application integration of certain functions.

Discretionary Access Control

Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of information or any resource is able to change its permissions at his discretion (thus the name). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.

• Data Owners can transfer ownership of information to other users
• Data Owners can determine the type of access given to other users (read, write, copy, etc.)
• Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user’s access
• Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminant copying by users (“cutting and pasting” of information)
• Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
• Access to information is determined based on authorizations to access control lists based on user identifier and group membership.

Mandatory Access Control

Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.

• Only administrators, not data owners, make changes to a resource’s security label.
• All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
• All users can read from a lower classification than the one they are granted (A “secret” user can read an unclassified document).
• All users can write to a higher classification (A “secret” user can post information to a Top Secret resource).
• All users are given read/write access to objects only of the same classification (a “secret” user can only read/write to a secret document).
• Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user’s credentials (driven by policy).
• Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)

Role Based Access Control

In Role-Based Access Control (RBAC), access decisions are based on an individual’s roles and responsibilities within the organization or user base. The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as doctor, nurse, attendant, nurse, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.).

An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.

• Roles are assigned based on organizational structure with emphasis on the organizational security policy
• Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)
• Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
• Roles are granted permissions based on the principle of least privilege.
• Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
• Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
• Roles can be only be transferred or delegated using strict sign-offs and procedures.
• Roles are managed centrally by a security administrator or project leader.

Attribute Based Access Control

Attribute Based Access Control (ABAC) is an access control model wherein the access control decisions are made based on a set of characteristics, or attributes, associated with the requester, the environment, and/or the resource itself. Each attribute is a discrete, distinct field that a policy decision point can compare against a set of values to determine whether or not to allow or deny access. The attributes do not necessarily need to be related to each other, and in fact, the attributes that go into making a decision can come from disparate, unrelated sources. They can be as diverse as the date an employee was hired, to the projects on which the employee works, to the location where the employee is stationed, or some combination of the above. One should also note that an employee’s role in the organization can serve as one attribute that can be (and often is) used in making an access control decision.

A typical ABAC scenario involves a requester who attempts to access a system either directly or through an intermediary. The requester will have to directly or indirectly provide a set of attributes that will be used to determine whether the access will be allowed. Once the requester provides these attributes, they are checked against the permissible attributes and a decision will be made depending on the rules for access.

Policy-Based Access Control

Most organizations have some kind of policy and governance structure in place to ensure the successful execution of the organization’s mission, to mitigate risk, and to ensure accountability and compliance with relevant law and regulations. The internal security posture of most companies and organizations has traditionally been out of the purview of law and regulation, although banking, government-related bodies, and critical infrastructure are some notable examples of organizations where the government has exercised its authority to push for tighter security controls. With the institution of regulation and legislation in several industries, such as Gramm-Leach-Bliley (GLBA) for financial services, Health Insurance Port ability and Accountability Act (HIPAA) for healthcare, and Sarbanes-Oxley (SOX) for corporations, many organizations are discovering that they need to put into place tighter policies and uniform controls across the enterprise in order to st ay in compliance. They need to create and enforce policies that define who should have access to what resources, and under what circumstances. They also need to put in place mechanism s so that access can be easily audited because these Acts hold the organizations’ executives responsible for their subordinates’ actions. Policy-based Access Control (PBAC) is an emerging model that seeks to help enterprises address the need to implement concrete access controls based on abstract policy and governance requirements.

In general, PBAC can be said to be a harmonization and standardization of the ABAC model at an enterprise level in support of specific governance objectives. PBAC combines attributes from the resource, the environment, and the requester with information on the particular set of circum stances under which the access request is made, and uses rule sets that specify whether the access is allowed under organizational policy for those attributes under those circumstances.

Risk-Adaptive Access Control

Organizations are not static; they constantly evolve and respond to a variety of stimuli, which can include legal requirements, economic and financial realities, market challenges, a variety of risk factors, and leader ship styles. Their dynamic nature means that the policies that guide them must also be adaptable; this naturally extends to the organization’s security and access control requirements as well. The security threats that organizations face are also dynamic, so they must constantly assess the risk to their IT infrastructure and the associated data. Even the more advanced access control paradigms, such as ABAC and PBAC cannot adequately address the need for dynamism and changes in the risk levels. The Risk-Adaptive Access Control (RAdAC) model was devised to bring real-time, adaptable, risk-aware access control to the enterprise.

RAdAC represents a fundamental shift in the way access control is managed. It extends upon other earlier access control models by introducing environmental conditions and risk levels into the access control decision process, in addition to the concept of “operational need.” RAdAC goes beyond the traditional reliance on static attributes and policies. It combines information about a per son (or machine’s) trustworthiness, information about the corporate IT infrastructure, and environmental risk factors and uses all of this information to create an overall quantifiable risk metric. RAdAC also uses situational factors as input for the decision-making process. These situational inputs could include information on the current threat level an organization faces based on data gathered from other sources, such as CERTs or security vendors.

Defenses Against Access Control Attacks

• Implement role based access control to assign permissions to application users for vertical access control requirements
• Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
• Avoid assigning permissions on a per-user basis
• Perform consistent authorization checking routines on all application pages
• Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis
• Where possible restrict administrator access to machines located on the local area network (i.e. it’s best to avoid remote administrator access from public facing access points)
• Log all failed access authorization requests to a secure location for review by administrators
• Perform reviews of failed login attempts on a periodic basis
• Utilize the strengths and functionality provided by the SSO solution you chose
• Perform access control reviews with respect to the access control matrix of the user interface / data access interface
• Ensure that access control matrix adhere to segregation of duties – that the requestor cannot perform authorizations.

 

Go back to Tutorial