Security cannot be isolated in one team; let's talk about how to make security everyone's responsibility by implementing a DevSecOps strategy.
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
Security isn’t a brochure with lots of rules and policies that developers and operators must follow. Security isn’t people arguing that they are the cyber-security team, where nobody knows what’s happening with projects or nobody is helping the development and operations to be secure.
Sometimes, the security team of our company performs the enforcement of the rules and policies through meetings, asking by e-mail, or chatting to know how the security is, or worse, after a security leak performs a witch hunting to find the guilty. This is a typical way to get hacked.
Security is made all the time, everywhere, by everyone.
Let’s Be More Effective
Concentrating the security of a company to a single team is a big mistake. Security is the responsibility of all people; every single person who is directly or indirectly involved with our company must be concerned.
This article resulted after I saw misunderstandings about how DevSecOps is applied in practice. Here, I will show how to be effective with DevSecOps and avoid the wrong approaches.
Rules and Policies Enforcement
We need brochures to know what we need to do, but the enforcement cannot be done reactively, during a war room or a coffee break. Again, delegating the entire security to a unique team will not work. The enforcement must be software-defined and embedded within our DevOps pipeline.
To enforce our rules and policies, we have many tools and approaches. In this article, I will show how to be effective when starting a DevSecOps initiative and how to get results.
To meet the objectives, we should employ the following steps:
- Define the target
- Create the blueprint
(I’m assuming that the company has already reached a mature DevOps level.)
Define the Target
To know where we want to go, we must define the objectives, our targets. Without them, we will be like a drifting ship.
Let’s take some examples and use them as targets for this article.
- No secret exposures: Works to guarantee that no one password, passphrase, certificate chain, or private key will be leaked.
- No certificate expiration: No more expired TLS certificate.
- No outdated library: Scans the project's dependencies, OS libraries, OS services and OS utilities.
- No code vulnerability: Statically scans the source code for vulnerabilities and bugs.
- Compliance with OWASP Top 10: Dynamically scans the running app for vulnerabilities.
There are a lot of targets, so let’s see more examples: no authorized process, no authorized ports, no bugged library, no authorized repositories, end-of-life management, no authorized account, compliance with Common Vulnerabilities and Exposures — CVE, vulnerability management, TLS everywhere, etc.
Create the Blueprint
A blueprint is a critical step because we will define how development and operations, together, are concerned about security. In this blueprint, we will define the rules and how they will be enforced, preparing the entire company for the next steps.
Here is a diagram to understand the blueprint for our defined targets:
In the diagram above, we have four building blocks to map our targets: Secret Management, Code Quality, Hardening, and Run Quality, but for your DevSecOps initiative, many others are necessary to map your own targets.
Side note: I defined a few targets and building blocks to write a non-exhaustive article.
Now create a space in your wiki and write clear and concise topics explaining every detail expressed in the blueprint, highlighting the following topics:
- Link the blueprint to targets
- Detail the building blocks
- How they will be enforced
- What’s the toolset
- Security first
- Security mindset
- Special exceptions
- How to stay in compliance
- The roadmap
Mapping the Building Blocks to our Pipeline.
As you can see, we must map each building block to our pipeline steps. This will drive us to enforce how to collect metrics and how to employ them in our projects.
People must know.
Now it’s time to market this new initiative. The best blueprint adds nothing without people knowing it and adopting it.
First, take the best sponsors ever. They will buy the blueprint and help adoption growth. Never perform a big bang as this is will not work.
People should know and understand the benefits, and how important to be in compliance with the DevSecOps blueprint because everyone performs a critical role. To broadcast successfully, a company should
- Communicate the roadmap. Put it everywhere: banners, intranet, videos, and digital signage.
- Make gifts: t-shirts, bottles, stickers, hats.
- Look for early adopters.
- Hold workshops.
- Have internal meetups.
- Show the benefits.
- Help teams play Sec.
A good solution has good communication and marketing. Nothing happens if people do not know how to play Sec; they must know what is right and what is wrong when they develop software or provision and configure infrastructure.
Now let’s enforce the rules and policies. Everyone knows how to play Sec and they are prepared to implement the policies and follow the rules.
If no human task is able to answer the demand, then we must implement enforcement in our pipeline, either for software and infrastructure. We will employ tools and automation to perform this task for each target we have defined. Here’s a toolset for each one.
I will not show a proprietary tool, but you will find paid alternatives in sites like stackshare.io.
No Secret Exposures
Secrets are passwords, passphrases, private keys, db account, or tokens.
To have no secret exposures, first, we must not have secrets saved within flat files, hardcoded, or within the Git repository, and no perpetual passwords. To solve almost all of these problems, we must employ a vault tool to manage every single secret.
A vault tool is obligatory to manage the secret life cycle, mitigating the vulnerability in case of a leak. A mature tool can manage many different types of credentials, like databases, operational systems, cloud providers, etc. and have the capability for consumers to get these secrets programmatically, through an API.
If you use secrets in your pipeline, SSH key, or consume it directly from your automation runner (e.g. Jenkins).
No Certificate Expiration
Nowadays, TLS is mandatory and we must manage certificate expiration to prevent SSL handshake errors.
Employ a tool to monitor each certificate, inside (private domain) and outside (public domain) of our company:
No Outdated Libraries
A big company has thousands of projects in development running in parallel. This is prone to using outdated libraries when a team starts to develop a new microservice, for example. We can’t allow this.
Side note: I wrote “…when a team starts to develop a new…” because we must be careful to enforce in projects that reach production or legacies. Never apply enforcement in legacy just to follow the crowd. Work with the teams and understand the impact of the new rules and avoid the chaos.
The tools available to perform this job are specific to the platform and language that we have in our projects, but these tools are a must-have to help us to identify outdated and bugged library dependencies:
We must create a step in our pipeline to enforce this target in every build. This guarantees that we never pass an unauthorized, outdated, or bugged dependency.
To enforce this target in the server farm, we can employ tools like Chef and Inspect to manage the configuration and maintain stability. These tools act at the OS level to maintain things right; normally they require an installed agent in the host.
No Code Vulnerability
Also know as SAST: Static Application Security Testing.
This target hunts bugs, bad practices, potential memory leaks, infinite loops, and anything that can cause a vulnerability. A well-known tool that handles this job is SonarQube, which provides several ways to scan the source files, hunting bugs and bad practices, and is used for many languages.
- Infer by Facebook: This is an option by Facebook and we can scan Java, C/C++, and Object-C.
Compliance With OWASP Top 10
OWASP Top 10 is a collection of the top ten security risks and the latest update was in 2017 (see all of them here). It’s a guideline to follow to deliver better security web applications. Many tools follow this guide and apply their own checks; for now, I will propose two good options.
Know the numbers to understand what happens.
The measurements are critical to understanding how much is effective with abDevSecOps initiative. Without them, we are in a darkened room.
There are good open-source options for metrics and for presenting them. I’m a huge fan of Grafana, which gracefully presents the metrics, and to store them, I suggest InfluxDB, which can integrate into our pipeline and ingest every single measure. Grafana has a good integration with InfluxDB, too.
What can we measure?
- Secrets found in the Git repositories
- Expired certificates
- Mean time to renew an expired certificate
- Outdated dependencies
- Outdated OS libraries
- Critical vulnerabilities found in the source code
- Top ten vulnerabilities found in the app
That’s all, folks! This is my view of effective DevSecOps. If you like it, give some claps and share your opinion!
DevSecOps is so hyped, but always try to be effective and not just talk, because “talk is cheap!” as Linus said.
See you in the next articles.
Published at DZone with permission of Fabio Jose Moraes . See the original article here.
Opinions expressed by DZone contributors are their own.