Privileged Access Management (PAM) is one of the most-discussed topics in presentations, tech shows, IT forums, IT groups, blogs, and meetings in the past few years (since 2014) when it comes to identity management. It has become a trending topic, especially after the Windows Server 2016 preview releases. In 2016, I traveled to several cities in several countries and found myself involved in many presentations and discussions about PAM.

First of all, this is not a feature you can enable with a few clicks. It is a combination of many technologies and methodologies that come together and make a workflow or, in other words, way of living for administrators. AD DS 2016 includes features and capabilities supporting PAM in the infrastructure, but it is not the only thing it has. This is one of the greatest challenges I see about this new way of thinking and new way of working: replacing a product is easy, but changing a process is more complicated and challenging.

I started my career with one of the largest North American hosting companies around 2003. I was a systems administrator at that time, and one of my tasks was to identify hacking attempts and prevent workloads becoming compromised. In order to do that, I had to review lots of logs on different systems. But around that time, most attacks from individuals or groups comprised of putting their names on the hacked websites to prove that they could hack them. The average daily number of hacking attempts per server was around 20 to 50. Some colocation customers were even running their websites and workloads without any protection (even when advised against it). But as time went by, year by year, the number of attempts dramatically increased, and we were beginning to talk about hundreds or thousands of attempts per day. The following graph is from the latest Symantec Internet Security Threat Report (2016), and it confirms that the number of web-based attacks have increased by more than 117% since 2014:

Not only have the numbers changed but so has the motive behind the attacks. As I said, in the earlier days, it was script kiddies who were after fame. Later, as users started to use more and more online services, the purpose of attacks changed to financial gain. Attackers started to focus on websites that stored credit card information. In the past 10 years, I had to change my credit card four times as my credit card information was exposed due to hacks on the websites I had used them with. This type of attack still happens in the industry.

When considering the types of threats, after the year 2012, most things changed. Instead of fame or financial gain, attackers started to target identities. In the earlier days, the data about a person was in different formats. For example, when I walked into my medical center 15 years ago, before I saw the doctor, the administrative staff had to go and find the file that had my name. They had a number of racks filled with files and papers, which included patient records, treatment history, test reports, and so on. But now, things have changed: when I walk in, no one in administration needs to worry about my file. The doctor can see all my records from his computer screen with a few clicks. In this way, data has been transformed into digital format. More and more data about people is getting transformed into digital format. In such a healthcare system, I become an identity, and my identity is attached to data and also to certain privileges. Think about your bank--an online banking system. You've got your own username and password to type in when you log in to the portal. So, you have your own identity in the bank system. Once you log in, you can access all your accounts, transfer money, make payments, and so on. The bank has granted some privileges to your identity. With your privileges, you cannot look into your neighbor's bank account. But your bank manager can view your account and your neighbor's account too. This means that the privileges attached to the bank manager's identity are different. The amount of data that can be retrieved from the system depends on identity and privileges.

Not only that, some of these identities are integrated with different systems. Industries use different systems related to their operations. These can be an email system, CMS, or billing system. Each of these systems holds data. To make operations smooth, these systems are integrated with one identity infrastructure, and it provides a single sign-on experience instead of using different identities for each and every application. It's making identities more and more powerful within any system. For an attacker, what is of more worth--focusing on one system or targeting the identity attached to data and privileges on many different systems? Which one would cause more damage? If the target is an identity having highly privileged access to the systems, it's a total disaster, isn't it?

Is it all just about usernames, passwords, and admin accounts? No it's not; identities can cause more damage than that. Usernames and passwords just make it easy. Just think about recent well-known cyber-attacks.

For example, in the Ashley Madison website hack, was it financial value that made it dangerous? No, it was the identities that caused damage to people's lives. The identities were enough to expose names and humiliate people. It ruined families, and children lost parents to divorce. This proves that it's not only about permissions attached to an identity; individual identities themselves are more important in the modern big data phenomenon.

It's only been a few months since the USA presidential elections, and by now, we can see how much news can be generated with a single tweet. It isn't necessary to have special privileges to post a tweet; it is the identity that makes that tweet important. On the other hand, if that Twitter account got hacked and someone posted a fake tweet on behalf of the actual person who owns it, what kind of damage could it cause to the whole world? In order to do so, would one need to hack Jack Dorsey's account? The value of an individual identity is more powerful than Twitter's CEO.

According to the following latest reports, the majority of the information exposed by identity attacks are names, addresses, medical reports, and government identity numbers:

Attacks targeting identities are rising everyday. The following graph shows the number of identities that have been exposed as compared to the total number of incidents:

In December 2015, there were only 11 incidents, and 195 million identities were exposed. This shows how much damage these types of attacks can make.

Each and every time this kind of attack happened, the most common response from engineers were "Those attacks were so sophisticated!", "It was too complex to identify!", "They were so clever!", "It was zero-day attack," and so on. Is that really true?

The Microsoft Security Intelligence Report Volume 21 ( January through June 2016) contains the following graph, which explains the complexity of the vulnerabilities. It clearly shows that a majority of vulnerabilities are still less complex to exploit. High-complexity vulnerabilities still comprise less than 5% of the total vulnerability disclosures. This proves that attackers are still after low-hanging fruit.

Microsoft AD is the leader in identity infrastructure solution providers. In all this constant news about identity breaches, the Microsoft AD name also appears. And people start to question why Microsoft can't fix it. But if you analyze these problems, it's obvious that just providing a technology-rich product is not enough to solve these issues. With each and every new server OS version, Microsoft releases a new AD version. With every release, there are new features to improve identity infrastructure-security. But when I go to work on an AD project, I see the majority of engineers not even following security best practices defined by AD versions released 10 years ago!

Think about a car race: race categories are usually based on engine displacement--3.2 L, 5 L, and so on. In a race, most of the time, it's the same models or the same manufacturer's cars. If it's the same manufacturer, and if they have the same engine capacity, how does one win and the other lose? It's in fact the car's tuning and the driver's skills that decide the winner and loser. If AD DS 2016 can fix all identity threats, that's really good, but simply providing a product or technology hasn't seemed to have worked so far. That's why we need to change the way we think about identity infrastructure-security. We should not forget that we are fighting against human adversaries. The tactics, methods, and approaches they use are changing every day. The products we use do not have such frequent updates, but we can change their ability to execute an attack on the infrastructure by understanding fundamentals and using products, technologies, and workflows to prevent it.

Before we move on to identity-theft prevention mechanisms, let's look into a typical identity infrastructure attack:

The Microsoft tiered administration model is based on three tiers. All these identity attacks start by gaining some kind of access to the identity infrastructure and then move laterally until they have the keys to the kingdom: the Domain or Enterprise Admin credentials. Then, they have full ownership of the entire identity infrastructure.

As the preceding diagram shows, the first step of identity attacks is to get some kind of access to the system. They do not target the Domain Admin or Enterprise Admin account first. Getting access to a typical user account is much easier than a Domain Admin account. All they need is some kind of beachhead. For that, even now, the most common attack technique is to send out a phishing email. It's typical that someone will still fall for that and click on it. Now, they have some sort of access to your identity infrastructure, and the next step is to start moving laterally to gain more privileges. How many of you have completely eliminated local administrator accounts in your infrastructure? I'm sure the answer will be almost none. Users keep asking for software installations and system-level modifications to their systems frequently, and most of the time, engineers end up assigning local administrator privileges. If the compromised account is a local administrator, it becomes extremely easy to move to the next level.

If not, the attacker will make the compromised system misbehave. Who will come to the rescue? It's the super-powered IT help desk people, of course. In lots of organizations, IT help desk engineers are Domain Admins. If not that, they're at least local administrators to systems. So, once they receive the call about a misbehaving computer, they RDP or log in locally using a privileged account. RDP always sends your credentials in plaintext. If the attacker is running a password-harvesting tool, it's extremely easy to capture the credentials. You may wonder how a compromised typical user account can execute such programs. It so happens that Windows OSes do not prevent a user from running any application in their user context. They will not allow a user to change any system-level settings, but they will still allow the user to run scripts or user-level executables:

Once an attacker has gained access to some identity in an organization, the next level of privileges to own will be Tier 1. This is where the application administrator, data administrator, and SaaS application administrator accounts live. In a typical modern-day infrastructure, we have too many administrators. Primarily, we have domain administrators and enterprise administrators, and then we have local administrators. Different applications running on the infrastructure have their own administrators, such as Exchange administrators, SQL administrators, and SharePoint administrators. Other third-party applications, such as CMS and billing portal, may have their own administrators. If you are using cloud services, SaaS applications have another set of administrators. Are we really aware of the activities happening in these accounts? Mostly, engineers only worry about protecting Domain Admin accounts but, at the same time, forget about the other kinds of administrators in the infrastructure. Some of these administrator roles can cause more damage to a business than a Domain Admin. These applications and services decentralize management in the organization. In order to move laterally with privileges, these attackers only need to log in to a machine or server where the administrators log in. Local Security Authority Subsystem Service (LSASS) stores credentials in its memory for active Windows sessions. This avoids the hassle of users entering credentials for each and every service they access. It also stores Kerberos tickets. This allows attackers to perform a pass-the-hash attack and retrieve locally stored credentials. Decentralized management of admin accounts makes this process easier.

Another problem with these types of accounts is once they become service admin accounts, they can eventually become Domain or Enterprise Admin accounts. I have seen engineers create service accounts and, when they can't figure out the exact permissions required for the program, add them to the Domain Admin group as an easy fix. It's not only infrastructure attacks that can expose such credentials. Service admins are attached to the application too, so compromising the application can also expose identities. In such a scenario, it will be easy for attackers to gain the keys to the kingdom:

Tier 0 is where the Domain Admins and Enterprise Admins operate. This is what the ultimate goal of an identity infrastructure attack is; once they obtain access to Tier 0, they own your entire identity infrastructure. The latest reports show that after the initial breach, it takes less than 48 hours to gain Tier 0 privileges. According to the reports, once attackers gain access, it takes up to 7-8 months at least to identify the breach, because once they have the highest privileges, they can make backdoors, clean up logs, and hide forever if needed. The systems we use always treat administrators as trustworthy people. This is no longer in the modern world. How many times do you check systems logs to see what your Domain Admins are doing? Even though engineers look at logs of other users, rarely do any of them check Domain Admin accounts. The same thing applies to an internal security breach too: as I said, most people are good, but you never know. Many high-profile identity attacks have proven this already.

When I have a discussion with engineers and customers about identity infrastructure-security, these are the common comments I hear:

• "We have too many administrator accounts."
• "We do not know how many administrator accounts we've got."
• "We have fast-changing IT teams, so it's hard to manage permissions."
• "We do not have visibility over administrator account activities."
• "If there is an identity infrastructure breach or attempt, how do we identify it?"

The answer to all these issue is PAM. As I said in the beginning, this is not one product; it's a workflow and a new way of working. The main steps and components of this process are as follows:

1. Apply pass-the-hash prevention features to the existing identity infrastructure (Chapter 15, Active Directory Security Best Practices).
2. Install Microsoft Advanced Threat Analytics to monitor the domain controller traffic to identify potential real-time identity infrastructure threats (Chapter 15, Active Directory Security Best Practices).
3. Install and configure Microsoft Identity Manager 2016--this product enables us to manage privilege access to an existing AD forest by providing task-based time-limited privilege access. I will explain this in detail later in this chapter with examples.