Cybersecurity starts with one major principle: “You cannot protect what you don’t know”. This is true for assets like endpoints, servers, etc., but it also applies to accounts. Ask yourself these questions right now: do you know which accounts exist in your environment, and do you know what they do in your network? On top of that, do you control what these accounts do, and how do you manage security enforcement on them?
In recent posts, we’ve discussed the different risks that human and non-human identities (NHIs) bring to an organization. In this blog, we will focus on the challenge of scaling the management and protection of a large amount of NHIs in an environment, by leveraging automation and security policies. We’ll discover why automating service account security is essential for enterprises to enhance protection, streamline management, and reduce risk.
Protecting Non-Human Identities
When discussing accounts, it’s not just about user accounts that represent human users but also non-human identities.
User accounts are, on the face of it, easy to manage, as they belong to a real-life person that uses the account to authenticate to services and resources. Additional security layers can be added to the account, like password rotation policies, account lockout thresholds, MFA validation, etc.
A Non-Human Identity (NHI) is a general term to describe an account used by a machine, (or application, service, automation, etc.) to perform non-interactive authentication in which no human user is involved. We refer to these as service accounts (Active Directory) or service principle (Entra ID).
Although service accounts tend to have a distinct usage pattern, limiting their security posture brings its own challenges. Every service running in the organization might need one or more service accounts, so protection needs to be at scale.
Protecting service accounts boils down to a few key aspects:
- Visibility: do you have a clear overview of all accounts?
- Purpose: do you know why they exist in the environment?
- Behavior: can you verify and validate usage?
- Privileges: can you validate and guard the permissions of an account?
- Attack Detection: can you protect against specific service account-based attacks?
- Security management: do you have clear protection capabilities for all your accounts?
A step back in time: Managed Service Accounts
Managed Service Accounts (MSAs) are specialized managed domain accounts in Active Directory designed to provide a higher level of security, such as automated password management and simplified service account management. Standalone Managed Service Accounts (sMSAs) are used for individual services on a single server and cannot be shared across multiple servers. Group Managed Service Accounts (gMSAs), on the other hand, are designed for use by multiple servers in an environment, such as when a service is provided through a load balancer.
Overall, gMSAs enhance security, simplify account management, and reduce the operational complexity associated with service accounts in enterprise environments. However, not all service accounts are suitable to be MSAs, and managing MSAs can pose challenges, such as ensuring correct application configurations and understanding domain prerequisites. Many of the challenges of managing regular service accounts also apply to MSAs, including several attack techniques. So, there is room for further enhancements that identity teams and security teams could benefit from.
Challenge of Automating and Scaling Service Account Protection
When embarking on the quest to have complete control over your service accounts’ activities and protection, too often and quickly a new challenge arises: how do you properly manage these accounts?
Here are the key challenges we continue to face with service account management:
- Number of service accounts: the number of accounts in an organization can rise quickly, especially when it comes to service accounts. One reason for this is that every service or application running in an organization needs specific access to other resources and will use multiple service accounts to achieve this, as best practice defines. A good example of this is the number of service principals in a Microsoft Entra ID environment.
- Multiple team responsibilities: most of the time, the team managing and configuring the applications is not the team in charge of the identity provider nor the security team. As a result, multiple teams like application teams, security teams, identity teams, etc. need to work together to properly secure the service accounts.
- Account lifecycle: service accounts grow with the number of services, and as we mentioned above, they can be generated automatically. This makes it hard for an identity administrator to keep track of all accounts and make sure new accounts are correctly secured. Applications and services could be decommissioned and removed from the environment; however, cleaning up any related service account is often forgotten, resulting in orphaned accounts which could pose a security risk.
- Visibility and documentation: service accounts are often poorly documented, which leads to a challenge when applying security policies on top. Account owners are also poorly documented and can even lead to ‘dangling owners’ when people leave the organization.
To deal with the challenges of scaling service account protection, organizations need efficient and clearer management capabilities for service accounts to strengthen their security posture.
Scaling Service Account Protection Policies in Silverfort
Silverfort Service Account Protection provides an overview of all your service accounts in a single place, monitors their activity in your environment and enforces protection policies.
To address the challenge of scaling your service account policies, Silverfort provides several mechanisms to keep control over your service account security protection layer. In this section, we will briefly touch upon these capabilities.
Service Account Categorization
Silverfort’s service account detection engine detects service accounts based on authentication behavior patterns and categorizes them into categories, including M2M (machine-to-machine) accounts, hybrid accounts, scanners and dormant. Classification is the first step towards identifying which accounts are machine-based and in use.
The service account engine also detects interactive usage, new accounts, broadly used accounts, etc. All this information helps in the initial ‘triage’ of the accounts, ready to be protected by a security policy.
Silverfort leverages best practices used in an organization to manage service accounts, helping the engine in not only categorization but also detection. Implementing best practices on service account usage gives you a head start in getting your security policies in place, so it should always be top of mind when dealing with service account protection.
In nearly all environments, numerous accounts exhibit mixed behavior patterns, function in a hybrid manner, suffer from misconfigurations, or remain legacy accounts. These accounts require the attention of the identity team. Categorization is the first step in getting the focus right.
Silverfort and Managed Service Accounts
Microsoft offers MSAs to help with the management and security of service accounts. They provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate management to other administrators. One of the key security measures is that they are not allowed interactive login, since they are intended for non-interactive use by services and applications.
Combined with Silverfort’s service account protection policy capabilities, the security posture of gMSAs is even more enhanced while maintaining the simplicity of managing them through Active Directory.
Silverfort supports features like gMSAs under the service account protection policy. These accounts are classified as machine-to-machine, and all the capabilities available on the platform are applied to them. Each gMSA will be detected and treated the same as any service account. This means that all features including service account policies are applicable on top of gMSAs in the environment.
Smart Policies: Your Way into Automated Service Account Protection
To ease the management of security policies, we recently introduced our Smart Policy capability.
A Smart Policy enables you to automatically protect entire logical groupings of service accounts based on their activity profile. The Smart Policy runs in cycles, scanning service accounts for baseline changes, and defines the service account protection policy accordingly. This change is automatic and dynamic, without any need for manual intervention.
If an account behavior remains consistent for a defined period, the policy will
automatically enforce a security layer on top of the account. Silverfort will protect any authentication deviating from the known baseline behavior.
With a Smart Policy, Silverfort enhances the resilience of stable and consistent service accounts, allowing you to focus on more complex and dynamic service accounts. Service account policies are automatically enforced based on your configuration settings, enhancing the security posture of your service accounts with minimal administrative effort while still maintaining a clear overview.
Integration with Service Account Policy API
A different approach for more automated and consistent service account policy management is building an automated correlation between Silverfort’s Service Account Policy and a third-party service. This can be established through Silverfort integrations; for example, by using Silverfort’s Service Account Protection app in ServiceNow (see below).
Service Account Protection Policy integrations use our Service Account Policy API, which allows full control over the service account security policies. As discussed earlier, part of these security policies can be fully automated using smart policies. Others might need some additional info or instructions to be effective. From the automation perspective, this can all be read and controlled via the API.
Capabilities through API are numerous. For example, you could leverage this API inside a playbook, or perform your own API interactions based on third-party events.
Integration with CMDB (Configuration Management Database)
A CMDB is often used to map an organization’s complete infrastructure in one place and provide a single system of record about the environment. The CMDB consolidates and maintains a combined set of complex data coming from different sources. A single location like a CMDB, where this kind of information is live and queryable, is a very valuable asset for every department of a company.
One of the key components of a CMDB is an overview of running applications and services. This includes the software versions, hardware mapping, communication flows and ownerships. The CMDB contains a vast amount of data on what keeps a service or application running.
In the context of service account protection, Silverfort is interested in the service account information related to a service or application in the CMDB. Leveraging the service account data vs application data in a CMDB allows Silverfort to enhance NHI security posture.
Not only can the CDMB act as the single point of truth, but by leveraging Silverfort’s service account detection capabilities, Silverfort is also capable of providing a validation mechanism and becoming one of the data sources for the CMDB’s data completeness and consistency. For example, this could help an organization to detect active accounts which are not documented anywhere in the CMDB.
Example: ServiceNow CMDB
Seeing the need for automated and scalable service account protection capabilities, Silverfort developed a ServiceNow application that specifically focuses on leveraging the ServiceNow CMDB data with the Silverfort Service Account Policy.
The integration delivers an automated enforcement of our Service Account Policy capabilities without any interaction of security admins. This happens in real time based on CMDB application and services data.
By using the Silverfort service account protection application on your ServiceNow CMDB instance, you enable:
Scalability: Scale service account protection by leveraging the CMDB as a single source of truth and enforce service account protection policies in real-time.
Team collaboration: leverage the integration for easy cross-team collaboration on security enforcement. Application teams updating CMDB application information can adjust the security policies for these applications without any manual intervention of security teams.
Minimizing human errors: mistakes are easily made by humans, but not by automation. Source data reflects immediately in corresponding policies with the right data in the right spot.
The integration can be installed through the ServiceNow Store here.
Conclusion
Scaling Non-Human Identity protection successfully depends on the consistency and quality of service account behavior. Silverfort’s automated behavior detection, categorization and Smart Policy enforcement make the initial step towards a fully automated and protected service account environment significantly easier.
Larger environments have a huge increase in data sources and mostly enroll a central data store (CMDB) as a single source of truth for IT infrastructure, including applications and services data. Leveraging this information using Silverfort’s integration capabilities allows real-time accurate security enforcement, building a stronger and more resilient security posture for NHIs in the environment.