James Cowling MIM Privileged Access Management

Overview What is Privileged Access? Why is it important to manage Privileged Access tightly? The consequences of failure

Defining “privileged access” General –Permissions which allow elevation of other accounts to privileged status –Permissions which allow denial of access to other accounts Implementation-specific –Permissions to data or systems whose loss or compromise would be catastrophic –Permissions in systems which are governed by external compliance requirements

What is the problem? Misuse of privileged accounts a primary concern in security –Static passwords, social engineering –Theft of credential token often via Advanced Persistent Threats (APTs) Once privileged accounts are compromised attackers can –Create additional accounts to evade countermeasures –Investigate/compromise security infrastructure to evade countermeasures –Install additional APTs –Exfiltrate and/or destroy data –Exploit data for profit/damage

Case studies Target Sony German Parliament (Bundestag)

What is the damage? Operational –Loss of IT functionality –Effort to remediate Reputation –Lost custom –Brand damage Business –Compromise of confidential plans/designs/campaigns –Damage to current or future business Financial –Lost business –Remediation cost –Regulatory fines Personal - can be career-limiting for IT staff…!

Prevent – Detect – Respond Prevent attacks –Infrastructure security – secure desktops and networks –User education – sensitivity to security issues –Use PAM Detect attacks –Median time to detection: 243 days –Use network monitoring tools such as Advanced Threat Analytics to detect early stages of attack Respond –Deal with the consequences of the attack… –Average cost of clean up: ~$150 per user in system

Response Countermeasures –Identify attack vectors (APTs, compromised accounts and systems) –Coordinated tactical measures to regain control Notification –Regulators –Customers, partners –Law enforcement, legal –Staff Remediation –Recovery (restore services and data) –Security (to prevent recurrence) –Preserve evidence (for law enforcement/insurance/legal/forensics)

Anatomy of an attack Usually a targeted attack –Initial attack on low-privilege account –Reconnaissance and lateral movement to identify and access high-privilege accounts –Privilege escalation via token theft Attack surfaces –User: social engineering, customized attack software, spear-phishing –Lateral Movement: cached privileged credentials repeatedly used to access additional systems to reach admin level –Once at admin level, accounts created to provide long-term access 11 Months 48h 13 Months Preparation Attack Spearphishing Lateral Movement Privilege Escalation Data Exfiltration Detection, Remediation

Defences provided by PAM Just-In-Time Admin (JIT) –Admin users are not permanent members of their admin groups –Users have “candidate” or “temporary” status but no permissions –User must request “elevation” prior to undertaking Admin tasks Option: two factor authentication Option: approval on elevation –Elevated privileges are valid for limited time –Stolen credentials less likely to have elevated privileges Just-Enough-Admin (JEA) –Permissions (and candidate permissions) should enable the task required, no more –Regular review (“attestation” or “re-certification”) of permissions –Stolen credentials less likely to have broad privileges

PAM Architecture: Overview Legacy approaches to administration Just-in-time administration Basic PAM architecture Candidacy and escalation

Legacy: Single domain, paired account Employees with Admin responsibilities have user account and admin accounts in the production domain –The admin account has permanent privileged permissions –Employees should not use their admin accounts for normal activities Advantages of paired accounts –Avoid “drive-by” attacks while they are accessing web-sites –Avoid damage by malicious software encountered by the use of local software or drivers Disadvantages of paired account approach –Attackers may find credentials in workstation credential caches, so admin permissions permanently available to attackers –Involves additional administrative effort and possible licensing cost –Risk of loose policy on admin accounts for “convenience” or “safety” Unchanged passwords over long periods Use of same password for admin and user account Shared admin accounts with known (or written) passwords

Just-in-time administration Users are normally just users, with no privileged permissions Users must escalate their permissions immediately before performing administrative tasks – JIT therefore provides users with their admin permissions just when they are needed Elevated permissions have a time limit (“time-to-live”, TTL) – on expiration, permissions become invalid Outside the escalated period, user is just a user – successful credential theft only grants access to user permissions Users have “candidate” or “temporary” admin status before this escalation –Controlling this candidate status is an important security task –Use monitoring, approvals and attestation to ensure that only appropriate candidates get escalated privileges

PAM architecture CORP is assumed to be compromised –No CORP accounts have admin permissions –We discuss “break glass” accounts later PRIV is a new AD forest established only for PAM use –Single-purpose system: small attack surface –High security via policy and close monitoring CORP trusts PRIV (one-way) –Members of PRIV security groups can have permissions in CORP Bastion PRIV CORP MIM PAM

Bastion PRIV CORP PAM roles and permissions MIM PAM Existing privileged user is represented by a corresponding: –User in PRIV –User object in MIM PAM Each relevant AD (Corp) security group is represented by a corresponding: –PRIV security group –MIM PAM permission group object –MIM PAM role object PRIV groups have SIDHistory (valid in the CORP domain) MIM PAM role references PAM permission group, and candidates (members of the original group) This is the simplest set-up – role objects can reference many permission group objects (of course this requires a reconsideration of permissions and roles) Resource User access is via Security Group SID

Bastion PRIV CORP Escalation Existing privileged user is represented by a corresponding: –User in PRIV –User object in MIM PAM Each relevant AD (Corp) security group is represented by a corresponding: –PRIV security group –MIM PAM permission group object –MIM PAM role object PRIV groups have SIDHistory (valid in the CORP domain) MIM PAM role references PAM permission group, and candidates (members of the original group) This is the simplest set-up – role objects can reference many permission group objects (of course this requires a reconsideration of permissions and roles) MIM PAM Resource PRIV.User access is via PRIV.Security Group SID history

Escalation CORP user no longer a member CORP security group(s) CORP security group no longer used A role can be escalated (a permission cannot) Escalation of a single role gives membership of the PRIV groups that correspond to the associated permission group objects Members of the permission groups have access to the resources in the CORP domain that they used to administer with permanent permissions (because of the trust, and the SID history) Bastion PRIV MIM PAM CORP

Candidacy Before a user can request escalation to be an administrator, they must be a “candidate” for the role in question Typical migration scenario: –All existing users of a group are added as candidates to the PAM role that references the permissions group –This is optional and a matter of policy – perhaps not all existing members will become candidates (and roles may reference many groups) Continuous management of candidacy is a key element of keeping the PAM environment trustworthy High-assurance environments will need to manage candidates purely in the PRIV environment Other environments may allow candidacy decisions to be taken in CORP and transported to PRIV –FIM/MIM (in non-PAM mode) could have a suitable schema extension and be used for candidate self- service –How transported to PRIV?

Escalation approval? Candidacy management is crucial: –Approving new candidates –Ongoing attestation of candidates Some Escalation will be for trusted admins, and they need it 24x7 – so there is no further approval cycle Some delegated admins may only require access when some is able to approve it, and it may be desirable to approve it –Could use the PAM portal (in a “MIM-like” mode) –Portal could send notification to an approver corp user account to say that there are PAM approvals to do (they can log on to PRIV and approve)

“Break glass” accounts If all else fails, you need to be able to access your systems directly, in case PRIV is not available or is compromised “Break glass” accounts are accounts which are only used in such an emergency –For example: account is a permanent enterprise administrator in CORP –Username and password held under physical security which is both secure and tamper-evident (hence “break glass”) If the account is never used, its credentials cannot be stolen remotely Monitoring should be configured to send an alert if this account ever logs in

Demo: PAM user experience Estimated time: 15 minutes

Thank You!

Redmond Summit Sponsors