Comparisons of the Access Control Models (Continued)

Role-based access control allows access to be based on the job title. Role-based access control largely eliminates discretion when providing access to objects. Here, we may have somebody (for example, human resources) specifying what privileges should be in place for individuals, for individual types of role or function. So essentially, this assigns permissions to particular roles, and then users are added to that role. For example, we may have an accountant, and they would be added as a user to the accountant role. And they would then inherit all of the resources related to that accountant role. So roles are slightly different here from groups, in that a user may belong to multiple groups.

Under strict role-based access control, a user may only be assigned to a single role within an organization. Typically what you see within organizations is that the roles are fluidly assigned to groups and that people are able to belong to multiple security groups. So it’s a slightly sort of varied implementation day-to-day. Additionally, there’s no way to provide individual users additional permissions in a strict role-based access model above those provided within their role. And again, this is not what we see day to day in most organizations. What we will see is that the day-to-day permissions are managed through a mixture of the role and also individual privileges. So we have a variety of different approaches.

A role-based access control started, in terms of being a popular approach, in 1992. It’s, again, a very, very mature system in terms of its presence. Can have some issues, and the issues with role-based access control can relate to our management of change. So if we have a user that moves through different roles within an organization, making sure that their role assignments remain current and up to date is critical. And where we see people moving to a more fluid approach – where it’s not a strict role-based access control model, where they start to assign individual privileges to the user and a number of roles – this is where we start to see problems.

A good example of that is the kind of privilege creep that we saw with Edward Snowden, where he moved as a contractor in the US government between different roles and gained different levels of access, depending on the different functions he performed. So, helpfully, we can restrict each person to a single role, and we can try to avoid assigning user-level permissions. This gives us a much stronger access control model. So role-based access control is technically non-discretionary. Here, the access is confirmed by role rather than by the asset owner. It’s defined based on your individual organization roles. So to look at implementing this, we need to understand, within each organization, what roles we have.

This can work well where we have large numbers of identical roles that exist within an organization. If we have 200 service desk operatives, creating 200 individual accounts with tailored permissions is much more onerous than defining 200 users who are then added to the single role. And this gives us a much better opportunity to spend our time defining the role appropriately, and then adding users into that role. So this is far and away the most common system we see used within enterprises. This is because we have high numbers of people matched against each role. It can become complex and onerous where we have high numbers of roles within each organization.

As we move towards the end of the different type of control models, we’re going to look very briefly then at rule-based access control. Under rule-based access control, here we have access that is allowed or denied to individual resources based on rules. And again, these rules, as with mandatory access control, are defined by the system administrator. However, as with discretionary access control, individual properties can be stored within an access control list. And examples of rule-based access control include situations such as permitting access to an account based on geography or based on a particular timing. So we may say that front line customer service operatives are

allowed access to a system between the hours of 8:00

AM and 6:00 PM, but not beyond. This would be an example of rule-based access control. Often, we will see rule-based access control used as part of an approach. So we may see rule-based access control used to control access to aour VPN, to our perimeter, whereby particular types of access are allowed only at particular points of the working day

to prevent people accessing the system maybe at 3:00 AM or 4:00 AM.

We also have a newer based model, attribute-based access control. And again, this links very strongly to the XACML standard that we’ll look at later in the course. With attribute-based access control, we reference the NIST document, special publication 800-162. This was released in 2014. So this defines access control where access rights can be granted to users through sets of policies. And these policies can be combined together to provide a complete set of permissions. So policies can use things like attributes, user attributes, resource attributes. And we’re starting to think about XACML in terms of providing support for logic statements, things like if statements or then statements. If somebody is a member of this group, then they’re allowed access to that.

This is referenced as being a next-generation authorization model, in part because it tends to be more dynamic, and it tends to be context aware in the way it’s implemented. So traditionally, with access control models, they’re applied at login and not refreshed until you log out and log back in. XACML and attribute-based access models can have a much more dynamic approach, where attributes of a user object or of an asset are checked on each access. So this starts to introduce very simple programmatic logic, Boolean logic, that can evaluate different criteria based on subject, object, on different permissions.

So, yeah, with XACML, the key standards we talk about are the use of XML type markup languages and Alpha. And again, we’ll come back to XACML later in the course.