When To Go Cloud-Native and When To Buy a Security Vendor Solution

A fundamental decision for cloud security architects is how much to rely on the cloud-native security tools of their cloud provider, be it AWS, GCP, Azure, or any other provider. “As much as possible” is the wish of cloud engineers, while security specialists tend to prefer third-party security vendors. Many security specialists implemented and worked with vulnerability management, anti-malware, or data loss prevention tools for many years; why not use the same tools in the cloud? It is a clash of cultures, and the following six theses are designed to help move from emotion-based to fact-based architectural decision-making.

Thesis 1: Cloud Vendors Are Neither Charities nor Superheroes -- They're Marketing Geniuses

Cloud providers know how to get good press. In 2021, Microsoft promised $20 billion in investment in security over the next five years. Will IT departments have to implement Microsoft’s security, and nothing else? Here are three thoughts:

Related:Why 'Data Center vs. Cloud' Is the Wrong Way to Think

The message of this first thesis is simple: Do not give up on security vendors yet. Cloud providers are significant players in the security business and might become dominant. However, at this moment, it is too early to assume, by default, that cloud providers have better or more cost-effective tools.

Thesis 2: Cloud-Native Security Services Create or Worsen Cloud Lock-Ins

Cloud-native security tooling can hinder moving workloads from one cloud provider to another (lock-in). Such cloud-provider lock-ins might violate regulatory requirements or contradict IT strategies highlighting the necessity to be able to change clouds with manageable effort. The lock-in can come in different ways:

Related:5 Considerations for Migrating Data to the Cloud

Figure 1 - Security tooling types from a lock-in perspective

Thesis 3: Switching On Everything Is Not a Security Strategy

Spending $300 in a grocery store does not guarantee a deluxe dinner. Ingredients have to fit together, and you have to know how to cook. The same applies to cloud security services. Switching on all does not ensure adequate security. Up to now, cloud providers emphasize the benefits of (paying extra for) every new security service and highlight their customer’s responsibility for a secure cloud setup. No cloud provider promises you are adequately secure when you switch on all its services. Therefore, IT departments should continue to identify their major risks and select adequate solutions to mitigate them rather than getting lost in features of mildly relevant cloud-native security services that are easy to activate and hyped by cloud vendors.

Thesis 4: Compare Service and Cost Models, Not Context-Less Numbers

Comparing the benefits and initial and ongoing costs of two or more IT solutions was always tricky -- comparing cloud services and third-party software adds another dimension. For security solutions, challenge one is understanding which threats and risks the solutions under consideration address and how comprehensive they are. Does the data loss prevention solution only look at email or also at HTTP traffic? Is the solution able to handle encrypted communication or email attachments?

Second, companies must understand the operational processes and associated costs for executing them with a particular solution. Can a junior IT technician supporter configure and manage the firewall rules, or do you need two senior security architects? For a DLP solution, the false positives ratio is crucial. If the tool generates only ten incidents per day, staffing costs are lower than if there are 1,000 false positives.

The next cost category covers configuring and integrating the solution with the rest of the IT architecture and ongoing maintenance (“application management”) costs. This cost category applies to self-hosted and cloud-native solutions. In contrast, one cost category differs between self-hosted and cloud-native solutions. Suppose an IT department self-hosts software, whether in the cloud or on-premises. In that case, there are hardware, computing resources, and operating system-related expenses, license and maintenance fees, and application operations efforts. In contrast, the service charge for cloud-native security services covers all these expenses.

So, understanding costs and benefits is tricky, but the mentioned categories and the visualization in Figure 2 provide a helpful structure.

Figure 2 - Cost-benefit analysis for security vendors and services

Thesis 5: Distinguish Solutions for Main Workloads and Niche Topics

As a rule of thumb, third-party security vendor tools come with higher fixed costs than cloud-native services due to the integration and application operations efforts. They are simply absent or much lower for cloud-native services. Suppose a company runs just two Linux applications; the rest of the workload is on thousands of Windows VMs. In such a context, cloud-native tools might be an effective solution for the Linux workload. In contrast, self-hosted third-party security solutions might be an option for the main workload on Windows. The take-home message: cloud-native tools are, cost-wise, unbeatable for niches.

Thesis 6: Don’t Let a Security Strategy Block Your Cloud Security Today

Cloud-native security tools are up and running much quicker, at least rudimentarily,  than third-party security solutions. Features might be limited, and extra staff may be needed due to missing interfaces, integration, and automation. However, a quick-and-dirty security solution is better than no protection. Quick-and-dirty enables going live with a new cloud environment early while actively managing and mitigating security risks.

Three milestones are crucial when setting up a new cloud environment:

Ideally, the security architecture development and tool implementation runs parallel with the cloud environment’s set up, allowing application deployments and productive cloud usage soon after the setup finishes (Figure 3).

Figure 3 - Ideal ordering of cloud environment and security tooling setup allowing for an early start of application deployments and cloud usage

In reality, the security tooling implementation often ends later than the cloud environment setup. Typical reasons for this are:

Companies can overcome delays caused by unready third-party security tools (but not by the structural constraints) by temporarily relying on cloud-native security services as a tactical solution. Their pay-as-you-go and quick-to-use nature makes them perfect tactical options. In parallel, engineers work on the strategic security tools that the company switches when they are ready to use (Figure 4).

Figure 4 - Distinguishing between tactical and strategic cloud security solutions to ensure a secure yet early “go live”

Tactical versus strategic solutions, cloud-native versus third-party security vendor tools, and many other dimensions matter. Designing a security architecture for cloud environments is a complex puzzle. Fun for most security architects and bothersome for others. In any case, these six theses can help to overcome a clash of cultures between cloud and security specialists when choosing between cloud-native and third-party security vendor solutions.