Automation continues to be a big driver for IT and security efficiencies, enhanced productivity, the reduction of errors, and improved security. Privileged task automation (PTA) entails automating tasks and workflows that involve privileged credentials and elevated access. In this blog, I will explore what privileged task automation is, what it requires, and the benefits it confers for employees and organizations. But first, let’s take a look at how task automation in general works.
What is Task Automation?
Task automation refers to the use of software to perform manual, repetitive activities rather than having them done by people. The goal of task automation is to improve productivity, increase efficiency, and reduce errors.
The phrase ‘task automation’ is increasingly used to encompass a whole raft of scenarios and approaches. While some task automation use cases have existed for decades, others are new and evolving. One consistent aspect of task automation is the intent to make life easier for the teams who manage our infrastructure and services.
Examples of Task Automation
Let’s look at a simple scenario that can be improved by automating a task—adding a full-stop to the end of every line in a long file. We’ve all tried to repeat three keypresses over and over. While it can certainly be done manually, I’m sure that most of us will start to make mistakes, and it will slow down our work. And then we will still go back over the entire file to see if we got it right. While it could seem like more work to use a tool or write a script, it’s likely to save time and be more efficient.
As you can see from the example in Figure 1, even if you don’t understand the actual code, there are only 3 lines doing all the work – 100% accurate, 100% of the time.
While automating tasks in this way requires some code writing, don’t be intimidated—it is typically easier than you might imagine. It’s highly likely that many of your IT administrators develop scripts to automate lots of activities without even thinking of it as ‘task automation.’
What is Privileged Task Automation (PTA) & What are the Benefits?
Our example task automation in Figure 1 runs in the security context of the user who starts the code. However, many of the activities targeted for automation will need to operate at a privilege level above that of a standard user. That privilege level is often at superuser level within your infrastructure.
This may be alarming at first reading, but automated task management, specifically privileged task automation, offers us an opportunity to abstract the user from the privileges and make the tasks more secure within our environment.
The simplest form of Privileged Task Automation (PTA) involves offering the user a predefined set of tasks to execute. A menu of tasks that are executed using privileged credentials, credentials stored within the tool. This is a vast improvement from users directly using privileged accounts to perform the tasks, even as a script.
Solutions at this level offer a mechanism to script the tasks and present them to users as a menu via a role-based access control (RBAC) system. In this scenario, for example, the database administrator only gets to see and use the tasks relevant for their role. They are also restricted to the set of databases and database servers for which they are responsible. They can perform that set of tasks from their standard user account, reducing the risk to the environment. These kinds of systems are often created in-house by organizations, leveraging relatively simple tools.
While risk is reduced with menu-based PTA tools, the tools still hold privileged credentials that need to be appropriately secured. With in-house built systems, this is unlikely to reach the same level of security found in commercial solutions.
Another challenge is the credential store needs to be updated every time the passwords are changed. This can lead to challenges in even moderately-sized organizations. Larger enterprises may find there’s a disconnect between the owners/managers of credentials and the myriad of uses of them.
We’ve all come up against the challenge that changing an account password may result in something failing unexpectedly. Sometimes ‘pulling the plug’ is the only way to find out where an account is being used. If you take this approach, make sure you know the original password, so you can restore function, while working to ensure everything can be updated to a new password.
More advanced PTA such as Robotic Process Automation (RPA), which involves software ‘robots’, is targeted at tasks that are more commonly triggered and executed in an automated fashion. The RPA bots are given their tasks either through a scripting language, much like the C# example above, or by recording the actions of a human operator.
This very similar to how the original robot arms used in manufacturing were trained. The operator would complete their task using the tool attached to the robot arm. The robot’s control system would record the movements and the actions, which it can then replay faster and more accurately than the operator. This allows the production line to move more quickly, increasing productivity.
With RPA, the software robot is watching the operator’s interaction with an application, local, remote or web-based, and recording mouse and keyboard activity. Many go a step further and are watching the interactions with the controls on the application. The recording can be replayed 100% accurately and often faster than any human could achieve.
Again, many of these activities will be utilizing privileged credentials and those will be stored in the RPA solution with the same complexities and risks mentioned above. One area where RPA does offer some advantage is in the recording of the activities, which can often be performed using the stored credentials through controlled sessions. This approach enables users to add new activities without needing to know the password for the credentials being used.
RPA is limited to the systems it can interact with and is generally focused on UI interactions, rather than API or other mechanisms.
Today, automation and orchestration tools such as Ansible, Puppet, Chef, Terraform and Jeeves are used extensively as part of DevOps practices. These tools are very much on the scripting end of the scale. Benefits of these tools include significant flexibility, expansive integration options, and the ability to quickly and reliably manage complex tasks. DevOps orchestration tools are often used to deploy huge resource farms and elastically scale them in real-time. As you can imagine, these toolsets make extensive use of privileged accounts and, in most implementations, are storing those within each tool.
Consider that most organizations will have 1 or more of these tools (many will not only have multiple tools, but lots of implementations of each). This means privileged credentials may be stored in multiple locations. And often, those tasked with IT security have no clear view into how and when these credentials are being used. This poses a significant security blind spot.
When we have privileged credentials stored across your enterprise, several key issues arise:
- Privileged credentials are often stored in plain text
- The credentials are often known to individuals within the team (particularly those who configure tasks)
- Tracking the instances of use of each credential is difficult
- Differentiating legitimate use from malicious use is extremely difficult
- Preventing privileged credential exposure and/or compromise is challenging
How do we take action to address these issues? It’s vital that we act because privileged credentials are still the primary objective of attackers. They remain the keys to the IT kingdom. Even something as simple as the unwanted changing of a password on a handful of critical privileged accounts by a threat actor could bring your business to its knees. All the automated tasks using that credential will fail, as the password is different from that stored locally.
More and more, we find task automation tools offer some level of encryption for stored credentials. This is a great first step—ensure your tools meet this basic requirement. Ensure that access to create tasks or record sessions is also as tightly controlled as those that provide access to privilege. Two-factor authentication into those tools is vital. It doesn’t matter how much the users may complain, it’s a route to the most highly privileged accounts in the company and that needs extra security.
I also recommend NOT enabling SSO leveraging their authentication onto their workstations. While this may already be secured using a 2nd factor (or more), the workstation remains the primary entry point for attackers who will be operating as the currently logged in user. SSO will give them unfettered access to those privileged accounts. SSO with an additional verification of the 2nd factor is acceptable – that’s the one thing they cannot get from the system.
The remaining 4 items on the list need outside help in the form of a Privileged Password Management (PPM) solution. Where DevOps is a part of your operation, Secrets Management should be part of that solution as well.
A Privileged Password Manager brings all privileged accounts under management through a centralized tool. It should offer the ability to periodically change the passwords on those accounts, a defense against brute force attacks, but also after each use. Changing the password after every use helps defend against attacks on cached credentials, such as with pass-the-hash attacks. The hash is useless if the password has been changed.
Good privileged password management solutions offer an extensive API that can be used by PTA, RPA, and bespoke code to retrieve credentials at the point they are needed and to check them back in, ready to be changed, when the activity is complete. We can now allow the credential to be changed as the tools get the current password on each request.
We also have tight control over which tools, from which IP addresses, and at which times, can gain access to the credentials. We can go a stage further where interactions are via human interfaces by offering remote sessions initiated by the PPM solution. These sessions are authenticated to the target system by the solution. Only details for the connection between the tool and the PPM solution are shared back to the tool. Those details should be a one-time token that connects to the session. Once used, they are invalidated.
There is another step we can take in securing the environment and that’s to provide the tools with unprivileged credentials for their access and layer Endpoint Privilege Management onto the target systems. We can now target individual processes and applications for elevated privileges constrained to those targets alone. This Least Risk approach to privilege management can also be applied to users in the environment.
PPM and EPM lead to a simpler security model based on enablement, rather than strictly trying to constrain privilege use. Providing access to privilege with constraints, even through tasks, leaves us with the default status, if the constraints fail or are circumvented. In other words—not the ideal safety net. Moving to an enablement model delivers the default of zero standing privilege (ZSP). If someone manages to circumvent the solutions, they effectively remove the system(s) that enable them – returning them to a standard user position.
Another benefit of this approach is that, when looking at the events raised by controls within the system, there are fewer events raised and less ‘noise’. By noise, I’m referring to the events raised from legitimate privileged activity, which need to be differentiated from potential malicious activity. When we have effective controls, the only privileged activities we are concerned about are those where there is no corresponding event from our PPM and EPM solutions--clear indicators of privilege abuse and a potential breach. Those events move from being potential malicious activity to a clear call-to-action and an effective indicator of compromise (IoC).
Layering up relatively simple controls presents a significant obstacle to malicious actors while, in many cases, improving the productivity of both our users and our cybersecurity teams. Automating privileged tasks enables us to push tasks and access down to less skilled employees or partners in a more self-service approach, save time, and boost efficiency—without increasing risk. This gives the more skilled people more space to contribute to the business rather than firefighting.
Brian Chappell, Chief Security Strategist
Brian has more than 30 years of IT and cybersecurity experience in a career that has spanned system integrators, PC and Software vendors, and high-tech multi-nationals. He has held senior roles in both the vendor and the enterprise space in companies such as Amstrad plc, BBC Television, GlaxoSmithKline, and BeyondTrust. At BeyondTrust, Brian has led Sales Engineering across EMEA and APAC, Product Management globally for Privileged Password Management, and now focuses on security strategy both internally and externally. Brian can also be found speaking at conferences, authoring articles and blog posts, as well as providing expert commentary for the world press.
