1 Locating and securing privileged IDs · 1 Locating and securing privileged IDs Managing the User...

1 Locating and securing privileged IDs

Managing the User LifecycleAcross On-Premises andCloud-Hosted Applications

Classify high privilege accounts, guidance for where they are found and best practices forsecuring access.

Idan ShohamHitachi ID Systems2018-06-04

2 What are privileged IDs and why do we care?

• Login accounts with higher access rights than most users.• Appear on infrastructure as well as systems "regular" users normally sign into (DBs, network

devices, etc.).• Misuse or abuse can lead to major damage:

– dd if=/dev/random of=/dev/sdb– drop table ...– format c:– rsync -avz /data/confidential [email protected]– void main() { for(;;) fork(); }

• Compromise of privileged credentials or login sessions is the #1 tool for attackers.

© 2019 Hitachi ID Systems, Inc. All rights reserved. 1

http://Hitachi.com/

Slide Presentation

3 Types of privileged accounts

Shared Administrative Embedded Service

Definition: • Interactive loginsused by humans.

• Client tools:PuTTY, RDP, SQLStudio, etc.

• May be used at aphysical console.

• One applicationconnects toanother.

• DB logins, webservices, etc.

• Run serviceprograms withadmin or limitedrights.

• Windows requires apassword.

• Scheduled tasks,IIS, DCOM, SCM,etc.

Challenges: • Access control.• Audit/accountability.• Single sign-on.• Session capture.

• Authenticating appsprior to passworddisclosure.

• Caching, keymanagement.

• Avoiding serviceinterruption.

• Restart service ifreq’d.

4 Shared administrator accounts


Slide Presentation

4.1 Windows and AD

4.2 Details and impact

Privileged accounts Potential impact

• Examples on Windows/local SAM:

– Any account with a SID ending in-500 (local admin)

– Any local group with a SID ending in-544 (local admins)

• Examples on AD:

– Any domain group with a SID endingin -512 (domain admins)

– Any domain group with a SID endingin -518 (domain schema admins)

• Basically local and domain accounts andgroups.

• Watch the SID, not the name.

• Copy / delete filesystems.• Edit / destroy directories or schema.• Add / remove / elevate rights for users.


Slide Presentation

4.3 Unix/Linux

4.4 Details and impact

Privileged accounts Potential impact

• Any user with uid=0.• Users directly mentioned in /etc/sudoers.• Users with memberships in groups that

appear in /etc/sudoers.• Don’t forget LDAP, NIS, NIS+ or AD

integration – the user or account may beelsewhere.

• Copy / delete filesystems.• Knock one or more systems off-line.• Interfere with critical infrastructure.• Add / remove / elevate rights for users.


Slide Presentation

4.5 SQL Server / Databases

4.6 SAP / Applications


Slide Presentation

4.7 Cisco / Network devices

4.8 VMWare/vSphere


Slide Presentation

4.9 AWS / IaaS

5 Embedded accounts

5.1 Embedded, static passwords


Slide Presentation

5.2 Eliminating embedded passwords is hard

Stored on client Transmitted to server

• Assume we’re going to replace embeddedpasswords with an API call:

– Sign into credential vault.– Retrieve current password.– Password is periodically changed.

• How does the application sign into thevault API?

– Password? We haven’t solvedanything.

– PKI? Cert unlocked by a password.– Token, smart card or biometric?

Designed for humans.

• What happens if the vault API is busy?Offline?

• Depends entirely on the protocolssupported by the service.

• Plaintext? Too bad!• IPv6 crypto? IPSec? VPN?

6 Windows service accounts

6.1 Windows service accounts

• On most operating systems, services can run in the security context of a named user.• On Windows the part of the OS that launches the service needs to know the account’s password as

well.• Some services run as Local System, Local Service or Network Service – no real ID, no password.• For other services, there is either a local or domain account, which has been assigned (lesser)

privileges.• The password for this account exists in at least two places: SCM, IIS, Scheduler, etc. and SAM or

AD.• Static / plaintext passwords are a risk as elsewhere.• Managing these passwords is complex and risky:

– Change the password but fail to update SCM, etc.: → SCHEDULE A FAULT.

7 Problem summary


Slide Presentation

7.1 High privilege IDs everywhere

What are they? Where are they? Why worry?

• IDs with high accessrights.

• Used by admins toinstall, configure, fixsystems.

• Used to launch services,especially on Windows.

• Used by one app toconnect to another.

• Every IT asset.• User devices: laptops,

desktops.• Network equipment:

routers, switches, loadbalancers, ...

• Hypervisors bothon-premises and cloud.

• Physical servers (iLOcards, etc.) and virtual.

• Apps and databases.• IoT endpoints and

control systems.

• Most orgs have moreprivileged IDs thanpeople.

• More dangerous,pervasive andheterogeneous thanpersonal logins.

• Do we even know wherethey all are?

• If we don’t find / fix them,the bad guys will do it forus.

8 Remediation

8.1 Basic approach

Static passwords are bad. → Periodically change them to random strings.

Nobody can remember randomizedpasswords.

→ Store them in a vault.

Systems and backup media could becompromised.

→ Encrypt the credential vault.

Need to control who can use privileged IDs. → Identify users via the directory, incorporatemulti-factor authentication, enforce robustauthorization rules.

Need accountability for admin changes. → Audit requests, approvals, login sessions.Record activity for forensic audits.

Now all the keys are in a single "basket". → Replicate vault across two or moreservers/databases.

If there is a disaster, we’d have to recover thevault before working on anything else.

→ Geographically distributed, active-activearchitecture.


Slide Presentation

8.2 Scaling up

This will take a while... → PAM should be organized as a program, withregular expansion of integration andfunctionality. This is not a "fire and forget"implementation project.

Large number of systems, accounts tomanage.

→ Automate discovery, classification wherepossible. Delegate onboarding to entire ITorganization for the rest.

Laptops move around – hard to integrate. → Roll out a local agent that calls home.

Hypervisors, IaaS – systems are onboardedand deactivated very quickly.

→ Install PAM agents on template VMs. CallPAM onboarding/offboarding APIs fromorchestration layer.

8.3 Non-human accounts

Lots of Windows services running underservice accounts.

→ Automate discovery, human classification,scheduled randomization and fault-tolerantpassword injection.

Scripts and applications with embeddedpasswords, source code available.

→ Modify to call a PAM API to fetch credentials.API fingerprints apps as authentication, priorto granting credentials.

Applications with embedded passwords,source code not available, vendor won’tmodify.

→ Have PAM inject new password values whereapp retrieves them (registry, configurationfile, etc.).

9 Planning ahead


Slide Presentation

9.1 Incremental delivery

• Deliver early, deliver often.• Basic PAM system:

– Fault tolerance.– Geographically distributed.– Strongly authenticated.– Pre-approved and one time request/approval authorization.– Robust audit.

• Start with AD accounts.• Expand to Windows-local, Unix/Linux, databases, network devices.• Return to Windows: service account passwords.• Add system-to-system (embedded) passwords.• Add session recording/search/playback.• User devices (laptops, desktops).• Integrate with on-premises or cloud-hosted hypervisors.• Periodic upgrades.• There will always be a next phase.

9.2 User adoption

• You have to get users of privileged accounts to cooperate.• Don’t forget: you are taking away their cherished administrative credentials!• Give back:

– Single sign-on to multiple systems, accounts, sessions after one authentication into the PAMsystem.

– Better collaboration: see who else is working on a given system.– Plausible deniability: "I didn’t break that!"– Simplified troubleshooting: "Who did break that?"– Multi-account check-outs, plus have PAM run commands across multiple systems at once.– Quicker approval for one-time access (manager can approve 24x7 from their smart phone).– Easier, more accountable vendor access.

10 Questions

• Hitachi ID has a booth in the vendor expo.• Come for a demo of Hitachi ID Privileged Access Manager.

hitachi-id.com

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 E-Mail: [email protected]

Date: 2019-01-21 | 2019-01-21 File: PRCS:pres

https://Hitachi-ID.com

1 Locating and securing privileged IDs · 1 Locating and securing privileged IDs Managing the User...

Documents

Transcript of 1 Locating and securing privileged IDs · 1 Locating and securing privileged IDs Managing the User...