Barriers to DevSecOps Adoption

Current state

DevSecOps — or the merging of Ops and Security — has been at the center of discussion for the better part of the outgoing decade. Today, the complexity of infrastructure change, demands security and DevOps teams to work together more efficiently. But there are hurdles to adoption of DevSecOps as a methodology.

Cloud-native applications often live in multiple clouds across data centers, co-location, and public clouds. As a result, security and observability signals must pool in a central location in order to operate securely and reliably.

Security is essential, but during an outage or when short on time, it’s also often the first thing to go. These changes compromise security due to short-cutting processes such as disabling a firewall rule, removing an extra authentication check, or using a shared account.

Any and all of these actions will increase attack surfaces. When these attacks occur, we rely on security personnel to identify and detect the compromise, then work with other teams to remove the holes. 

Balancing DevOps and Security When Scaling

The hero culture is common across all technical teams, but it creates challenges when scaling teams. Visibility or the use of specific DevSecOps tools are often the domain to those with the right skills and status versus using tools that can merge diverse security signals effectively.

The data which we must analyze comes from servers (containers, VMs, and platforms), networks, storage systems and security infrastructures.

On the end user side, data collects from endpoints. Those endpoints run as embedded or agent technologies on user devices from desktops, laptops, and mobile devices.

These environments house a dizzying array of application. They have variable and non-standard designs due to differences in age and in who implemented them. 

It’s impossible today to understand all the threats facing an organization. That is, it would be sans correlating data across multiple infrastructures and applications to find bad actors on the network. 

Right now, security teams have their own budgets, which are used to buy tools specifically for security, but other teams rarely use these tools.

Security tools cater towards the expertise and language of the security professional versus the generalist who is increasingly being called upon to secure, remediate, and determine vulnerabilities and compromise.

Ideal State

Today’s IT organizations have more generalists than ever; we require people with broad expertise — because of the diversity of technologies and the pervasive use of the cloud — so engineers need to know a little about everything. 

Specialists such as members of the security team are essential, but generalists must use the security tools to ensure we meet the organizational needs. Tools alone are not enough, though. We must couple them with training, education, and best practice guidance.

During our most recent Logz.io strategic advisory board, we heard from DevOps customers that they’re bearing more security responsibility. It’s on their shoulders to manage remediation, research, and the analysis of security signals and data. This confirms that DevOps teams — and generalist teams — are taking on more responsibility for security. 

Between Generalists and Security Specialists

Security is everyone’s job. We all run educational programs for users that make sure they understand that we all must secure our assets.

The vigilance we must all have should always be paramount, as we must think about our customers. Protecting their data is essential to business success.

Similarly, security tools should be in use across organizations. That way, all teams are aware of the current security situation. It facilitates the protection of customer data and the reputation of the organization.

Often security teams will say the tools have sensitive information which is why segmenting and setting permissions is critical.

This is the reason Logz.io is a cloud-native multi-tenant service. But, each customer and account is also multi-tenant allowing you to handle any advanced use case.

Embedding Security Pros in Every Team: Future state

Getting security in alignment with product and business initiatives will create more value and protection for the organization. Security specialists should be embedded where necessary, based on the products and projects in flight.

Having this type of dynamic team is unnatural for many organizations, though, since resources in this dynamic model are not tightly managed. As a result, we have to place some trust that staff members will do the right thing.  

Dynamic Teams

One way to build dynamic teams is to have these specialists impart expertise in a concept typically called augmented teams. 

This method is one way that advanced organizations like Google get better security across the organization. They have a team of specialized security Site Reliability Engineers (SREs) who are both operational specialists and programmers who spend time on security work.

They receive assignments to various teams based on their current initiatives and how critical the work is to the business (along with the risk levels of the relevant engineering work). In larger organizations, this will probably become the de facto way that security is integrated into generalist teams as this trend expands. 

SREs’ role have steadily grown in ops-based organizations over the last four years, since Google released its first SRE guide. In 2020, Google and O’Reilly published the third SRE book, this time with a focus on security and resiliency.

Security in the Background

The second future trend is that security will fade into the background. In other words, it will be virtually invisible as it embeds within virtual networks by more advanced methods. This is something we’re seeing with secure access service edge (SAASE) technologies, critical to today’s growing remote workforce. These cybersecurity technologies combine VPNs, single sign-on, firewalls, and other security services into a single offering. 

As these new offerings mature, this trend of embedded security will accelerate, creating new ways to observe, secure, and manage the expanding enterprise network. 

Additionally, automation will increase. One example of this is by leveraging Security Orchestration Automation and Response (SOAR) tools to orchestrate complex workflows and responses. 

However the number of organizations using SOARs will still be a small subset of companies since there needs to be a certain level of operational maturity on teams to implement these sorts of sophisticated,active response automation tools (beyond what vendors embed directly). 

Many managed security service providers (MSSPs) — as we see among Logz.io’s customer base — are using these kinds of automation systems for active responses and workflows. 

The Promise of DevSecOps Adoption

Finally, the last future state trend is that the promise of DevSecOps adoption will only happen as we embed security into DevOps pipelines and automated systems we use to build and release code. The use of open systems to consolidate security signals will drive pipelines to enable more secure systems by default. In parallel, this will allow us to operate them with high availability and security. 

The need for cloud-native SIEM is already critical to organizations. With generalists taking over more security responsibilities, there will be more change in the security market. Stay tuned for more innovation.