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:
- There will be no free lunch when it comes to cloud security services. Companies invest to generate (higher) paybacks. Cloud providers spending large sums on building services must refinance them with customer revenue.
- Security vendors have been in the market for decades and are continuously improving their software. In contrast, cloud providers are engineering from zero or acquiring existing vendors – costly investments for catching up before they can innovate.
- Microsoft’s $4 billion investment per year is not lightyears away compared with traditional vendors: Symantec reported over $4 billion in revenue in 2019, McAfee reported around $1.6 billion in 2020, and Fortinet reported $4 billion in 2022. However, revenue and investment are not the same.“Investment” is a nebulous term. It covers everything from engineering to marketing, acquisitions, and “free” customer training and consulting, potentially even certain operational costs.
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:
- Workload-related security tools inspect and protect virtual machines (VMs) and containers by looking at them at run-time and checking workloads before deployment. Anti-malware or vulnerability scanning are typical examples. Using cloud-native tools for these purposes implies the need to select alternative tools and integrate them when changing the cloud. Also, these tools can cause extra work and complications for application teams due to potential interoperability issues (e .g., caused by agents running on VMs).
- Cloud vendor-specific security features address risks specific to a particular cloud. When changing the cloud, the old rules and tools in this area become obsolete. For example, if replacing Azure Functions with AWS Lambda, IT departments must engineer and set up completely new solutions for AWS Lambda, whether their current implementation for Azure Functions works with cloud-native or security vendor tools.
- General security tools are solutions without tight integration or interactions with applications or a specific cloud. A prime example is a company’s security information and event management (SIEM) tool. It can run on any cloud or on-premises. However, suppose a company chose a cloud-native SIEM solution and now moves all of its workload to another cloud provider. In that case, the company must replace its cloud-native general security tools with new-to-identify and new-to-implement security solutions. In contrast, third-party security vendor tools running on VMs or containers require less migration effort and, thus, imply a lesser cloud-vendor lock-in.
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.
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:
- Finalizing the design and implementation of the cloud setup (without security features),
- The preparation of security tooling for the new cloud environment, and
- The deployment of applications to the 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).
In reality, the security tooling implementation often ends later than the cloud environment setup. Typical reasons for this are:
- Structural constraints. The cloud design tends to change during the project requiring adaptions of the security tooling.
- Third-party security tools. Deploying them on VMs or containers requires a somehow mature cloud environment; plus, there are the typical additional efforts when setting up (new) software in a new environment.
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).
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.