Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to establish layered security in the whole DevOps". In daily operation, I believe that many people have doubts about how to establish layered security in the whole DevOps. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to establish layered security in the whole DevOps". Next, please follow the editor to study!

By dividing our DevSecOps approach into multiple layers, we can find the right balance between the need for strong security and the need for fast movement and frequent deployment.

The DevOps movement has changed the way we integrate and distribute. It allows us to transition from a slow release cycle (sometimes an annual release cycle) to a daily (sometimes even hourly) release. We can write code and see changes in production almost immediately. DevOps is an amazing first step in breaking down barriers and supporting rapid response to market changes and customer needs, but there is still an important barrier to break down, and we need an important group to compromise: security Operations (SecOps).

To include this critical team in the continuous integration and deployment of production changes (CI/CD), we redefined DevOps as DevSecOps. The challenges we face in this work are the same as those in integrating development and operations: developers want to act quickly and make changes frequently, while operations require stable and infrequent changes. Security teams tend to support stability and infrequent changes, because changes may mean repeating security tests and authenticating the environment again.

When we move at the speed of DevOps, how can we expect these teams to redo their work every day or every week?

Security layering

Before delving into this issue, we should talk about a key security practice: hierarchical security or in-depth defense. Hierarchical security is a practice of applying multiple security measures, each of which overlaps the previous layer and the next layer to create a security control network that can work together to protect technical systems.

In the hierarchical security approach, companies mitigate intrusion into technology systems by using access controls such as WAN gateway firewalls and data at rest encryption. The list of controls is extensive, but the point is that no control can fully protect the technical system. The same method applies to performing security analysis on our application.

Contact the company's application security team and ask them what scanning tools they use to secure the applications they write. It is possible that they will not reply with one tool, because no tool can do it all. Instead, they may provide you with a list of tools or types of tools that they use or expect the development team to use.

This brings us back to the previous question: how can we expect to maintain a continuous deployment cycle when doing all these scans and using all these tools? This is an arduous task. Some of these scans and tools can take hours, days or more.

Inline scanning

While some security tools and scanners do take a long time to run, there are faster tools that can be used early in the development lifecycle to form our first layer of DevSecOps. This is the idea behind moving left: move the process from the end (or right) of the development life cycle to the beginning or middle, that is, to the left.

The first layer should include tools and scanners that take a few seconds (or minutes) to run. Some common examples are code lint, unit tests, static code analyzers such as SonarQube, third-party dependency vulnerability checking such as OWASP Dependency Checker, and a subset of integration tests.

You might ask, "how does tidying up your code and running unit tests fit into DevSecOps?" Errors in the software can provide the perfect solution for the opponent you are looking for. For example, OWASP listed code injection as the first vulnerability in the past two key Web application security reports (2013 and 2017). Unit testing and static code analysis can help catch some of our errors and may help prevent security vulnerabilities in your code.

Since these tools take very little time to scan, it is best to push them to the far left of the development lifecycle. When the developer pushes the code to our Git repository and opens the request, these tools and scanners will run to ensure that the code passes before merging. In addition to ensuring that our trunk branches remain buildable, having these tools early in the development lifecycle can also provide feedback to developers early and often.

Pre-deployment scan

The second layer of DevSecOps runs inline with our deployment pipeline and takes a few minutes or even an hour to complete. This may include more in-depth third-party vulnerability scans, Docker image scans and malware scans.

One of the keys to this layer is that scanners and tools can run after generating build artifacts and before storing them anywhere, such as Artifactory or Amazon Elastic Container Registry. More importantly, any failure in this layer should immediately stop the current deployment and provide feedback to the development team.

Another key is parallelization in this layer and in all future layers. Developers want to deploy their changes as soon as possible, and running multiple scans in succession (each scan can be as long as an hour) will unnecessarily slow down the deployment cycle. By running these tools in parallel, the reduction in deployment speed is equal to the longest running scan.

Scan after deployment

The next layer of DevSecOps includes tools and scanners that we can use after deploying the code to a pre-production environment. These tools may include performance and integration testing as well as application scanners, such as OWASP Zap. We should try to make this layer run quickly, hoping to run in an hour or less to provide developers with quick feedback and limit the impact on the CD process.

To ensure that we do not mistakenly deploy vulnerable code into production, this layer should be run as part of the CD pipeline to delete artifacts and roll back the environment when any scanner finds vulnerabilities or the following conditions. Or fail.

According to industry, security and regulatory requirements, we can automatically deploy to production after the successful completion of this layer. There should already be enough automated scanning and testing in the pipeline to reasonably demonstrate the security and robustness of the application.

Continuous scanning

Most of the scanners and tools we discuss are embedded in the CI/CD pipeline. Our goal is to balance the impact of these tools on the timeline of the CI/CD pipeline while providing reasonable assurance for the security of the application.

The last layer of DevSecOps is continuous scanning or continuous security (CS). Just as continuous integration, testing and deployment are synonymous with DevOps, continuous security is synonymous and cornerstone of DevSecOps. This layer includes tools such as Nessus,Qualys,IBM App Scan, as well as other infrastructure, applications and network scanning tools.

CS is not embedded in the CI/CD pipeline, but as asynchronous and provides continuous feedback to developers. How developers receive and respond to feedback needs to be discussed and agreed upon. The developer will process any feedback as soon as it is received and resolve it within a long turnaround time.

How these tools and scanners are started and how often they run is another aspect that stakeholders should agree with CS. After the deployment is complete, you can launch the tool with API through the CI/CD pipeline. Others may be done as needed or based on a certain time rhythm. No matter how complete, it is important that these tools and scanners not be run only once, or even once or twice a year. Instead, these tools and scanners should be run as often as possible and make sense for applications.

At this point, the study on "how to establish hierarchical security in the entire DevOps" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.