23. Part 2/2 - Why are there so many cybersecurity products and what do they *really* do?

While I worked at Google during the publishing of this post / video. The views expressed here are my own and may not reflect those of my employer. Only publicly available material is used to put together the content of this article.

In the part 1 of this series, we looked at what lead to creation of newer security product categories. In this part, we are going to delve a bit deeper.

Chapter 3 - Next Gen Products (Iteration 1 - Addressing Security)

As we have seen in the previous chapter, the security products were inadequate for the new cloud reality. So various security vendors came up with newer security and networking products.

But, Rome was not built in a day! (And, also, old habits die hard!) There were a few iterations before we reached the current state of security products and their delivery.

Following diagram shows the iteration 1. Again, explanation is below the diagram.


In this iteration,

  1. New security product categories (e.g. SWG/NGSWG/CASB, NGFW, EDR/XDR etc) were created to secure cloud in addition to on premises
  2. But most of these solutions were still deployed in the data center requiring hairpinning of the traffic (traffic to productivity and public cloud and internet) through the data center.

So while improvements to security posture were done; There were network inefficiencies (As the user traverses Endpoint (e.g. laptop) -> VPN (in DC) -> Internet -> Cloud instead of Endpoint -> Cloud).

So let’s talk about some of these modern solutions.

Next generation Firewall (NGFW) - NGFW is an evolution of traditional firewall where in addition to filtering traffic based on source and destination alone, it can filter traffic based on application awareness, automated threat intelligence (bad IPs, URLs, Well known Tactics and Techniques ). They also perform ID/PS and deep packet inspection. Moreover, they allow organizations to define policies based on specific applications and user groups.

SWG/NGSWG & CASB - We can consider Secure Web Gateway (SWG) as the evolution of the traditional proxy server - providing URL filtering, malicious-code detection and filtering, and application controls for popular Web-based applications in addition to standard web filtering of a proxy server.

NGSWG is the next generation of SWG and CASB being the next generation of SWG/NGSWG for the most part, however CASBs mainly provide visibility, compliance, data security and threat protection for your SaaS and productivity cloud (check more here).

While, ideally both NGSWG and CASB are supposed to be deployed in cloud (iteration 2, below) instead of on-premises, many organizations still prefer to deploy these products as appliances on premises.

Note - Proxy Server, SWG/NGSWG/CASB generally protect traffic between user endpoints(laptops, desktops) and web and productivity cloud. CASBs can go one step ahead and protect your productivity cloud tenant as a whole (e.g. don’t allow malicious uploads to Google drive, Allow downloads in accordance with GDPR, restrict access to personal Gmail but allow access to Corp Gmail etc.). NGFWs on the other hand protect server type endpoints (application and web servers, DB servers, SAP deployments, servers used for AI/ML training etc.).

EDR & XDR - EDR (Endpoint Detection and Response) evolved from traditional antimalware/antivirus solutions by expanding their focus beyond signature-based (signature - examples) malware detection. EDR enhances threat detection by continuously monitoring endpoints for suspicious behaviors and activities, offering real-time visibility into potential threats. It incorporates advanced analytics and machine learning to identify complex threats, making it more adept at detecting zero-day and targeted attacks. EDR also provides in-depth forensics and response capabilities, enabling organizations to investigate and mitigate security incidents comprehensively.

Extended Detection and Response (XDR) is an evolution of EDR that expands its scope beyond endpoints to include other parts (or domains) of the IT environment, such as network traffic, cloud resources, identity and email systems. XDR aggregates and correlates data from multiple sources to provide a more comprehensive view of potential threats and to enable more effective threat detection and response.

So in this iteration (iteration 1), the products were upgraded to protect the cloud and the DC. But for the end user (employees), they still had to use VPN to log into the corporate network or had to be in offices/branches/HQ.

In addition to network efficiency, this access pattern allows a much wider access to the resources. For example, let’s check what options does an employee have to access server (e.g. over SSH) within their public cloud VPC.

  1. Access servers directly over the internet (don’t do it)
  2. Access servers over a private connection (site to site VPN/ Direct Connect/ Interconnect) between corporate network and public cloud VPC
  3. Access servers behind an NGFW by logging onto the VPN provided by that NGFW

Option 1 is the most insecure as it requires your infrastructure exposed over internet. Options 2 and 3 while more secure, allow the employee (potential) access to everything within the cloud VPC, they also require additional products and configuring them.

So network inefficiency (adding to costs and suboptimal user experience) and less than granular access to resources needed to be addressed.

πŸ’‘ This model of deploying modern security solutions in the data center is still quite pervalant. Organizations frequently value control (of network traffic) over network efficiency and granularity of the access (which results in less-than-optimal security).

Chapter 4 - “Next” Nextgen products (Iteration 2 - Addressing - Security, Network Efficiency, Costs and Posture management)


Iteration 2 differs from iteration 1 in following aspects

  1. Security solutions are delivered as SaaS wherever possible
  2. There is little / no hairinning of the network traffic through the data center, especially for the remote users.

So let’s briefly look at the security solutions mentioned in the diagram.

SASE/SSE - This link explains it the best (so just pasting it below).

SASE (Secure Access Service Edge) uses a software-based virtual network to create regionally distributed points of presence (PoPs) that provide nearby secure networking and cloud-based security functions (CASB, SWG, ZTNA, FWaaS etc.) to branch offices and remote users. SASE brings security and networking geographically closer to users, cuts down lag and latency, eliminates the need for a company VPN, abolishes the obsolete perimeter model and lets organizations shift from on-premises to cloud-based security solutions.

SSE (Secure Service Edge) is a subset of SASE, eliminating the SD-WAN but retaining the CASB, FWaaS, SWG and ZTNA functions. It also retains PoPs, which can be connected over the internet using ZTNA policies rather than via an SD-WAN.


ZT/ZTNA - Zero trust is a set of principles, a philosophy, culture and way of operating your infrastructure. It is based on the phrase Never trust, Always verify. So every resource request must pass

  1. Authentication
  2. Context verification (context is roughly defined as - user and device information, device security posture, access pattern with respect to the user’s access baseline etc.)

Instead of providing full lateral access by means of a VPN, access based on evaluating ZTNA (Zero Trust Network Access) access policies can provide a more granular level access without using VPN. ZTNA can be coupled with other security functions (e.g. CASB, Private Access etc.) to fortify them.

PA - Private access is required in two main scenarios (check diagram). Accessing the instances/applications within the cloud VPC or Accessing instances/applications within the data center. With modern private access solutions, a private access publisher is deployed within the VPC and the DC and the users can connect to it using a private access gateway which could be same as your SASE/ SSE gateway after ZT/ZTNA policies are verified. So the question that we tackled in previous chapter (how to access a VM), can be easily solved by PA. In fact with PA + ZTNA policies, organizations can allow certain employees access only certain VMs within a VPC.


  • CSPM (Cloud Security Posture Management) tools ensure that organizations setup their cloud environments (e.g. AWS, Azure, GCP) securely according to best practices of respective cloud provider. E.g. Do not allow SSH to VMs over public IPs.
  • These tools also scan organization’s cloud configurations for misconfigurations, vulnerabilities, and compliance issues.
  • Basically, CSPM solutions check if cloud settings follow security rules. Some cloud providers have inbuilt CSPM tools, for example Amazon Trusted Advisor.


  • SSPM (SaaS Security Posture Management) solutions secure and ensure compliance within SaaS applications.
  • This includes monitoring user activities, data access, and compliance settings in applications like Office 365/Google workspace, Salesforce etc.
  • SSPM ensure employee/user activities within SaaS applications are safe and compliant.


  • CWPP (Cloud Workload Protection Platform) tools help secure the workloads (applications, processes, and services) running within an organization’s cloud environment.
  • They offer real-time monitoring, threat detection, and vulnerability management for cloud-based workloads.
  • CWPP is a dedicated defender for the programs and processes running within your cloud setup.


  • CNAPP (Cloud Native Application Protection Platform) refers to security measures that focus on protecting cloud-native applications specifically designed to run in cloud environments.
  • These platforms provide security features like runtime protection, vulnerability scanning, and container security for applications built using cloud-native architectures.
  • Imagine CNAPP as a shield that’s tailored to safeguard applications designed to take full advantage of the cloud’s capabilities.

On the face of it, both CNAPP and CWPP seem very similar - CWPP tools focus both on applications that could be traditional applications ported to cloud (lift and shift) and cloud native (e.g. microservices, serverless applications) applications. CNAPP on the other hand, is ideal for securing applications that are purpose-built for the cloud and use modern cloud-native technologies.

CNSS* - While this is not really a defined category, Cloud Native Security Services (CNSS) play a very important role in securing your public and productivity cloud. We will delve a bit deeper into those in the next chapter.

Chapter 5 - The role of Cloud Native Security Services (Brief)

Every cloud provider has its own set of security services suite. This applies to both public and productivity (or SaaS) cloud. In case of productivity cloud security is mostly a matter of configurations, settings and best practices (e.g. Google workspace - Security checklist for medium and large businesses).

In case of public cloud however, security is provided by distinct services (called as 1st party solutions) and partner integrations (3rd party solutions).

Since cloud native services are not the focus of this blog, let’s just wrap up this part with a comparison between GCP and AWS security serviecs. Let me know if you are interested in a separate detailed blog series for public cloud security services.

Sr. No.AWSGCPDescription
1.Identity and Access Management (IAM)Google Identity and Access Management (IAM)Access control and security policies management.
2.Amazon GuardDutyCloud Security Command CenterThreat detection and security monitoring.
3.Amazon MacieCloud Data Loss Prevention (DLP)Automated sensitive data discovery and protection.
4.Amazon InspectorGoogle Cloud Security ScannerAutomated security assessments for applications.
5.AWS WAF (Web Application Firewall)Google Cloud ArmorProtection against web application threats.
6.AWS Firewall ManagerGoogle Cloud Armor (Centralized Management)Centralized management of firewall rules.
7.AWS Key Management Service (KMS)Google Cloud Key Management Service (KMS)Encryption key management.
8.AWS Certificate Manager (ACM)Google Cloud Certificate Authority ServiceSimplified SSL/TLS certificate management.
9.AWS Security HubCloud Security Command Center (Integrated View)Comprehensive security alert and compliance view.
10.AWS Secrets ManagerGoogle Cloud Secret ManagerSecure and manage sensitive information.
11.Amazon DetectiveGoogle Cloud Security Command Center (Forensics)Security issue investigation using machine learning.
12.AWS Control TowerGoogle Cloud Organization PolicySimplified governance of multi-account environments.
13.AWS PrivateLinkGoogle Cloud Private Google AccessPrivate connectivity to cloud services.
14.AWS Identity ServicesGoogle Cloud Identity Services & Workforce Identity ServicesIdentity management and authentication.
15.Partially with Amazon CognitoGoogle BeyondcorpZero Trust Enterprise Security
16.NAChronicleCloud-native SIEM and Security Operations Suite

We can conclude this chapter with following learnings

  1. Cloud providers have various security services to improve the security posture of their customers. Some of these are first party services and others are partner solutions integrated with the public cloud (and generally sold/subscribed via marketplace)
  2. The focus is always to move the security to the left (towards the cloud provider) and the emphasis is to provide secure by default services. Although with the shared security responsibility, customers are supposed to configure their cloud environments according the best practices of the corresponding cloud provider.
  3. When it comes to public cloud in addition to security, sovereignty and compliance are becoming important concerns. Please check out the sovereignty blog series if you need to learn more about that.


Security product categories and mode of delivering security has changed a lot since past few years. It helps to understand how we arrived here to keep track of new changes in enterprise security. This blog series while not comprehensive, should provide the reader that perspective.

Thank you for reading through, Please like πŸ‘, share πŸ”— and comment ✍ if you found it useful.


Further reading / listening

comments powered by Disqus