Are you authorized to read this post?
Jane Porter
Building on our previous blog around authentication, we will now discuss the other side of the coin; and one that is often confused with authentication—authorization. Having proved that we are allowed to access the system, we now need to be allowed to access the various resources of the system. This is a more granular approach and allows the system owner to determine which users can access which resources.
As we have said, authorization within IoT environments is a granular approach based on the user and the level and amount of information they should have access to. The first decision to be made about a given resource is whether you want to centrally control access or devolve the responsibility to the resource owner. Both are valid approaches and can be used in conjunction with each other. The important thing is to ensure that you have a coherent approach that is easily understood by both the users and the resource owners. Otherwise, you can end up with a situation where users cannot access the necessary resources, or perhaps more troubling, people are given access to resources that they should not see.
Let’s look at some of the initial approaches that can be applied to either system-wide or resource-specific authorization.
- Role—This is where a user is provided default access to resources in the system based on a given role. The most common, and well understood, is that of the Administrator.
- Context—Taking our example of the Administrator, we can further increase or decrease the access for the Administrator role based on another factor. For instance, not allowing Administrator access from an untrusted device.
- Attribute—To extend our example, we can use attributes to provide further granularity for authorization to the resource. In this example, we want to limit access based on time and location, so now our Administrator, using a trusted device, can only access the resource from the local location between 09:00 and 17:00.
Authorization, therefore, is based on a variety of factors, such as the user’s role or permissions, the request’s context, or the resource’s attributes. The process often involves checking against a set of rules or policies to determine whether the user or system is authorized to access the resource or perform the action.
There are several types of authorization that are commonly used in cybersecurity applications.
1. Discretionary Access Control (DAC)
DAC is a rule-based access control system in which the owner of a resource has the ability to grant or revoke access to that resource for other users. The owner is typically someone who has been granted ownership of the resource through a process such as file creation or explicit assignment of ownership.
Some examples of systems that use DAC include:
- File systems on personal computers and servers: When a user creates a file, they are typically made the owner of that file and can grant or revoke access for other users on the system. Users can set read, write, and execute permissions on files and directories, allowing or denying access to them.
- Database management systems: Owners of database objects (such as tables or records) can grant or revoke access to other users, allowing them to read or modify the data in the object.
- Object-oriented programming languages: Some object-oriented programming languages, such as Java, include support for DAC in the form of access modifiers such as private and protected. These modifiers allow the developer to control which parts of a class can be accessed by other classes.
- Cloud storage services: Users who create a file or a folder in a cloud storage service have the control to share the files with other users, giving them access to read or write in the file.
2. Mandatory Access Control (MAC)
MAC is yet another rule-based access control system in which access to resources is based on security labels and clearance levels that are assigned to both objects and subjects (e.g., users, programs). Access to resources is determined by a central authority, usually in the form of a security administrator, who defines and enforces the security policy.
Some examples of systems that use MAC include:
- Secure communications systems: Some secure communications systems such as military or government-grade encryption systems use MAC to control access to the encrypted information. Only authorized users with the appropriate clearance level can access and decrypt the information.
- Industrial control systems: Industrial control systems, such as those used in power plants or oil refineries, use MAC to prevent unauthorized access to critical systems and infrastructure. Access is restricted to authorized individuals and groups and is granted or denied based on their clearance level and role within the organization.
3. Access Control Lists (ACLs)
An ACL is a list of permissions that is associated with a resource. Each entry in the list specifies a user or group and the permissions that are associated with that user or group. When a user requests access to a resource, the system checks the ACL to see if the user or the user’s group is listed and if the requested permission is granted.
4. Role-Based Access Control (RBAC)
This type of authorization is based on a user’s role within an organization. Users are assigned to specific roles, and each role is associated with a set of permissions. When a user requests access to a resource, the system checks the user’s role and grants or denies access based on the permissions associated with that role.
5. Attribute-Based Access Control (ABAC)
This type of authorization is based on the attributes of both the user and the resource. Users are associated with a set of attributes, and resources are associated with a set of attributes. When a user requests access to a resource, the system evaluates a set of rules that use the attributes of the user and resource to determine whether access should be granted or denied.
In Summary
When choosing an authorization method, it’s important to consider factors such as the size of the organization, the complexity of the environment, the types of resources and actions that need to be protected, and the threat model of the system. For example, a large organization with many different types of resources and a complex threat model might benefit from ABAC, while a small organization with relatively simple needs might find RBAC to be sufficient. Additionally, it is important to consider the scalability, flexibility, and integration with other security controls of the solution. Authentication and authorization methods should also be considered together when designing IoT architecture.
In our next post, we will explore the necessary considerations for incorporating application security both in the cloud and at the edge for IoT deployments. This is an area where it is important to consider the capabilities of your platform to deploy across the edge to cloud continuum.