Centrify

centrify-logo

As a proud partner of Centrify, LeadThem Consulting offers  services on Centrify’s best of breed, security products like: Centrify Server Suite, Centrify Identity Services, or Centrify Privilege Services.

We know there is no perfect fit, but rather small adjustments that make everything fit perfectly. The same is true when it comes security and we have found that Centrify listens to their clients and makes those key adjustments to create a solution that is the fit organizations are looking for.

Don’t take our word for it, see what Gartner has to say below:

Twelve Best Practices for Privileged Access Management

08 October 2015 | ID:G00277332

Analyst(s):

Anmol Singh, Felix Gaehtgens

Summary

Organizations need to balance significant security risks associated with privileged access against requirements for operational efficiencies. IT operations and security leaders should use this research to learn about best practices for effective and risk-aware privileged access management.

Overview

Key Challenges

  • Management of privileged access is a major challenge for most organizations. Regulators and auditors are increasingly aware of the need to control and monitor access to privileged accounts.
  • Many organizations allow unrestricted and unmonitored use of privileged credentials that are shared among users, and thereby severely limiting the possibility of personal accountability.
  • Many organizations assign full superuser privileges to application developers, DBAs and others, which is an egregious violation of the principle of least privilege.
  • Effective procedures around managing privileged access and shared accounts are cumbersome without specialized tools.
  • A lack of access governance model for privileged accounts in most organizations leads to governance issues, such as accumulation of privileged access, orphaned accounts, ownership conflicts and others.

Recommendations

  • Identify all privileged accounts and their owners in your IT infrastructure. Review business, operational and regulatory requirements to classify these accounts based on the level of risk they present in your environment.
  • Do not allow passwords for privileged accounts to be shared. Establish processes and controls for managing and monitoring the use of shared accounts and their passwords.
  • Grant only the minimum level of privileges required to carry out a task, and limit the time when they can be used whenever possible.
  • Evaluate and implement appropriate PAM tools and compensating controls, including risk-appropriate authentication methods for access to PAM tools.
  • Establish privileged access governance by extending identity governance controls, such as automated provisioning, entitlements cataloguing and access certification, to privileged accounts and administrator access.

Strategic Planning Assumption

By 2018, the inability of organizations to properly scope and contain privileged access will be responsible for up to 60% of insider misuse and data theft incidents, up from more than 40% today.

Introduction

All organizations need to balance expedient operational privileged access to authorized users with security, operational and business risks created by shared and personal accounts with superuser privileges. The distributed and heterogeneous nature of such privileged accounts makes them difficult to manage with a single approach that meets the needs of all organizations. IT organizations are under increased business and regulatory pressure to control access to these accounts. This research outlines best-practice approaches for management of privileged access.

Privileged accounts are broadly classified in three basic categories:

  • Administrative accounts: A nongeneric personal (named) user account that is assigned to an administrative role or assumes elevated privileges in the process, and therefore has access to all standard user and privileged operations.
  • System accounts: These are built into systems or applications, such as root on Unix/Linux systems or Administrator on Windows systems.
  • Operational accounts: This type of account falls into two subcategories and may have elevated privileges:
    • Shared accounts set up to be used for administration and software installation. These accounts were not created for the exclusive use of a particular user, and may be shared by multiple users. They may also include emergency accounts, often known as “firecall” or “break-glass” accounts, used in the event of an emergency that requires privileged access on a temporary basis.
    • Service accounts or application accounts that are used to allow remote (software-to-software) interactions with other systems, or to run system services.

Even when users’ superuser privileges are justified, they are not without risks. Administrators must be discouraged or prevented from using privileged accounts for mundane, non-administrative activities, because even simple typographical errors made when entering commands can cause severe problems. Also, applications such as browsers or email clients are potential vectors for malware; the risk is dramatically exacerbated when those applications are running with administrative privileges.

System administrators are often not the only users who require superuser privileges on a long-term basis. However, other users, who typically include application developers and database administrators (DBAs), require only some of those privileges intermittently. Some organizations handle this procedurally: Any tasks requiring superuser privileges that application developers or DBAs need to perform are handed off to “true” superusers. However, this process can introduce a bottleneck and doesn’t scale well. This often causes non-system-administrator users to receive permanent, full superuser privileges when deemed operationally expedient, violating the principle of least privilege that stipulates that only the minimum privileges should be granted for the duration of a specific task that needs those privileges.

Poorly managed superuser privileges leave organizations exposed to security breaches and regulatory rebukes, which may result in business losses and financial penalties. Granting permanent, full superuser privileges to application developers, DBAs and others unnecessarily exposes mission-critical systems to accidental harm and malicious activity. Even full-time system administrators do not have a continuous need for full superuser privileges. Though often more trusted, such users can still be the root of exposures.

Shared privileged accounts can be indispensable, but they, too, pose a significant risk of accidental and deliberate data compromises. Because a default privileged account — Administrator on Windows, root on Unix, IBMUSER on z/OS RACF, and so on — must be able to log into the “raw” system and must be available for use by a number of people, it’s generally unfeasible to use an authentication method other than native authentication by a legacy password. However, routinely sharing superuser account passwords dramatically increases the risk that a password may become known outside the intended groups. Furthermore, poorly controlled use of shared accounts cannot provide the individual accountability that is a security best practice and demanded by regulatory compliance. Firecall or break-glass accounts used to deal with critical problems outside normal working hours also pose a significant risk where the passwords are managed using fragile manual processes.

Although it is theoretically possible to use manual processes to manage privileged access, in practice it is too cumbersome to do so, and virtually impossible to enforce such practices without specialized privileged access management (PAM) tools. PAM is a set of technologies designed to help organizations address the inherent problems related to privileged accounts. Gartner classifies the available PAM technologies in four main categories:

  • Shared-account password management (SAPM) tools: Control use of (usually privileged) shared accounts
  • Application-to-application password management (AAPM) tools: Control use of (usually privileged) application accounts for programmatic access
  • Superuser privilege management (SUPM) tools: Allow users granular, context-driven and/or time-limited use of superuser privileges
  • Privileged session management (PSM) tools: Manage privileged sessions to target systems and provide detailed privileged activity logging and monitoring

A variety of tools address different aspects of the problem, and we see increased convergence in the market. These tools are discussed in detail in “Market Guide for Privileged Access Management.”

Using most of these tools within effective processes is a best practice. However, the ideal combination of PAM tools varies for different organizations depending on a number of security and operational requirements. Different organizations make different decisions based on working practices, audit requirements and cost constraints. More explicitly, not all organizations can justify implementing multiple tools unless there is a strong need to address all the inherent problems associated with privileged access.

Analysis

Best Practice: Inventory All the Accounts With Privileged Access and Assign Ownership

All the privileged accounts in your IT environment that enjoy privileges beyond that of a standard user should be recorded and accounted for. It is a security best practice to frequently scan your infrastructure to discover any new accounts introduced with excess privileges. This becomes even more important for dynamic environments that change rapidly, such as those using virtualization on a large scale, or hybrid IT environments that include cloud infrastructure. Organizations should consider using auto discovery features offered by many PAM tools to enable automated discovery of unmanaged systems and accounts across the range of infrastructure.

As new privileged accounts are discovered, they need to be onboarded. This usually means that their passwords should automatically be managed by a SAPM tool. Ownership must also be assigned in order to track who is responsible for those accounts. It makes most sense to assign ownership in an indirect manner: Instead of assigning ownership of a privileged account to an individual, ownership should be assigned to a functional role, and this role should be assigned to one or more individuals. Using this approach prevents a high number of orphan accounts if an individual leaves the organization.

Discovering and enrolling application and service accounts is tricky; however, these accounts are sometimes hard-coded (often in clear text) in scripts, application code or configuration files (see ” How to Manage Authentication and Credentials for Software Accounts “).

Best Practice: Shared-Account Passwords Must Not Be Shared

The golden rule is that shared-account passwords must not themselves be shared. Sharing passwords, even among approved users, severely erodes personal accountability; this is a security best practice and demanded by regulatory compliance. It also makes it more likely that passwords will leak to others.

Thus, process and controls must ensure that the password for a shared account is known to only one approved person at any one time. This is much easier said than done, especially when SAPM tools are not used. The best practice is to use those tools in combination with PSM tools to automatically establish a session with single sign-on to avoid having to reveal a shared account password in the first place. In those situations where a password must be revealed, it must be changed after use.

Best Practice: Use Shared Accounts for Sporadic and Contingent Use

Use shared accounts for privileged access whenever named users do not require a regular (nonprivileged) account on that particular system. Exceptions are, for example, software developers who use personal, nonprivileged accounts for their regular development activities, or other users who do regular (nonprivileged) activities. For those users, you can use privilege elevation to allow those users to execute specific commands in a privileged environment.

For all other cases of privileged access, use shared accounts. This includes exceptional out-of-hours support, break-glass scenarios and other contingent use. Organizations should establish a procedure for emergency access or break-glass scenarios where preapproved users acquire adequate administrative rights on impacted systems in response to an incident. Set up custom firecall or break-glass accounts that have sufficient privileges for the purpose. Not all such accounts need to be accounts with superuser privileges — for example, they may only allow a high level of file/dataset access for a group of preidentified users to assess the situation and undertake remedial measures.

Use shared accounts for day-to-day use, too. Custom shared privileged accounts should be set up for day-to-day system administration or for use by application developers and others. Again, it is a best practice to use SAPM tools. Although operational staff often express concern that this will impede their work, SAPM tools are flexible enough to be used with minimum disruption — in fact, when combined with PSM tools, they can really streamline privileged access in a way that saves time and often wins over skeptical system administrators.

Best Practice: Minimize the Number of Personal and Shared Privileged Accounts

Eliminate, or at least drastically reduce the number of users with (permanent, full) superuser privileges to the minimum that is consistent with operational and business needs. Auditors will always find that enterprises have “too many” personal privileged accounts in use, but will rarely suggest what number is acceptable. Migrating to shared privileged accounts is a recommended practice; however, this requires appropriate tools — managing the risks and control issues that arise from use of such accounts is inefficient and complicated without a SAPM tool. There are also some cases where this may not be practical — specifically, in the case of specialized applications that support a set of “administration” capabilities that are typically assigned to a set of users. As long as those applications can provide a usage trail for those administrative users, it may be justifiable to give individual users access that includes administrative privileges to that application.

Minimize the number of shared privileged accounts, too. Even with best-practice processes and controls in place, excessive numbers of accounts amplify residual risks. At the end of the day, organizations must define and be able to defend the number of accounts that yields the best balance between security, operational and business risks.

Best Practice: Limit Scope for Each Privileged Account

Limit the scope across the infrastructure of any privileged account to enforce the principle of least privilege: Each account should have exactly the minimum rights required to carry out a specific task. For example, an account set up for administering an application should not have any system privileges beyond what is needed to make changes to the application’s configuration and to restart the application. On a similar note, avoid enabling accounts on systems where they are not needed. Following the last example, the account set up to administer the particular application must not be enabled on systems where the application is not running.

This also applies to personal privileged accounts — however, keep in mind the recommendations to migrate personal privileged accounts to shared accounts in the long term. Limiting scope reduces the risk of mistakes and malware of malicious intent.

Best Practice: Use Privilege Elevation for Users With Regular (Nonprivileged) Access

Administrators will typically have personal, nonprivileged accounts that they use for their day-to-day work, such as reading email, browsing the Web, accessing corporate applications, creating and reviewing information, and so on. Never assign superuser privileges to these accounts, because these might exacerbate accidental actions or malware that can cause drastic consequences when used in a privileged environment. Instead, use privilege elevation to allow temporary execution of privileged commands.

The following use case exemplifies the use of privilege elevation: A system administrator may have two personal accounts — one for his or her regular (nonprivileged) daytime activities, and another account for privileged operations. One day, the system administrator accidentally starts a browser under the privileged account, and unknowingly introduces malware into the environment that spreads quickly. To remediate this, the organization deploys SUPM tools that allow the temporary execution of privileged commands for those system administrators that are authorized to do so. In that case, the administrator uses his or her personal account to log into a system, and can then use a restricted set of privileged commands, or temporarily elevate the session for a specific purpose and duration in a controlled manner. On a similar scale, execution of dangerous applications (such as browsers or applications with known vulnerabilities) can be denied execution within the privileged context (see “Market Guide for Privileged Access Management” ).

Best Practice: Implement “Separation of Duties” Model to Manage Superuser Administrative Privileges

Enterprises should strongly consider implementing a “separation of duties” (SOD) model to grant and restrict superuser administrative privileges. This model allows splitting up required privileges for a specific task or role among multiple administrators. It also ensures that administrators do not have conflicting permissions, such as executing a system command and manipulating the system logs to tamper with the evidence. SOD controls for privileged access eliminate the possibility of a privileged user carrying out and concealing an illicit action.

Basic SOD controls are essential for enterprises to ensure separation of access privileges between developers, testers and operators on your systems. SUPM tools offer granular command filtering to allow enterprises to restrict superuser access by privilege (for example, database administrator or developer roles) and by scope (for example, development or production systems).

Best Practice: Use Contextual and Risk-Appropriate Authentication Methods for Privileged Access

Protect all privileged access with risk-appropriate authentication methods — typically in the form of multifactor authentication. Higher-assurance methods such as one-time password (OTP) tokens or X.509 smart tokens are popular; however, not all form factors are practical in those cases where privileged access needs to be granted to vendors or other third-party users that require sporadic access. Gartner clients and PAM vendors have indicated that delivering OTPs by phone or via email is a good alternative to physical tokens in these circumstances.

Organizations should also consider using context-aware access controls that make use of certain predefined inputs to dynamically determine the privileged access decision — allow access, deny access or elevate authentication. For example, a privileged session being attempted from an unknown device ID in an undesired location should be immediately terminated, regardless of whether the user authentication was successful. Some contexts can be applied at a more granular level to implement a risk-adaptive approach and determine access to privileged accounts based on the evaluated risk score. For example, a user attempting privileged access to critical systems or sensitive data can be limited to only low-risk operations from specific countries. Enterprise-adaptive access management tools can offer a consistent and risk-appropriate authentication for privileged access. When evaluating PAM products, check for possible integration options.

Another example is the combination of vulnerability management and PAM tools, as in the case of BeyondTrust, which can limit or prevent privileged operations on systems that have known vulnerabilities, or can turn away administrators logging in from unsafe systems.

Best Practice: Establish Processes and Controls for Managing the Use of Shared Accounts

Establish processes and controls for managing shared accounts and their passwords, but be aware that manual processes and controls can be fragile, do not scale well and need careful oversight (see Note 1). Implement SAPM tools (and, optionally, PSM tools) to automate processes, enforce controls and provide an audit trail for individual accountability.

SAPM tools encapsulate an approach often used in enterprise’s manual processes — some of them explicitly using the “password in an envelope in a safe” paradigm typically used for firecall or break-glass accounts — but applying them broadly in an efficient and scalable manner.

SAPM tools have emerged as a best-practice choice for managing shared-account passwords across all sizes of organizations and all vertical industries. These tools are mature, and provide efficient and effective password management for shared superuser (and other) accounts in a robust, controlled and accountable manner, enabling any organization to meet regulatory compliance requirements for restricted access and individual accountability.

Best Practice: Use Default Administrator, Root and Similar Accounts Only in Extreme Circumstances

The default system accounts on different systems and platforms (including network devices) should not be used for routine administration — they should be used only in exceptional circumstances. This best practice addresses operational as well as security risks, such as avoiding or limiting the damage from accidental employee actions or mistakes, which could otherwise have a greater impact if a default system account with full privileges was used.

Best Practice: Monitor and Reconcile All Privileged Access Activity

As in other areas of identity and access management (IAM) and information security, logging, monitoring, reporting and analysis of privileged access activity are essential detective and corrective controls. Monitoring is what proves the effectiveness of the controls used to manage privileged access — and ultimately keeps privileged users honest.

Monitoring privileged access happens through different complementary methods:

  • System logs will record events around the use of privileged access, such as when a privileged user elevates privileges or executes specific commands, or specific system actions (such as restarting a system or application) has occurred.
  • Authentication systems will record sign-on events.
  • Application logs will record specific privileged activity specific to the application.
  • PSM tools have session recording features that range from keystroke logging, screen scraping, full digital-video-recorder-like session recording and playback, up to optical-character-recognition-based session transcription.

We have learned from conversations with several Gartner clients that most organizations store session logs for eventual forensic analysis, but don’t usually review those sessions unless there is an incident to be investigated. Reviewing session logs is not only a good idea, it is necessary to reconcile privileged account activity. Other benefits include learning and propagating good practices and weeding out bad behavior. Organizations should make a point of reviewing privileged activity — at minimum, by matching privileged activity with a risk score and reviewing privileged sessions to sensitive or critical systems — especially privileged activity by third parties.

Most PAM vendors include robust monitoring and reporting capabilities within their offering in the form of a PSM tool, whether as an integrated function of an SAPM or SUPM tool, or as a discrete session monitoring tool. Potential buyers of PAM solutions should evaluate their auditing needs and any use cases related to the investigation of privileged account use, paying close attention to how well each vendor meets those needs in terms of out-of-the-box functionality for data collection, data mining (scheduled and on the fly), and formalized reporting and dashboards. Platform-specific SUPM tools can provide more granular activity data than native syslogs. If the organization already owns, or is planning to deploy, a security information and event management (SIEM) tool, then careful project planning is necessary to avoid duplication of effort or the unintentional creation of unnecessary data silos.

Best Practice: Establish a Privileged Access Governance Model by Extending Identity Governance Controls to Privileged Accounts

Extend identity governance controls to support privileged users and accounts in order to meet an organization’s compliance requirements, such as access certification and auditing users’ access to shared accounts. It becomes increasingly important for organizations to periodically review and validate that privileged users have appropriate access to corporate resources. Organizations should use existing governance controls around self-service access and password reset requests for privileged accounts. They should also consider performing periodic access certification campaigns for privileged accounts to ensure that account owners certify that the account is still needed, that account privileges are scoped properly, and that access to the accounts is properly controlled and monitored. While some PAM tools are beginning to provide governance features of their own, most others offer out-of-box integration with identity governance and administration (IGA) tools to deliver a common access governance model for standard and privileged users (see “Four Account Management Practices That IGA Implementations Must Get Right” ).

Note 1

Processes for Managing the Use of Shared Accounts

Processes for managing shared accounts may differ in detail, but will share a common structure:

  1. Request
  2. Approval — Some organizations that have a formalized change management process, require an approved change request before granting privileged access. For example, many SAPM tools can prompt users to enter a change or incident record number before allowing the use of a shared privileged account, and some allow verification of that record number with the service desk tool.
  • In some cases, privileged access has (at least implicitly) pre-emptive approval:
    • Emergency privileged access out of hours by designated staff (in this case, the request may be implicitly approved, but approvers will be notified afterward to review why emergency access was requested).
  1. Retrieval (or Reset) — There are several possibilities here; for example:
    • A previously set password may be retrieved from an envelope in a safe in the data center under dual control (where two people are required to access a password)
    • A system administrator enables the shared account and resets the password
  2. Use
  3. Closure — Once the immediate need has been met and the shared account is no longer needed, the account is disabled and the password is reset. If the envelope-in-a-safe model is used, an administrator must write down the new password, put it in an envelope and send it to the data center, where it is stored in a safe. For out-of-hours use, formal management approval must be sought and recorded retrospectively.
  4. Logging — All steps must be logged, preferably using session recording.

Manual processes are cumbersome and have several problems:

  • Administrators who set passwords know passwords, and could use the password again or disclose it to others.
  • Passwords in envelopes might be discovered en route to or in the safe.
  • Disabling the account or changing the password after use may be overlooked.
  • Accountability is dependent on manual logging, which may be overlooked.
  • They need significant oversight.
  • They are unsuited to geographically distributed users and systems.
  • They do not scale well.
  • They are unsuited to shared superuser accounts used for normal operations, as noted above. (It is common for administrators to flout the rules in the name of efficiency, leading to passwords being known to everyone in the appropriate group and changed only infrequently.)

© 2015 Gartner, Inc. and/or its affiliates. All rights reserved.

As you can see, we only associate ourselves with companies that will bring the best software solutions available for our clients as they expect the best from LeadThem. Please feel free to contact us to discuss your current needs and how we may meet them with our solutions like Centrify.

logos

LeadThem Consulting
20418 SE Hwy 212
Damascus, OR 97089