One of the points David Gee, a guest speaker in Spring 2019 Building Networking Automation Solutions online course, and Christoph Jaggi touched on in their interview was the security of network automation solutions (see also: automated workflows and hygiene of network automation).

What are the security risks for automation?

Security is an approach, not an afterthought.

Workflows should be designed making use of experience gained from doing things the secure manual way. This means belts-and-braces protection of management plane services with authentication, encryption and gated IP access using access-lists or firewall rules.

We covered these aspects of network automation in Security and Reliability part of Getting Started module of the network automation course.

Credential management seems to be the lowest hanging fruit. It’s one of the easiest components to get right from day zero and sadly, one of the last things to be thought about. Leaving credentials in text files is a sure-fire way to give your keys to the Kingdom away. At a bare minimum, base64 the entries or even better, encrypt them. Even better than that, use a proper secrets platform!

Ansible Vault is described in the videos I mentioned above. Jeremy Stretch described how NetBox stores secrets… and of course there are tons of other solutions you could use.

Where securing automation differs from manual operations is through the use of source code. Scripts and open source platforms, either home-grown or consumed provides a huge surface area for attacking your system. It’s super easy to inject code into libraries and intercept credentials as they’re being used by your systems. To secure this aspect of automation, File Integrity Monitoring is important. Secure your automation stack with an FIM approach and check your logs for unauthorized service restarts as reconnaissance and probing might trigger vulnerabilities in code.

Unexpected changes when doing things in a new way can hide security issues. For instance, manually restarting an automation service or device proxy might be normal in maintenance windows, but in the middle of business hours may flag an issue. There are different ways of dealing with this and they range from having Chatbots reporting on service restarts or crashes and having a rule engine that generates alerts based on time of day or maintenance window schedules.

Final word on security is to involve your security team. If the business insists that automation is the way forward, then the role of the security team changes from saying “no” to “ok, let’s harden it”. When engineers learn automation skills, the learning material rarely includes secure practices. It’s not the fault of the engineer, but a combination of time pressure of the job and the education material available at the time. A good approach is to write your code and workflows with clear intent, then involve a professional who can help secure your stack.

Want to hear more from David Gee? Register for the Spring 2019 network automation course.