Archive for the ‘privileged access’ Category

IAM versus PAM: understanding the differences

Tuesday, September 25th, 2018

I frequently talk to people tasked with “securing privileged accounts” who struggle to understand the roles of different product categories — separating identity and access management (IAM) from privileged access management (PAM).

In the interests of clarity, I thought I’d try to clear the air about what these distinct product categories have in common and where they diverge.

First, lets consider what problems we are trying to solve:

  • There is at least one login ID with elevated security privileges (entitlements) on every system and application that one can sign into. This includes hardware — servers, iLO or DRAC cards, desktops, laptops, network devices, etc.; operating systems and hypervisors; applications and databases; on-premises and cloud services and more. If it’s a physical or logical computing system, there is at least one administrative account on it and in almost all cases, this account only supports password-based logins.
  • These accounts are normally shared by multiple people and sometimes also accessed by software processes (scripts and applications). This makes them shared accounts, which leads to accountability problems — who used this account? What did they do? Was their activity appropriate?
  • The passwords to these accounts are static by default and because the accounts are shared, coordinating password changes is difficult. Static passwords represent an elevated security risk, because the window of opportunity for a bad actor to guess or steal the passwords is large.
  • The passwords to these accounts are often stored in plaintext — in scripts, applications, registry entries, configuration files, spreadsheets or printed on paper. Plaintext passwords are a clear security problem.
  • As these accounts represent an elevated security risk, they should be subject to closer scrutiny: are they still required? Do they really need all the entitlements they are assigned? Who owns them?

    High risk accounts that aren’t really needed should be disabled or deleted, to reduce unnecessary risk. Likewise, entitlements that are not actually used should be revoked. Accounts without clear owners are especially vulnerable to abuse, because (a) nobody can make a determination about their continued need or appropriate entitlements and (b) it’s likely that nobody would notice successful compromise of the account in question.

Alright – so what do we do about it? This is where two product categories come into play:

  • Identity and access management (IAM) systems are used to manage the lifecycle of accounts and their entitlements. Specifically, we can use an IAM system to:
    • Create privileged accounts when needed (often this is not necessary as most systems and applications come with these accounts already present).
    • Disable or delete no-longer-needed accounts.
    • Periodically review these accounts and update information such as who owns them or what access rights they have.
  • Privileged access management (PAM) systems are used to control access to the accounts that already exist:
    • Periodically randomize and vault passwords.
    • Identify, authenticate and authorize people before brokering their access to shared accounts. In other words: directory integration to authenticate users, MFA to authenticate users and single sign-on to launch logins.
    • Record and enable search/playback of login sessions, to create strong, forensic-level accountability.
    • Enable scripts and applications to fetch the passwords they use to connect to services in a secure manner, rather than from plaintext local storage.
    • Periodically change the passwords for service accounts, used to launch scheduled jobs, services and other unattended processes.

In other words, IAM systems manage the lifecycle of accounts while PAM systems act as a gate to gain access to the accounts at runtime.

Incidentally, this is why the industry seems to have finally settled on the terminology “privileged access management” and deprecated older terms such as “privileged identity management,” “privileged user management,” or “privileged account management.” These older terms might lead you to think that a PAM system creates and manages accounts, rather than brokers access to existing accounts, which is wrong in most cases.

In some organizations, there are additional differences, because IAM systems have not (yet?) been integrated with privileged accounts. When IAM systems are not used to manage privileged accounts:

  • The IAM system will typically have a few (or even a few hundred) integrations, as compared to thousands of integrations for the PAM system.
  • It is reasonable to onboard managed systems and applications into the IAM application manually, one at a time. This does not scale for PAM systems, where automation is required to onboard thousands of endpoints at once.

IAM systems also have more normal “uptime” requirements than PAM systems. If an IAM system is shut down for a few hours for maintenance, the few people who needed to request access, approve requests, perform reviews or change their own password during that time window can wait a bit or call the help desk. The impact is not catastrophic. On the other hand, if a PAM system goes down for a few hours, the entire IT operation grinds to a halt as nobody can access the accounts they need to do their jobs.

To summarize:

  • IAM systems:
    • Are used to create, update and delete accounts.
    • Grant and revoke entitlements and track account ownership.
    • May only have a modest number of integrations.
    • Can tolerate modest outages without severe business impact.
    • Are always integrated with major systems and applications that thousands of users sign into.
    • May not be integrated with the thousands of bits of hardware and software that only IT staff sign into.
  • PAM systems:
    • Broker access between strongly authenticated and authorized users and already-present high-privilege accounts.
    • Address the problems of static, plaintext passwords.
    • Are used to introduce strong accountability.
    • Require extreme scale, including in how endpoints are onboarded and removed.
    • Cannot tolerate outages.
    • Typically have thousands of integrations.

Organizations don’t get to choose one or the other — IAM or PAM. All organizations need solutions from both categories.

Privileged Access in an IoT world

Tuesday, June 19th, 2018

While it may seem like securing IoT is an abstract problem, in reality it is anything but.

Apparently Tesla (and possibly also SpaceX, separately, a couple of years ago) has been hit by internal sabotage to critical code and possibly other processes.

SC Magazine.

If you thought PAM was purely about administrator access to IT systems, you were wrong. How about PAM access to code check-ins? PAM access to factory control systems? PAM access to sensors (cameras?) and actuators?

This is reality, not theory.

Equifax breach

Friday, September 8th, 2017

The Equifax breach reported this week sets a new bar for exploited PII!

Apparently SSN, name, DoB and in some cases CC data for 143 million Americans was compromised. Given that probably 1/4 of the population has no credit cards (children, the elderly, illegal immigrants, etc.), this means that PII for over half of US card-holders was compromised in a single hack. That’s huge!

What can we learn from this?

First, what not to do? Other firms should learn from Equifax’ mistakes:

  1. Equifax let this happen, presumably by under-investing in IT security. Did they have a privileged access management system? Effective access deactivation processes? Pen testing against apps? Sound firewalls? 2FA? I don’t know, but I bet some of those questions will come back with a “no.”
  2. Equifax discovered the breach on July 29 but disclosed Sep 7. That’s a 40 day delay – disgraceful and probably illegal in some states.
  3. While the Yahoo breach was larger, this one included SSNs and some D/Ls, so the data stolen from Equifax is much more suitable for identity theft. This is bad folks.
  4. There may have been insider trading – three executives sold some stock after the breach was discovered but before it was public. If they knew about the breach, they are risking jail time.
  5. Equifax setup a web site for consumers to check if their information was included in the hack. But apparently you have to waive your right to join a class action lawsuit against Equifax to use it. That’s “sneaky” – except that lots of people caught on, so now it’s just more bad press.

Bottom line: Equifax could well go out of business as a consequence of this event and how badly it was handled. I’d lay at least 50/50 odds that this event kills them within the next few years, as litigation works its way through the courts.

Next, what to do?

  1. Watch your mail for letters from banks or other firms, to see if someone has taken out a loan in your name. Consumers beware, your info is probably compromised!
  2. Stop using name, SSN or DoB as credentials. If someone calls your IT help desk and you need to authenticate them, this data should be assumed to be public and not suitable for authentication.
  3. Lock down your IT systems. You don’t want to be the next victim.

UPDATES:

  1. just saw this:
    Equifax Faces Multibillion-Dollar Lawsuit Over Hack. That didn’t take long!
  2. Krebs lambastes Equifax, noting among other things that the web site to check if you’re affected by the breach appears to be bogus – it just returns a random string, and issues a predictable PIN. He also gives good advice (news to me, as I’m not an American), that you can visit his earlier post to learn how to lock down your credit profile, which should offer some protection against incompetent credit rating agencies combined with identity thieves, at no cost.
  3. It just won’t stop. They were caught with their pants down in Argentina too! admin/admin logins