Types of Permissions: Privilege Granularity

One of the things that can help us with this is by having a very granular privilege allocation. If we look at privileges from a very simplistic perspective, we could say you were given access or you were not given access to a particular resource. This is rarely enough in a modern digital environment. What we’re looking to understand is you are given access to some of the resources within this security realm, and the type of access you are given is very, very specific, lots of different attributes. So we need to establish for our identity and access management implementation, a method of ensuring that the privileges are granular enough.

And the opposite of a granular set of privileges is course privileges where we have very few layers of privilege. If we look at something like Active Directory, here the levels of privilege can be very complex. There are lots of different types of privilege. So we need to make sure we understand what they are, what we’re designing, what our requirements are, and whether or not our implementation meets the requirements of our design, of our set of requirements. So what we’re trying to maintain here

is least privilege: the lowest level of privilege that people need in order to do their job effectively. I don’t know about you guys, but I often see domain administrator privileges used excessively. For example, service desks, first-line support staff, given domain administrator access. And this isn’t necessary. This is not necessary at all. They’re given domain administrator access because they have to access lots of different systems in different ways. And this is just the easiest way to achieve that goal. What we can start to do is to understand some of these groups and the permissions that they create, that they generate. Things like domain administrators, the print operators group, the enterprise administrators group, and also the local administrator group.

There are different ways to meet these challenges. Microsoft, for local administrator accounts, rather than providing access to the local administrator account and the password, we can use their LAPS solution. LAPS stands for Local Administrator Password Solution. This allows us to delegate and revoke privileges on a person-by-person basis without revealing the administrator password to people. We can also look at the individual granular permissions that are needed, maybe, to reset print queues, to reset passwords, to create users without affording too many privileges. So we can break this up. And we should. With our disparate systems, this creates a particular challenge for us around identity and access management. When we look at Active Directory, we’ve said that’s complex. But it is overarching.

If we can master that, we’re mastering a huge section of our identity and access management system if we’re using that as a technology. However, for most organizations, they have many different identity and access management components – individual systems within that that may represent silos. So, individual line of business systems that do not integrate with the wider systems. These may be managed centrally. These may be managed locally. And we need to be careful in terms of ensuring that we understand where they are, what they are, and how they are managed, and also how well they are managed. So we can think about integrating our identity and access management system into security incident and event management systems as well.

So SIEM systems help provide the ongoing monitoring of events. They aggregate our log files for specific events that we’ve defined, for example, the use of elevated privileges. And we can integrate our identity and access management system into them. I’m a big fan of receiving a notification from the SIEM system if somebody joins or leaves the domain administrator’s group or somebody is created as an account with domain administrative privileges. So these disparate systems– ideally, we want to form an identity and access management baseline for each system to understand what information it holds, what level of privileges are required, what processes are in place to manage access.

We also want to consider whether or not these individual systems are part of a wider federation of identity management – something we’ll touch on later in the course. And also, for business intelligence and data warehouses and data archives, we need to be very, very careful. Typically, our line of business applications will be well secured with some kind of login process. Whether that’s a local process or part of an integrated single sign-on system, it’s managed. There is some kind of tiered privileges that are created. Quite often, when we archive data into the data warehouse, to enable analytics, what will happen is the permissions will be flattened.

And so your business intelligence team suddenly gain access to lots of different types of data that they would not ordinarily be provided with. And so this can change, inadvertently, through poor design, the access that is granted to these people. They can start to join different data sets up to create new perspectives on data, which is part of why we’re doing this, why we’re using business intelligence and big data. But also, some of this data still may be classed as being sensitive within our organization. So we need to control that. We need to think about that within a range of systems and our identity and access management.