2. Securing Privileged
Accounts with an Integrated
IDM Solution
Olaf Stullich
Product Manager, Oracle
Mike Laramie
Oracle Cloud for Industry Architecture Team
This is our Safe Harbor statement…Please take a moment to review it…
With Great Power Comes Great Risk Organizations are trying to drive greater productivity out of administrators. In optimal cases today organizations can get 1K to 2K users per administrator ratio. Increasing that ratio is important Most organizations have 100s of service accounts that execute software on servers and web-servers. These accounts if hijacked are a key entry point for fraud Excessive access is also the number one attack vector at the database level. (March 28 2012) http://educationinfree.wordpress.com/2012/03/28/top-10-database-attacks/These accounts are shared across multiple administrators and becomes difficult to monitor who is doing what. Analogous to this problem is the privileged elevation problem where someone uses a privileged account to elevate the privileges of another account, then logs in to the other account and performs malicious activity … very difficult to track.
In most cases the exploits we are seeing exploit Identity and access weaknesses. When hackers break in they are going after password weaknesses – orphaned and dormant accounts. They are using means like phishing etc. They are using accounts that have excessive access in the organization. Most of the data stolen comes from servers – not from last laptops of stolen phones – this is something well within our control. 17% are just misuse of privileges – good people gone bad. 86% of the hacking are lost or stolen credentials – so instituting good behavior on password reset and access review can reduce that number 48% caused by insiders What’s more important is that the hackers are going after our applications and our data – they want to perform transactions that are impactful or financially beneficial … ie give yourself a raise… trade beyond the controls of the organization. They are going after customer information.. Financial information. Its really all about access – Despite all the money we have spent on firewalls and network security we have left the applications vulnerable and we can get better results for our spending if we refocused.In the Forrester Insights 2011 – they noted that companies have spent an inordinate amount of time on perimeter security and have left the applications and data vulnerable. Hence the 48% cause by insiders are not being addressed adequately. Take away : Its about your applications and data Its about access both internal and external. The ORCLE FOCUS IS THAT…..IF WE FOCUS ON CONTROLS THAT IMPACT THE 48% and FOCUS ON THE DATA AND APPS WE CAN REDUCE approx 48% OF THE PROBLEM. APPS AND DATA ARE OUR STRENGTH. – WE HAVE ONE OF THE STRONGEST IDENTITY MANAGEMENT PLATFORMS AND WE HAVE BEEN SECURING DATA FOR A VERY LONG TIME.
Today Managing Privilege Access is Not Well Defined Organizations have a difficult time managing privileged access because the people who have these accounts are the people we rely on to keep the business safe. Organizations take a few approaches Ignore the issue Have help desks handle administrative requests Deploy point solutions for specific systems Largely the problem is ignored and administrative and service accounts are a huge vulnerability The help desk approach hampers productivity administrators have to wait to get access and removing the excessive is a pain to do.The impact is reduced productivity and an approach that does not scale beyond a department level.The problem is that each request is manual and takes a long time t complete There is no visibility across all privileged accessThere is no way to monitor and report on access There is no way to centralize policy control across departments or multiple systems.
Two Big Management Problems Managing privileged accounts presents to big problems which point solutions don’t address well1 Identifying the accounts . they are not just root and sys admin accounts they also include any account where privileges are elevated. They include service accounts and accounts from apps to databases to operating systems to firewalls. 2. Tracking privileged accounts.. we have to have the notion of identity because they are not tied to one person . they can be tied to multiple people and that creates the risk
The Right Approach is Self-Reinforcing By combining the ability to control accounts on multiple platforms along with the workflow automation that can span cross system .. we can get a self-reinforcing and intelligent approach to privilege account management. We call this a platform approach.We can tie multiple identity to a privileged account We can automate the remediation and removal of excessive accessWe can automate the request of access for privileged accounts so there is no lost productivity waitingWe can track when privileges are increased because the platform approach includes the ability to automate provisioning and change controlWe get consolidated auditing And we get visibility across the complete user access which is keyWe can serve multiple systems because the platform has a breadth of target system support
Oracle Provide a Platform Approach to Privileged Account Management Connectors reuse – build on your existing deployment – and reduce overall TCO Centralized policy control Interoperable with the other components including OIM and OIA So what we are providing here is a password checkout system for shared OS, application and database accounts. Today these accounts are the most impactful and because they are shared increases the risk of fraud. With privilege account manager we can lease and account to a user for a period of time and remove the access when the time period as expired.It takes a platform approach leveraging the connectors, workflows, certification and closed loop remediation of OIA and OIMProvides emergency access – and removes access within a given timeframe.With service accounts – we can control the time fo day the account is used etc.
With Fusion Middleware, you can extend and maximize your existing technology investment with the same technologies used in Fusion Applications, including embedded analytics and social collaboration, and mobile and cloud computing. Oracle’s complete SOA platform lets your IT organization rapidly design, assemble, deploy, and manage adaptable business applications and—with Oracle’s business process management tools—even bring the task of modeling business processes directly to the business analysts. Oracle Business Intelligence foundation brings together all your enterprise data sources in a single, easy-to-use solution, delivering consistent insights whether it’s through ad hoc queries and analysis, interactive dashboards, scorecards, OLAP, or reporting. And, your existing enterprise applications can leverage the rich social networking capabilities and content sharing that users have come to expect in consumer software. Oracle Fusion Middleware is based on 100 percent open standards, so you aren’t locked into one deployment model when your business requirements change.
We’ll spend just a few minutes reviewing some common terms relevant to OPAM.A privileged account is….A service account is…really a privileged account, sometimes referred.From an OPAM perspective…An end user is…An administrator is…And finally…Application Accounts are…
The next 4-slides provide a high-level introduction into OPAM…OPAM provides a password vault capability to privileged, service and application accounts…OPAM integrates with DB Security in that it leverages Oracle DB EE as it’s password vault and uses the Transparent Data Encryption (TDE) capability of Advanced Security Options (ASO) to encrypt passwords in the Oracle DB (secure data at Rest)To support customer requirements, OPAM enables declaring a privileged account as exclusive or sharedWhen the account is “shared”, this means……multiple administrators can check-out the account credentials at the same time, e.g. if multiple administrators need to apply patches or run backup jobs…it’s difficult to know “who” was using the privileged account, when reviewing audit logs, etc.When an account is “exclusive” (e.g. not-shared), this means……only one (1) user can check-out the password at any point in time…this provides clarity into “who did what” with a privileged account by matching the check-in/out activity against the native system audit logsWith the next upcoming patchset (11g R2 PS2) we’ll address some of these potential limitation.
In addition to storing the privileged account passwords, OPAM provides controls for managing user access to these passwordsPassword access is available via “grant”…it controls WHICH privileged accounts any given person can access via OPAM…it optionally controls WHEN / HOW a privileged account is accessed by this personGrants are managed within OPAM as Usage Policies.Grants can be “directly-assigned” or can be indirectly assigned via LDAP Group MembershipIt is recommended as a best practice to avoid dual-paths for a user to privileged accounts, since this can lead to non-deterministicBehavior. The indirect-grants via Group Membership provides a familiar and scalable “role-based access control” model for OPAM.The other type of policy within OPAM are Password Policies…these determine the composition of the managed password. …only one Password Policy is defined for any given privileged account; but the PW Policies can be used by multiple accounts…the PW Policy must be at-least as strong as the one on the native system – e.g. database, directory, operating system… multiple password policies can be created, to mimic corporate policies. At this time OPAM cannot “simply” import existing corporate policies an OPAM administrator has to create them.The OPAM Policies and configuration also determine when a privileged account password is changed – e.g. …on check-out…on check-on…or both-- each checkout of a shared account has the same password, however once the last shared account occurs this password will be reset
OPAM supports a wide range of account types including:Generic UNIX Any UNIX/LINUX server with SSHGeneric DatabaseOracle 9-11AnyGeneric LDAPAny LDAP
Here is an example of how OPAM is Interoperable with OIM Request access De-provision access Connector reuse – means that OPAM can use all existing OIM integrations Works with the OIM request catalog – for easy searching and self service request for passwords