Introduction to Access Control Security Models
Security, or more specifically Cybersecurity, is the core foundation of how our current digital world operates, from the phones we hold in our hands all the way to how food arrives in the supermarkets. Without proper cybersecurity measures, supply chains can be severely disrupted, as highlighted with the recent Colonial Oil Pipeline hack. Even worse, without steady supplies, cities may run out of food within a matter of days. This crisis was originally mentioned by Alfred Henry Lewis in 1906, “There are only nine meals between mankind and anarchy.” This worst case scenario cannot be stressed enough and has even caught the attention of the World Economic Forum in recent articles.
World Economic Forum 2020 states: “We should prepare for a COVID-like global cyber pandemic that will spread faster and further than a biological virus, with an equal or greater economic impact.”
To prevent or at the very least delay this worst case scenario, robust security measures must be in place to deny unauthorised accesses; and, at the centre of all applications is an access control system. Because it is so important and mission critical, it was one of the OWASP Top 10 Critical Security Concerns in 2017. Furthermore, it is also the very first domain of knowledge to be introduced as part of the SSCP Certification.
Whilst there are a variety of access control systems, this post will be focusing on the 3 main types of Access Control security models that systems are designed around. They will each be considered in terms of flexibility to a wide number of use cases, as well how easy they are able to be audited and maintained.
Discretionary Access Control (DAC)
The first security model, known as Discretionary Access Control, is most commonly seen when discussing Unix file permissions. The user that owns a file is able to decide all of the file’s read, write and execute permissions. In other words, access to the resource (in this case the file), is to the owner’s discretion. An example of how this looks is shown in Image1 below.
The benefits of this access control model can be seen to be the amount of flexibility given to the owner to individually manage each resource. In regards to the above Unix file permissions, if the owner requires, they can still grant a specific user access permissions even though they are outside the group using ACL (Access Control List) Permissions. Nevertheless, the central idea here is that each single resource is managed by an owner individually and not a central administrator. This, in effect means more responsibility for resource owner and less burden for administrator.
Obvious downsides to this amount of maximum flexibility would be the long term impacts on the auditing and maintenance processes. Every time auditing is performed on a user’s permissions, all resources must be checked to determine the user’s overall permissions in the system. While this is fine for a small set of resources, this model won’t scale. Similar problems also occur during maintenance, when permissions need to be given and/or removed from a large amount of resources. Security risk may also increase when resource owners aren’t aware of the impacts of granting access to the wrong users.
What if there’s a way to remove some of the flexibility and risk, to allow permissions or access to resources to be managed in groups? This is what Role Based Access Controls aims to address.
Role Based Access Controls (RBAC)
For the RBAC security model, administrators and/or supervisors will be able to group a common set of permissions and resource restrictions together into a specific role to apply to users. These roles can be quickly given to and removed from users depending on current task requirements, without the need to check all individual resources.
A good example of how RBAC can be used, is that developers shouldn’t access resources specific to the finance department and vice versa. Therefore, a good way to enforce this is to specify a role for all developers and restrict developer roles to only have access to developer resources.
To see a real example of this is, we can refer to Github’s documentation, whereby different roles have access to different resources. As can be seen below, the Members role don’t have permissions to view and edit billing information.
The other benefit mentioned before is the ability for RBAC systems to be able to group permissions and resources access into a role. To see this in action, refer to Microsoft’s Azure RBAC.
Azure RBAC states: A role definition is a collection of permissions. It’s typically just called a role. A role definition lists the operations that can be performed, such as read, write, and delete. Roles can be high-level, like owner, or specific, like virtual machine reader.
Therefore, as long as roles are established correctly, the flexibility from DAC is traded off to allow central administrators be able to manage more resources effectively. During maintenance, the process should be much quicker as well, since administrators can simply add or remove roles from users. Furthermore, auditing can be accomplished by checking role definitions instead of each individual resources.
With such significant advantages of the RBAC model, it can be seen why it is commonly used in many places. Hence, the only real disadvantages are that firstly for RBAC systems like DAC, supervisors may accidentally grant the incorrect role to users. Secondly, administrators need to be careful that new roles aren’t constantly created to handle new or special situations. For both these disadvantages, the risk can be managed by enough due diligence and periodic auditing.
Nevertheless, even RBAC might not be enough for sensitive military applications which is where security is the top priority and Mandatory Access Control systems are typically used.
Mandatory Access Control (MAC)
Mandatory Access Control, is a security model that uses a central authority such as the administrator or the system to determine the access permissions for a user. There will be no resource owner or roles to determine permissions and the the rules used to determine access are usually based off a security policy or existing regulations.
A commonly seen security policy would be the security classification levels seen in movies i.e. Confidential, Top-Secret, etc. In those situations a Top-Secret document cannot be seen by those without sufficient security clearance. This same type of policy can also be applied to computer systems, where resources can be classified into different security levels. The Bell-LaPadula security model is a good example of this.
Of course, the advantages and disadvantages to using MAC make sense in the context of military applications. All responsibility lies with the central authority, and auditing and maintenance will revolve around the security policy and the central authority that enforces the policy. In essence MAC operates in a completely opposite method to DAC security models.
Conclusions
In conclusions, while there are many more security models that exist such as Attribute or Context based access control models, the 3 presented in this post represent the most basic models that are most commonly referenced when discussing about access control.
The choice of which security model to utilise will depend on the situation or applications requirements. For situations that need the most amount of flexibility, consider using DAC, or if a generalised solution is required RBAC is generally a good choice that’s used in many places.
Whichever model is chosen, hopefully this post has given some useful information needed to make a decision. Now all that’s left is to start building your next secure system.
