How to Perform Identity and Access Management

Cybersecurity studies have shown that most security vulnerabilities are associated with highly privileged accounts, which, when compromised, can result in serious security issues such as data loss, data theft confidential data breaches. To make matters worse, these sensitive accounts are sometimes managed poorly because their passwords are shared among multiple users via emails. Sometimes a password is accidently left in code or a configuration file where a perpetrator can get easy access to it. Also, compromised passwords and accounts can be taken over by internal or external malicious users.

To be compliant with programs like FedRAMP Authority to Operate (ATO), meet your customers’ evolving security requirements, and tighten your overall security posture, you need to implement solutions that abstract administrator privileges from application developers and provide it as a service by your product security team. The architecture has to ensure that these services are available to all existing and new platforms, infrastructure and tools via direct and secure interconnection versus going over the public internet to access them. These decisions should be baked into everything that an  organization builds, from new products, services, platforms and most importantly, the interconnection across all of these things. In addition, all existing products have to be properly retrofitted and audited to incorporate these best practices.

Getting there

Without visibility into who has access to administrator accounts, it is impossible to analyze who performed which privileged activity. Also, due to a lack of centralized lifecycle management and governance, these shared accounts often contain high-privileged entitlements. This happens when:

• The process for creating and assigning membership for shared accounts is not well defined and is inconsistent across different infrastructure components like operating systems, databases and others.
• It takes too long to create a shared account and analyze who has access to which accounts.
• A lack of administrative visibility results in shared accounts being overprivileged, allowing all privileged and sensitive activities to be accessible by all users.
• The process of assigning or revocating privileges for users is often manual or non-existent.

We use the following best practices at Equinix to resolve these issues:

Standardize

• Develop standardized processes to create and manage shared accounts and privileges that include requesting and approving access to shared accounts.
• Architect to centralized governance and control for shared accounts across all infrastructure components.

Automate

• Leverage governance identity products to automate a request, approval and access review process for shared account definition and membership.
• Integrate shared account password controls and identify lifecycle processes to automate password changes upon user transfer and termination.
• Externalize membership entitlements to get access to privileged accounts as active directory (AD) groups.

Monitor

• Integrate identity governance, privileged access management (PAM) session recording and password check out event logs to provide analytic reports and dashboards highlighting who performed which privileged activity.
• Integrate logs and events into log management and Security Information Event and Management (SEIM) tools for centralized security event monitoring and user behavior analytics to detect potential fraudulent events.

Centralizing the definition of shared accounts using an identity governance solution enables business owners and IT super administrators to leverage the principle of least privileges in the shared account definitions. The membership and activities performed can then be tracked in identity governance, password vault and privileged user management solutions.

Some of these changes will require additional administrative and security steps to be taken by developers, administrators, deployment and maintenance teams as they focus on building, maintaining, monitoring and running the environment. While it may seem like these steps will slow them down, the minor investment into additional security controls will significantly elevate the security posture of their products and platforms and ensure that customer data is protected. You’ll also recoup your investment in these measures by avoiding costly data breaches. 

Securing different types of accounts

Privileged accounts

First, your architecture for privileged accounts should be based on three tenants:

1. Some multi-factor authentication (MFA) should be involved in overall privileged authentication for human accounts.
2. All activity should be traced back to a user, as opposed to a shared account, so you can identify who used the shared account.
3. The need to have shared accounts should be minimized, as should all password distribution to human beings, the storage of passwords anywhere outside regulatory compliant and hardened password vault systems.

Shared accounts

Any enterprise with a shared services architecture needs to address some kind of privileged access to the operating system.This iswhere shared and vendor-seeded accounts are disabled and eliminated from common privileged use. The users of shared accounts are asked to use their Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) credentials (generally known as network ID) to log on and perform privileged activities.

This approach can be further integrated with hardened privilege activity servers known as “Bastion Hosts” or “Jump Servers” (see diagram below). The users are first expected to perform a MFA login to a Bastion host, using their password and second factor in registered channels. They then need to use their network AD credentials to log on to the system to perform privileged activities.

Vendor seeded accounts

For databases, tools and platforms there are three options for securing non-human, service-oriented accounts that can be used, depending upon the integration architecture. In most cases Option 1 is the preferred option:

Option 1: In this architecture, the use of any and all shared accounts and vendor seeded accounts are restricted. Instead, vault systems are used to first define privilege bundles as “roles.” Then on an as-needed basis, the administrator will “lease” a personal account to perform the administrative activity. Various vault tools provide advanced privileged user management modules, which enable the creation of these temporary leased accounts on the fly. These accounts are assigned designated roles that are created as privileged bundles and only authorized users are allowed to lease them out.

Option 2: In this option, the user is asked to use his/her personal AD and MFA credentials to logon to a hardened system designated as Bastion Host. The privileged activity using shared accounts is only allowed from these hardened servers. This enables the audit and compliance team to leverage log management and SIEM tools to analyze who performed a privileged activity and when it happened.

Option 3: This option, which is quite popular in the industry, is known as Privileged Session Manager (PSM). In this case the user does a MFA logon to the PSM tool that provides a managed session for the privileged account – the managed session could be a Telnet session , a PuTTY or secure shell (SSH) session, a browser, etc. The key here is that all keystrokes are logged and privileged activity moves are recorded and stored for forensics or change management analysis if needed. The user gets the session after being authorized properly; no one other than the tool knows the real passwords of privileged accounts. These solutions, while popular, are expensive and take longer to implement. Also it can become unmanageable to store and safeguard all of the “moves” of privileged activities.

None-human services accounts

There have been many breaches against non-human services accounts that are being used by an application to call another application or to log on to an infrastructure component like database. Perpetrators  use the credentials of these accounts to gain access to private/sensitive information. The most common way to safeguard these accounts is by vaulting their password in a safe. In this case, the “calling application” contacts the vault at run-time and gets the password to the program/process. As per security guidelines, the running program is not supposed to cache, archive or audit the password that it received from the vault, and the overall integration ensures that an attacker cannot obtain these passwords (see diagram below).

Understanding the basic types of accounts for secure identity and access management is an important first step to safeguarding your private assets. That knowledge, coupled with a direct and secure interconnection strategy, which leverages Interconnection Oriented Architecture™ (IOA™) best practices and solutions like Equinix SmartKey™ for deploying security policies and controls, will give you the interconnected platform required to deploy a hardened, security infrastructure.

Learn more by reading the Distributed Security Digital Playbook.

You also may be interested in checking out:

Decentralized Identifiers: Putting You in Charge of Your Identity

3 Best Practices to Enforce Media Data Security with Encryption Key Management Services

Data Privacy Day: 3 Trends to Watch