A privileged account is a user account that has more privileges than an ordinary user. For example, they can read and modify the security-relevant configuration of a system, perform functions that can affect many users, and so on. As such, these accounts are the favourite of attackers (with 75% of organizations having experienced a breach involving privileged access)​ and so need the maximum amount of security by a business.

This webinar focused on securing access to IT assets such as servers. However, it is important to understand that secure access is also required in many other elements (such as applications) and that there are many different types of privileged access, making security not a one size fits all solution.

Traditional security approaches used by organizations, including the traditional PASM solution, are not solely enough to secure privileged access from attackers because they do not address the 5 key questions that need answering for strong security, which are:

• How to deploy strong authentication?
• How to secure built-in superadmins?
• How to control effective permissions?​
• How to manage a large number of servers?​
• How to closely monitor operations?​

To address this issue, companies can improve the PASM solution to make it more effective at securing privileged access. This is done by:

1. Automating permissions as much as possible: Servers are numerous and change frequently which is the same for users – standardizing and automating permissions will allow them to keep up with the pace.​
2. Addressing other use cases beyond interactive administration: this involves considering other needs to avoid users bypassing the PASM.​ Such examples include scripts using admin credentials, break-glass, and DevOps / machine-to-machine.
3. Designing your account model with least privilege in mind​​: For example, designing it so that there is 1 single nominative centralised account per user​ to simplify management, although this does not propagate lateral propagation. Designing a local generic account would be the most favourable in this instance, although it is the hardest for an organisation to implement and raises the question of who is responsible for the local accounts which makes governance more complex.

Are there any risks to PASM?

There runs the risk at project phase where admins reject the PASM solution because there was insufficient change management to onboard the admins on this solution from the start. To avoid this, onboarding and training admins on the PASM solution from the beginning is critical. Additionally, difficulty to deploy and cost can be a blocker of PASM solutions to organisations. Thus, the simpler the access model, the easier the solution will be to deploy and the less time it will take, meaning costs are reduced. Lastly, an on-premise PASM solution can run the risk of being very heavy and costly in terms of architecture so defining a SaaS solution would be beneficial. Although a thorough security solution, PASM solutions alone may not be the future of security solutions with the emergence of the ZSP strategy…

Zero-standing privilege (ZSP) is an alternative security strategy that aims to replace persistent accounts and privileges with just-in-time and just-enough cases and can be applied at both the user and server level.

User level:

• Zero standing privilege: Users are eligible to a pre-approved set of privileges, but those privileges are not activated by default.​
• Just enough admin: When they need to perform an operation, they can activate the minimal privileges…​
• Just-in-time: …for the required period of time; privileges are automatically revoked then.​

ZSP applied at the user level increases the awareness of users, improves the traceability of organisations’ operations, and helps limit the fat-finger risk.

Server level:

• Zero standing privilege: Accounts do not persist on servers, or they do not have any permission.
• Just enough admin: When a user needs to access the server, an account is created on-the-fly only on the targeted server…
• Just-in-time: … only for the duration of the session.

ZSP applied at the server level avoids the compromising of an account in the case of a breach, avoids bypassing of PAM tools, and avoids gaps between theoretical and effective solutions.

Is ZSP the future of privileged access management?

ZSP is designed for the future of IT where lots of users have access to lots of changing resources and it enables efficient user of Zero Trust approaches. However, ZSP does not address all use cases (such as machine-to-machine) and it is still immature in its development, meaning solutions are different and field experience is lacking.

Subsequently, Wavestone’s optimum strategy advice is to first define your global PAM strategy, followed by a solid PASM solution to effectively secure privileged access to your servers and then considering the introduction of a bit of ZSP in the estate. For example, at the user level for high privileges or for users with occasional needs and at the server level for cloud instances

Webinar accessible here: https://www.thesasig.com/calendar/event/23-10-11-networks/

Cet article Securing privileged access: approaches to a multifaceted challenge est apparu en premier sur RiskInsight.

Reminders on tiering

Tiering is a security model that is applicable to Active Directory. The main idea is to separate privileged accounts into different layers (tiers) and functional scopes, in order to restrict possible use to their originating tier only, so that if one tier is compromised, it does not lead to the compromise of other tiers. This allows, for example, to contain a ransomware attack in the original tier of the attack only, or to prevent the classic scenario of discovery and replay of a domain administrator credentials on a workstation. Typically, the model breaks down as follows:

• Tier 0 is the most critical. It consists of the AD itself, i.e., the domain controllers that carry it, as well as the components that interact directly with it, or that can compromise it by rebound. These are typically the ADLDS, ADCS, PKI, but also the IT components necessary for its operation: hypervisors, SCCM, SCOM, backup, and dedicated administration stations (PAW, for Privileged Access Workstation). The administration accounts for these components are those with the highest privileges, as they are necessarily the domain administrator accounts (the accounts with rights over the entire Windows estate of the organisation), but also the accounts of the other components that can indirectly assign themselves domain administrator rights, through interaction with the domain controllers.
• Tier 1 typically consists of the company’s applications and the servers that host them. The privileged accounts are therefore those of the functional administrators of the applications as well as those of the technical administrators of the servers.
• Finally, tier 2 includes everything that revolves around the user environment. In addition to the accounts and office workstations, we can find printers, telephony, as well as all the accounts for the different levels of user support.

To make it possible to seal off the tiers, and therefore limit the scope of compromise, “deny logon GPOs” (simpler to set up) or Authentication Policy Silos (more secure) are set up, to prohibit an account from a higher tier connecting to a component belonging to a lower tier. Also, another objective of the tiering implementation project, which may have an impact on PAM, is to restrict the number of tier 0 administrators to a minimum, again with a view to reducing the attack surface and the scope of a potential compromise. Having established this new concept, let us look at what already exists.

Bastion? Did you say bastion?

The security bastion is a very common tool used by organisations to implement PAM. The principle is to host privileged accounts in secure vaults, and to enforce administrator logins (with a non-privileged account) to a central bounce machine, which will play these privileged accounts for the administrator, without revealing their password. Another advantage of the bastion for organisations is the ease with which they can set up multi-factor authentication, the recording and traceability of administration actions, the automated management of password rotation, etc.

So far, there is nothing incompatible with the tiering model. And yet there are similarities. The structure of privileged accounts that was created in the bastion (by perimeter and/or by functional team and/or type of component, etc.), was created without consideration of the concept brought about by the AD security project: the notion of tiering.

In order to identify the potential impacts, let us place ourselves in the perspective of tiering and ask the questions simply in relation to the bastion.

How to adapt the bastion to the tiering model?

If one were to synthesise the problem to be solved, this would give the above diagram. To adapt it successfully, choices must be made.

Should the bastion be placed in a specific tier? Should it be duplicated in each tier?

As described in the diagram from a purely theoretical point of view of tiering, there should be an instance of a bastion in each tier, and perhaps even an instance from different publishers in order to protect against a 0-day flaw in the technology used. But the measure comes up against a financial reality, as the possession of several bastions has a certain cost, coupled with an operational reality that does not support the multiplication of tools for the same need. Fortunately, adaptations are possible. In reality, no company puts a bastion on tier 2. As this tier is relatively homogeneous and monolithic in terms of responsibility, it is allowed to connect directly to it, obviously through a tier 2 privilege account, or with the local administrator account (protected by LAPS) which has the advantage of being robust with respect to a total compromise of tier 2 in the event of the compromise of a single tier 2 privilege account.

For tiers 0 and 1, their fate is linked and depends on both the context of the organisation and the existing situation. The first option, as mentioned, is to deploy a dedicated bastion in each tier. Being a bit more realistic , if only one bastion instance is possible, then this should necessarily be positioned in tier 1. The reason for this choice is very simple: the bastion meets a functional need for administration, and the largest number of machines and accounts are in tier 1, as opposed to tier 0, where you want to restrict exposure (i.e., the number of administrators who have access).

Tier 0 can be more simply managed by PAWs, dedicated and hardened administration workstations with the specific purpose of accessing privileged accounts and resources. Access to the network area which hosts tier 0 is subject to a VPN connection, authorised only from these PAWs. There are organisations that have done a combination of both: bastion and PAW. This implementation remains perfectly valid from a security point of view, but its feasibility depends on the company’s ability to deploy PAWs for all its tier 1 administrators, which represents a much larger target population and cost. One last point to conclude this topic: the use of bastion and PAW are compatible, and the security benefits are complementary for the protection of privileged accounts.

In the case of a single bastion, can the other tiers be administered via the bastion?

This would simplify things, but unfortunately it is not desirable. Administering tier 0 from tier 1 would break the whole segmentation we are trying to implement, especially because privileged tier 0 accounts would be hosted in tier 1 and accessible by the tier 1 administrators of the bastion. That said, a tiny possibility of this implementation exists, but it is very technology-dependent, as very few bastions offer the appropriate functionality. In principle, by placing the bastion in tier 0, administered by tier 0, it would be possible to create groups of rebound machines, as well as dedicated (logical) vaults, active or passive, in each tier. However, it should be noted that the few organisations that have tried this are now retreating from the technical management of the vaults and the administrative burden involved.

Should the allocation and distribution of accounts in the bastion be reviewed?

Not necessarily, but again, it depends on the context and the existing situation. Firstly, the accounts from each tier must be hosted in different safes, in order to respect the segmentation and watertightness of each tier. If necessary, there is nothing to prevent the vaults from being broken down into sub-areas within each tier to suit the existing technical or functional organisation (e.g., teams responsible for the MCO/MCS of components hosting databases are different from those responsible for the MCO/MCS of business applications). Finally, it is recommended that as many named accounts as possible be used, rather than generic or shared accounts. While there is nothing to prevent the use of a single administrator account for all tier 1 servers used by all administrators within the perimeter, and this method of operation does not contravene the principles of tiering , it is still preferable to be able to immediately identify the owner of the account that performed the action, in order to better control the accesses and authorisations of each person, even if the stronghold would still allow the identity to be traced indirectly by cross-checking the logs.

Providing a good framework for the implementation of tiering

Tiering is currently the project that most reduces the risk of compromise of high-privilege accounts and the AD in general. However, it is also a complex subject, which has a lot of impact on all infrastructures, and which requires many adaptations to the existing system for its implementation to be considered successful. As PAM is an essential building block for the management of these administrative accounts and accesses, it is necessary to ensure that its implementation does not interfere with the principles of tiering, or even break down the segmentation and isolation into layers. If there is only one thing which must be remembered to succeed in this transformation, it would be that the implementation of tiering, contrary to popular belief, is far from being a simple AD subject,  but rather that it must lead to a rethinking of all administration practices in their entirety.

Cet article Security bastion (PAM) and Active Directory tiering mode: how to reconcile the two paradigms? est apparu en premier sur RiskInsight.