Solving Business Challenges with Access Control Strategies
The key to applying access controls to solving business challenges is in taking a systematic approach to designing a comprehensive strategy. As you consider each element of access control, you will begin to see how various strategies interrelate to form a multilayered security system.
NOTE
Remember, a subject is anything that acts upon another entity. An object is anything that is passively acted upon by a subject.
The first step in creating a comprehensive access control strategy is to define your subjects and objects.
The most common subjects are:
- Users—They are generally the individuals who need access to resources. In some cases, applications can also have user accounts. The most common example of this scenario is a web-server application that is typically run under the “nobody” user account.
- Applications—Applications often access the file system directly by reading or writing files, make database connections, and utilize the mail system on a server. These are all access control requests to be managed securely.
- Network devices—A proxy on one network will often request access to resources on another network on behalf of a user or application on its own network. The proxy is, in effect, making an access control request, and is, therefore, acting as a subject.
Your infrastructure may have other subjects. These are simply the most common types of subjects. Once you have defined all the subjects in your infrastructure, you can begin to categorize them into groups and roles.
Groups are useful because they allow you to generalize the access privileges needed by several subjects. They also allow you to create specialized combinations of privileges by adding a subject to two or more groups. To remove certain access privileges, you would simply remove the subject from one or more groups.
Roles also allow you to generalize and separate a subject’s function from its identity. For example, Bob Smith may hold the role of user on his workstation most of the time and the role of administrator only when he needs to install a new application. Rather than assigning administrative rights to Bob’s user account when he only needs those rights occasionally, he will have access to two separate role-based accounts.
Once you have defined your subjects, you will need to similarly define your objects, or the data and resources in your infrastructure. This list of objects should contain every significant asset as well as notes about the asset’s worth and value to the organization.
Employees with Access to Systems and Data
Even nonsensitive data should be stored under some level of access control. For example, the company newsletter is available to every employee but should not be available to the general public. As soon as you limit access to data or resources, you have an access control scenario. Some employees will have no need to access IT systems and data. The custodians and groundskeepers, for example, will probably not need access to the network or the data stored there. They may, however, need access to the automated time clock system or the maintenance schedules stored on the company Intranet. Whether certain employees require access to IT resources depends upon the individual organization and its business processes.
Who Needs Access to Which Resources?
When creating an access control strategy, the main question to ask is, “Who needs access to what?” If a user does not have a legitimate need to access data or resources, that user should not be granted access. If the user does need access at some point in the future, that user’s access privileges can be modified then. Do not be tempted to assign high levels of access to a user simply based upon his or her status within the organization. Chances are the executive vice president of accounting does not actually need administrative rights to the web server. Assigning those rights to that user would represent a significant vulnerability in the access control system because it is unlikely that the executive vice president of accounting has the technical knowledge and background to safely administer the web server.
Creating Groups and Roles
When deciding which users need access to resources, try to think in terms of roles or job functions rather than individuals. Individuals may leave the company at any time, and some other individuals will be found to take over their roles. As discussed above, an individual may hold several roles depending on the task at hand.
Groups and roles also simplify the task of administering permissions. Take the scenario of an employee who transfers from one department to another. Rather than auditing the employee’s permissions individually, the systems administrator simply needs to remove the employee from the old department’s group and add the employee to the new department’s group.
External Access to Systems and Data
Finally, determine whether any external subjects will have access to internal systems and data. An external subject is anyone who is outside the organization’s physical and network boundaries. Why would someone outside the organization need access to internal systems and data? The following is a list of common external subjects who have a legitimate need to access internal resources:
- Third-party vendors and application service providers (ASPs)
- External contractors
- Employees with remote access
Each of these subjects needs some of the same rights and access to resources as an internal employee, and like internals, each should be restricted to the lowest level of privilege needed to perform necessary tasks. Employees who work remotely are a special case here, because they are both internal and external. They are employees but access resources from outside the organization’s network and physical boundaries. The primary access control challenge with remote workers is that of creating a virtual private network (VPN) and ensuring that sensitive data are not compromised due to a lack of infrastructure security at the employee’s location, which could be the employee’s home, a coffee shop, or some other public place.
Once you have determined who should have access to resources in general, you can go further and consider which employees should have access to sensitive systems and data.
Employees with Access to Sensitive Systems and Data
At this point, you already have a comprehensive list of objects. Now you should go back over that list and note which of those objects should be considered sensitive. Consider that a variety of factors may make a given system or data set sensitive:
- Regulatory compliance
- Privacy, either for customers or employees
- Business continuity
- Competitive advantage
Any system or data resource that, if it were lost, stolen, damaged, altered, or publicly divulged, would cause a significant negative impact to the organization should be considered sensitive.
Administrative Strategies
Once you know what subjects to account for and which objects to protect with access controls, you can devise administrative strategies to support access controls. There are two issues to consider when defining administrative access control strategies around new and expiring accounts:
- How will new accounts be created and new access levels be granted?
- How will accounts be removed and access levels be lowered?
New employees and employees who take on additional job functions may need new accounts. Employees who are given temporary responsibilities may need higher access levels for the duration of their increased responsibility.
Normally, a manager fills out an account request form, which explains what access is needed and what business need this access will fill. The form should also specify whether the new account or heightened access is temporary (and when it will expire) or permanent. The manager submits the form to the security team, which reviews the request and either approves or denies it. Once the request is approved, it is forwarded to a member of the accounts team to actually create the account or modify the user’s access level.
Access levels that were granted temporarily should be lowered as soon as the need for heightened access is no longer present, and accounts for employees who leave the company should be removed immediately.
The workflow to remove or downgrade accounts is similar to that described for creating accounts. A manager fills out an account request form and submits it to the security team, who forwards it to the accounts team. When an employee is terminated or leaves the company, his or her accounts should be locked immediately.
Keep in mind that the goal of these administrative strategies is to minimize the human error inherent in any access control strategy.
Technical Strategies
The technical aspect of an access control strategy may include some or all of the following techniques:
- Discretionary access control (DAC)—DAC is an access control system where rights are assigned by the owner of the resource in question.
- Mandatory access control (MAC)—MAC is an access control system where rights are assigned by a central authority.
- Role-based access control (RBAC)—In an RBAC system, rights are assigned based on a user’s role rather than his or her identity.
- Automated account review—All accounts should be reviewed periodically to ensure that they still need the access to resources and privileges they currently hold. As job functions change and evolve, so do their access needs. An automated system cannot replace human knowledge of business processes and the resources those processes require, but it can determine which access rights have not been used recently. Unused rights are a vulnerability in any system.
- Automated expiration of temporary access—When accounts are created for temporary employees or access levels are temporarily raised, those accounts should be downgraded or removed promptly. Automated expirations are an easy way to ensure that a temporary account is not forgotten and left sitting around on the system, just waiting to be exploited.
NOTE
The terms “separation of duties” and “segregation of duties” are synonymous with “separation of privileges.”
Every organization has unique business challenges, so there is no one-size-fits-all technical access control strategy. Use the methods and techniques that make sense for your situation.
Separation of Privileges
The principle of separation of privileges is designed to ensure that if an attacker compromises one account, he or she will be denied access to highly sensitive information because it is protected by two separate conditions. Both conditions must be met for access to be granted. If one condition is met but not the other, access is denied. Separation of privileges is a strategy that is used extensively in many areas:
- Accounting department employees usually do not have the ability to create new vendors and cut checks. This policy exists to prevent a single employee from creating a fake vendor, then creating checks made out to the fake vendor. It will take at least two employees working in tandem to embezzle this way. The two conditions that must be met to pay a new vendor are executed by two separate employees: one to create a vendor and one to cut checks.
- Safe deposit boxes usually have two keys that are kept physically separate. Both keys must be present to open the box.
- Missile launch procedures require two military officers of sufficient rank to give the correct command and turn launch keys in order to arm a missile launch system. A single officer is not sufficient, as this would place too much power in the hands of a single individual.
In access control systems, separation of privileges has two aspects: compartmentalization and dual conditions. Compartmentalization is the practice of keeping sensitive functions separate from nonsensitive ones. In practice, this is implemented by isolating programs running under one user account from other users. Dual conditions are most often implemented through two-stage authentication methods, which require both a biometric scan or token device and a password to grant access.
Least Privilege
The principle of least privilege is based on the idea that a subject—whether a user, application, or other entity—should be given the minimum level of rights necessary to perform its legitimate functions. The purpose of this principle is that if an account is compromised, an attacker will have a minimal set of privileges and will not be able to use the compromised account to do real damage to the entire system.
NOTE
On Windows servers, the administrator account is called Administrator. On UNIX and Linux servers, the administrator account is called root.
In practice, the principle of least privilege is usually implemented as least user access (LUA), which requires that users commonly log onto workstations under limited user accounts. Administrative accounts should be reserved for administrators and then used only when performing administrative tasks.
Risks Associated with Users Having Administrative Rights
On a server, having an administrator logged into a privileged account can create an opportunity for an attacker to hijack the administrative session.
If an administrator regularly logs into the server using the administrative account to perform routine tasks, the window of opportunity is larger than if that account is activated only for specific tasks and promptly logged off.
Workstations are not usually connected directly to the Internet the way a server is, so the risk is much lower that an attacker will attempt to hijack the administrator account. On a workstation, the major risks to allowing users to log onto the administrator account for routine tasks are malware and misconfigurations.
Malware, such as viruses, Trojan horses, and spyware, usually require administrative privileges to install them, just as any other application does. If a user is logged in as administrator on his or her workstation, the chances of infection by any given piece of malware are greater.
The risk of misconfigurations is based on the fact that many users are not experts in computer maintenance and configuration. If users without sufficient knowledge attempt to change their firewall settings because they read a blog post or heard someone talking about the latest virus, they are likely to do more harm than good.
Common Roles
There are three common roles on any system, either workstation or server: administrator, user, and guest. Many systems have other customized roles as well, but the ones discussed here are the ones you will find on any system.
Administrator. The administrator, or root user, has the ability to perform most tasks on a system. At a minimum, the administrator can:
- Create user accounts and assign privileges
- Install software and devices
- Perform low-level system maintenance tasks, such as registry maintenance, start and stop services, installation of drivers, and management of log files
NOTE
Some user accounts are limited to a subset of the applications installed on a computer. It does not make sense to enable a user account to run the user-creation application because that is an administrative task.
This is by no means an exhaustive list of the tasks an administrator can perform. These are simply the primary categories of tasks for an administrator.
User. There will usually be more than one user account on any given system. Some user accounts are tied to individuals, while others are used by applications. In general, a user account can:
- View the status of services, drivers, processes, and so on
- Run programs
- View log files
- Make limited changes to registry entries
- Add, modify, and delete data and files owned by that user
This is the most common type of account and may be further defined into specific types of users with more granular privileges.
Guest. Some systems will have a guest or anonymous account. Others will have this account disabled or removed. The guest account is a severely limited version of a user account that is enabled to run only specified programs and view specific data. On a system without a clear need for a guest account, it should be disabled or removed. An attacker could potentially use the guest account to attack the more privileged accounts on the system.
WARNING
In practice, it is rare—and a bad idea—for an authentication system to query a database with a plaintext password. More likely, the system will query the database with the results of a password hash equation.
Need to Know
Users should be given access to the minimum amount and sensitivity levels of data and resources necessary to perform essential functions. If a user does not need to know the Social Security number of a client in order to do his or her job, he or she should not be given access to that information.
FYI
When users enter their usernames in an authentication system, the system sends a request to the database: “Does a record with the supplied username exist?” If the record exists, the database returns the Boolean result TRUE. If the record does not exist, the database returns FALSE. Likewise, when users enter their passwords, the system sends another request to the database: “Does the password in the database record keyed on the supplied username match the user-supplied password?” Again, the database will return a Boolean result, either TRUE or FALSE. The authentication system uses secure hashing technology to avoid sending the password across the network in cleartext. This prevents an eavesdropper from observing the password. Additionally, the authentication database contains only hashed passwords, not the corresponding plaintext passwords that would be needed to access the user’s account. A hash of the password is not the password, and it is not the password encrypted. It allows the verification of a password without possession of the password itself.
There are three basic levels of need for information:
- Existence of information—At this level, the subject only needs to know whether or not a certain piece of information exists or if it matches a predefined pattern. Username and password authentication systems are a good example of this level of need.
- View partial information—This is the most common level of need. Most users will need to know some sensitive information, but not all. For example, an office manager preparing a letter to be sent to a firm’s entire client list will need to know the clients’ directory information—names and addresses—but will not need those clients’ Social Security or account numbers. Another employee in the accounting department may need clients’ account numbers but not their directory information.
- View full record—The need for this level of access is rare and should be granted only to those who cannot perform their job functions with partial access to information.
In all cases, the need to know principle dictates that users be granted access only to the information they actually need, and no more.
Input/Output Controls
Input and output controls dictate a user’s ability to interact with devices and data. The guiding principle for input and output controls is the same as for everything else: Users should have the least access possible to perform their job functions.
Input Controls
Input controls dictate how users can interact with data and devices that introduce new data into a system. For example, input controls might dictate whether a user is entitled to write new data files or modify existing rows in a database. Input controls are also concerned with physical security such as automatically locking server rooms and securing unused network jacks on servers. Left unsecured, an unused network jack could be used to attach an unauthorized device to the network via a server.
Output Controls
Output controls are similar to input controls, except that they are primarily concerned with the output of data, either to a screen, printer, or another device. A user’s ability to read a data file would be the focus of an output control rule, as would a system that requires a personal identification number (PIN) to retrieve print jobs. This type of system is usually put in place to prevent unattended output on a shared printer.