DevSecOps — What’s it all about ? Part 3
In this last part we will try to incorporate some additional security controls into our devops lifecycle and try to bring it all together under a single umbrella.
The current architecture looks like this :
And the pipeline looks like this :
Vulnerability Scanning
We have looked for vulnerabilities in our application during the DAST phase, however it is important to scan our infrastructure for vulnerabilities. Tools and techniques used in this largely depend on the type of infrastructure you have. There is a wide array of tools available to achieve the required outcome. You should ensure that the tools used scan for latest know vulnerabilities in your infrastructure.
For Pools-App, i have only used a single VM which has Nginx server. For vulnerability scanning i have used one of my favorite — OpenVAS. It scans for a large number of vulnerabilities which is regularly update through the NVT feed. Earlier i had not really tried to automate it and had used it only through the web portal. While automating i found out that it does have cli however it does not have an REST API. This didn’t suit my needs much as i wanted to make it on demand as earlier i had used docker for other tools. I did find two separate projects — REST API implementation for OpenVAS & Dockerized OpenVAS. However i wanted to combine these two into one and perform on-demand scans. So i made a openvas-as-a-service implementation which provides a node REST API in a docker container. It uses cert based authentication to avoid using secrets.
Compliance Scanning (Compliance-as-Code)
Compliance checks are set security standards that need to be maintained in an environment. It is often handled by a dedicated team and there is lot of efforts spent on getting compliance reports. Compliance reports may be required by different teams like legal team, management team, external auditors, etc. Automating it through the pipeline is an obvious choice as compliance checks are required whenever there are any changes or updates to the application or the infrastructure.
For Pools-App i just have a single web server hosted on Ubuntu so i used SeBAz — compliance checker tools with support to multiple benchmarks. I’m scanning our server for CIS benchmark.
Observability
We have numerous scans and tests happening in our DevSecOps pipeline. They are not only restricted to security but also contain application testing, performance testing, build reports, etc. Different teams work on different aspects in the pipeline. However it is important bring everything under a single umbrella to provide a holistic view of the application lifecycle. We need to have a single dashboard or project management tool where everyone from different teams like development, operations, security, management, legal, delivery should come to know about the current status of the applications. Each team on their side can also have additional tools to manage their action items more efficiently, like for eg security team can use Archery to detect and manage vulnerabilities, but it wouldn’t be much helpful for the development team. And DevSecOps aims at bridging the gap between the team to increase efficiency and agility. So based on your existing infrastructure you can use a observability tool that is already been used by some teams or you can select a new one that suits your needs.
For Pools-App i choose Grafana due to its sleek visuals, support to multiple data sources, alerting rules and of-course dockerized version. We can also manage users and give them only access to required reports. So now we can have set metrics to view of failures or alerts related to the app in all Dev Sec & Ops domains in a single place. Different teams who require reports which are the responsibility of some other team can easily download those and also provide reports to other teams. This greatly enhances the observability of the application over the organization.
So here we come to an end of this effort to include as much security controls as possible into the devops lifecycle for our Pools-App. At the end the infrastructure looks like this :
And the pipeline looks like this :
The tools used above are not the global standards. In fact there is no global standard that defines which tool to use where. It completely depends on your environment and what you are trying to achieve out of it. Some common things you should consider for implementing DevSecOps practices are -
- Go Native. Try to use as much native solutions as possible to avoid movement between platforms. Cloud service provide most of DevSecOps services in their environment. Try to avoid custom implementation and intermediate scripts to connect resources as they open up attack points.
- Use tools that can be automated. Tools has a CLI — good, has a REST API — better. Use tools that can be easily integrated into you existing environment. Also check what type of output formats do they support and try to have a consistent format so as to manage everything in a single place.
- Use tools that are regularly updated. Security is an ever changing landscape and the tools that you use should be able to keep up with it. We cannot achieve agility if the tool requires frequent manual intervention for updates or gets delayed updates
- Integrate ticketing or change management tools. Have a cross team ticketing or change management system. Instead of having different solutions for different team, have a single solution which then you can segregate between teams.
- Setup a unified view of the application. Have a common dashboard or view of the application. DevSecOps aims to bring all three of the terms together and not separating it even further.
So this is all there is in DevSecOps and you can call yourself an expert in it!!! Just kidding, here we tried to implement some general features and the ‘production’ environment that you will be working on will be far more complex than this. We haven’t touched topics like Infrastructure-as-code, container security, WAF, cloud security, SIEM, etc. as including all of them in a medium article would be insane and no would read it ;)
Last but not the least here are some good collection of resources that i referred to while making this series —
