Operationalizing Security the DevOps Way
Companies are moving to cloud native development because it speeds up product delivery cycles and innovation. This is an exciting time, as developers can create complex applications, deploy them more quickly at scale, and deliver more value to customers.
But what does this mean for security? Security is challenged by cloud native development because current security methods introduce waste and slow developers down. No one has time to insert security processes or file a ticket for the security team to set something up. All too often, developers spin up new environments and deploy applications while security has no visibility or control.
The good news is that we have a new opportunity to operationalize security, empowering developers to deploy security on their own terms. In this blog post, I’ll discuss the current state of cloud native security, and describe how we can use Kubernetes to operationalize security. You can also download the whitepaper Operationalizing Security the DevOps Way that goes into more detail.
Why Security Is Left Behind
Cloud native development enables engineers to more quickly produce and iterate new versions of products, helping companies get ahead of competitors and increase profits. Ease and speed of development are both often higher priority than deploying security measures because the results of secure development may not be as clear or tangible as increased productivity and profits.
We need to empower developers to deploy secure services while the security team stays out of their way
Security vendors have not helped their customers by adapting their approaches to this new world. Security vendors are accustomed to selling into the security organization because in the past, companies had centralized control of acquiring, deploying, and maintaining IT assets and infrastructure. This was possible with homogeneous computing environments with slow rates of change.
This doesn’t exist in the cloud native world; developers can rapidly spin up new containers across different environments. And they don’t want to spend extra time using the traditional security solutions. Provisioning access, running a vulnerability scan, checking configurations – all take time. Filing a ticket to get help from another team – security or operations – interrupts their work.
This is why enterprise security vendors can’t meet the needs of cloud native development. They are looking for a single buyer with authority to push their software across the enterprise. It fails because the central authority and buyer is gone. It has been replaced by the developer, and the developer just wants to code and ship software.
The Current State of Security
When we talk to security leaders at companies, we typically see them falling into one of three tiers for how they are addressing security for cloud native development. In the top tier, there are a handful of elite companies known for reaching new levels of productivity and scale. They have security and operations teams with skilled staff who can cobble a mix of open source and in-house developed tools to ensure availability and security.
But few organizations have access to security and operations teams, or cloud native security experts. So there is a second tier of companies that may have a roadmap for security projects to secure cloud native workloads, but they may not have the expertise, time, or money to do them. Finally, the third tier of organizations knows it needs to do something to enable cloud native environments, but may not even know where to start.
Organizations shouldn’t have to spend time and resources building custom solutions. It would be better if companies had access to best of breed solutions so they could immediately secure their environments.
Developers care about shipping code. For DevOps and operations, developers care that their infrastructure works and is reliable. They don’t care about the set up or how it works – they just want it working. Successful operations and DevOps teams operationalize functional, reliable infrastructure – while staying out of the developers’ way. When they are successful, developers can quickly ship code, and the underlying stuff works.
We have the opportunity to do the same with security – operationalizing security the DevOps way. Developers can test early in CI/CD and fix problems directly, empowering them to deploy secure code while the security team stays out of their way. Security gets the information they need for visibility, reporting, and compliance, and developers keep shipping software, unimpeded.
More importantly, this gives all companies access to security for modern software development.
So what are the components of Operationalized Security? Here are the five requirements:
- Self-serve, easy to deploy SaaS. Security solutions need to be easy to deploy and consume with a pay-as-you-go model.
- Shift security work left to development in CI/CD. Empower developers to test and fix security issues early in development, without requiring them to have security expertise or specialized skills
- Centralized visibility and control. Operationalized security requires a centralized view of security activity across CI/CD pipelines – from code ownership, to testing status, to issues found, and remediation.
- Reduced work across teams. Shorten feedback loops for fixes, reduce the number of security issues deployed into production, and make it easier to track issues and alert owners directly to fix problems.
- Works within existing developer workflows and tools. The developer cannot be interrupted by forcing them out of their normal toolset.
At Soluble, we are using these five components to operationalize security. By providing a centralized platform orchestrating security tools that developers can use starting early in their CI/CD pipelines, we can help organizations meet their security and compliance objectives while enabling rapid innovation and delivery of product.
Contact us to learn more, or download our Whitepaper: Operationalizing Security The DevOps Way.