Privileged Task Automation: The Natural Extension of Privileged Access Management

Privileged Task Automation: The Natural Extension of Privileged Access Management

Oct 04, 2017 / Kron

A lot has been written about Privileged Access Management (PAM) and for good reason. The number of individuals required to run a modern network – or networks in the context of our multi-network, multi-cloud world – continues to grow.


Gartner cites as reason to invest in PAM the risk of breaches and insider threats, the need to prevent, isolate and limit malware attacks that target privileged accounts, audits that fail as auditors start to pay more attention to privileged accounts, and new regulations requiring that a strong evidentiary trail be recorded associated with individuals authenticated to perform work inside of networks.


The risks are exacerbated when companies allow third party contractors, vendors and service provider technicians into their networks, and is daily impacting cybersecurity defense. Add to this the growing number of cloud-related DevOps access needs, and suddenly enterprises and services providers are finding themselves in the “Wild Wild West” again, often threatened by criminals from within.


Humans are one thing – automation is another. Just as driverless cars are the wave of the future, given that humans make more mistakes than machines, our industry is turning towards more automation of security, including driving control of nonhuman service and applications accounts through Privileged Task Automation (PTA). There are more machines with software than there are people on the planet.



How does PTA work and benefit enterprises and service providers?


When a corporate customer creates a support ticket/incident to a service provider about a data connectivity problem, a technical level-1 support professional reads the ticket and connect to devices in the network to check status for troubleshooting purposes.


This is a repetitive task, and there are tens even hundreds of them each day.


Normally for this task to be completed, level-1 support professionals must have privileged access to many or all network devices.


This is the heart of the problem. In a big, service provider network, or in a large multi-site enterprise network hundreds of individuals – employees and contractors – have direct access to the network. Suddenly, the attack surface is huge, and the service provider is vulnerable to intentional insider attacks or accidental misconfigurations.


With Kron’s Single Command, service providers design a flow for repetitive tasks, and grant the rights to all level-1 support professionals to run this automated task on Single Command.


Then, when that professionals receives a ticket from a corporate customer, he just connects and logs in to the Single Command portal, chooses the “troubleshoot” task from the list, enters the minimum set of information (customer name, service name, etc.) and clicks run button.


After that, Single Command, behind the scenes, connects to the network devices, runs the commands/scripts on the network devices as designed in the flow and displays the results on the screen.


In addition to day-to-day task automation, improving admin access, there are critical emergency response actions. Security response can be triggered by AI or analytic tools based on a combination of events (SIEM tools are one of the most predominant examples of these analytics solutions). PTA can trigger countermeasure actions faster and more accurately than any employee.


One should never forget that, people, no matterhow talented they are, may panic –

but software never panics. Therefore, emergency response actions are better automated, before the day of an attack comes.


We are helping our clients to work on scenarios such as “under DDOS attack,” “hacked operating system,” “intruder inside,” and many more scenarios that implement automated emergency response actions with Single Command.



The benefits? Here are six, to start:


First, service providers and enterprises running large networks are not delegating the right to access network devices to internal users, but instead are delegating a task (right to run a troubleshoot task) to employees and contractors working in the network.
Second, service providers and enterprises running large networks are decreasing the attack surface, eliminating hundreds of internal accounts which have access right to network device. After Single Command, none of them can access directly to network, they all access “only” Single Command with zero visibility into network devices/topology/local accounts on devices, etc.
Third, service providers and enterprises running large networks ensure that least privilege is granted to internal users. Normally when a user has access right to network devices, he or she is involuntarily allowed to run many commands on that device. So, when that internal account is hacked or used maliciously, there are big risks. With Single Command, the user has only the right to run a “troubleshoot” task. He or she is not allowed to run any other command on any other device.
Fourth, PTA approaches like Single Command help prevent accidental misconfigurations. Normally when a user is directly connected to a device, he or she may accidently run a wrong command and cause a service interruption. This happens, and it is not rare! With Single Command, it is almost impossible to run a wrong command because users are entering minimum required input then click run, and that’s it. All the commands are executed automatically, without any human error.
Fifth, Single Command is increasing the security level, but at the same time increases the efficiency of operations (unlike most of the security solutions). Because automated tasks run much faster than manual tasks,
Sixth, planned and tested emergency responses against breaches and attacks can save your company and prevent your company from having to publish a blog like this: “On Behalf of Equifax, I’m Sorry.” (embed link:



Finally, everything is logged and recorded – indisputably.


As organizations continue to adopt virtualization and cloud infrastructure, for example, it’s time to invest in cloud automation in parallel with network automation which is orchestrated with traditional PAM. It’s high time we simplify the discovery and prioritization, the management and reporting of not just PAM but PTA.


Before the complexity being caused by DevOps, as more and more business applications, more and more IoT deployments, more and more mobile applications are being created by often rogue developer teams – enterprise IT leaders can get out in front of the risk, and leverage software to provide full visibility and control within their network, or networks. Every end point, every end-user – automated or semi-automated – can be held accountable.


Doing so manually will never scale.


Implementing PAM and PTA in parallel will never fail.

Other Blogs