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.