Asset management is one of the most fundamental cybersecurity best practices. Regardless of whether the technology is on-premise, in the cloud, or operating in a hybrid environment, understanding and documenting all your assets is critical. After all, you cannot adequately develop a security strategy against threats if you are unaware that an asset exists and needs protection. And in the cloud, even though it may not be your computer or resource, tracking and classifying the asset is crucial. This will help ensure that it does not become a risk from identity management attacks, data governance issues, and the persistence of exploitable vulnerabilities.
While this discussion on asset management could focus on performing an inventory of everything your organization has in the cloud, one form of Cloud Security Asset Management (CSAM) is critical to protecting against cloud attack vectors. Therefore, this asset management discussion will focus on the identities and, specifically, privileged accounts that are crucial to your asset management and cloud security strategy.
Privileged accounts are a key part of the cyberattack chain. These accounts and their credentials are estimated to be involved in at least 80% of breaches, according to Forrester.1 Protecting privileged user accounts and, increasingly, machine accounts (nonhuman accounts) is a key priority for every security-conscious organization. They are also central to addressing many regulatory requirements and enabling zero trust (will get to this discussion a little later as part of a zero trust common office environment strategy). Privileged account access can enable a threat actor to acquire sensitive information, make system changes, manage resources, and even override security controls and erase traces of their actions, depending on the type of privileges obtained.
As enterprises become more complex and decentralized, embrace the cloud, and as more users work from home, the number and diversity of privileged accounts is exponentially expanding. Every cloud asset needs at least one privileged account at some point in its life cycle. Many of these privileged accounts are proliferating unseen, unmonitored, and unmanaged, presenting dangerous backdoors to the environment for threat actors. Asset management is a critical starting point for getting on top of this risk.
While some privileged users are employees, other privileged accounts are associated with contractors, vendors, auditors, or even automated third-party services and nonhumans who are accessing on-premise, in the cloud, or hybrid environments. As a part of any cybersecurity strategy, the most important first step is to perform an asset inventory and, in this case, to ensure that inventory discovers all accounts and their associated privileges. After all, if you do not know what exists in your environment, you cannot design an appropriate strategy to manage and mitigate their risks. This strategy is most effective when the entire cloud environment and the privileges that exist therein are identified and well understood based on function.
Many organizations rely on asset discovery to perform the most basic asset inventory. This technique ideally identifies every asset, active or dormant, in the cloud and provides details on the associated services, accounts, applications (software), configurations, operating systems, etc. This information then helps the organization classify assets and accounts based on sensitivity, data, ownership, geolocation, and potential attack vectors.
While digital discovery is never perfect, and often suffers from some blind spots based on technology limitations, it does help generate the much-needed baseline for organizations. Ongoing discovery then becomes a routine part of the cybersecurity practice of identifying new assets, shadow IT, nonconforming systems, and even assets that should be deprecated, if not managed via automation. With all this information, privileged account asset management in the cloud can begin to take shape.
In this author’s opinion, the best way to embrace asset management of privileged accounts in the cloud is by using a privileged access management (PAM) solution. To start, PAM enables the management and protection of accounts (both human and nonhuman/machine) and their associated privileges throughout an on-premise, hybrid, and cloud environment. Common use cases can include secure storage, rotation, and retrieval of privileged credentials, removing administrative rights, secure session access, and managing secrets used for automation.
- 1.
Perform a discovery and enumerate accounts associated with each asset.
- 2.
Identify your sensitive assets and crown jewels. If possible, identify any asset that stores or processes PII (personally identifiable information).
- 3.
Perform a classification of the account to determine if it is local or directory based.
- 4.
Classify whether the account is interactive or machine based. If the account is interactive, ensure it is not using single-factor authentication.
- 5.
Determine all the privileges associated with each account.
- 6.
Identify all assets, applications, services, scripts, etc. that utilize shared accounts. By definition, a shared account is any account used by multiple identities for authentication.
- 7.
Rate each account in terms of importance based on asset inventory. This will include personally identifiable information, trade secrets, financial information, payroll, etc. The list will vary per company, but the compromise and disclosure of any asset that could cause extreme embarrassment, market or financial stress, or is a “game over” event is typically classified as “critical.”
- 8.
Associate which accounts have access to these resources and place them under privileged access management. The process should continue through your inventory until you have covered every asset and account that you deem important or that is required to mitigate perceived risk. New accounts should always be added, and deprecated assets should have all privileges removed.
- 9.
If possible, remove all excessive privileges and administrative rights.
While many asset management solutions allow you to discover an account, if you do not classify how it is used or the source of the account, then anything you do next is a moot point. A list of accounts, with no relevance nor context, will not provide you with any assessment around impact, should an account be compromised.
While the process we outlined in steps 1–9 has been admittedly simplified for this book, there are a few accounts in particular that pose the most risk to your cloud attack vector mitigation strategy, if they are not discovered and adequately managed.
Domain Administrator Accounts: The most important privileged accounts in your cloud or on-premise environment are ones that have access to virtually any and every asset. These are typically domain administrator accounts. These accounts represent the highest value to a threat actor. Organizations should strive to minimize the number of domain administrator accounts – and who has access to them – and should place all of these accounts under privileged access management.
Nonhuman Automation Accounts: Next, seek out any account associated with an application, operating system, database, service, network device, etc., that is shared among multiple assets to enable functionality. While these generally do not have blanket administrative rights, compromising one asset with the shared account can easily be used for lateral movement. This authenticated “hop” to other assets typically occurs by a threat actor until some form of privileged escalation can occur and the compromise of administrative privileges is achieved. In general, the existence of shared accounts represents a poor security practice. Yet, shared accounts persist because they offer the most workable and convenient way to enable some use cases. Therefore, these accounts should always be identified and placed under privileged access management as well.
Management Solutions: Technology used to manage, monitor, configure, automate, and install/modify a cloud environment – from directory services to security solutions – should never have shared accounts. While this may not always be technically possible, they should always be minimized. Security best practices dictate that access from a user to these solutions should absolutely always have a one-to-one relationship. Therefore, all the accounts used by application, network, security, and operating system administrators should be placed under management. This can ensure the one-to-one relationship is maintained and all access is monitored for appropriate behavior. This encompasses any access that occurs on-premise or in the cloud and any work performed remotely by employees, contractors, vendors, auditors, etc.
Service Accounts: The most under-the-radar accounts in every cloud environment are associated with running services and processes. Service accounts represent the plumbing for applications in a cloud environment and are often assigned credentials that cannot log in locally, yet they can be abused or misused to compromise the operating system or an application. Service accounts are generally a form of shared account that, depending on the application, can be shared on multiple assets in order to operate as a single system. When service accounts are placed under management by a PAM solution, changes (such as for credentials) must be synchronized; otherwise, connected resources will not seamlessly stop and restart their services. This is why attributes are such an important component of discovery. It is imperative to identify all the locations for service accounts and to automatically link shared ones so the accounts can be managed as one group. Otherwise, some accounts could be missed, they could fail to correctly rotate credentials, and new assets that utilize the same service account will not be placed under proper management. Each of these events can contribute to security holes and cascading outages.
Cloud Accounts: When using the cloud to manage your workloads, vendor-specific IAM accounts are created to manage instances, runtime, and resources based on an identity, entitlements, and permissions model. As a discovery function, these accounts should be enumerated across multicloud environments and represented in a common format for risk assessment (principals). By uncovering and onboarding these cloud accounts, you can manage cloud account entitlements and determine when accounts are over-provisioned, stale, or even misused during operations.
Specialty Accounts: Some of the most overlooked types of accounts for discovery and management are specialty accounts that are created on endpoints, locally, to support reimaging, by the help desk, and for other information technology functions. Often, these accounts are created as a local administrator and represent a legitimate backdoor into the host by authorized sources. As you can surmise, these accounts frequently lack unique passwords, or they may have passwords that have been shared between similar devices based on age, geolocation, or owner. As a security best practice, each one of these accounts should have a unique password. Access should be monitored and managed for each device, especially if they communicate with cloud assets, because they can be the initial entry point in an attack, should they become compromised. This represents a unique challenge because on-premise and cloud-based password management solutions are typically unable to establish a network route to a remote host to manage these credentials. This is especially true with work-from-anywhere users. In addition, basic endpoint hardening would prevent any inbound connection that could administer these accounts. Therefore, management of these accounts is typically done with a PAM agent. The discovery functions are performed using the same, or similar, technology to populate an asset management database with the attributes necessary to onboard accounts and ensure that privileged accounts on endpoints do not become the entry point into your environment.
Accounts with Embedded Credentials: There are a myriad reasons why a developer, administrator, or even an application may have credentials embedded in scripts, configuration files, or compiled code. This is typically tied to DevOps automation for Agile development, but best practices may be beyond the control from a development, quality assurance, and automation perspective. The files could be scripts created by any department looking to automate a task (e.g., business logic) or a third-party program that self-compiles code once a credential is set. Many older ERP (enterprise resource planning) solutions suffer from this type of flaw, which highlights why cloud washing is a bad idea. The practice of embedded secrets is well recognized as a high security risk, so it’s important to discover and onboard these credentials for management, if even possible. However, once discovered, secrets and passwords stored in files may need additional automation tools to replace them or to have code recompiled within your PAM solution.
Aside from these important privileged account types, there are a wide variety of other accounts that should be discovered. Security best practices suggest that your environment identify, classify, and rate the risk for each one to determine the sensitivity and prioritization for onboarding and management via continuous monitoring. An automated discovery process can also pinpoint risks related to the password/account attributes that were found in the discovery process, such as passwords that are defaults, reused, or which have not been changed for a long time and have become stale.
Following a proven privileged account asset management plan can help you improve your cloud security posture. By leveraging an asset management database and discovering all your accounts, you can effectively manage this critical threat to your cloud environment. And, as a best practice, the discovery, onboarding, and offboarding of privileged accounts should be an ongoing process that is baked into daily operations.