This is our second in a series of commentaries on minimizing the risk of becoming the next front page news story on data breaches.
Privileged and Shared Accounts are some of the most critical assets to manage in an organization since they provide broad access to systems and sensitive corporate and state information. Privileged Accounts are those that typically allow administration of a system or provide higher levels of access within a system such as Linux/Unix ‘root’ or Oracle Database ‘sys’.
There can be many reasons why a user with access to a privileged account does bad things — they were not given an expected raise, denied a vacation or a promotion, or maybe they disagree with the ethical and moral policies of their employer. Poor password management practices, such as sharing passwords for privileged accounts, or falling prey to smart social hacking is a simple way for others with malicious intentions to gain access to the Keys to the Kingdom. There can also be privileged escalation attacks where a user can gain additional access to a system beyond what he or she has been authorized to have by exploiting a vulnerability in that system.
As we discussed in our last blog entry, most data breaches are caused by events such as employees losing, having stolen, or simply unwittingly misusing, corporate assets. After questioning over 7,000 IT executives and employees across North America and Europe, a recent industry report has found that 31 percent of employees cited simple loss or theft of credentials as the explanation for data breaches they had experienced, ahead of inadvertent misuse by an employee 27 percent of the time. External attacks were mentioned in 25 percent of cases with abuse by malicious insiders at 12 percent. The same selection of causes was cited at much lower levels for business partners.
It is equally important to keep an eye on service accounts associated with test and demo environments. The principle of least privilege is the key — only assign privileges which are necessary for an employee to effectively do their job, and put the necessary controls in place to remove privileges when no longer warranted. Start with the most restrictive state possible and build out from there.
Organizations are struggling to manage a large number of administrative accounts in a secure, efficient, and scalable way. So the problem is how to handle the situation where we only provide access to a privileged account when it’s required to perform a specific task and how do we audit and report on those situations.
Oracle Privileged Account Manager (OPAM)
Fortunately, there are technologies available to protect an organization’s privileged or shared accounts. When coupled with industry best practices, a program can be put in place to ensure that your organization doesn’t become the next headline data breach story.
- Requester raises request for access to certain systems, groups, etc.
- Approver (manager, system owner, etc.) can deny, approve, or delegate request.
- As per the roles and policies configured for this request, OIG will provision appropriate access.
- (Privileged) User will login to the OPAM self-service console and be authenticated for the request.
- OPAM allows the user, for example a database administrator, to use a privileged account by “checking out /check in” a password for a particular enterprise application, operating system, or database server.
- ICF connectors provide out of the box integration with various target systems.
- When session access is granted, a notification (text message or email) can be sent to an OPAM Admin/IT Security admin. OPAM Admin/IT Security admin can keep/terminate the session as appropriate.
The request based flow as depicted above ensures that the proper admin team is notified for the access which the present users have. Policies and roles ensure that the only access granted to a user, is that which they require (as per the principle of least privilege). It is always critical to do a periodic review of the policies and roles that are configured. Sunrise and sunset of accounts and entitlements, access violations and certifications can all be handled by Oracle Identity Manager which will be discussed in a future blog post. The password policies in place here can ensure strong authentication standards are followed. Additionally, the end users don’t need to remember multiple passwords — they actually never have to see the password for these protected, privileged systems.
Default passwords are prone to risks so OPAM is configured to automatically change the password and thereby eliminating the possibility of the password being reused. The system is set to change the password on every check-in, thereby precluding the administrator from reusing the same password again and hence is less prone to sniffing of password of privileged accounts. There may be cases where we need to rollback our privileged account target and in that case OPAM maintains a password history.
OPAM additionally provides session management and auditing capabilities to address various use cases. The OPAM dashboard shows real time status. By creating a single access point to the target resources, OPAM Privileged Session Manager helps administrators to control and monitor all the activities within a privileged session. When session access is granted, a notification can be sent to an auditor. Compliant third-party clients (e.g. Putty, OpenSSH) are supported. OPSM will monitor SSH session activities through keystroke logging and records the input/output for each session into searchable historical records (transcripts) to support forensic analysis and audit data. OPAM leverages an OPAM agent on the target to capture and record user activities into a MPEG-4 encoded video for Windows playback. OPAM audits and logs all operations and provides its own built-in audit reports.
Additional benefits of OPAM are further realized when deployed in conjunction with some of the other capabilities delivered through the Oracle Identity Governance Suite. This integration provides an enterprise with a complete governance solution to support ordinary and privileged users in order to meet compliance requirements. We will go into greater depth in our next blog on how OIG provides a simple and robust solution to fully manage the user life cycle with all essential features to secure enterprise assets.
Abhinav Raina, Amit Kumar and Shashank Kulshreshtha