We’re back with another blog, and this week we’re looking at privileged access, explaining its importance, and some considerations for implementation.
Why is privileged access so important?
We need to look at this in a few ways. As cyber security professionals we need to not only consider the risk from a security standpoint, but also from a business efficiency perspective. If IT staff do not have an effective way to administer the systems for business as usual (BAU) and cannot do their jobs, then the organisation suffers. Alternatively, if IT staff are over provisioned with excessive permissions they can potentially implement changes they should not be able to make, and the risk of compromise increases as there are a disproportionate amount of highly privileged accounts within the environment.
One of the biggest threats to organisations comes from phishing emails, and human operated ransomware, both of which rely on gaining access to privileged accounts. The quicker they get access to privileged accounts or workstations, the faster they move throughout their victims infrastructure and achieve their ultimate goal. Simply put, when a privileged account is compromised by an attacker, the likelihood of serious negative impact greatly increases. We simply can’t overstate how important it is to ensure you are using a least privilege model for privileged accounts.
Reducing the amount of privileged accounts, the level of privileges applied to those accounts, and the fewer locations where those accounts can be used will directly result in reducing the likelihood of a compromise via a privileged account.
We need a privileged access strategy.
We need to think about this as more than just implementing least-privilege for IT admin accounts, we also need to think about accounts used to facilitate automation, dev team accounts, and device least privilege. What we mean by this is can an admin account be used via an unmanaged personally owned iPhone to login to your Cloud admin portal, a VPN (Virtual Private Network) or an internet facing Citrix virtual desktop? If so, we definitely need to restrict that.
We need to create an enterprise access model based on our current infrastructure, this model will be different dependant on whether we are full cloud, hybrid, or on-premises.
Initial investigation and considerations.
- How are admins connecting and carrying out privileged actions? (When, where and what).
- Which accounts are authenticating APIs, workloads, or automation? (Service Accounts).
- Can we monitor changes such as additions to privileged accounts or groups? (Global/Domain Admin).
- MFA, MFA and MFA!! (Especially for remote or VPN access).
- How are privileged accounts currently used? (Admin only changes or also to browse the internet and access emails).
- Are privileged accounts separate accounts or are privileged roles applied to standard user accounts?
- Is role based access control (RBAC) in use where possible to simplify privilege control?
- How often are assigned privileges being reviewed and removed if no longer required?
- Is there an established process for approving and assigning privileges to accounts?
- Where there is a requirement for shared accounts, how are the credentials managed, shared, stored and monitored?
We need to understand these items as a minimum before we can create a strategy, and effect any meaningful change.
What are PIM and PAM?
There are now ways to simplify privileged access via “Privileged Access Management” (PAM) and Privileged Identity Management” (PIM), however although these are fundamentally concepts first, there are now also many vendor products using the same names which can be purchased to manage privileged management.
Both improve visibility of the three “A’s”, Authentication, Authorisation, and Accounting. In a standard on-premises environment controlling and monitoring privileged account use is very difficult and that is where tools such as PAM and PIM come in. Cloud based infrastructure tends to have more in-built functionality being newer products, but often advanced features require additional licencing.
The terms PIM and PAM are used interchangeably and some products are arguably both PIM and PAM, however the differences between the two is in their respective names. PAM focuses on access, whereas PIM focuses on identities. PAM will manage how privileged accounts access assets and infrastructure and can provide additional functionality such as password rotation, session recording, and remote access. An example would be logging into an on-premise PAM solution often via a web-portal (which is often Cloud-hosted), once logged in our dashboard would display only the accounts and endpoints we have approval for. When a session is launched all actions are logged and in some cases screen recorded which can be viewed if required for an investigation or incident. We’re able to centralise existing privileged accounts, enforce least-privilege, configure and monitor them centrally. With PAM users don’t even need to know the passwords, they are either available to copy and paste (in older PAM systems) when connecting or automatically entered by the PAM system on connection to the host.
PIM on the other hand will provide functionality such as Just In Time (JIT) access, time-bound access, audit history, and approval chain. In practice this would mean that any user wishing to perform an action requiring additional privileges could request the required role, provide a justification, and then be granted time-bound access (which auto expires) once this has been approved. Although this sounds prohibitive and inefficient, modern solutions allow this process to be very easy and expedited. We don’t have to enforce JIT for ALL privileged roles, which means most admins can do most daily tasks as required, however where a high privilege role is required once a week, or month for example, then a request and approval would be required and this can be time-bound to hours, days or weeks.
This helps strike a balance between usability and security, and allows us to create our own bespoke models based on our organisation and risk acceptance level. PIM also allows us to configure co-approval whenever a critical account such as Global Administrator, is required to complete an action or configuration change.
PIM also allows us to raise privileges for extended periods when project work requires temporary permissions for the length of a project. One of the biggest overheads for IT Teams is auditing of privileges, and privileged accounts, with auto expiring elevated privileges, we can be less concerned that accounts within our organisation are over provisioned or subject to privilege creep. Permission reviews are still required regularly, however we should find far less issues when using PIM, and this translates into a reduced attack surface, and less administrative or manual overhead. We can also configure auto-removal of any permissions assigned to accounts which have not be used in X amount of days, so even if requested and approved, if the permissions are not being used we can automatically revoke them.
The most simple way to compare the two is; think of PIM as users having a separate admin account which is given additional privileges via an approval process and these extra permissions auto expire based on the period of time they are granted for. Whereas PAM is a central repository for accounts and passwords (and other secrets such as certificates for SSH) which users access to connect to systems and infrastructure as per their set permission level.
Why Are Access Reviews Important.
To reiterate this point, PIM and PAM are not only about securing privileged access, it’s also about ensuring users can complete the tasks they require to be productive.
Excessive privileges can lead to compromise and a severe negative impact to the organisation, however the same can be said for poorly designed and overly restrictive controls. Too often in cyber security we get too focused on being “secure”, when we should be focusing on preventing the business being impacted negatively, and facilitating key business functions. This does not mean we should not be considering security, it means poorly implemented security can have a negative impact on the organisation as staff implement workarounds which are insecure or increase risk, or are incredibly inefficient due to overly restrictive controls. Buildings need to be secure for example, but if no-one can get inside, then that is not considered as effective security.
Access reviews should therefore not only remove excessive privileges, but also confirm users are able to complete their day to day work.
Whenever we set and forget anything within IT it will become neglected, invisible and fall into a poor state. Before we know it we have to start almost from scratch, unpicking everything to understand what is in place, before it can be rectified. Regular reviews ensure that configurations are fresh in our minds, documentation is current, and keeps any remediation work to smaller bite-sized chunks. It’s much better to continuously maintain than let things fall into a poor state as it will always be more difficult to rectify when left for long periods.
PIM and PAM Vendor Offerings.
When it comes to vendor offerings it’s not always easy to label them as exclusively PIM or PAM as much of the functionality and principles from both are now mixed into most offerings. For example Microsoft provides JIT access as part of their PIM offering, whereas ManageEngine include JIT in their PAM product.
We should try not to get bogged down on these terms when looking at solutions because we should not be buying a system because it’s a PAM or PIM solution, we should be deciding which principles of PIM or PAM we have identified as being required by our organisation, and then purchasing a system which meets or aligns with those requirements. The moment we go to market to purchase “the best” PIM or PAM solution we lose sight of what we want to achieve, the risks we have identified as a priority, and our focus becomes drawn to which product provides the most functionality.
More often than not we over provision when we buy a product. We often can’t take advantage of its full functionality, or we implement 50 areas of functionality poorly, rather than implementing 5 specific areas to a high standard. Alternatively we can find that although we succeed in implementing all the available functionality, we simply do not have sufficient resource to maintain a strong configuration, or use the tool effectively. This is where we find ourselves cutting corners or ignoring other areas of the product as we simply do not have time to manage it. Remember, every new system we implement has to be maintained, patched, tested, and documented. If managing a sprawling PAM system takes valuable staff away from other security focused functions, have we actually achieved anything? Sufficient skills and resource are paramount to any successful digital implementation, so we must account for this.
Summary.
PIM and PAM are effective cornerstones of any privileged access management, whether fully cloud-based, on-premises, or Hybrid. We should focus more on what we are trying to achieve and less on vendor products and functionality. Ideally you will already have this mapped out before purchasing a product, rather than doing both at the same time.
We should also not focus on whether we want PIM or PAM, we should focus on our strategy and pick the correct functionality which best addresses our current privileged access management risks and gaps.
@2codemonte 