If you are new to DevOps, you can check Siili Academy courses for a quick and easy way of learning DevOps.
DevOps and security main challenges
You can find three core parts in DevOps: methodologies, technologies, and shared responsibility. All these areas need to co-exist for teams to succeed with DevOps. Security teams would also need to go through these core parts and adapt to their principles. The challenge with secure DevOps is in the philosophy of faster, better, scalable, and cross-functional.
When the risks are everywhere you tend to slow down. Complex systems are run by machines and designed by imperfect humans, so there will always be some security risks.
Remember, the same thing has already happened when smartphones were introduced. Security practices needed to adapt and that they did even though there were risks. Security and change go hand in hand, but the pacing is usually slower.
Secure CI/CD pipeline
Cloud solutions are one of the enablers for DevOps. Companies state that they have over 50 % of their workload in the cloud, and the number is growing fast. As more companies are shifting to the cloud at a faster pace, the overall security needs to keep up. What is concerning, is that in recent research, it was stated that over 40 % of companies think that security in a cloud-native environment is challenging. As Cloud and DevOps should go hand in hand, we need to look at what can be causing these problems.
One of the corner stones of DevOps is CI/CD pipeline that enables faster and smaller patched publishing. Let us concentrate on pre-build and post-build phases and how to adapt security practises in them. Four methods pop out regularly:
- Static testing
- Dynamic testing
- Interactive testing
- SCA
With Static testing (also SAST or white box testing), you can check your pre-build for vulnerabilities. It takes some time if you have a lot of code to go through, but the excellent thing is that in DevOps we try to deploy smaller batches to be faster, so this is a win-win situation. One challenge with the mentioned testing is the tendency to give false positives or negatives often. That is where DAST comes in.
Dynamic testing (DAST or black-box testing) is good at finding vulnerabilities on running applications and feeding malicious data to the software. With DAST, you can find annoying and one of the most common threats like XSS or SQL injection. The downside is that you always want to find the errors as soon as possible in the pipeline to minimize the cost. Security errors found by DAST are more costly to fix than in SAST due to the part of the process they run. Also, you might run into problems while using newest frameworks.
Because SAST is good on flagging errors in code, while DAST is programmed to see runtime errors from the application side, you should use both. Using both in the same process helps you to lower the uncertainty in your security. Tools like SonarQube (SAST) and OWASP ZAP (DAST & pen-testing) are programs that are developer-friendly and easy to use with many known languages.
Due to the previously mentioned solutions lacking some reliability on modern frameworks and libraries, Interactive testing (IAST) was introduced recently. IAST is faster and more easily adaptable to the DevOps pipeline than SAST or DAST due to being run while another testing occurs in the background. IAST is better, faster, and works with APIs. There is also Runtime testing (RASP) that is almost like IAST.
Most of today's software is third-party libraries. As far as security goes – no software is security bulletproof. Therefore, it's advisable to check vulnerabilities from outside your system. SCA or Software Composition Analysis is something that performs checks to identify vulnerable third-party software. There are a lot of SCA tool providers for different usage.
Example of working and secure pipeline:
Vulnerability management
Minimizing unnecessary manual work and giving simple and fewer tools for your daily work is very important in DevOps. That has proven positive effects on the dev team and also for the system's reliability and work efficiency. Security monitoring and alerting can also be troublesome if you have too many tools or if they are not simple to use. One study tells us that 53 % of companies spending more than $100 million in the cloud have five or fewer cloud security tools.
One dashboard to show what is happening with the system is a great way to make security simplistic and approachable for dev teams. It should monitor previously mentioned tests and production environment for malicious activity. When developers can see possible causations faster without jumping around different dashboards, they are also able to concentrate on more meaningful work – for example, fixing the security issue and giving more time for mitigating actions in the future.
Also, a simple dashboard that is made to give quick information for developers fixing the issue will additionally give information to CXO-level persons wanting to know more about the situation. Developers getting those “hurry up!” calls know how time-consuming they can be.
When implementing a simple dashboard for efficiency you should also think of naming the rotating line of command to make sure security management doesn’t drain the team too much, and also to give clear responsibilities when everything goes red.
Security responsibility
Today, systems are very complex and tend to become even more complicated in the future. That is why to minimize stress and inefficiency, the security team should not be the only one held responsible for security.
A company named Snyk made a report where they asked "who should have the responsibility of security", and gathered some interesting data.
Only about 55 % thought that Security teams should have the responsibility of security. Over 80 % saw software security to belong to the developers’ field. What is more interesting, is that infrastructure security is seen very even for everyone.
In DevOps, it is efficient to share more responsibility to the ones maintaining or doing the changes. The same goes for software and infrastructure security. The problem is that only 22 % of companies stated they use cross-functional security teams. So maybe the biggest challenge in the end is just letting go and give responsibility to others outside the security team.
Conclusion
DevOps might seem to have some challenges when implementing security and reliability to the processes. In this blog post, we have looked at some basic practices to make the security adaptation easy for your DevOps culture. Key points were:
- Share security responsibility and watch out for siloes. Security should be concerning the ones running the software and infrastructure.
- Find tools that work best for your developers and your processes. Start from the more lightweight open-source tools and experiment a lot.
- Make simple ways of visualizing the security topics to the team for a faster and more reliable process.
- Try to think about how many tools are necessary for your system to be secure and steady. Challenge your status quo.
If you need help with your security and reliability, just give us a call or contact us by e-mail.
May your servers be secure and reliable!
Written by
Niklas Lintumäki
Sources:
- Building Secure & Reliable Systems (2017): Heather Adkins, Betsy Beyer et al. S
- Site Reliability Engineering: Betsy Beyer (2020), Chris Jones, et al.
- The State of Open Source Security 2020 by Snyk: Alyssa Miller, Sharone Zitzman
- The State of Cloud-Native Security 2020 by Paloalto networks