Security Automation By Example
The Firewall Change
Just when you thought DevOps was the new black, along comes SecDevOps. Yes folks, like most things in life, the new cool is already here. Before I move on to trying to explain SecDevOps, please accept my mea culpa because for many people DevOps is yet to be clearly defined. I can imagine your frustration that I’m going to try and explain a new term based on a loosely defined term.
I’m not going to try and provide a complete definition of SecDevOps, but instead I’d like to provide what I believe to be important attributes of the SecDevOps movement. In this post, lets discuss security automation and use a firewall change process as an example.
One important attribute of SecDevOps is heavy use of security automation. In particular when I think security automation, I tell people to use IFTTT thinking. Stolen from the service whose tagline is “put the Internet to work for you”, I explain security automation simply as “if this, then that”. Its a highly simplistic, but poignant way to imagine ways in which one would automate workflow.
A simple act of changing a firewall has huge potential for security automation. The SecDevOps firewall change process goes beyond changing a few lines in a config, but also provides an independent and automated verification process that most organizations don’t perform today.
Consider what happens when a firewall policy is changed. First the policy change request is reviewed and approved. Then the policy change request is assigned and acted upon. Many times, but not always, the change is verified by another person through configuration review.
Security automation takes this process one step further. Imagine when a firewall is changed that a security audit event is automatically logged. Next, an automation component notices the firewall change and automatically spins up a remote scanning instance in a cloud provider. Next, that scanning instance is contacted using APIs to perform a remote network scan. The scan completes, results are exported and compared with prior scan results automatically. Finally, the automation component automatically updates the firewall change request in a ticketing system showing the scan results. We have now completed an automatic, independent and autonomous firewall change verification. That simplified yet powerful workflow is security automation and completes what many people refer to as a closed loop.
The new SecDevOps method for a firewall change not only provides a closed loop process, but does so by automating the verification steps. Joining traditional security processes with new API driven cloud services is a true force multiplier that many organizations will soon wish they had.
In upcoming posts, I’ll also discuss some of the other important components of what I believe make up the new black of SecDevOps.
