Privileged Task Automation Myths and Realities: Rolling A Boulder Up a Hill

Privileged Task Automation Myths and Realities: Rolling A Boulder Up a Hill

Oct 04, 2017 / Kron

As more and more network functions are being virtualized, it only follows that the tasks associated those virtualized functions be automated. Privileged Task Automation (PTA), done properly, ensures that tasks which may previously been assigned privileged users (network operations teams, administrators, contractors, and vendors who need access to networks for maintenance and updates) are done with more accuracy and far less cost through scheduled software actions.

Automation picked up early traction when it came to testing networks and apps connected by those networks. While it is still true today that the majority of testing is done by technicians typing in data associated with processing functional and regression tests, more and more testing is being assigned to “the machines” programmed to automatically interact with networks and applications, in an attempt to bring them down, or prove they are unbreakable.

We’re seeing a lot of hybrid testing, as well as day-to-day network management, where individuals are empowered with automated testing tools that can run 24/7 and deliver data, analytics and reports to those individuals. Very often, test automation tools and protocols are developed internally for highly specialized and often vulnerable applications within organizations.

Whether PTA is used for testing or generally, or testing moving to general use – let’s not kid ourselves that we can automate everything. We cannot, just yet. Consider driverless cars – will they be our future in 10-20 years? Quite possibly, yes. But over the next few years, there is great wisdom in ensuring we have a driver behind the wheel or at least in close proximity should the “machines” go sideways.

If organizations are slow to adopt network automation, is it because IT and OT teams are threatened by “the bots”?

Not in our experience. We meet with our customers constantly, and the most advanced IT and OT leaders are embracing automation, as long as the initiative to automate is thoughtfully strategized and frame-worked. Network operations teams actually love the idea of automating the mundane, tedious but completely necessary tasks, so they can manage more devices, and more access to those devices more efficiently and effectively.

Network automation and, in particular, PTA comes with an exciting promise – allowing enterprises and service providers to build the amazing new networks we’ll need to support the Terabyte world and hyper-connectivity we are already seeing straining communications infrastructure.

The “epic fail” of some PTA deployments isn’t helping the cause; too many vendors have sold PTA solutions that turned out to be “not so good.” It is not easy to protect what we connect, and it’s getting harder every day, in large part due to the volume of things and people being connected to networks and the tsunami of applications. With more and more digitization, we need more network capacity and management of those networks.

The main reason lies in the foundation of the designs. With a vast amount of different players today, and an increasing number of players tomorrow – without sharing standard configuration “languages” intentionally, it is impossible to capture a snapshot of the network configuration as it is too complex. Collecting comprehensive information will never happen on time or within budget.

Relying a virtual model based on data having integrity issues will always fail.

IT teams, without the proper security solutions, will feel like Sisyphos, the cursed king of Ephyra, who was sentenced to endlessly roll a huge boulder up a steep hill, only to have the boulder roll back down to the bottom.

New alternative approaches – which are based on templates – are now being deployed to help manage network configurations. Given these approaches, there is a reference configuration file of a network device, and the solution prepares the new configuration block/subset and applies that new configuration block to the target network device.

While the idea looks elegant on paper, there have been epic fails in production environments.

Networks are living entities, dynamic and fast-moving. Configurations are changing all the time, and there are often hundreds of engineers working on network at any given time. As a result, refence templates may easily and quickly become obsolete, and impossible to manage.

The Kron approach simply simulates human behavior – and it works. First, the systems connect to a device and makes a pre-check, then runs the exact commands that an engineer would run, with a final post-check if it succeeded. We’ve proven this works in production.

Enterprises and service providers are at a crossroads where the traffic is zooming by at unprecedented speed – the new pace of change! Rather than rushing into implementing PTA on their networks, however, now is a good time to step back and understand what needs to be accomplished and can be accomplished, avoiding risk and ensuring a sustainable upside over time.

We’d love to learn more about the challenges you are facing as you plan, project, budget for and roll out network automation initiatives, including PTA. Are your IT and OT teams supportive of more automation vs. manual labor, and if so – which tasks are most important for them to hand off to the machines?

Implementing PTA can be of huge value – or it can become a huge headache. The problems PTA can solve are many, and the money PTA can save is substantial. Just make sure to choose the right software and partners to help implement not only the technical solution, but the training that goes with it as well – an investment in happier technicians and administrators, network executives and a healthier bottom line is well worth thinking through completely.

To learn more about our PTA solutions

Other Blogs