Managing User Privileges: How Can Software Help?
If you go to your search engine of choice and type in “privilege management”, you’ll be inundated with adverts from companies who want to sell you a software solution. What exactly is privilege management? Does it relate to just infrastructure, or also websites? Is there a software solution that will help with it? That’s what we’ll discuss here.
Privilege management (aka Authorization), broadly speaking, is what can be accessed by who. A typically accepted security best practice standpoint is one of “least privilege”, meaning that people have access to what they need to perform their (daily) tasks and nothing more.
In a Windows environment, the most common tool for dealing with privilege management is Active Directory. This is where users and groups are created, as well as resources such as computers and servers, and permissions can be assigned to them as to what they can do. The folder structure we all know within Windows can then have permissions assigned to it on a granular basis using these objects made in Active Directory.
Let’s look at an example here of how Active Directory can be used to manage privileges with regard to shared folders on a network.
A company, Example Corp, has two managers called Bob and Jane. They both need access to numerous folders across the network that nobody else should have access to. These contain performance spreadsheets, strategy documents, staff salaries etc. We make an assumption here that nobody has access to any shared folders by default, as we’re operating on a system of “least privilege”, as stated above.
Option 1 is to add Bob and Jane individually to the permissions for these folders. This is a completely valid option and will do everything it needs to do; they will both have access to these folders and nobody else will.
Option 2 is to create a group, for example “Managers”, add Bob and Jane to this group and then add that group to the permissions for these folders, meaning Bob and Jane inherit access rights due to being a member of the group. This way, if Bob or Jane need to no longer have access to those folders, they can just be removed from the “Managers” group rather than having to be manually removed from the permissions for each folder. Equally, if someone else is promoted to a manager they can just be added to the group and don’t need to be individually added to each folder’s permissions. This prevents the possibility of someone forgetting one or two folders that people need to be added to or removed from, so increases both security and efficiency.
A possible drawback of option 2 is that as more and more managers are added to the group, granularity is lost amongst them. This could mean some folders are marked as accessible for the entire managers group, whereas they may contain documents only a subset of those managers (2nd level managers) should be allowed to access. This would necessitate creating a separate group once more and consistency and good accounting is necessary to keep all group memberships and folder permissions correct.
During an internal network test, BTL found a share named SOFTWARE which was writable by any user. This folder seemed to be used for storage of software packages which were then automatically installed by script or group policy to new network users. This obviously needed to be accessible and readable by any user, but being writable opens up an avenue of attack. If an attacker gained access to a low level user account through phishing, for example, then they could have replaced one of the software package files with a malicious one which would then run with the privileges of whichever account was installing it, providing access to other user accounts which potentially had higher or at least different privileges to the one which has already been compromised.
Privilege management isn’t just important on a network, though. It’s also necessary on websites and in mobile applications. Logging in with an email or username and a password and then being presented with your own information is an example of privilege management. Nobody would want another member of the public to be able to access, for example, their medical information. Standard users should also not be able to access any administrative functions on the website to be able to make changes to the website itself. The creators of the websites, APIs and applications that deal with this data are responsible for implementing privilege management to make sure that people can only access what they are supposed to.
So, is a software solution required to help with this? That depends on a number of factors.
There are many third-party libraries already written that can deal with privilege management for a website or mobile application, for example. It may not be necessary, therefore, for a developer to do all of this work again. This is especially useful for companies with a small staff/budget, or self-employed developers. Some bigger companies may prefer to develop these things from scratch, but for some companies this is literally not an option for time or financial reasons.
In one example BTL recently tested a web application, where the developers had developed the authorization from scratch and felt they had covered all the bases, where the website access was split between different client companies, with each company having admin as well as regular users. During scoping the test emphasis was also placed on the fact it used a binary protocol (namely gRPC) and hence they would expect it difficult to be reverse engineered. This protocol however is entirely publicly documented, and likewise, given enough time, anything implemented on the client side of a website can eventually be reverse engineered anyway. Using basic knowledge of the protocol it was shown that a few authorization checks were actually not in place, resulting in any user being able to create user and even admin accounts in other client company sections of the website. This shows the danger of developing authorization checks from scratch as well as overreliance on security by obscurity (i.e. using protocols deemed difficult to reverse engineer).
With regards to networks, if it’s Windows-based and there is a Windows Server then Active Directory or Azure Active Directory if there are no on-premises servers are a perfectly adequate way of dealing with privilege management, as described above.
In many of these instances, if someone is unsure, it may be best to speak to a consultant or other expert to find out what option is best. It would most likely be cheaper, for example, to pay for a software solution that deals with privilege management than to create something oneself that is not fit for purpose and results in a data breach and subsequent fines and/or bad PR. Equally, if there is a free or cheaper way to do something that works just as well, then there is no point in spending that money on the software solution.
Simply put, there is no one-size-fits-all solution for privilege management. For Windows networks, the tools that Microsoft provide are more than adequate. For websites and applications it is a little more complicated, but not unmanageable. What is important is making sure that users have access to everything that they need, but nothing more.