The recent NotPetya ransomware attack was a game changer in many ways – the speed at which it spread and its destructive nature, have been a wakeup call to both the affected and unaffected organizations who watched NotPetya ravage networks around the world. Pharma companies, the Chernobyl radiation detection systems, the Kiev metro, an airport, and a few banks were affected by the malware within a few hours from the outbreak. The most important thing to realize in the wake of such attacks is that they push the likelihood of being hit, and the consequences of an attack, into a much more perilous ballpark.
The reason that this attack is a game changer is that, in contrast to attacks like WannaCry, where the exploited vulnerability could have been patched using standard methods, the advanced methods used by NotPetya to capture valid user credentials and propagate laterally in the network are not easy to re-mediate on older, still supported Windows platforms (like Windows 7 and Windows Server 2008).
The issue with this is that while credentials are needed for the IT Infrastructure to allow access to authorized parties, valid credentials in the hands of an attacker – be it a human adversary or an automated worm – can be akin to them obtaining the keys to the kingdom. Obtaining that key is complex and expensive for the attacker, but is worth the effort if that key is a master key that opens all doors (i.e. domain admin credentials). One of the mitigation concepts here is to follow a “One key – one lock” principle, rendering a retrieved key valid only for the compromised system and not laterally throughout the network. This concept can work well without hindering the usual business and administration of these systems for its authorized parties.
The purpose of this writing is not to address the general actions needed to implement a “One key – one lock” principle, but rather to focus on what the concept means for IAM implementations in times of attack, and in general.
The Least Privilege Principle must take precedence
IAM can be seen as the discipline of balancing two principles – the principle of timely authorized access (or access when needed), and the principle of least privilege (access on a need-to-know basis, or only being able to do what is required).
In theory, or in high level perspective, these principles do not seem to collide, but since we live in an imperfect world, the cost of ensuring the limitations is inhibiting, and the result is that the timely access is often prioritized for quick and easy enablement and the least privilege principle suffers by making access coarse-grained, where permissions are granted in larger sets/more generic bundles rather that smaller sets tailored to individuals and roles. It can also result in the least privilege being enforced and causing the business to wait for legitimate access.
Let’s keep in mind that the inherent nature of IT is to enable faster/richer functionality to its users, and we, as security professionals, are here to help balance the principles that would allow IT to achieve availability at a reasonable security level.
It is important to realize, that in order for security to be effectively adopted by the organization, security must never be a hindrance, but rather seek to help enable the business in a secure manner. Especially for fast-paced businesses, where continuous business transformation, mergers and acquisitions dictate a more responsive approach to security, enablement can not be met by traditional methods without loosening the strict enforcement of security policies.
But the NotPetya attack changes that balance. Oftentimes companies run an infrastructure that is complex and time consuming to secure, and hence all remediation that can limit the impact of a similar or even more potent attack is required. Thus, the focus on least privilege must take precedence more than it traditionally has been done before.
Let us state clearly that there are already many general guidelines available on how to secure the IT environment – the purpose of this paper is to focus on the IAM-specific consequences and guidelines that can assist with this endeavor, as IAM is the cornerstone of each IT deployment. IAM can help bolster security by enforcing good practices and automating some of the associated workload. However, there is no silver bullet available that can achieve this result easily.
Let us divide this discussions into 3 sections:
- The “Least Privilege Principle” – What it means and how to work with it
- Management of identities in the IT environment
- IAM infrastructure requirements – As one of the crown jewels, it requires stringent protection
Obviously, a subject this complex, is not covered by this paper alone, but the intention of this writing is to create awareness rather than provide a complete solution. Our purpose is to allow professionals to take away some of the principles and add to the guidelines where needed.
The Least Privilege Principle – Concept and use
The concept of Least Privilege can be rather intuitive: it means that no more access-rights than needed at any given point in time are granted to any one party accessing the system. But be aware that the time perspective of the matter can complicate the task, since permissions are subject to change over the user’s life-cycle in the organization. There’s also time needed for optimization and for implementing atomic permissions. In the real world, this means a pragmatic approach is needed; do not let “the perfect” get in the way of “the doable”, and keep the focus on the important problems!
On a functional and practical level, this means that administrators need to perform some grouping of their users’ permissions in entitlements on most systems called groups, and again group those into a Role Based Access Control (RBAC) scheme for provisioning purposes.
We do not recommend aiming for a complete RBAC model; rather, it is better to focus on the key business processes and ensure a reasonable governance structure around it. This will cover most of the Access Management requirements, but in most cases, there will be a need for more sophisticated or fine-grained access control in the form of Attribute Based Access Controls (ABAC), or its siblings Risk Based Access Control and Policy Based Access Control. All those methods require bringing additional context into the decision of access permission granting.
It is important that access can be logged and audited. This is not only for providing an audit trail when things go wrong, but also, today’s SIEM systems can correlate this data to other incoming information and help security staff quickly identify and contain a breach by disabling a given user and terminating all associated sessions near real-time.
The ability to automatically link system local account identifiers to their respective owners during event correlation is a key prerequisite to early detection of suspicious employees, victims, or malicious persons. Enriching events with consistent identity information adds context to audit trails.
With the help of the IAM solution, the SIEM system can correlate all uses of entitlements across systems, which can enable the detection of behavioral anomalies and suspicious patterns around the usage of entitlements, thus potentially exposing a burgeoning breach.
The Least Privilege Principle also dictates that the number of identities and entitlements should be kept as low as practically possible. This means that the IAM implementation should support tracking of all identities/accounts and entitlements in the system at any given time. This entails strict control on the creation of accounts and entitlements, which should be tightly overseen, as well as adhering to processes that would allow administrators to discover entities created outside the legitimate processes. Controlling the process properly can help detect and deal with unauthorized incidents quickly. Jump back to the NotPetya attacks here, and we can appreciate how detection of unauthorized use of existing credentials could have been an early indicator to something going wrong.
Adhering to process would also mean that local accounts are controlled frequently. No “orphan accounts” should be allowed to exist without an owner; it is imperative to use methodologies that can handle built-in and system accounts, and ensure these are assigned an ownership at all times.
In addition to cutting unknown accounts or entitlement which were created in a way that bypassed the IAM processes, there should be automated processes in place to ensure that once legitimately created but now obsolete entitlements and accounts, or those which have become unnecessary due to job role changes, are disabled and cleaned up automatically. This practice can clearly decrease the attack surface where it comes to adversaries abusing existing identities on the network.
What we listed above can be considered fairly standard IAM functionality, however, the emphasis is on the consistent and precise enforcement of these policies to yield reliable detection of deviations and robust automation which is able to execute in real world conditions.
Such robust foundations are needed in order to have measurements and key performance indicators to monitor how the environment evolves over time. To gain objective insight, we suggest tracking some of the following metrics:
- Number of accounts per system/registries (Windows AD, ldap RACF etc.)
- Number of entitlements per system
- Number of entitlement assignments (entitlement to user)
- Usage of entitlements metrics
Metrics should be part of the IAM Governance processes and reviewed regularly. Which metrics to select, and at what interval of reporting, must naturally depend of the actual risk circumstance of the organization and should be established as part of the IT Security Risk Assessment process.
Applying the Least Privilege Principle to identities
In this section, we will propose some guidelines that are not often used in current IAM implementations, to increase and enforce the Least Privilege Principle and reduce the number of attack points in terms of deployed accounts and entitlements.
We will look at users/identities divided into the following groups:
- Standard users – User accounts only used by their respective owners to perform standard business functionality on systems
- Privileged users – User accounts with higher level of access rights used to perform privileged or administrative tasks, either:
- Named privileged users – Privileged user accounts which are assigned to, and only used by one person.
- Shared privileged users – Privileged user accounts used interactively by multiple administrators, not belonging to one particular person (including superuser accounts and shared operator accounts).
- Service users – Technical users not associated with specific people performing services on systems
We recognize that there are other identities in the real world, such as “robotic” users to perform task on behalf of real users, IOT and other devices/machines using API keys etc. However, this writing only discusses the above-mentioned categories and notes that most concerns related to the current subject will also apply for other kinds of users.
We will also emphasize the use of strong authentication schemes such as Multi-factor Authentication (MFA) in a separate section.
One of the central concepts for standard users is to ensure that all standard users have their required entitlements at any given point in time.
This implies putting more focus on ensuring timely provisioning/deprovisioning of entitlement whenever the user’s needs change. It is our recommendation to focus more on time-based access and automated management of entitlements in case of organizational changes rather than relying on regular re-certification campaigns.
Automation is key here. While initially complex, it is a simple matter of statistics: Every time the human element comes into play, the risk of error or malpractice rises exponentially. Furthermore, event driven automation effectively decreases the time window of potential misuse compared to manual re-certification campaigns that are run periodically.
Lifecycle Management of identities is also fundamental here. Processes to ensure on-boarding, and even more importantly, off-boarding (leaving process), should be automated and integrated with trusted authoritative identity sources and processes. Processes must be in place to lock/remove entitlements quickly in case of the risk of a breach. The identity lifecycle management should also be able to detect and trigger changes in access requirements due to job role/organizational changes.
A good practice is to remove business related entitlements when changing job roles for entitlements that are not provisioned automatically in the identity lifecycle management to ensure removal of excessive entitlements.
In some scenarios, we would recommend enforcing strong passwords over frequent password changes. A good and sufficiently strong password can be less likely to be compromised by using brute-force methods if the system does not have any inherent weaknesses that would allow an adversary to exploit a poor implementation. This can mean that systems would have to be evaluated separately, so that passwords should only be changed in case of a suspected breach.
Forcing a person to change a password every three months, means these people will likely use an easy-to-guess series of passwords (e.g. Password01!, Password02!). Hackers know this, and the methodologies for cracking password already take such man-made “password mutations” into account, cracking 80% of any given hash file in less than 2 hours. Long gone, are the days where an attacker had to perform a linear brute-force attack to reap the rewards of a user’s password.
Privileged users are the primary attack vector of any breach due to the associated strong entitlements of these parties. There is no way to completely remove privileged users from systems and applications since there must be a way to access/manage the infrastructure in case of a disaster or unavailability of the IAM systems, but these “break the glass” accounts should be reduced to an absolute minimum, be strongly protected, and not used for any other purpose other than emergencies.
As a general rule, the following considerations can be envisioned when enforcing Least Privilege for privileged users:
- Enforce strong passwords/authentication keys for such special access and keep the passwords unknown until absolutely needed. Wherever possible, avoid passwords and where unavoidable consider a Single Sign-On (SSO) solution that can hide the password from the end-user.
If the user does not know the password, they cannot accidentally expose it. Once the password has been unveiled in a “break the glass” scenario, generate a new one and keep it unknown, analogous to the concept of storing admin passwords in a sealed envelope, locked away in a physical deposit. One can also use a split key which requires the consent of multiple parties (N out of M) to gain privileged access.
- Restrict accounts wherever possible, to least possible privileges (user rights, policies, SUDO restrictions, SUDOer files), avoid using Administrative/root users/privileges wherever possible.
- Except for the exceptional accounts/credentials mentioned above, rely on Just in Time (JIT) provisioning of the privileged accounts to ensure that accounts are always under full control. One may acknowledge that this is not standard functionality in most PAM solutions and may require substantial work. Nonetheless, it can be one of the keystones to help minimize attack vectors.
- Force access through controlled and hardened gateways (e.g. RDP/SSH gateways) for CLI/UI access to the actual systems. Only allow direct access to systems via controlled procedures, preferable with special hardened equipment and under 4-eyes supervision. Put a procedure in place to ensure the integrity of such gateways or equipment. Use file integrity monitoring, trusted computing base or other approaches.
- Provide controlled means of file transfer to and from systems – do not allow files to be stored on gateways where they can be left and later be compromised. Do not allow jump hosts/gateways to store files locally, as this has a tendency to “sand in” over time, with people leaving potentially sensitive information “in transit” inside a temporary directory on the jump host, not cleaning up after themselves. In case this cannot be configured, automate the clean-up of any leftovers upon session termination.
Service accounts with high privileges are another important attack vector to protect. Again, the most important principle is to reduce the privileges to the absolutely necessary – in this case it’s easier as this is rather static and should be compared with a standard user under change control.
In general, the following practices can help limit privilege levels:
- Reduce the permissions of service accounts to the bare minimum possible. Avoid running services as superusers, and do not share service accounts across multiple services.
- No interactive logon permitted for service accounts, ever.
- Restrict service users into jails/sandboxes via chroot, home directory or other mechanism applicable to the target operating system.
- No system/administrator/root/sudo privileges – privileges should be well-defined and static using existing security groups. As services usually have a well-defined set of access requirements, specifically granting these should be manageable and preferable over simply running a service as system/root or with sudo capabilities.
- Avoid passwords if possible or use strong passwords unknown to anybody.
- In cases where setting a password for a service user cannot be avoided, change the password periodically if possible. Consider changing the password as often as practically possible.
- In cases where system components have to use the credentials of service users (application server connects to database via technical user), use a trusted mechanism for centrally stored passwords (password vault). Storing the passwords in configuration files, even if obfuscated, is a risk.
- Service users are rarely configured for account lockout and hidden or forgotten to daily operations, thus a several months’ long brute-force attack could be silently running against a service account, with no repercussions or risk of being detected. Monitoring brute force attempts in tandem with the measures listed above is favorable, and automated responses should be triggered whenever a brute force attack is detected.
Deployment and use of strong authentication
Multi-factor authentication is generally seen as an effective measure to decrease password-related security risks. It has been adopted in one of its simplest forms by a number of enterprises, but traditionally the scope has been restricted to guard external access (i.e. VPN) of technical staff, such as developers and operators. The most common approach in this scenario is the use of disconnected hardware tokens (typically TOTP) as a second authentication factor is addition to the password.
Regardless of the inherent trade-offs in user experience and operational cost overhead, it is strongly encouraged to implement two factor authentication to guard interactive logon activities of IT staff on selected systems, or enable a second factor for VPN access in general as the user population requiring VPN access is typically limited.
While hardware token devices are reasonably secure, they are also expensive and difficult to deploy on a large scale for business applications and standard users, be it employees or clients. Soft tokens, typically running on mobile phones are being increasingly adopted, although inherently less secure than hardware tokens, as they provide a low-cost alternative with reasonably improved user experience (no need for yet another device) and easy enrollment and distribution. In summary, soft tokens seems to be a good choice for decreasing password-related risks in services exposed to a large scale of standard users. This could be a logical next step once core IAM practices have been put in place and privileged users have been addressed.
Although the application of mobile soft tokens is getting increasingly popular with time-based one-time passwords (in particular RFC8238) being the most widely adopted algorithm, it should be noted that other means of mobile phone based second factors exist, with different security implications, benefits and limitations. A systematic analysis and comparison of these methods under a common threat model is beyond the scope of this document, the reader is encouraged to assess and compare the following, fundamentally different mobile authentication concepts:
- Random passcode sent by the application to the user via an independent channel, e.g. in SMS, which the user has to echo. This non-cryptographic protocol provides a low level of security but still enjoys wide adoption across the financial sector in many countries.
- Shared key-based dynamic passcodes, such as TOTP or hash chain based token, which allow offline, disconnected generation and verification can make it a good candidate if both the mobile device and the mobile application are reasonable secured.
- Challenge-response tokens employing asymmetric keys, which require out-of-band communication between the mobile device and the application (e.g. internet, camera)
It is highly recommended to adopt a protocol with strong cryptographic properties, and a particular mobile application which implements the protocol securely and employs additional measures against unauthorized use in case the adversary gets temporary physical access to the mobile device, such as secret or biometry based unlocking, or a remote wipe capability.
Protecting the IAM infrastructure
The infrastructure of the IAM systems needs special attention as breaking the defenses here allows an intruder to obtain as many credential sets as they can. This is essential – implementing an IAM solution is carrying all your eggs in one basket. The benefits, if done right, far outweighs the drawbacks, but it is imperative that the IAM infrastructure is guarded exceptionally well.
It is our recommendation to secure this with a well-known methodology e.g. following the PCI-DSS methodology from the credit card industry in terms of network segmentation and change management. The important points are that all IAM backend servers should reside in a separated segment and all servers in this segment should be regarded and handled like IAM servers following the same strict rules concerning access, maintenance etc.
One of the key elements in PCI, is that if a machine is considered PCI-compliant, then all connected equipment (i.e. on the same network segment) is automatically considered PCI-compliant as well. Translating this to the IAM segmentation means that any system on the same segment would be considered “part of the IAM solution”, thus requiring same strict security policies and change management as the IAM solution itself. This ensures that the organization does not suddenly end up with a less protected development/pre-production server on the same segment, possibly even with some kind of test access to the production environment.
In cases where the production and non-production IAM instances run in separate segments with different security levels, do not load data for testing purposes from the production instance into pre-production servers.
IT hygiene is key
The systems in the IAM segment should be built on hardened and standalone (non-domain) machines. Using Unix/Linux-based operating systems with a proven security record and support can be a good choice here. Administrative accounts should be local and have strong and different passwords.
Access to IAM systems should be performed only by using privileged users through controlled mechanisms as explained in the section about privileged users. Firewalls/Jump hosts to use for access should be restricted to a minimum of ports. IPs should be white-listed. All communications should be strongly encrypted using two-way authentication e.g. mutual SSL.
All communication from IAM infrastructure to the managed (agents/adapters) should follow the same rules as should all internal communication within the IAM segment.
IAM end user interfaces should be protected by having the UI running on separate application servers in a DMZ for this specific purpose, calling the back-end functionality using secure API communications. This is not always a possibility – but if it is, it can lower the risk of compromise through injection attacks by separating the presentation layer from the core model of the IAM application
As mentioned earlier in this writing, this text was written in the aftermath of the NotPetya attack. In it, we wish to exemplify how organizations can bolster their security posture from the inside of their existing systems. We did that by focusing on well-known and existing security principles to the specific area of IAM, emphasizing the Least Privilege Principle, Identity Hygiene, and no lingering accounts (JIT provisioning – if an account does not exist, it cannot be misused). Hence this text is best used as inspiration and for trying to understand the reasoning behind the advice rather than providing a ‘solution’ per se.
There is no silver bullet that can guarantee 100% security, but well-understood and consistently applied multilevel security policies will make it difficult for both targeted and accidental breaches to succeed. Security is constant and hard work, but building the foundations of security through applied methodologies and process systems can help limit the damage of attacks.
About the authors of this article
Tibor is the Lead Security Architect for Central and Eastern Europe within IBM Security. He has more than a decade of hands-on experience in the field of Identity & Access Management and has lead several implementations across Europe. He is an Open CITS certified Distinguished IT Specialist.