Security Automation: What is it good for?
Automation is a key process for secure software development. It is a requirement because we are extremely short on resources and we need to catch-up with the speed of development to production. This is Bedirhan and in this post I’ll try to explain what security automation brings into our dubious battle against hackers. Equally importantly, I’ll try to list the stuff we should know about any security automation technology so that we never assume that we win the battle when we have them in-place.
We produce huge amounts of code and it should be tested, deployed & maintained. Sure, we can build efficient processes for humans to follow to handle these tasks, however, those are no good and fall short when done manually. So, we rely on technology to make these processes actually work.
And automation is everywhere; aiding code writing, executing tests, deploying to and managing these environments. The same holds for security.
There are all types of automated security solutions for various purposes dealing with security bugs;
- revealing them,
- preventing them,
- managing them and
- sometimes fixing them. (preventing and fixing mean different things, you may prevent a bug to be abused without fixing the root cause)
All this is actually part of a popular methodology, dating back to 1964, with three pillars; human, technology and process.
We automate when the process interacts with the technology.
These three components all play integrated and critical role for a successful change in an organization. There are a ton of ways to look at these pillars, but for our specific topic, the need for automation arises when the process interacts with the technology. Solid and built-in processes are immensely important for an organization to accomplish a goal. Without the well-defined and followed processes, it’s hard to keep an organization running in consistent manner. Everything happens by chance.
So, it is important that people follow well-defined processes, however, sometimes it’s hard to implement them without the help of technological tools. That’s where the automation plays a key role. Here are some of the vivid advantages that security automation bring into our information security table;
- Security automation takes short time to complete relative to manual processes. It generally takes minutes to days to finish depending on the scope of work.
- Security automation is repeatable. Due to short execution time, it can be scheduled daily, weekly, etc.
- Security automation does not need expertise. The actual implementation of a solution, for example a static code analysis tool, requires deep understanding of programming languages, compilers and security. In contrast, executing and interpreting the results don’t require expertise to the same extent.
- Security automation makes sure that every test is comprehensive, so that each and every one of individual tests includes a known number of checks. Moreover, the number of checks increase as the tools get updated.
- Security automation plays nicely with other business and technical tools (such as JIRA, ServiceNow, Jenkins, etc.) through parse-able outputs and provided APIs. So that one can easily feed and synchronize data in existing workflow applications.
In short, security automation saves a lot of time and enables manpower to concentrate on other important items that really needs manual work. Such as business logic security issues and eliminating false alarms where any automated solution comes short. Well, it’s not wrong to say that some of the tools are worse than the others when it comes to false alarms. For details, check out our post about important attributes of program analysis.
These are cool, however, in order to make the security automation puzzle complete, we also have to approach it critically. Let me quote from a 1981 IBM paper by Kennedy et. al. about a claim on the automation of code optimization, which also forms the basis of static code analysis for security.
There’s a widely-held notion that optimization is intended to compensate for bad programming. Nothing could be further from the truth. In fact, no currently-known technique can compensate for the main component of bad programming: a poor choice of algorithm. Instead, optimization encourages good programming by making high-level languages more attractive and by taking care of small matters of efficiency so the programmer is free to concentrate on the essence of his problem.
What a nicely put one! The same goes with the “security optimization”. Let’s go through some of the items we should be aware of when doing security automation against our software portfolio.
Security automation is not a compensation for insecure programming.
First of all, security automation is not a compensation for bad/insecure programming. Static code analysis shouldn’t become one of those reasons that lead to the pitfall of false sense of security. On the contrary, it should encourage developers to be more security savvy by presenting unknown security knowledge to developers by using their own code as a leverage. Therefore, results of static code analysis bring closely related context for awareness that no other training can achieve. Coupled with secure coding trainings, developers may easily relate their own security mistakes to best practices of coding.
Security automation is not a compensation for manual bug hunting.
Second of all, security automation is not a compensation for hunting security bugs in our code. We can’t leave all the work to be done with automation. Although, tools are excelled at finding mass amounts of relatively hard to catch vulnerabilities, there are crazy types of issues where no security tool can catch. Human intelligence, at least for now, is needed to understand the internals of the target application and look out for critical errors either by reading the code line by line, or using the application with malicious intentions. Security automation lets this opportunity real by taking care of “small” syntactic details, such as SQL Injection, Mass Assignment, Directory Traversal, Insecure File Upload, etc.
Security automation doesn’t necessarily lead to mitigation.
Lastly, security automation doesn’t necessarily mean mitigation. Well, obviously. There should be well-defined processes and well-aware people to mitigate the bugs found. Sure, there are virtual patching solutions etc. , however, they are fast and dirty. A good vulnerability management flow should always be there in order to fix the resulted issues. And that flow is the combination of human, process and technology, of which the security automation is just one important piece of the secure production puzzle.
Automated tools born out of necessity. So, are security related ones. We have to use them and use them well. I wish I could say it’s enough to use these tools for secure development, but no. Consider these tools to be a great leverage and prepare to do more to aim for secure software.
