Background

Early adopters of shared account password management  (SAPM) solutions have discovered that a single strategy (e.g. password-driven) does not provide the assurance for modern IT infrastructure.  Despite the quick way some audit comments can be mitigated with a shared password solution, when you explore the modern enterprise, there are many issues and opportunities for improvement.  In this article, we'll discuss the challenges with vaults, and how with Centrify we can either compensate, enhance or consolidate security capabilities.

The idea is to explore each topic, and propose and demonstrate a scenario, provide recommendations and use an example with Centrify Infrastructure Services. 

You can also use this series to explore the capabilities of Centrify Privilege Service (a.k.a Centrify's vault)

The Traditional Password-Driven PIM Design and its Challenges

The illustration above provides a generic diagram for a password-driven PIM design; the whole premise of this design was that if you can control access to the password of a shared privileged account, provide secure access services (like terminal/desktop transport, auditing and recording) all via the vault and centralize access via a portal, then the issue could be resolved.  In time, many issues were observed:

• "Productivity-driven" abuse:  when vault users suddenly "camp" (check out credentials for a long time), lobby for multi-checkouts, "try to go around" the vault when they can.
• Deferment of identity or privilege consolidation:   very prevalent on the UNIX/Linux world, suddenly it was OK to continue with identity duplication in /etc/passwd, /etc/group accounts as well as managing and maintaining sudoers file configurations.  This was also influenced by the advent of DevOps solutions that make configuration management much easier.
• Challenges for security practicioners:  Due to all the moving parts, it is hard to prove the effectiveness of these controls; there are many moving parts, and not enough compensating controls at each critical area.
• Identity duplication:  The "vault" over time became another identity silo, especially if the design implied that all the local passwords for privileged accounts (e.g. root, administrator, etc) along with the user's "administrative, or -a" account was also living there.  This means that rather than eliminate the problem of "too many passwords" we decided to embrace it and get a tool to manage the issue.
• Did not solve the issues faced by most enterprises:  Modern enterprises need flexibility and productivity, there are challenges with Filers, client-server applications, high-frequency transaction and other scenarios where this solution set does not provide a solution or simply does not scale well.  There are enterprises that have solved the problem of centralization, but simply chose the wrong infrastructure; and they want to come to Active Directory for more than just authentication.
• Did not survive the test of time:  Although credential password management is one of the fundamental tools to mitigate security breaches, the goal is to achieve security assurance as threats evolve as well.  A key example is that this model does not solve issues like PTH in Windows or works well in multi-private/public cloud scenarios.
• It's not really protecting the target systems:  This is perhaps the biggest flaw of this design.  All it's doing it's securing a privileged account password; if the system is compromised, there's no active software locally to provide assurance.

Framework

These articles will cover how Centrify Infrastructure Services addresses many of the issues outlined above, from identity consolidation to auditing and monitoring, across different platforms, however we'll do it maintaining our Identity Maturity model:

 Series Content

• Identity consolidation as a way to avoid vault-bypassing and to maintain assurance
  • Maintains productivity
  • Promotes centralized administration
  • Eliminates friction to adopt other identity-driven controls (like MFA or Risk-based access control)
  • Maintains flexibility for different types of enterprise challenges and apps
• MFA across multiple contexts and use cases to provide identity assurance
  • At login (portal and system)
  • When using a shared account with secure access
  • When checking-ount a password 
  • When elevating privileges
  • When accessing a legacy platform
• Securing the target systems with Centrify Zones
  • Using Centrify Local Account Management as a temporary phase
  • On the target system (UNIX, Linux or Windows)
  • Enforcing least access and least privilege
  • Embracing temporary access controls
• Demonstrating the efectiveness of the controls
  • Monitoring (easy security operations integrations)
  • Attestation (portal, system)
  • Auditability and reportability (portal, systems)
• Automation, DevOps and Operations
  • Components required
  • How processes are affected
  • Using an ITSM Solution to consolidate access requests

Combining Shared Accounts with Least Privilege

Article format

In each article, we'll try to define a challenge and illustrate the different ways Centrify can compenate or enhance the challenged caused by the Password-driven design.  We'll try to use existing articles when possible to reference past Tech Blogs.  As we add articles to this series, we'll list them below.

Articles

• How to check out passwords from the CLI using Centrify Infrastructure Services