Why Security and DevOps Should Work Hand in Hand

As a modern cybersecurity professional for a corporation, you may get many headaches when working with the people responsible for developing applications, the DevOps team (and vice versa).

This article explains why this is the case and structures good communication for a fruitful together in the company. Plus, it outlines two concrete strategies for continuously creating more secure applications: security champions and tool integration.

What Are The Security Team’s Requirements

What do you, as a security professional, need when interacting with development teams?

• When an application is developed in-house, the most essential requirement as a security professional is to get involved in the DevOps process. Often, developers do not think and/or care about security. Therefore, security testing is only thought of shortly before the release. I have seen projects developed for years and then canceled shortly before the production release due to security risks and concerns. In one case, a portal was designed to consolidate customers’ contracts. It was stopped as it would have been a “single big honeypot” for the company. This cost the company millions of Euros for the development of the system. It could have easily been prevented if the security teams had been involved early during the software’s planning and development cycle.
• “Security is always a blocker.” As long as this is the attitude that people responsible for a product have, you are in trouble. Only by instilling the attitude of “Security is an enabler” will you be involved earlier (or at all) in the code reviews and work together to create secure applications for your customers.
• You do not have a lot of time for comforting the DevOps department. You probably have enough to do even without taking responsibility for the security of a new application. There are product owners who should take care of those kinds of things. The time you invest in security should be spent as much as possible. It does not make sense to explain basic security vulnerabilities and concepts to people creating and operating the application. You should be able to see the big picture of security postures in the company.

If you invest time checking a single application’s security, you want to concentrate on potential threats’ important, complex, and exciting parts. Therefore, baseline security, like a secure server configuration or up-to-date libraries, should be the security standard. In addition, the correct usage of frameworks to prevent vulnerabilities like SQL Injections and Cross-Site Scripting should not be something you need to check. Instead, you can use OWASP ZAP or your favorite tool to check for flaws in the application’s business logic.

What Are The DevOps Team’s Requirements

Try to take your DevOps Team’s perspective now. What do they need when interacting with you?

• They probably hate to interact with you. Or at least they could think of thousands of different ways to use their time instead of talking to you. Their focus is to create meaningful applications for your customers. That is what they get paid for – Features.
• They do not care about security. In most cases, there will not be User Stories related to security issues. Things like “Authentication” are implemented as an essential product requirement to have an internal area, but that’s it. The difference between authentication and authorization is where the problems usually start…
• If security is a topic, time is usually the most significant issue. Either the developer has many more important things to do in the software development lifecycle, which prevents him from focusing on security flaws. Or there is something that needs to be resolved by the developer ASAP. This is usually when DevOps security becomes relevant: Only if the business objectives are critical. Either because a vulnerability was detected and can lead to severe troubles if it remains unresolved or a customer is asking for a security vulnerability assessment, suddenly, the most unimportant topic of all time becomes a blocker.

What About Security and DevOps Working Together

Planning phase before and the testing phase after the development in the waterfall development process. This is where security was involved.

For example, setting up security requirements when creating the system specification and checking before the operation started. Nowadays, fast iterations and continuous delivery are fast, and the planning is usually done in user stories. Therefore, it is much harder to integrate security requirements when security needs to be involved every two weeks when new user stories are decided upon.

Also, it is not feasible to do manual penetration testing every two weeks after a sprint. In contrast, manual tests were doable after a project period of multiple months or years. Traditionally, security measures involved a lot of network and firewall rules. However, when networks were separated properly, a vulnerability in an application opened a much smaller attack surface than in interconnected networks (See also our post on the interconnection of web applications then and now). E.g., network access to an air-gapped network for industrial controls is much harder to gain than jumping to the same control system over an infected website. With web applications for monitoring and steering everything, their vulnerabilities are much more important than ever for attackers to access networks, steal data, or sabotage companies.

DevSecOps – The Solution?

What does DevSecOps mean, and is it the solution for all those problems?

DevSecOps is an attempt to bridge the gap between DevOps and Security. In the same way that single people or teams take responsibility for development and operations, they are also responsible for their applications’ security. Not to be confused with SecDevOps, which we explain in another blog post.

This does not mean that you need to start developing applications now or that the DevOps engineers will do your work. It means that altogether, you take shared responsibility for the security of the application. As a security expert, you will support the application development (instead of restraining it).

To be your voice in the team and as a relief for you, there is the concept of security champions, which are “active members of a team that may help make decisions about when to engage the Security Experts.” This helps you engage non-security people in security, establish a security culture, and scale through multiple (DevOps) teams.

Often, product owners feel well in a security champion’s role if security is an issue for them and their product. But also, people with development, operations, or testing background are good fits for security practitioners. However, they need to stand in the team to be heard (and not overheard).

Finally, these security champions should receive training through courses or coaching to professionalize their teams’ work.

The security champions will be your “security voice of reason” during the regular sprint planning. When a user story is defined, they can add misuse cases to it.

For example, a user story may define that a user of an application can download his invoices. The abuse case may be to download different users’ invoices. If this is forbidden within the acceptance criteria, there will be no doubt whether this security requirement has been implemented. It also serves as a guideline for testing the implementation of the feature.

Your job is to provide the necessary guidelines, tools, and security processes to the teams (and your security champions). This usually will be a mixture of the following:

DevSecOps Teams and A Secure DevOps Cycle

As shown in Figure 2, there are multiple ways to integrate security into the DevOps cycle. Below is a DevSecOps tool overview in a table format:

Below, we dive deeper into some of the topics:

• Policies: What are the overall security policies for the company? The security champions and product owners can use threat models for their applications in combination with your policies to create an overall security plan for the application. They will also be used for validation once features are released.
• Coding Guidelines: What is allowed in the technologies or libraries? How are the frameworks used securely? The DevOps teams then use this information to follow the best practices of a secure development process. Finally, during peer reviews, they check whether the guidelines are followed.
• Vulnerability Scanner: Which scanners are used within the company to detect vulnerabilities early? Tools such as SonarQube for Static Analysis or Crashtest Security for Dynamic Analysis greatly help to identify any flaws or issues before the deployment – even in an agile environment. If the scanners are set up and ready to use, it is easy for the teams to get started with them, immediately get feedback, and benefit from continuous checks for insecure software.
• Infrastructure-as-Code (IaC) Modules: How can a server be configured securely? How does a firewall need to be configured? Using tools like terraform, it is easy to create reproducible infrastructure. You can create modules, e.g., for server setup in your preferred cloud environments. The module contains the server, network configuration, firewall, and access restrictions. This way, the team can easily spawn their servers with a secure configuration. Furthermore, if you change the module due to new security requirements, all the existing infrastructure is automatically updated with the next release.
• Secret management: How can secrets be stored securely? It is always hard to store your secrets securely. You do not want to reveal secrets when they are leaked in code repositories. Provide a secret management service, including guidelines and documentation on how to use it. You can control the application’s secrets, rotate them in case of an incident and monitor their usage. The teams have control of which secrets they need and have an easy way to handle them.
• Threat Intelligence: Are there any new developments regarding the threat landscape? Important attacks on your infrastructure? This is one of the main tasks that you will keep in your hands. Then, in case of incidents or a change in the attacks, you can take over and support the teams on topics where you are most needed.
• Logging & Alerting infrastructure: How do you keep track of the running application? Provide a logging infrastructure for all the teams. That way, you can correlate events and detect incidents that otherwise would not have been visible. If you pre-configure alerts, the teams will be notified if there is an incident within their application. They will be responsible for it and only need to call you if the incident has security implications and cannot handle it themselves.
• Vulnerability Disclosure Policy or Bug Bounty Program: What happens if an external researcher detects a vulnerability? You will be responsible for set-up and leading the vulnerability disclosure within the whole company. If you are setting up such a program, you can pre-screen the issues and create comprehensible chunks of action. Then discuss the issues with the security champions and slowly transfer the responsibility to them. In the long run, they will be capable of screening the reported issues for their team and only consulting you in critical cases.

Prevention Guide

Big fat growing cybersecurity ebook

This ebook shows best practices and prevention techniques for keeping vulnerabilities away and securing your web apps.

Download

Summary

By using the tools mentioned above, you will end up with much more secure software. Every software is created by your guidelines manifested in the tool implementation.

Additionally, you have a team of security champions spread throughout the company. So if there are serious issues, you will be involved.

Security is thought about and integrated from the beginning of software projects till their operation and maintenance. So instead of being the DevOps people’s enemy, you are their friend, and they are happy to ask for your help whenever they need your support.

One step closer on the way to continuous security. And if you are just started with DevSecOps, read The 6 DevSecOps Quick Wins You Need Today post.