When I was at a previous employer the development team was embarking on a move to DevOps. I realized that this was a perfect time to inject security into the process and make everyone in the development process responsible for the security of the web application. This is when I started developing CyAn as a dynamic web application vulnerability scanner aggregator. It was a way to scan the web application for security bugs during the build process of the web app. This proved to be very valuable throughout the entire organization. This also sparked a new passion within me for automating security and coding for a security purposes.
Let’s fast forward to today… Security automation through technologies such as SOAR has become my new passion. I see Cyber Automation as flipping the DevSecOps around. SOAR stands for Security Orchestration, Automation, and Response. The way I visualize this process is a central spoke of a wheel that ingests and sends information back and forth between all your security products. This all is achieved by the use of API calls. Almost every modern security product has an API portal that allows web calls to manage and operate the tools. From host based security products to cloud services, a simple curl web call and initiate a myriad of functions.
Modern incident response (IR) and security operation center (SOC) teams have playbooks that allow a repeatable process for IR/SOC functions. It’s a sensible next step to automate those playbooks using code/api calls. Since code is being used for for those calls shouldn’t we look at this as a Software Development Life Cycle (SDLC) process? Bringing already standardized DevOps practices to security processes is a no brainer. To achieve this a cyber automation team should follow those processes, in using a dev->test->prod environment infrastructure. (More on this below). Moreover proper IDE usage and code sharing technologies such as git. Integrated AppSec is about bringing security to app development, cyber automation is about bringing devops to cyber security.
In a proper development infrastructure the idea of collaborative work and repeatable processes are paramount. With this in mind a proper test environment will lend itself to be destroyed and rebuilt in a very fast repeatable process. The environment should also allow for code to be shared and worked on between multiple developers. This is where code repositories such as git and CI/CD tool like Jenkins come into play. I truly believe that proper planning and building of the development infrastructure is a key to success.
I am aware that everything I stated above is all “in theory”; however, I felt I needed to get my thoughts down on paper. In a future blog post I will get into more technical detail on how we are building out the infrastructure and keys to planning.
I once believed that security has a place in all application development. I now believe that app development has a place in security. I have always seen this connection as a symbiotic existence where continuous delivery and continuous improvement will benefit an application development team. However, I see that this continuous iterative process is a benefit to all work work in Information Technology.