1 Locating and securing privileged IDs · 1 Locating and securing privileged IDs Managing the User Lifecycle Across On-Premises and Cloud-Hosted Applications Classify high privilege
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
• 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.
• 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.
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.
– 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]