Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
Over the past couple of years, sysadmins increasingly abandoned the “traditional”, hands-on, approach to identity and access management in favor of IAG (Identity and Access Governance).
Switching from a hands-on approach to IAG means much more than taking advantage of emerging technologies, like automated privileged access management solutions.
Before going over the details of what is access governance, I believe it’s only fair to explain a bit about how it came to be and why it’s vital for a company spanning hundreds of endpoints and users to implement this change as fast as possible.
The Newfangled Threatscape and What Is Access Governance
To understand why access governance became the golden standard of the industry, regardless of purpose or nature, it’s only fair to try to ascertain the role of the system administrator. Not the cushiest job right now, considering how fast companies tend to grow. It’s difficult enough to maintain a network of 10 endpoints, not counting BYODs, with every employee flocking around you to ask for elevated privileges sessions.
Why would an employee need administrator rights in the first place? Think about it: each company has its own ‘pool’ of software (ERP, invoicing\accounting, Microsoft Office, etc.). Of course, there’s no such thing as a one-size-fits-all solution; as the company grows and expands, so does its need for able-bodied software, robust enough to remove major ‘roadblocks’. Thus, arises the issues of deployment and up- or downscaling, as the situation dictates.
This brings us to what we can only call the crux of system administration – figuring out its own ‘role’ in relation to the other players. Should a sysadmin be that person who goes from endpoint to endpoint just to avoid giving an employee elevated privilege? To be honest, that would mean bringing back Sisyphus from the dead – not a very productive approach! In a company that spans hundreds of endpoints, some of them not even being on the premises, this kind of approach is impossible.
The search for a unified, granular, and comprehensible solution led to the advent of Identity Access Governance, a methodology poised to provision the sysadmin a never-before-seen vantage point, one that he could use to determine what goes on, both inside and outside the company network. With such a praxis in place, companies will fall in line much easier in terms of regulatory compliance but will also be able to establish its own policies and procedures regarding the way users interact with the IT infrastructure.
From obscurity to stealing the limelight, I.A.G is swiftly changing the way we look at the traditional sysadmin – end-user model. Instead of pre-defined, convoluted, and often subjective role-attribution, we have two explicit approaches: RBAC (role-based access control) and ABAC (attribute-based access control). The ramifications are even broader. I.A.G is what you may call a binary system, although the methodology itself is subjected to continuous change, depending on the attributive process. I’ll get to that shortly.
As far as the theoretical part is concerned, I.A.G has two major components: authentication and access. These are the main support pillars that maintain the ‘framework’. The system itself may be binary, by nature, but here’s where things get a little complicated.
I.A.G, being about setting up identity & access policies, managing and finding ways to enforce them, further divides into role-based access control and attribute-based access control. We’re still talking about the access side of I.A.G. On the authentication side, we have ID management policies. It may sound very confusing, but all shall be made clear in a second. Let’s begin by breaking down I.A.G into its most basic components.
RBAC, Compliance and Corporate Thespianism
One of the models that make up I.A.G is called role-based access governance. Basically, it’s long-winded list of network permissions and restrictions based on the employee’s role within an organization. The roles themselves are pre-defined, based on several factors, the most important of them being job competency, responsibility, and, of course, the level of authorization.
Here’s a quick example of how this model works. Let’s assume we are dealing with two roles: sales consultant and a simple user. It’s easy to imagine that the “sales consultant” role bears a little more weight in terms of access & permissions compared to that of a simple user, which can be anything from a dummy account (used for QA testing) or a temporary account set up for interviews.
So, what type of permissions are we talking about? Well, the user, for instance, doesn’t have enough clearance to access sensitive documents and files such as the customers’ database, salesforce CRM or the mainframe. Instead, he or she will only be given access to the company’s email and, possibly, the corporate network. On the other hand, the sales consultant, which is more important than the user, entails a higher level of clearance.
For instance, apart from the company’s email, this role could also be granted access to role-specific systems and/or tools such as the customer database, and salesforce CRM. Those are just two of the roles covered by RBAC. There are many more, with some of them being ‘concocted’ in-house, meaning that the sysadmin can alter these properties to fit the company’s business profile.
The major advantage of deploying an RBAC-type I.A.G is that it works in tandem with the employee’s job description, meaning it’s a more cost-effective way (both time- and money-wise) to set up a user within a corporate network.
In terms of compliance, RBAC covers many aspects, some of them vital to the company’s survival. Lately, insider threats have increased both in number and strength, with companies leaking millions of dollars. The early implementation of this type of I.A.G ensures that end-users without the proper clearance will not be able to access or make any changes to business-sensitive information. For instance, an employee defined as a “simple user” within the corporate network will be unable to access or modify info pertaining to, let’s say, the CRM and its business prospects.
The early implementation of RBAC comes with many advantages:
- Complete compliance with state, federal, and local laws, rules, and regulations, including GDPR. Companies using RBAC have a much clearer view of how the data is used and accessed.
- Downsized costs. RBAC-enforced policies are easier to deploy and spread across multiple endpoints, and tends to use apps which are costly to maintain and manage. Furthermore, it was shown that RBAC also decreases costs associated with the overall network infrastructure such as bandwidth, storage space, and memory.
- Downsized insider threat risk. Since the access to sensitive information is restricted, it’s far easier to keep tabs on who can see, write, and edit that particular section of the secure corporate network.
- Increased overall visibility over authentication protocols and access requests. I.A.G builds on the premise of a crow’s nest overview of information security and management. If necessary, the focus can shift from “aerial” to “granular.” This is particularly effective at ‘picking up’ threats and infiltrates that are below the detection threshold. For more info about stealthy threats, you should check out my colleague’s article on POLP (Principle of Least Privilege) and privilege creep.
RBAC may very well become the industry’s baseline, but it’s not flawless. Here are a couple of disadvantages you should know about before deploying it within the company’s network.
- “Role explosion” – a defect endemic to RBAC. Role explosion is a direct consequence of rapid upscaling, both in number of employees and in roles. The best example of a role explosion would be a doctor working in a hospital receiving the role of “medical consultant” within I.A.G. This entitles him or her to call up role-specific commands such as “review medical record.” However, this entitlement also allows the physician to view his\her medical record, not just those of the patients. This means that the doctor whom the sysadmin assigned the I.A.G “medical consultant” designation, exceeds the boundaries of the pre-assigned role, which doesn’t bode well with a system aiming to close all access & authentication loops.
- RBAC is static and doesn’t factor in context-dependent information. In an RBAC system, roles are loosely defined and do not incorporate contextual info such as location, device type, or time. That is the main reason why ABAC (attribute-based access control) is preferred over RBAC in cases where contextual data is needed to further outline the role.
- Fine-particled control filters are available, but painfully difficult to implement. RBAC allows for some degree of granular control over permissions, accounts, and roles. However, if the sysadmin wants more than just a “birds-eye view”, a finer-particled filter is quite difficult to implement, since RBAC relies heavily on APIs, third-party apps, and Dbs.
RBAC is not the only approach to identity and access governance. In an attempt to have more control over the granularity, ABAC or attribute-based access control has been created. The major advantage ABAC has over RBAC is the ‘ability’ to integrate contextual information, which is essential in further defining the role an employee plays within the company. Let’s shed some more light on ABAC how it can help your business.
ABAC, Compliance, and “Rich Policies”
Whereas RBAC is static, ABAC is the very embodiment of dynamicity – the model can factor in various datasets that RBAC cannot. ABAC is the way to go for fast-growing companies who want to mitigate insider risk threats as fast and efficiently as possible. This approach heavily relies on rapid cloud deployment, which not only reduces the time-to-market for new software but also increases transparency and regulatory compliance.
One of ABAC’s greatest deterrent would be the need to change the way we think about traditional roles in the company, from a sysadmin standpoint. It’s like having to learn a new language. Actually, for ABAC deployment, the sysadmin has to get very familiar with XACML (eXtensible Access Control Markup Language), a policy language that is used to define the various entities operating within its boundaries.
With that in mind, let’s begin by taking a closer at ABAC’s operators:
- Subject.
- Action.
- Resource.
- Environment.
At a glance, it looks more like something taken out of a linguistics book, rather than something you would normally use to manage permission and auth session. Here’s where it gets really interesting.
1 The Subject
It’s the user who’s demanding access to info within the network. To determine the subject’s role, some descriptive attributes are called up from the system (usually from the HR). These attributes can be anything from “general role” properties to “group membership” or even the “parent department.”
2. The Action
As the name of the operator suggests, it refers to a specific action the user intends to perform on the info he requested access for in the first place. The most common actions are “read” and “write”. However, as the roles grow, both in number and complexity, the available actions increase exponentially.
The best example, in this case, would be someone from Finance wanting to transfer a sum into an employee’s account. Apart from “read” and “write”, other attributes are necessary to complete the action such as “transfer” and, of course”, “amount”.
3. The Resource
It mostly refers to the actual resource that is impacted when the subject performs a certain action. If I were to use the above-mentioned example, the resource impacted in this case will be a string appended to your bank account.
4. The Environment
It provides the context in which a user initiates an action that impacts one or more resources. As an operator, the environment can also ‘receive’ various attributes. Some of the most common contextual attributes are date, time, and location. This operator can also carry auxiliary attributes such as the strength of the encryption protocol or the type of machine used to carry out the query.
So, how do you create powerful access and authentication policies using these operators? Let’s see a quick example. Imagine that you’re are a sysadmin tasked with creating a policy that would allow regional sales department managers to access (“read”) customer proposals.
The newly-created policy further specifies that only users belonging to the sales department and are managers are able to execute a “read” type command on the document, as long they belong to a specific region. Now, the database entry for this type of evaluation should look something like this:
Subject: “department” = “sales”
Subject: “sales region” = “NJ”
Action: “read”
Resource type = “customer proposal document”
Resource region =” NJ”
ABAC is an extremely complex and multi-faceted identity and access governance model. Cascading attributes make it easier to manage permissions on both global and local levels thus allowing the sysadmin to fully automate the entire flow. If you think that your company’s profile might benefit from ABAC, here’s a short list of pros and cons.
Attribute-based access control advantages:
- Dynamic I.A.G model, capable of integrating contextual-sensitive data, as well as meta-data.
- Adds more granular control over your network’s security.
- Near endless combinations – ABAC policies are only limited by the user-defined attributes and, of course, the computational language.
- Supports additional security protocols, such as auth strength, physical location, and multi-factor decisions.
- Reduces risk associated with human error. Since automation is one of ABAC’s USPs (unique selling points), the adoption of such an I.A.G could greatly decrease the risk of insider threat due to human error if all the attributes, roles, permissions, and policies are carefully appended.
Attribute-based access control disadvantages:
- Some difficulties may arise in sketching policies and appending the right attributes. Without a doubt, defining attributes is infinitely harder than coming up with roles, as in the case of RBAC.
- Dataset becomes very complex to analyze as the number of users (and values) increases.
- Already defined attributes require constant maintenance. They could be also subjected to change, depending on the company’s needs.
Access Governance Deployment Strategies – ABAC or RBAC?
ABAC and RBAC aren’t just pen-and-paper theories. They are meant to be put to good use. Naturally, one questions “how can such models serve the authentication and access needs of my company?” This is why it’s of the utmost importance to strategize your I.A.G deployment in order to cover all of your security network’s ‘pain points.’ Below, you will find several useful bits of advice on how to bolster your I.A.G’s efficiency, achieve maximum compliance, and reduce the time it takes to achieve system-wide deployment.
1. Thoroughly consider data integration before making the transition
Before committing the change, ensure that the I.A.G models can accommodate all datasets and software your company is using. Access governance should be at the heart of every company, but there are times when this type of transition is unwarranted, as it may cause a complete breakdown of the system.
For instance, RBAC or ABAC deployment could render some software useless, thus interfering with normal operations. In this case, it would be best to stick to a more traditional privileged access management approach, rather than trying to reconcile these incongruities. Remember that the purpose of I.A.G is to simplify the system, by reducing the workload, not add even more issues.
2. RBAC over ABAC for onboarding
From an HR standpoint, RBAC is a far better approach than ABAC, especially when it comes to the on-boarding process. It’s quite difficult to ease someone into a new role. Imagine how burdensome the on-boarding can become if the company was operating an attribute-based system – you just can’t figure what your position entitles just by looking at some raw values and strings. You should also factor this in your decision to deploy I.A.G.
3. Consider implementing Blockchain Identity
Blockchain identity is a somewhat new concept that proposes a new way of storing information. Instead of dumping everything in the system and hoping for the best, this model the storage of data in blocks that are linked by a chain. What that means is that the system won’t allow anyone to make any additions to the stored info after the chain has been verified. One major advantage is that Blockchain Identity removes the needs of intermediaries, which greatly decreases the risk of insider threat.
4. I.A.G deployment for filling compliance gaps
Complete compliance with state, federal or local laws is oftentimes difficult to achieve, some administrators finding out too little, too late that the system is not up to par. Identity and access governance will help close any compliance gaps which, in turn, will reduce the risk of data breach or insider threat.
What Happens After Deploying I.A.G?
The sysadmin’s role doesn’t stop after implementing an access governance solution. Some models like ABAC can offer some degree of automation, but no solution could account for unforeseen. So, without further ado, here are some tips that should help you improve your PAM hygiene.
1. Implement SSO (single sign-on) authentication
If you want to avoid accidentally revealing passwords to a shared account, you should definitely consider implementing a single sign-on authentication service. This enables the user to employ a single set of credentials across multiple apps.
2. Elevated instead of superuser privileges
In a company with hundreds of employees, there may be more than one administrator. Naturally, each admin should have special rights in order to perform his tasks. To further reduce the risk of insider threat, consider elevating privileges for your admins each time they have a task to perform.
3. Keep tabs on privileged sessions
To prevent the user from installing malicious software on the machine during an elevated rights session, you should definitely consider recording the session for a future audit.
4. Choose an appropriate PAM solution
While deploying I.A.G, a third-party solution might help you close some gaps and avoid things like privilege creep. For instance, Heimdal ’s Heimdal Privileged Access Management can handle all privilege escalation queries. More than that, it’s the only PAM solution on the market that automatically de-escalates admin rights upon threat detection.
Privileged access management has gained quite some traction most of the latest security reports pointed out that many malware has managed to penetrate the IT infrastructure through accounts running admin rights. Without a way to contain these threats, major data leaks are imminent. This is the main reason why sysadmins are circumspect in releasing rights to ‘non-privileged users. P.A.M solutions like Heimdal`s Privileged Access Management aim to streamline (and simplify) the entire permission-granting (or refusal) flow.
Heimdal® Privileged Access Management
- Automate the elevation of admin rights on request;
- Approve or reject escalations with one click;
- Provide a full audit trail into user behavior;
- Automatically de-escalate on infection;
Wrap-Up
As access governance continues to evolve, it presents a promising solution to reduce costs, workload, and security risks for organizations. By embracing IAG and leveraging RBAC or ABAC approaches, sysadmins can revolutionize their roles and bolster enterprise security standards, paving the way for a more secure future.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, and YouTube for more cybersecurity news and topics.
