Over the past few months, we have seen widespread attacks such as NotPetya and WannaCry cripple organizations at record scale and speed, either for monetary gain or with the sole purpose of causing destruction. In their wake, many professionals are assessing what these new threats mean for their security strategies, infrastructures and policies. As a point of entry and a means of fast propagation, stolen credentials play a key role in these attacks, so an important part of this thought exercise is the identity and access management (IAM) program.

Security Specialists Share Identity and Access Management Best Practices

IBM security specialists Franz Wolfhagen, Rune Espensen and Tibor Bősze are keenly aware of the importance of IAM in the prevention of these events and the limitation of the damage they can cause. These experts detailed their recommendations in a paper titled, “Identity and Access Management (IAM) in the Aftermath of NotPetya,” which I found so helpful that I asked them to sit down for an interview to delve deeper into some key points.

Question: There are many different types of threats that keep chief information security officers (CISOs) up at night. Why do you want to talk about ransomware in particular?

Rune: I have noticed that ransomware attacks tend to follow a certain pattern in how they work and the level of destruction they cause. I also believe that the motive behind ransomware, which is generally financial gain, will have much more widespread appeal in the future than a pure malicious and destructive worm like NotPetya. And even NotPetya, which had other motives, had inner workings similar to ransomware. It was purposefully disguised as such, probably in an attempt to control the media narrative, and it worked. So I believe that the evolution of ransomware and ransomware-like attacks is cause for concern because of the severity and potential popularity of this attack style.

Read the complete paper: Identity and Access Management in the Aftermath of NotPetya

What common IAM practices can increase the risk of suffering a large-scale attack?

Tibor: I believe that one of the most common practices that weaken organizations’ security is to give too much access to users in general for the sake of simplicity. More access rights are granted to users than they need to perform their job. This way, if the users’ needs change, business isn’t slowed down. This means that at any given time, the potential attack vector for a hacker is broader than it needs to be.

Franz: This trend is particularly dangerous when it comes to privileged accounts. Many security administrators are performing their privileged duties across all domains and are not separating that access from their day-to-day work. Many administrative accounts automatically become domain administrators across all servers and domains without requiring different credentials for different domains. One key to open all the locks results in attacks being able to propagate quickly throughout a network with only one set of compromised credentials.

Rune: The most fun assignments, as a white-hat hacker, are those where you get free reins to hack a client by any means necessary. One of the primary focus areas for me is always to gain credentials, either by exploiting vulnerabilities, technical or in configuration/processes, or by simply going after the human element. Getting my hands on the right set of credentials can basically give me ownership of an entire organization.

Think about that for a moment: One set of credentials, and I can shut down your company. Without going into the business implications of placing so much power and responsibility in the hands of single entities, the dangers of them being compromised are clear. This is why segmentation is key.

In IAM, this translates into separation of duties, principles of least privilege and a limited lifespan for any given credential. If the credentials are limited to just one task or only exist for 30 minutes to perform a specific task before being deprovisioned again, you have severely handicapped me, and I can start over with very minimal damage done to your organization.

[onespot-mobile-content]

Now that organizations are facing the threat of faster, more complex and larger-scale attacks, do they need to change the way they think about IAM?

Franz: We need to change the mindset from giving excessive access rights for convenience to saying that the principle of least privilege is going to take precedence. This will help ensure that each account is protected properly, in turn narrowing the attack vector for potential hackers.

Tibor: Franz’s recommendation isn’t a new approach. It’s really going back to the roots and ensuring that the IAM program is built upon a solid foundation that is properly executed. Least privilege is a common principle that experienced IAM practitioners all know. Instead of trying to add additional layers on top of their IAM programs, organizations should first make sure that their foundational IAM procedures are properly executed.

Rune: Unfortunately, we often face a tug-of-war with clients between us wanting to atomize accesses and them wanting to group it up in huge chunks for easier maintenance. I think it stems from the fear of maintaining too many accesses and losing oversight, which is a valid fear. However, recent months have reiterated the importance of this and, if done right, it does not have to become a burden. Security must come before convenience, but it does not have to be a limiter or hindrance for business.

Why is it important to differentiate between standard, service and privileged users?

Rune: The standard user, while often the first breach (simply due to their typical multitude, compared with the more golden sets of credentials), is usually only a transit account for a hacker to move laterally. Once more interesting accounts have been revealed, it is left behind. A typical use case would be to hack a standard user, use Mimikatz on his system, grab some domain admin credentials and move on. The service user is often forgotten: Install a product, set up a user and this guy will exist in a given environment for 10 years, usually with the same password and system access privileges. Finally, the privileged user is a prime target, for obvious reasons. It feels like home logging into a client’s system with domain admin!

So there are distinct patterns separating these users, thus distinct ways to handle them. The standard user can be severely limited to perform just the tasks he is supposed to. The service user needs to be monitored and automated. They will be forgotten — make sure the system is not forgetting them too. Privileged users should be very tightly controlled and preferably transient in nature. It should not be day-to-day business to log in with an admin account. When I dump credentials from any random server, it is not uncommon to get credentials from at least a few administrators still in cache on that system. Wouldn’t it be lovely if those credentials were already deprovisioned once I get my hands on them? You can’t do that with standard users, or you’d severely disrupt business. Hence the need to look at each type and set up very specific processes for each of them.

Tibor: If you look at the activities and usage patterns of these accounts, they are fundamentally different. Standard and privileged user accounts are subject to interactive login patterns, and the time lags you see between login and action in the accounts that are consistent with a human navigating through an application. Service accounts are automated and used by programs, so when they are used in an interactive way, you can flag that they are suspicious and probably not being used for legitimate purposes.

What IAM functions are key to preventing these attacks?

Franz: Two functions we discuss in our paper are multifactor authentication (MFA) and just-in-time provisioning (JIT). MFA helps reduce the risk of an illegitimate user being able to log in to an account with stolen credentials. As you cannot misuse an account that isn’t there, JIT helps reduce the number of accounts that exist in a system. This helps limit the chances of human error in not setting the right passwords or other actions that could compromise an account and give a hacker access to critical systems and domains.

Tibor: It is also important to decrease the time span that an account exists or the existence of access rights tied to an account to just the amount of time the user needs to fulfill its purpose.

Rune: There are several levels of MFA, but even the most basic method of sending an SMS, while not recommended as a totally secure solution, will go a long way to prevent misuse as it does take some extra effort to intercept a text message. Single sign-on solutions, where the user never knows his own password, allow for easy implementation of best practices such as very long passwords with high entropy. This also means that a user can never, intentionally or unintentionally, share his password.

Cybercriminals going after privileged credentials can target the IAM infrastructure itself to reach their goals. How can organizations protect themselves?

Franz: By limiting privileged credentials to the bare minimums. It is very important that the different domains be separated with no shared credentials across the domain boundaries because that’s what kills the system totally. If you cannot go from one domain to another seamlessly, then the attack is much more difficult because you need to find the credentials in each domain. This becomes time-consuming, and an attack can’t worm itself through an organization as effectively.

Tibor: If someone is compromising the IAM stack, forget the keys to the kingdom — they have the whole keychain! So while the IAM platform is a special IT system, it is like any other in some respects. Users are still able to log in to it to take some action. Therefore, it is important to follow the exact same measures and strict execution of policies.

Rune: Segmentation, segmentation and segmentation. Like any other IT system, this should be protected well. It’s easy to say, and that is where things often go wrong. How well is well? In the case of IAM, it has to be very well. But think of the benefits: Rather than maintaining secure policies for users and access rights on all systems in the organization, you can leave all that up to the IAM platform and focus on doing a damn fine job on the IAM system.

Next to that, consider your IAM an island: Never intermix the IAM platform with anything else. Create a specific IAM scope, and anything directly connected to this platform, logically, is considered in the same scope. Only a very few tightly controlled paths should exist in and out of this scope: Outbound connections from IAM to the provisioned platforms and, preferably, keep the graphical user interface (GUI) in a demilitarized zone (DMZ), leaving only the IAM provision application program interface (API) between the GUI and the IAM back end open. Secure that with all the bells and whistles. Run at least biannual penetration tests or whenever system changes mandate it. It should be able to stand up to continuous attacks from experienced hackers.

Tibor: One particular area where it’s important to be careful is in working from the test to the production environment. Real, nonobfuscated production data should not be used in a testing environment because those tend to be less secure. The test environment should use test data that resembles real data in its complexity so the tests are representative of what you would find in production, but it shouldn’t be possible to derive production data from test data. We recommend some sort of automated generation of test data, scrambled or obfuscated, or even generating testing data from scratch. There are solutions that are able to do that.

Don’t Make It Easy for Identity Thieves

As Franz, Rune and Tibor highlighted, focusing on key IAM security principles such as least privilege, concentrating extra security efforts on privileged or service user accounts and properly isolating IAM production environments can help organizations bolster their security posture from within their existing systems. While it is impossible to eliminate the risk of targeted attacks or accidental breaches, implementing these policies can make it much harder for them to succeed.

Read the paper: Identity and Access Management in the Aftermath of NotPetya