Customers migrating to Public Cloud (Azure, AWS, Google Cloud) are often lifting and shifting existing toolsets. Some customers have the misleading notion that a best of breed approach is better than using Cloud Native solutions. As a result, their cloud workloads suffer from security and efficiency gaps.
These 3rd party solutions rely on the visibility provided by CSPs APIs. However, each solution comes with its own set of limitations/blind spots. As a result, customers’ security becomes a combination of these blind spots, making it harder for security engineers and analyst to triage and respond to threats.
We will use Microsoft Azure (Azure) to demonstrate the advantages.
When transitioning to a public cloud platform such as Azure, the security attack surface undergoes a significant transformation. The attack surface expands as organizations relinquish some control over their infrastructure to cloud service providers.
In the cloud, various entry points, including virtual networks, APIs, and web interfaces, expose potential vulnerabilities. Misconfigurations in cloud settings, inadequate access controls, and insecure application designs can be exploited by malicious actors. The defense strategy, as a result, must evolve from a harder shell – a softer core requires a capable layered defense where each layer operates independently.
Additionally, shared responsibility models (https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility) necessitate careful consideration of security responsibilities between the cloud provider and the customer.
While cloud providers like Azure offer robust security measures, organizations must actively manage their configurations, monitor for potential threats, and enforce stringent access controls to mitigate the widened attack surface and safeguard sensitive data and applications in the cloud.
More often, customers leverage third-party solutions not to enhance and complement the cloud native security capabilities, but rather, to replace them. Customers often cite the following as key drivers:
In reality, CSPs often have more highly specialized resources with vertical expertise. These resources not only understand their security domain (application security, container security, governance, etc.) but also have deeper understanding of the Cloud. CSPs also have a large attack surface themselves and at a scale unlike most of their customers. As a result, the CSP not only sees issues from different vantage points but also have developed counteracting mechanisms that scale. It will be hard for a security vendor to meet these capabilities.
In reality, CSPs are exposed to a large number of use cases because of their diverse customer base. As a result, the CSPs have an inherent incentive for native solutions to accommodate their customer base.
In reality, Microsoft Defender for Cloud is a multi-cloud solution by design.
In reality CSPs, given their attack surface, have very mature practices that they often incorporate in their products, which are integrated by design. Microsoft Defender for Cloud and Azure Sentinel provide alerts, automated responses, and incorporate latest Threat Intelligence (https://www.microsoft.com/en-us/security/blog/topic/threat-intelligence/?sort-by=newest-oldest&date=...)
Microsoft, for example, has made AI and ML a core capability, and has devoted immense resources: https://www.microsoft.com/en-us/microsoft-cloud/blog/2023/11/07/come-build-with-us-microsoft-and-ope.... As an outcome that benefits customers, the native solutions are leveraging these AI capabilities (https://www.microsoft.com/en-us/security/blog/2023/11/15/microsoft-unveils-expansion-of-ai-for-secur...). Defender for Cloud has several alerts that are AI/ML driven (https://learn.microsoft.com/en-us/azure/defender-for-cloud/alerts-overview#microsoft-initiatives)
Microsoft also spends over $4B /year on Security, this is much more than any other third-party.
Most of the CSPs provide compliance assessment solutions as a native capability. Microsoft Defender for Cloud, for example, has a native regulatory assessment capability as part of Cloud Security Posture Management (https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-regulatory-compliance-standards). The solution also allows customers to write their own controls to extend out of the box capabilities.
As mentioned above, Microsoft Defender for Cloud is a multi-cloud solution that provides a unified security management capability (https://learn.microsoft.com/en-us/azure/defender-for-cloud/multicloud)
Microsoft has devoted large number of resources as part of the Secure Future Initiative. This new initiative will bring together every part of Microsoft to advance cybersecurity protection. It will have three pillars focused on AI-based cyber defenses, advances in fundamental software engineering, and advocacy for stronger application of international norms to protect civilians from cyber threats (https://blogs.microsoft.com/on-the-issues/2023/11/02/secure-future-initiative-sfi-cybersecurity-cybe...)
In summary, Customers’ desire to use third-party security solutions on public cloud platforms is often driven by the need for specialized expertise, customization, integration capabilities, advanced threat protection, and compliance adherence. In reality the native solutions can more efficiently fulfill the customer requirements.
Let’s talk about some issues that will impact customer’s capability for an efficient and more secure environment when they base their strategy on a best of breed approach.
The "best of breed" security approach involves selecting the most effective and specialized security tools from different vendors to build a comprehensive security posture. While this strategy has its advantages, it can also introduce security blind spots, particularly when applied to securing public cloud environments. Here are some reasons why:
This will never be an issue when using native solutions as the CSPs make sure the services work with each other seamlessly. For example, most of Defender for Cloud’s workload protection plans (https://learn.microsoft.com/en-us/azure/defender-for-cloud/workload-protections-dashboard) have push-button enablement, requiring no integration effort from Customers’ side. In most cases there is no reliance on an agent.
In contrast, when using the native security solutions, security teams don’t face a steep learning curve as the native solutions leverage other native services such as dashboards, responses etc. For instance, Defender for Cloud leverages Azure Policy for security recommendations (https://learn.microsoft.com/en-us/azure/defender-for-cloud/security-policy-concept) and Azure Monitor Workbooks for Dashboards (https://learn.microsoft.com/en-us/azure/defender-for-cloud/custom-dashboards-azure-workbooks)
When leveraging native security solutions, this will never be an issue as they have first party integrations by design. For example, Defender for Containers natively integrates with Azure Kubernetes Services and Azure Container Repository (https://learn.microsoft.com/en-us/azure/defender-for-cloud/custom-dashboards-azure-workbooks) as a result, changes in the Workload (AKS and ACR) will not require corresponding changes in Defender for Containers.
Defender for Cloud leverages Microsoft’s threat intelligence natively https://learn.microsoft.com/en-us/azure/defender-for-cloud/threat-intelligence-reports, https://techcommunity.microsoft.com/t5/microsoft-defender-threat/defender-for-cloud-and-defender-for...
Given the native solutions are first party and do not require changes to customers’ cloud environment, they do not introduce additional weaknesses.
This will never be an issue with native solutions as they are designed for efficient usage if customers’ cloud resources and often the heavy lifting is done within CSPs control plane. For example, in case of Defender for Containers the limits are predefined. https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-containers-architecture?tabs... Similarly, Defender for SQL on VMs keeps impact on customer workloads to minimal CPU usage, averaging 3% for peak slices, compared against benchmark loads. https://learn.microsoft.com/en-us/azure/defender-for-cloud/faq-defender-for-databases#is-there-a-per...
In contrast, when using the native security solutions security teams don’t face a steep learning curve as the native solutions leverage other native services such as dashboards, responses etc. For instance, Defender for Cloud leverages Azure Policy for security recommendations and Azure Monitor Workbooks for Dashboards.
Defender for Cloud builds upon Azure policy and provides single pane to manage the security of customers’ entire multi-cloud environment. So, customers can easily identify, diagnose, and respond to the security events.
A fractured cloud security control plane, characterized by a lack of cohesion and centralized management in security controls, can introduce various challenges and problems.
Security Analyst:
Security Assurance:
Security Engineering and Architecture:
Relying on a variety of security tools from different vendors may result in vendor lock-in issues. Migrating to a new solution or adapting to changes in the technology landscape becomes challenging when there is a lack of standardization and interoperability.
These solutions often leverage the capabilities that CSPs provide. When leveraging native solutions, the lock is not a major concern as the customer is already operating workloads on the Cloud.
Implementing changes or updates to security policies across a fractured control plane can be cumbersome. Coordinating changes across different tools and ensuring that updates are applied consistently can be a time-consuming process.
Additionally, in the event of a security incident, a fractured control plane hampers the ability to respond quickly and effectively. Coordinating incident response across different security tools and platforms may result in delays and increased impact.
When using Third party solutions it would be prudent for customers to keep in mind the motivations (https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/motivations#motivations) for migrating to the Public Cloud in the first place.
In doing so customers will realize that the third-party solutions often adversely impact these motivations, like so:
Customers often have negotiated steep discounts with CSPs based on their usage. When customers leverage native security solutions, the usage helps them leverage these discounts. Additionally, the third-party solutions often leverage the CSPs native APIs as a result customer pays both for API usage as well as cost of Third-Party solution.
As we discussed above, Third-Party solutions increase the overhead on customers’ teams as a result the agility decreases because of skill gap, fractured control plane etc.
Unlike native solutions, third party solutions do not scale with customers’ workloads as a result customers are required to either horizontally or vertically scale.
Native solutions provide resilience by design. However, the third-party solution require customer to implement resilience using architecture patterns.
Complexity
As we discussed above, the third-party solutions add complexity in customers’ environment due to integration, operation, and maintenance requirements.
We discussed the challenges that customers face when they use third-party solutions in their cloud environment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.