One of the tough things about security is that it is something of a game of whack-a-mole. Handling a one-off whack is pretty straightforward. Many vulnerabilities are known. Patches are available. And you probably have processes in place to apply them.
The hard part is that there are so many moles to whack. You may not have a lot of time to keep your systems safe. And there are so many avenues by which you can be compromised. As a manual process, it’s exhausting and you only have to miss one thing. That’s why you need automation.
Security automation: 5 approaches that make sense
But that’s a very general statement. What’s some advice for approaching security automation? Read on for five approaches that make sense for enterprises.
1. Understand what's important to you
Many security tools can be integrated into automated processes such as a CI/CD pipeline. The integration of security in this manner often goes by the DevSecOps moniker. DevSecOps is a way for organizations to extend some of the practices and processes from DevOps to continue rapid development and release cycles while simultaneously addressing security concerns. And doing so without the overhead and delays for which security often gets blamed.
But where to get started?
One ongoing challenge of DevSecOps – with respect to both applications in general and cloud-native applications in particular – is that security is a multi-faceted problem. There’s scanning for known vulnerabilities in source code. There’s confirming that current versions of application dependencies like libraries are used to build code. There’s checking that applications running in production remain up-to-date. There’s searching for vulnerabilities in containers that encapsulate applications together with other components they need. There’s making sure that the application platform, toolchain, and developer clients are themselves secure.
Many of these tasks require different tools. But not all these tasks may be of equal importance to you. If you’re not yet using containers – or only use containers that you build yourself – a container scanning tool probably shouldn’t be a priority. If you’re in a regulated environment, you may want to prioritize extra levels of security for certain types of data or communications.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
2. Go for the low-hanging fruit
While implementing a more comprehensive approach to security may be a significant project, you can get big wins from some relatively small improvements. Take securing your software supply chain.
With the increased use of open source software generally, open source code is finding its way into more and more applications – proprietary as well as open source. For example for its “2020 Open Source and Risk Analysis Report,” Synopsys audited 1,253 applications and found that 99 percent of them included open source components and that, overall, 70 percent of the total code was open source. Synopsys also found that 82 percent of codebases had components more than four years out of date and 88 percent of the codebases had components with no development activity during the last two years.
However, the lesson shouldn’t be to avoid open source libraries and other components. It should be to obtain signed software from trusted sources and to keep it up to date. Improving software supply management is one of the most important first steps you can take if you use open source software as part of your development process – and you almost certainly are.
3. Culture trumps process. Process trumps tools
There are many good tools out there. And you should be making use of at least some of them to automate your security. But tools by themselves are not enough.
There needs to be a process whereby tools are used in a consistent manner. Automation helps with that a lot.
But you also need a culture of security whereby security is something that everyone thinks about rather than leaves for the security team.
That’s not to say that everyone needs to be a security expert. But I like to point to the list of the top 10 web security risks maintained by the Open Web Application Security Project. The list includes risks such as injection flaws, cross-site scripting XSS, broken authentication, and so forth and is updated every year. What’s striking, and not in a good way, is how little changes from year to year; go back to the list of ten years or so ago and you’ll find many of the same risks as today. Change comes slowly. And that’s because, important as it is, culture is hard to change.
4. Shift automation left
One result of having a security culture that implements solid security processes and uses security tools throughout the development process: Security starts getting built in earlier.
This is advantageous because, even if you ultimately catch all the security flaws before the code goes into production – and you won’t – a problem found just before the code enters production means you now have to go all the way back to the beginning and start over. That’s how security becomes a bottleneck.
Instead, catch problems as early as possible and they can be relatively cheap to fix. This means doing things like catching vulnerabilities in dependencies using automated scanning, before they get added to your application. This is a well-known practice in modern manufacturing systems. You want to catch a supplier problem before the part is installed in a vehicle, much less shipped to a customer.
5. Security automation is about operations teams, too
Finally, while DevSecOps has operations right in the word, that constituency often gets short changed, given that DevOps historically tended to be developer-centric.
However, security automation is just as important for the ops team. That automation often looks different than it did before cloud-native architectures when you were more likely to remediate drift and other problems in long-running virtual machine or server instances. Now, you’re more likely to kill a container and fire up a new one.
But you need to know which containers need to be updated with new container builds that include security patches for a newly discovered problem. Furthermore, rapidly putting those updated containers into production without downtime may benefit from blue green and canary deployments.
Does that sound like a lot of work? It is if you do it by hand. (And you’ll make mistakes too.) Instead, the process of monitoring containers in production and refreshing them as needed requires robust and automated processes.
And that’s a common thread throughout security automation. Computing environments have become sufficiently complex and interdependent and the threat landscape has become so, well, threatening, that automation is no longer just a nice-to-have or something to implement “someday.”
[ Want to learn more? Get the free eBook: O’Reilly: Kubernetes Operators: Automating the Container Orchestration Platform. ]
