I wrote about the basics of service account management in Back to Basics: Service Account Management 101. Before I dive into service accounts in the cloud, here’s a quick recap of that post.
A quick recap on Service Accounts 101
What exactly are service accounts and why are they needed? Most organizations have two types of accounts that are used for authentication and authorization.
The first is human user accounts which are typically used by employees or contractors to log into systems and applications to perform tasks and functions that assist with their jobs.
The second is non-human accounts which are usually used by systems and applications to access resources, either local to the system or across the network. Most often they are used to perform automated tasks or part of API calls within an application, sometimes initiated by a human account.
Service accounts are a type of non-human account typically used within operating systems executing applications under the context of system privileges or a defined account created during the installation of an application that requires certain local system privileges to function or to connect with other network resources to perform tasks.
It’s quite common for service accounts to have high level privileges—this makes them an attractive target for cyber criminals
In Unix and Linux, service accounts are known as init or inetd and can execute applications. In the cloud, service accounts are referred to as cloud compute service accounts or virtual service accounts. It is quite common for service accounts to have high-level privileges, which makes them an attractive target for cyber criminals.
Here are some common types of service accounts—these probably sound familiar to you
- LocalSystem
- LocalService
- NetworkService
- Local User Account
- Domain User Account
- Cloud Service Account
- Cloud Compute Service Account
- Virtual Service Account
In Cloud Computing 101, I described the cloud-first approach and explained the benefits of cloud computing for businesses.
Let’s revisit that theme briefly:
Cloud computing recap and the cloud-first approach
Many organizations now take a cloud-first approach. So it’s important to understand that cloud computing is simply the act of “renting” another organization's compute resources and storage.
It’s a mistake to transition to cloud using traditional methods of perimeter security—they do not work well in cloud models
All connected computer systems and services have security risks, whether they are delivered from the cloud or on-premise. However, many companies make the mistake of transitioning to cloud computing using their old, traditional methods of perimeter security which do not work well in cloud models. This can lead to serious security breaches and data loss. Cloud computing has very different security risks that you must assess, understand, and, where possible eliminate or reduce. In order to do this, your security strategy must be adapted for the cloud.
Here’s a simple analogy I use to demonstrate why a cloud-specific security strategy is critical as your organization transitions to cloud computing:
Traditional on-premise security is like protecting your car in your own garage: you need only protect a single door and you do it with locks, maybe motion detectors, and if it’s a really expensive car you might even have a security guard. Anyone who wants to steal your car must go through the garage door, but it’s protected. These techniques are similar to perimeter cybersecurity. They reduce the risks and make it more difficult, but not impossible, for a criminal to break in. Most companies’ cybersecurity is similar to this, which means that once inside the “garage” (network perimeter), the intruder has access to everything because internal security tends to be much weaker.
But when you transition to cloud computing it’s like parking your car in a shared parking garage: the old method of locking the garage door is no longer sufficient. You must now reevaluate your security strategy to accommodate and reduce new risks. Sure, some parking garages might have some really advanced security solutions. However, if you leave your car door unlocked (weak or default credentials,) anyone who has access to the parking garage now has access to your unsecured car.
Now, using cloud computing in a true SaaS (Software as a Service) model is more like using a taxi service or Uber instead of owning a car at all. You get all the benefits of a car without the responsibility of maintaining it.
What all this means is that cloud computing needs a very different security approach, and as companies continue to transition, they must evaluate what security they need to protect their information and services. Identity and Access controls take on new levels of importance, and a strong privileged access management solution must be in place to limit who can make changes. You must use encryption to keep your data private, and multi-factor authentication to verify your authorized access.
Service accounts are subject to the same risks whether on-premise or in the cloud. These are high-privileged accounts that once compromised give the attacker full access to move around your networks and access your sensitive data. So choose your cloud environment with care because security controls differ.
Here’s why service accounts are challenging and risky
Organizations that have services accounts—pretty much all organizations—run into a lot of challenges protecting and securing them.
Service accounts can get automatically created during new application installs, and when configuring DevOps and virtual environments, and can be initiated by automated infrastructure and environment scaling processes. This regularly leads to default settings, and sometimes even default credentials, being used for those accounts.
In most organizations, the only security control protecting service accounts is a weak human-created password, or a key
Another example: an organization hires a 3rd party vendor or consultant to help deploy new applications or services in which they use default settings, or reuse previously used passwords for service accounts. Once the new application is deployed and being used to deliver new business services, the department fails to change anything. This includes the security or password that was used to create the service account, as well as the default settings. This is how service accounts with high privileges wind up with weak security. You can see why cyber criminals see them as an attractive target. In most organizations, the only security control protecting service accounts is a weak, human-created password or a key.
Here are some common risks that come with service accounts:
- Excessive Privileges
Most services accounts have too many privileges – typically more than they require, but organizations are usually reluctant to reduce those privileges in fear of breaking the applications or tasks that rely on the service.
- Default Passwords or Weak Passwords
Service accounts commonly have only a password or key as the sole security control, and a common method of creating the password is just leaving the default password in place during application installation, or via a consultant who just recycles the same password from previous installations.
- Poor Configuration
It is common to find configuration mistakes, such as registry entries without quotations, This allows cyber criminals to exploit these weak security configurations that can either be created directly or inherited from previous work.
- Interactive Logon Enabled
Sometimes accounts are cloned using accounts that have interactive login enabled and organizations sometimes forget to disable interactive logon, which can be abused by cyber criminals or insiders to gain access to systems with high privileges.
- Copied or Reused Service Accounts
Some teams cut corners and instead of creating unique accounts they will clone another service account and reuse it for a different purpose. This leads to over-privileged service accounts.
- Inconsistent and Incorrect Security Group and Controls
Leaving humans to create service accounts typically leads to inconsistent configurations and mistakes.
- No Date Restrictions
Some service accounts have time constraints or certain time windows for operations. They should be limited to use during those time schedules only. Most organizations do not configure or limit service accounts for use during certain time windows. Monitoring usage and frequent auditing can also help with this.
- Failure to Lock Down Edit Permissions
Many organizations fail to lock down who can make changes to service accounts, and how. The result is service accounts that can easily be modified by privileged user accounts.
- Lack of Audit Trail
Because service accounts tend to not be used by humans, and machines are trusted, organizations often overlook the need to audit the usage of service accounts. Cyber criminals tend to abuse service accounts because they can stay hidden for long.
- Unremoved, Unused Service Accounts
Yes, service accounts are almost never removed when they are no longer required, sometimes even when the application is long gone.
- Failure to apply Principle of Least Privilege
Applying the principle of least privilege is a best practice used to reduce the risks that come with over-privileged users and limit the potential damage posed by malicious malware, ransomware, or unwanted software. Security-savvy organizations are now starting to use least privilege principles with user accounts, but the same should also be applied to service accounts.
The importance of service accounts in the cloud (and even those on-premise)
If you’ve transitioned to cloud models such as Azure, AWS, or Google, you’ve probably already discovered how important service accounts are for cloud computing, and that it’s imperative you create a solid provisioning and security process to keep applications and services protected.
Below are my 7 quick tips to get started with your cloud service accounts—securely
- Service Account Creation/Approval Process
As new applications or services are being deployed ensure that you have a service account creation and approval process. Align this with your risk classification process to ensure that more sensitive applications have strict security controls in place; more than just a password. Having an automated approval process will ensure that security controls are consistently applied.
- Service Account Expiration/Review
Require that service account owners set an expiration date or review date to assess if the application is still required. This could be aligned with the license date, or yearly, depending on your business needs.
- Service Account Security and Governance
Is your organization required to have strict security controls that are mandated by compliance with internal policies or regulations? Ensure that, if the application has sensitive data that requires adherence to a compliance requirement, you set the appropriate security access controls and report on governance.
- Service Account Auditing and Reporting
Monitor, record, and report on service account usage and updates. This will help track authorized and unauthorized changes.
- Service Account Attributes
Group your service accounts according to similar risks and categories. Then ensure that the correct and required attributes are set on each service account
- Service Account Continuous Discovery
Chances are you already have many service accounts that have been created outside of this process or lifecycle. Discover those service accounts and set them to be reviewed, applying the same policies they would have received if they were created via your new service account creation and approval process.
- Service Account Dependency Mapping
Many services will be dependent on or related to other applications, so it’s important to map those dependencies because making changes to one service account can impact another. Having a dependency mapping process will help identify which service accounts must have changes made, and the order in which those changes should be done.
Get in control of your service accounts now, both in the Cloud and On-Premises:
Account Lifecycle Manager
