What Is Access Control?

What Is Access Control?

Without thinking of it in such formal terms, access control is something we’re all familiar with in everyday life. Most of us don’t leave home without locking our doors, we can’t buy liquor without proving we’re of legal age, and we can’t open our safety deposit box at a bank without presenting proper ID and a key.

These are all examples of access control, but how exactly do we define it? Regardless of context, industry, or organization, access control is any measure or mechanism designed to restrict or grant access to resources—whatever they might be—to ensure they’re not stolen, destroyed, exposed, altered, or used inappropriately by unauthorized parties. Access control is fundamental to any type of security effort, whether the goal is to protect military secrets or the script for the final episode of a hit TV series.

In the context of information security, access control is about protecting an organization’s data. By extension, that also means protecting the facilities, infrastructure, networks, systems, and apps that transact in and store that data. To accomplish this, organizations implement physical, administrative, and technical security controls, which we’ll look at in more detail shortly, as well as identity and access management solutions. For now, let’s take a high-level look at the essential concepts and components of access control, beginning with why it matters.

Why Is Access Control Critical?

At the heart of information security is the requirement to provide confidentiality, integrity, and availability. Access control is just one of many measures security teams use to uphold these foundational security principles. Without access control, how can an organization ensure that only the appropriate people see and use its sensitive data (confidentiality), that data is complete, intact, and unchanged by unauthorized users (integrity), and that authorized users have access to data whenever they need it (availability)? The answer is, it can’t.

Who and What Does Access Control Apply To?

Anytime we talk about access control, we’re talking about the relationship between subjects and objects and the interaction that’s allowed (or not) between them. Subjects are active entities that request access to or act upon (interact with) objects. Users are the most obvious example, but systems, programs, processes, and services are subjects too. Actions a subject might take include reading, writing, creating, or deleting a file; retrieving data; or executing a program.

Objects are passive entities that contain or receive information or provide functionality to the subjects requesting access to them. Examples include systems, files, services, directories, databases, and devices (like printers).

In completely nontechnical terms, rules—defined and enforced using various mechanisms—determine the relationship and permitted interaction between subjects and objects. Table 1 provides an example of one of the simplest—an access control list (ACL) that indicates each subject’s permissions with respect to various objects.
 

How Access Control Works

Now that we know more about subjects and objects, let’s look at how the access control process works. It’s based on a decades-old framework known as authentication, authorization, and accounting, or AAA (pronounced “triple A”).¹ Although AAA is not cited frequently today, it’s good to be familiar with the term. The AAA process includes the following steps:

1. A subject seeking access to a resource presents a claim of identity.
2. The authentication process attempts to verify the subject’s identity.
3. The subject is either authorized or denied access to the requested resource based on predetermined rights.
4. All actions of the authenticated and authorized subject are tracked for accounting purposes.

This process goes on behind the scenes whenever a user logs into a password-protected device, network, app, or website to access a resource. Let’s look at each step in a bit more detail.

What Is Identity?

Presenting a claim of identity is often lumped together with authentication. We call it out separately because the two steps are distinct—identity is actually a prerequisite to authentication.

To make any kind of request, every entity requires an identity—a set of attributes that uniquely identifies it, similar to the way a driver’s license uniquely identifies an individual by name, address, birth date, height, weight, and eye color. When you present your driver’s license, you’re claiming that you’re the person it represents. Similarly, when you enter your username to log into a corporate network or a website, that’s your claim of identity, but it’s an unproven claim at that point.

A crucial part of access control is enrollment. Subjects (entities) are enrolled into an access control system when administrators of this service register their details and create a new identity on their behalf. When subjects later attempt to gain access to an object, they are attempting to assert their identity, not themselves as an entity.

Since identities create a layer of abstraction from the entity, it is possible for subjects to possess multiple identities. In our everyday lives we hold not only a driver’s license but also national identity cards, bank cards, keys, and many other forms of identification.

Enrollment is a crucial part of the access control process, since a failure to properly identify a subject at this stage may allow malicious or unintentional access to objects later.

What Is Authentication?

Authentication (abbreviated AuthN) is the process of verifying the identity of a subject seeking to access a resource. To prove a claim of identity, the subject must present some corresponding information, provided to it during enrollment, called an authentication factor. The three types of authentication factors include:

• Something you know, such as a password, PIN, or answers to security questions.
• Something you have, such as an access card, a key, or a token that generates a number or code you enter.
• Something you are, a biometric factor, such as a fingerprint, iris scan, or voice print.

These examples are fairly obvious when we’re talking about human subjects. For a nonhuman subject, such as a service, the device running the service might be required to present a valid digital certificate for authentication. Similarly, an application requesting data through an application programming interface (API) might need to provide an API key for authentication.

A subject’s identity is considered proven (authenticated) when the required factors correspond with what’s stored in the system.
 

What Is Authorization?

Once a subject is authenticated, authorization (abbreviated as AuthZ) is the process of determining whether the given identity (for example, a user) is allowed to access the requested resource and, if so, what actions they are allowed to take. The goal is to give authenticated users access to the resources (such as networks, applications, or data) they need to do their jobs and nothing more (also known as the principle of least privilege) and deny all other access (we’ll see how shortly). Sales managers have legitimate authorization to view sales projections of their direct reports, but their job function does not authorize them to alter product source code, read email communications between board members, or access the payroll system to give themselves a raise.

Note that authentication and authorization are often confused or used incorrectly as synonyms, but they are entirely separate functions. In theory, a subject could be authenticated and yet be authorized to access nothing. Conversely, an administrator who is authorized to access anything would be denied access if they cannot be successfully authenticated.

What Is Accounting?

Accounting (sometimes called accountability or auditing) refers to tracking a subject’s actions. That means logging and monitoring everything that happens with that subject while authenticated into a network, system, or app. Accounting also tracks unauthenticated attempts to access resources, which is equally important as it indicates possible malicious activity.

Accounting is sometimes skimmed over in discussions of identity, authentication, and authorization, but it’s important to understand its significance and relationship to these three. Accountability is essential for detecting unauthorized actions. It would be impossible to hold a subject accountable for unauthorized access or actions without first knowing (identifying) who or what performed those actions.

Access Control Models

How an organization determines who should have access to resources and what actions they’re allowed to take depends in part on the access control model it chooses to follow. Of the many available models, one isn’t better than another; rather, each addresses a different security challenge and has its pros and cons. An organization chooses a model (or combination of models) based on its unique business and regulatory requirements as well as which CIA triad objectives it deems most important to its business. Here are four of the most common models, with role-based being the most often used commercially:

• Mandatory access control (MAC) requires all objects to have labels (such as top-secret, secret, confidential) and all subjects to have clearance levels. As an “implicit deny” access model (meaning that access is denied by default unless explicitly granted), MAC grants a subject access to a resource only if its clearance level is equal to or greater than the object’s label. (Sometimes need to know, another important security principle, is an additional requirement in MAC systems.)
• Because MAC is centrally managed, highly granular, and cannot be overridden by users, it is considered the strongest access control model, although more difficult to implement and manage. It is often used in high-security environments like military and government organizations because of its emphasis on ensuring confidentiality.
• Discretionary access control (DAC) allows the resource owner to decide which subjects can have access to specific objects. Individual users decide who has access to files they own and what actions authorized subjects can take. This model—the default that Windows, macOS, and many UNIX file systems use—provides great flexibility but comes with potential security issues. A user could easily violate confidentially by mistakenly sending a confidential company file to a public email distribution list. A seemingly innocent app a user downloads could be infected with malware, putting their own system, other systems, and potentially the entire network at risk.
• Role-based access control (RBAC) determines access based on a subject’s job function or role (for instance, payroll specialist, HR director, or marketing manager) or possibly by department (Payroll, HR, or Marketing). A subject can be assigned to multiple groups (such as All Employees and Marketing) and privileges are assigned to each group rather than to subjects individually. This makes RBAC easier to manage and administer than other models as long as the number of distinct roles remains manageable.
• Attribute-based access control (ABAC) is the most granular model, granting access based on virtually any aspect of subjects, objects, or actions, as well as context. For example, an HR director might be restricted to reading confidential employee records only during regular business hours Monday through Friday using a company-issued laptop that’s directly connected to the corporate network, never remotely. While this model provides more fine-grained control than others, it can be challenging to manage given the potential to create too many complex or contradictory policies.

Other models include:

• Brewer and Nash (also known as an ethical wall) is a commercial, context-oriented model designed to prevent exchange or leakage of information that could lead to conflicts of interest.
• Clark-Wilson, an integrity model designed to protect data from unauthorized changes.
• Bell-LaPadula, commonly known as the “no read up, no write down” model, emphasizes confidentiality.
• Biba, an integrity-focused model characterized by its “no write up, no read down” requirement.

Note that all of these are models only. They’re designed to help organizations determine their approach to access control; none addresses implementation.

How Do Organizations Implement Access Control?

At the most basic level, access control mechanisms are built into the core functionality of operating systems. But that’s just the beginning. At the enterprise level, security professionals must manage physical-, network-, system-, and application-level access by implementing a combination of administrative, physical, and technical security controls.

An example of an administrative control is an organization’s written access control policy that, at a minimum, spells out the organization’s stance regarding physical access, remote access, password requirements, administrator and privileged accounts, logging and monitoring, auditing, and adherence (enforcement) policies. Examples of controls for managing physical access include gates, locks, keypads, and biometric readers. Technical access controls include any software-based mechanism for controlling access, such as passwords, encryption, ACLs, firewalls, intrusion prevention systems (IPSs), and others.

Identity and access management (IAM) solutions are also a technical control. They are comprehensive, centralized solutions that help organizations automate and manage numerous identity- and access-related tasks, such as adding (enrolling), modifying, and disabling user accounts; managing passwords; authenticating users; assigning permissions and authorizing users; and providing logging, monitoring, reporting, and auditing capabilities. IAM solutions may also support single sign-on, enabling users to securely log in once and have access to multiple systems, applications, and other resources within a specific domain. They may also support federated identity, which essentially provides the same type of capabilities but across separate domains. Federated identity works by authenticating a user to an application based on a trusted third-party’s identity store (such as Google’s or Facebook’s).

The Challenges of Managing Access Control in the Cloud Era

As a critical function of IT security, access control has never been a trivial undertaking, even in simpler times when most applications ran on premises within an organization’s protected perimeter. Authentication and authorization functions were often custom-written and built into the applications themselves. As organizations ventured outside of their protected perimeters and began to embrace Software as a Service (SaaS) apps in the early 2000s, new access control challenges emerged. Suddenly there were more user credentials “out there” than ever before—outside of IT’s control—and, not surprisingly, access breaches increased as a result.

Third-party IAM¹ solutions sprang up, first as on-premises solutions and then as SaaS apps, yet some fundamental challenges remained. Vendors used several different mechanisms for handling authorization and authentication and there were no implementation standards, so integration across vendors’ solutions was nearly impossible. The growing demand for simplification, integration, and especially federated identity services gave way to the evolution of open standards as well as richer solution offerings.

Today’s computing environment is substantially different, with organizations embracing the cloud and moving entire workloads to private, public, hybrid, and multi-clouds. This has spawned new business, operating, and application models—containers, microservices, cloud-native apps, and serverless computing. Just as apps are no longer contained within a protected perimeter, neither are users. Multitudes of employees, business partners, consultants, contractors, interns, and temporary staff are now working from home, all using different devices (often with questionable security postures) and all needing remote access (often across unsecured networks) to corporate, third-party, and widely dispersed cloud-based resources. It’s the most complex and challenging access control environment yet.

With the great cloud migration here to stay, the challenge for today’s organizations is to choose IAM solutions that can bridge the gaps that exist across boundaries, disparate solutions and mechanisms, as well as multiple cloud providers, who each have their own Identity as a Service (IDaaS) offerings now. Does the solution an organization is considering speak to all of its applications, including all of its SaaS and legacy applications? Does it support modern open standards and protocols, such as Security Assertions Markup Language (SAML), OAuth, and OpenID Connect (OIDC) as well as traditional protocols like Kerberos, NTLM, RADIUS, and others? Does it securely authenticate APIs? Can the solution integrate multiple identity stores? Conversely, does it give organizations the option of not replicating their identity stores with IDaaS and cloud-based IAM offerings? Does it easily provide timely, relevant data for monitoring and auditing purposes?

Access Control Best Practices

As organizations settle into cloud computing, access control is no less critical than it has always been. Regardless of where or how access control is implemented, the following best practices apply. This list is by no means exhaustive but could be considered a minimum starting point.

• Understand the different access control models and which one best suits your business.
• Do the work to define comprehensive access control policies tailored to your organization’s unique needs.
• Create a strong password policy (such as length and character requirements, lockout and reset policies, and rotation frequency) that discourages users from circumventing the rules.
• Use and enforce the principles of least privilege, need to know, and separation of duties, where applicable.
• Enable MFA for all users and for all applications that support it.
• Limit the total number of administrator accounts and don’t create or use shared accounts for administrators.
• Don’t allow administrators to use privileged accounts for everyday (non-admin-related) work.
• Perform proper monitoring and auditing; accountability is impossible without it, and most compliance frameworks require it.
• Review all user privileges annually and whenever employees change jobs. Purge old accounts. (Many insider breaches occur due to former employee accounts not being immediately disabled as part of the exit process.)
• Continually train users in security awareness (in general) and specifically in the latest social engineering tactics attackers use to steal credentials. This is one of the most effective means of thwarting access control attacks and possibly the most overlooked (or poorly implemented).

Conclusion

The topic of access control is deep and wide enough to fill an entire book. If you’re starting from ground zero, it’s essential to understand the general concepts and fundamental principles upon which access control is based before exploring it in more technical depth. An overarching goal of all security programs is to ensure the confidentiality, integrity, and availability of its resources to reduce risk to the organization’s assets, operation, reputation, revenue, and even its viability. Access control is a critical component of information security that gives organizations the ability to do exactly that.