Securing DevOps

DZone’s Guide to

Securing DevOps

Automated DevSecOps is how IT execs are integrating security into their DevOps pipelines.

Tom Smith

Nov. 01, 18 · DevOps Zone ·

Free Resource

Like (1)

Comment (0)

Save

{{ articles[0].views | formatCount}} Views

Join the DZone community and get the full member experience.

Join For Free

Learn how integrating security into DevOps to deliver “DevSecOps” requires changing mindsets, processes and technology.

To understand the current and future state of DevOps, we spoke to 40 IT executives from 37 organizations. We asked them, "How are you addressing security in your DevOps pipeline?" Here’s what they said:

DevSecOps

Anyone with customer data has to use DevSecOps because the risks are too great to leave security to the end.
DevSecOps security baked in from the beginning. Security is a first class citizen with the number of breaches. Without security can’t survive. Have automation built in with security checkpoints. Skills are an issue, need to automate so as not to overwhelm developers. Address code security up front.
As cyber threats continue to grow unabated and infrastructure becomes ever more complex in the cloud, it’s more critical than ever that DevOps embrace security from the outset. SecOps aims to ease the pain of integrating security into development and operations by automating as many security tasks as possible, fostering communication between teams, and enabling development that remains agile while being secure. Here are some specific best practices to undertake in six areas of infrastructure: 1) Create a Security Liaison — At Threat Stack, we have a senior-level engineer that acts as a security liaison between the security and operations team. Whenever there is a dispute between the two teams, the liaison is able to use his expertise to find a resolution that aligns with the company’s goals. 2) System Access & Users — When it comes to system access and users, live by the principle of least privilege. In order to achieve true security maturity in this area, you will need to embed the principle into your tools and day-to-day processes, even if you have already modeled it into your policies. Systematically automating and verifying your user access policies allows you to reduce the risk of human oversight that could result in insider threats. 3) Patching & Vulnerability Management — Think patching is simple? Think again. According to the 2017 Verizon Data Breach Investigations Report, companies aren’t doing it with nearly enough regularity, giving attackers plenty of time to exploit known vulnerabilities that are months (or even years) old. To catch vulnerabilities before cybercriminals do, your organization’s approach to patching should be automated, standardized, and resilient enough to withstand automatic software updates. 4) Infrastructure Control Plane (AWS Console/API) APIs and management consoles are the functional equivalents of data center access when operating in the cloud. However, securing only your own data center in the cloud would leave your APIs exposed. Therefore, it’s necessary to evolve your security approach as you move to the public cloud by handling management consoles and APIs with the same level of sensitivity as you would a data center. This involves automating the shutoff of access to insecure or potentially compromised systems. 5) Networking With environments that are more complex and interconnected than ever before, traditional network security controls are no longer cutting it. Currently, many security and operations teams are restricting access between systems with network topologies, but it’s necessary to group servers by roles instead and to leverage automation to establish small network paths to model trust between peers. Additionally, architecture should run over the WAN rather than LANs. SecOps maturity in this area, therefore, means modeling authentication and authorization and not simply relying on the underlying network topology to define security. 6) Runtime & Services Considering that operations and security teams both benefit from the standardization of run times and software management, continuous integration, and streamlined software development life cycles, aligning goals should be relatively easy here. Once everyone is on the same page, infrastructure and runtimes can function as a shared utility, allowing engineers to innovate within these common structures. Applying the same principles across teams increases efficiency and helps to minimize the risk of failure.
1) With DevOps, security is not left to security experts but is simply a routine part of the delivery process. It has to be built through automated testing at critical points throughout the development lifecycle. By integrating security into DevOps, developers can easily and routinely produce software that is free of flaws, helping to accelerate timelines and improve the quality of each release. 2) As a lot of software is open source, it is important to be very selective about what we choose to embed in our code base. We should only add open source components that also follow DevOps security principles themselves. Otherwise, we might get surprised by vulnerabilities in embedded open source components in production.

SCA/DAST

Transform DevOps into DevSecOps. Realize all apps are insecure. SQL injections are always present. 38% of cross-eyed scripting. Information leakage in 45% of applications. 40% content spoofing. 23% insufficient transport layer protection. It’s getting worse. We expedited the delivery of applications. This increases vulnerabilities. We offer three fundamental technologies: 1) SAST (static analysis security testing) analyzing application code like a compiler and build logic tree and data flow of an application. Shows detected vulnerabilities and suggested remediation. Detect vulnerability as early as possible and fix as inexpensively as possible. 2) DAST dynamic application security testing, an automated hacker. Repository with scenarios. Analyze response to determine if broke or tricked the application. Produce a report with detected vulnerabilities and remediation advice. Need to keep testing on an ongoing basis. Hackers are looking for new types of attacks. Have to make sure new attacks do not penetrate your application. 3) SCA (software composition analysis) analyzes components of your application. Analyze application code, detect open source code and determine if secure, legality of the component, how far behind you are lagging from the most recent releases. Go get a fix. Detect vulnerabilities across the entire lifecycle in the code, the runtime behavior, and the components. With our technology DevOps transformed into DevSecOps.
There are several ways of looking at security. First, it’s a vital part of DevOps and a CD pipeline, so you need to make sure it’s implemented at the procedural level. Our security starts at the lowest end with static code analysis. Later in the pipeline, we do dynamic security scanning, so all of these technical aspects of security are built into the pipeline. Second, we make sure our engineers understand secure approaches like secure coding. We train them with the right knowledge. Third, we require that people do a peer review before they merge code—it’s the “four-eyes” principle: there are always two people involved in looking at the code before it’s merged. Fourth, we have segregation of duties in place, for security and compliance reasons, the person writing the code cannot be the person pushing it into production. And fifth, we track how everything is produced in the pipeline—who did what and when, so we can easily give this information to the auditor without hours or days of digging to get it.
There are several different places in the DevOps pipeline where you need to take action to ensure strong security. Ensuring that you hook an AppSec testing pipeline as part of your CI processes, before code gets deployed, to guarantee a basic level of automated security testing is one key area. Another is ensuring that you’re properly implementing commit signing procedures and treating code from developer’s laptop to deployed application as a form of “chain of custody.” This ensures malicious action at any point is detectable. Finally, it’s essential to have good security practices and use modern technology like data-at-rest encryption, strong TLS configuration, and SELinux or other MAC to help resist breaches occurring in your systems.
We use both static and dynamic analysis to assess project security vulnerabilities. Static analysis is used to catch coding issues based on a language or the libraries used. Static results can also lead to more formal code reviews. Dynamic or runtime analysis is used to test services in their operational environments. It identifies issues related to how the operational environment deals with threats.

Other

Obvious things managing what code gets into the pipeline, projects included, how managed, hardened view of where keep stuff. For us, it’s also understanding what’s going on. We use our own product for monitoring our own product – utilization and ingesting from what and where queries. Need discipline of always having your own practices that are at least as good as what your customer needs.
From a consulting perspective, we recommend ingraining security into the value stream. Include in value stream mapping. If there are deficiencies, we make security part of the product. We promote it being farther left in the process and help understand how it affects the pipeline.
Securing the containers. Having security engaged as part of the DevOps process. Include security on the team. It’s about automating security. If you are not automating your turning into a giant manual process. Why does going fast matter? Consider a critical vulnerability like struts two. Four months later Equifax admitted to a breach. Forget speed for speed sake. Look at remediation or recovery from the error. The ability to respond to a security incident in real time. Move security further left in the pipeline and teach developers about security and the need to write secure software.
When leverage CI/CD you become more structured in how you bring the software to life. You offer early access to developers for the security of the code. You have checkpoints for many things including security. Block code from going into production. Faster feedback loops. Docker container image scanning. Developers should know when they commit code with a vulnerability to change direction and correct. Write more secure applications. Security is a critical part of a DevOps and CI/CD pipeline.
Like any other have roles and permissions in place. Critical in DevOps since executing code from development to production. Ops and support need to be able to view as much as possible. Have secure SDLC as part of DevOps.
Historically it’s hard to ensure every time developers build app follow security rules of the organization. Separate flow not part of the build. Now with containers and images, we can have the scanning as part of the build process itself. Developers just click the build now button and the image is automatically scanned. Everything to remediate the problem. If the, the build does not match policy fail it and send it back to the developers.
Security begins with AWS best practices focused on user management. Clean up account access. Get rid of shared accounts. AWS best practices related to networking and network access. Reverse engineer an environment already built and bake in configurations around security.
Automated vulnerability testing is an important part of the application development phase in that it helps identify security issues. Managing access rights and credentials is another important way to enforce necessary security practices. Besides these options, occasionally performing ethical hacking helps determine potential security flaws that could get overlooked in the normal course of development.

Here’s who shared their insights with us: