Security automation is an inherently broad—and increasingly important—concept in IT. It’s also another expanding terrain where IT Architects have a growing opportunity to influence strategy.
Let’s start with a definition from someone doing the work: “Security automation means that computers are able to deal with spotting patterns inside millions of alerts that occur daily,” says Laurence Pitt, global security strategy director at Juniper Networks.
This growing category includes everything from automated tests and runtime vulnerability scans to automation tools such as Ansible to machine learning algorithms that process massive amounts of security data and automatically respond to incidents when appropriate.
Any definition of security automation is incomplete if it doesn’t also cover the why—as in, why do we need it?
In short: The modern threat landscape is far too busy for human eyes alone to monitor. In particular, larger companies contend with hundreds of thousands, if not millions of security data points and events. Manually processing all of that information—not to mention initiating appropriate incident responses and remediation, all while trying to engineer a strong security posture that reduces risks—is no longer a tenable position.
“Practically speaking, humans will struggle to identify [all] actionable security events generated during multi-vector events,” says Travis Volk, technical VP of global business development and carrier sales at Radware. “[This is] the new normal, as sophisticated events use a combination of techniques to bypass security layers, while constantly looking to identify legitimate credentials, escalate privilege and take control over safeguarded assets.”
Enterprise architecture teams need to develop new skills in response to these new threats.
Security automation in practice
Enter security automation: Its primary goal is to help security professionals, developers, SREs, and plenty of other roles sift through the noise and focus on the information and events that actually need their skills and attention. In Volk’s experience, a company might have hundreds of thousands of security incidents in a single quarter. With machine learning and automation, “actionable events can be reduced to twenty to fifty correlated incidents that require human intervention to ensure long-term remediation, improving security posture,” Volk says.
This is a good point to make extra-clear: Security automation does not mean removing people from your security program. Instead, it’s about helping security analysts, engineers, and other stakeholders to more effectively do their jobs—and avoid drowning in a sea of data, much of which probably does not actually require their attention. It’s also about striving for the ideal of keeping security top-of-mind for everyone, not just those who have the word “security” in their job title.
“When many people think about automation, they think of it as ‘making tasks happen without human interaction,’ when it actually is much more than this,” Pitt says. “Well-deployed automation will work across solution stacks in an organization, so that data and information can be shared between products to make them more effective overall.”
IT Architects are uniquely positioned to help their organizations because they already see across teams and tech stacks as a function of their roles. They can help others on the team prioritize security in their systems, workflows, and culture. Moreover, IT Architects across multiple domains can help to ensure security is an early part of any new system or product. This is yet another way IT Architects are becoming strategic leaders in their IT organization and their overall company.
Software supply chain is key
Pitt from Juniper Networks notes that the software supply chain is, in general, a good place to look for security automation opportunities relatively early on. Again, IT Architects have a significant role to play here because of the depth and breadth required to do their job well. They understand the ins and outs of their environments and the various dependencies of their systems. They can be a key source of expert guidance when determining when, where, and how to bring more automation into those environments and systems, too.
“The goal is to embed security automation into development using suitable tools which add value at each stage of the software lifecycle,” Pitt says.
For example, Pitt notes that introducing more automation into your software supply chain in and of itself is not overly complex. It’s the people, process, and culture part—and this is again where Architects can be very influential.
“It is a commitment,” Pitt says.
If you’re starting from a place where one-off, highly manual security processes are the norm, it may seem a little overwhelming. However, security automation doesn’t have to happen overnight. In fact, you’re better served going piece-by-piece.
Four steps toward security automation
I recently asked Jerry Gamblin, manager of security and compliance at Kenna Security, for his advice on identifying “square one” (and two, and three…) in a long-term commitment to security automation. His advice should resonate with IT Architects and their ability to plan and prioritize for both short-term improvements as well as sustainable, continuous progress over time.
You start by making a list of tasks or processes that a team does on a daily or regular basis. Then, you categorize them in this framework:
- This task is simple and takes very little time to complete.
- This task is complicated and takes very little time to complete.
- This task is simple and takes a long time to complete.
- This task is complicated and takes a long time to complete.
Gamblin recommends saving anything in #2 or #3 for later stages of the journey. Start with something in #1. Here’s a quick example from Gamblin: “Build a simple slack bot to send alerts [upon] completion of your vulnerability scans every day instead of having someone log in to manually check,” he says. (Check out more of Gamblin’s insights on taking this approach.)
As Red Hat technology evangelist Gordon Haff wrote recently, it’s a good idea to start with what’s most important to your company.
“While implementing a more comprehensive approach to security may be a significant project, you can get big wins from some relatively small improvements”
~ Gordon Haff
If you’re not running containerized workloads in production, for example, it doesn’t make a whole lot of sense to add an automated container runtime scanner to your toolchain, at least not yet. Similarly, Haff advises starting with the proverbial low-hanging fruit.
Security automation tools available today
Technology options are abundant here, including various free and open source tools, not to mention the native security features of the multiple platforms that your organization relies upon. Much of this technology can be found under the concept of DevOps pipelines. Kubernetes has plenty of rich security capabilities that need to be properly configured and optimized over time. All of the major cloud platforms do, too.
One benefit of many open source options is that they’re built to plug into the other platforms and tools you’re already using or will use in the future. Pitt mentions Gauntlt as an example: It works with a variety of different tools and processes and can essentially attack your code to check for known vulnerabilities.
There are many other tools and scripts that could be good fits depending on your needs, such as the Open Web Application Security Project (OWASP) Dependency-Check tool. Some tools will be relatively broad; others are more specific. If you’re running containers with Kubernetes, for example, you might look at an open source tool like kube-hunter to automatically pen-test your clusters.
And of course, there are commercial options, as well as the security tools baked into the platforms you already use, whether a public cloud, an orchestrator, or other technology.
The reward is worth the effort
“The benefits of adding security automation into software development definitely outweigh the difficulties,” Pitt says. “Plus, once added, the tools are always there, making it a one-off lifting effort."
Again, remember that it’s not an overnight switch-over from a highly manual security program to security automation. Incremental progress is a good sign, especially when trying to deliver short-term results in the context of an infinite (in the good way) project.
This is another place where IT Architects shine, so even if security isn’t one of the first orders of business in your job description, consider this another strategic leadership—and career development—opportunity. It’s not just about dropping some tools into your software pipeline, either. It’s a long-term commitment and mindset, and Architects can drive the collaborative culture needed to make security automation work.