Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

// // //
3/26/2021
10:00 AM
Steve Quane
Steve Quane
Commentary

Moving from DevOps to CloudOps: The Four-Box Problem

With SOC teams running services on multiple cloud platforms, their big concern is how to roll up configuration of 200+ servers in a comprehensive way.

There have been problems with organizational silos forever, namely with siloed teams not working together well. That might be why siloes began. But one of the most common organizational disconnects I've seen over the past 5+ years is security teams versus developers. We called this the Two-Box Problem. 

There were two groups responsible for different aspects of the company's software and products. Developers care about making their code work, and security teams care about their code only working as intended. You can see where this is going: Major clashes drove a wedge between the two teams. And this dilemma only gets worse with cloud migration.

Related Content:

5 Strategies to Secure Cloud Operations Against Today's Cyber Threats

Special Report: How IT Security Organizations Are Attacking the Cybersecurity Problem

New From The Edge: Does XDR Mark the Spot? 6 Questions to Ask

The introduction of DevOps created a Three-Box Problem.

Developers want to be fully focused on code, so the DevOps function took on the operational responsibilities. And security is an operational function.

The DevOps model has huge benefits to organizational functionality, impeccably outlined by Gene Kim in his books. These include open communication, a positive work environment, and dismantling silos.

However, security is still a problem in the DevOps model. Historically, security tools were built for security teams. With the Two-Box Problem, security teams were solely responsible for choosing and using security tools. But with the Three-Box Problem, DevOps teams now have that responsibility.

This isn't ideal when security tools are still designed for security teams. DevOps folks might not be coding every day, but they think like developers and don't want clunky tools with pages of documentation. 

Security tools also require input from developers, which hasn't changed since the Two-Box Problem. Only the responsibility shifted from security to DevOps. The core challenge of developers versus security persisted. 

With complex cloud infrastructures, DevOps teams are focused on much more than security. They're focused on overall orchestration and process management.

Some businesses have found a solution to circumvent this challenge. Enter CloudOps and the Four-Box Problem.

Enterprises with CloudOps teams have a lot of cloud infrastructure with a multicloud strategy. They change the dynamic faced by previous models by including security. With the Four-Box Problem, developers are only responsible for coding and DevOps is responsible for the continuous integration and continuous delivery (CI/CD) pipeline.

CloudOps teams care about agility and elasticity. Optimizing architecture, cost management, compatibility, and cloud operational excellence are their main charter.

Security controls are not their priority, but they are part of the game. Security for CloudOps is centered around cloud security posture management (CSPM) rather than patching and other classic security challenges.

These teams are running services across all three major cloud players. They're less worried about each server configuration, but how to roll up the overall configuration of 200+ servers in a complete way. 

Watching this evolution has left me wondering, "Why all the shuffle?" What is the core problem that leads businesses to reallocate so many resources and responsibilities? 

It comes down to the initial reason for the Two-Box Problem. Teams want to only focus on their core responsibility. Which sounds great — people are motivated to do their jobs. But not wanting to talk to other people creates a problem as businesses are made up of countless teams that must work together for the business to function. 

The Four-Box Problem stems from years of painful conversations, broken processes, and dead ends. CloudOps teams have some security functionality in their team, and they talk to the security team when there is a problem to address. This "talking" is a ticket system, but it's still interteam communication. 

When security (or security operations/SecOps) scans the infrastructure to make sure all cloud environments are secure, they send notices to CloudOps of any problems. CloudOps gets the alert that states the problem, who is responsible for it, and how to fix it.

This looks like technology solving a people problem. By automating the whole chain with a ticket management system, security problems are addressed without the security team talking to the development team. 

Regardless of the implementation, the core concept remains the same — no-touch, fully automated security. 

No matter the approach, companies are looking for security solutions that can plug into this ideal automated ecosystem.

Are We Stuck With the Four-Box Problem?
I don't think so. CloudOps will likely add more traditional security functions, like incident response, making all things related to cloud infrastructure management centralized under one independent function.

That would be a big change — like a mini-cloud SOC within CloudOps. 

With such a change, we might see the problem knock back down to only two or three teams involved in security. If a CloudOps team manages all cloud infrastructure security, as well as the overall agility and orchestration, they may only work with developers through a ticketing system to fix specific code issues. A modification would be Three Boxes for CloudOps, Developers, and DevOps if runtime and CI/CD pipeline management remain separate.

This constant evolution of org structure and security responsibility makes it tough to effectively staff a security team or design a workable security stack.

My advice for all the security folks out there: Learn something about cloud environments. There's no going back from digital transformation, and you will be best suited if you can secure cloud infrastructure. The need for security isn't going anywhere — it's increasing. Developers, DevOps, and CloudOps all need the security person's mindset to work within their org structure and ensure business data remains secure. 

Steve is responsible for the global strategy and execution of Trend Micro's Hybrid Cloud Security and Network Defense solutions. Since joining Trend Micro in 2001, Steve has held a variety of roles including Chief Product Officer and Chief Marketing Officer. He also worked ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-33196
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
CVE-2023-33185
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
CVE-2023-33187
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
CVE-2023-33194
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
CVE-2023-2879
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file