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

Sep 3, 2023 8 min read technical

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 and video. The website and the Youtube videos are NOT monetized.

As a cybersecurity professional, I have got to confess - I am writing this 2 part series because I genuinely asked myself,

How did cybersecurity industry end up with this mess?

And mess it is - because, with so many products (or product categories to be precise) I regularly come across customers that

  1. Just don’t end up using any of the products they really need.
  2. End up using too many products that address same areas (e.g. perimeter security). Leaving security holes across other areas (e.g. Vulnerability management, Threat hunting etc.)

So in this series, I am addressing how enterprises evolved and how security products categories evolved with them. And in the process briefly explain each of these product categories with examples.

If this is not your thing, you can stop now and blame Gartner, as more often than not - they come up with these categories (Kidding! 😀 but here’s their IT Glossary)

But, if it is your thing - let’s go -

Just remember, our goal is to protect following for an organization/ a company

  1. Company’s IT resources (also involves insuring continued access to them)
  2. Company data (Intellectual Property, Trade secrets, Transactions etc.)
  3. Employee data
  4. Customer data

🎯 Our fictitious organization throughout this post is going to be a Big Bank.

Chapter 1 - Back in the day -

So, about 10-15 years ago, typical infrastructure layout for such bank looked like following (I explain it in detail below the diagram)

alt

Let’s explain the diagram

  1. The bank has its offices, branches, HQ connected to its data center over MPLS (or direct p2p connectivity)
  2. The employees use desktops or laptops within the branches and can connect to the infra/ applications within DC directly over MPLS at offices.
  3. Remote employees login using Remote Access VPN (RAVPN) or VDI over RAVPN (explained below)
  4. The bank’s data center infra runs the following
    1. Exchange server and other productivity infrastructure for employees (chat, meeting servers etc.)
    2. Intranet and HR apps (Payroll, leave etc.)
    3. Servers running customer applications (e-banking website, ATM backend etc.)
    4. Any ERP/ CRM products needed for business are hosted here as well
  5. But in addition to that the DC also holds a stack of security products
    1. VPN concentrator for WFH employees to login into and bring them on to the corp network
    2. Firewall
    3. IDS/IPS
    4. Proxy server (to provide internet connectivity to employees and applications among other things).
    5. Any VDI (Virtual Desktop) infra that might be needed in case bank want some sensitive tasks only done via VDI and not via endpoints (desktops and laptops)
  6. Any developers (the bank might have) are developing, committing and deploying the code within the DC.
  7. All the traffic going to internet is hairpinned (notice the shape of yellow arrows) through the DC’s proxy server (Remember setting proxy.your_org_name.com:port in internet explorer ?? 😁 - Yes. That one.)

💡 The thing to note here is - Most of the traffic remained within the bank’s own network. As everything that was needed by the employees was within the company network (mail, chat, meetings, HR Apps, apps developed and deployed for the customers etc.). With only the customer consuming applications (e.g. e-banking deployed in the DC) over the internet.

This (having most of the traffic within the organizations own network) has since changed. But we will get to that later.

Notice that in the above diagram (and for that era in general) the security products required by our bank are limited and most importantly very straight forward and understandable. Let’s see what they were (for the most part)

  1. Firewall - based on list of allowed / not allowed addresses and ports (rules), a firewall will allow or drop packets. In our example above the bank has a firewalls for both north south (internet, branches and offices to DC) and east west (within DC) traffic.
  2. Proxy Server - Allows or denies connectivity to internet for employees and applications
  3. IDS/IPS/IDPS - Intrusion Detection and Intrusion Prevention System, Detects (IDS and IPS ) and can prevent (IPS) ongoing attacks on the bank’s network (viz resource within the network) based on various threat intelligence (like Mitre ATT&CK, suspicious files, domains, URLs and IP addresses etc.)
  4. VPN Infra (VPN servers, concentrators) - Used by WFH employees to connect to bank’s corp network.
  5. SIEM - Security Information and Events Management. An application/product that can ingest logs and alerts from all the above and any application that the bank runs and analysts can use to corelate this information to create security and performance related findings.
  6. Antivirus Software - Locally protected endpoints (employee desktop and laptops) from malware.

Now all of the products above were mostly available as physical appliances and some were available as VMs. The bank had to buy them and deploy into their DC. The vendors of such appliances obviously provided updates and support to the bank. Some big vendors also bunched the products (firewall + IDPS + VPN) into single product/ appliance.

⚡ So the world was simple. But then entered cloud. Both Productivity/SaaS cloud and the public cloud as well. And things got interesting. Let’s see how.

Before we do that, let’s understand what do I mean by “both” clouds

1. Productivity and SaaS cloud - Productivity cloud refers to employee collaboration solutions that enable an organization get off the ground and carry out day to day tasks. So emails, chat, meetings, storage and docs suites like Office365, Google workspace, Zoho workplace, Slack etc. These are delivered as SaaS solutions and an organization buys a subscription for these. SaaS (or SaaS cloud) is any solution that an organization uses (e.g. salesforce - a CRM/Sales product) and that is delivered as a SaaS (salesforce SaaS is called as lightning).

2. Public Cloud - Public cloud refers to the infrastructure (e.g. VMs and other low level services) that an organization rents to deploy applications for their own use or for their customers. For example, in our bank’s case, it can deploy their e-banking solution on a public cloud provider infrastructure (GCP, AWS, Azure etc.)

So now, let’s redraw our diagram for this new reality of our Bank.

Chapter 2 - Advent of cloud based productivity and solutions

Again, explanation follows below the diagram

alt

The new diagram shows -

  1. The data center deployments dwindled as most of the productivity and other applications moved to cloud
  2. For example the bank started using Google Workspace productivity suite (which provides Gmail for email, chat, drive for storage, docs, slides, sheets and of course Google meet) - the bank no longer needed the DC infrastructure hosting the exchange, chat and meeting servers.
  3. Bank’s CRM/Sales solution was moved to cloud as well with salesforce ligthning.
  4. Moreover, the bank deployed its customer facing applications on to a public cloud like GCP

But while the infrastructure changed a lot, the security posture and approach of delivering the security remained the same. Viz. Hairpinning traffic and using old security stack that was meant for DC based IT.

Issues with this approach

Access Inefficiency
  1. Notice that even after the DC being the fraction of what it used to be
    1. The employees still log in to the corp network (physically at branch or remotely via VPN)
    2. Their internet access is still via the proxy server
    3. Bank still maintains the very heavy and costly MPLS infrastructure
  2. Also notice, while most applications that the employees accesses (e.g. entire productivity suite e.g. Gmail, docs, Google meet and Salesforce Lightning for sales) are available directly on internet but even then, the employee traverses endpoint (laptop) -> VPN / MPLS -> DC -> Proxy Server -> Internet path. Introducing inefficiencies. And also leaves possibility for the employee to directly access the Sales/ CRM application (available on Internet) directly from his own (unmanaged) home computer or from work machine without logging into VPN!
Inadequate Security
  1. Shadow IT -
    1. Employee can open his own Gmail instead of corporate Gmail as the DC proxy server just allowlists mail.google.com and cannot differentiate between personal / corporate email.
    2. Employee can use some new tools like WeTransfer for file transfer that they are not supposed to use. Proxy server may not even be aware of this data exfiltration.
  2. Additionally, even for applications that remain on the data center, the bank continues to use moat or perimeter security - which means once the employee logs in from the branch or via VPN - they can potentially access EVERYTHING on the corporate network.

So clearly, using the same on premises / DC security stack is not enough / efficient for this new reality.

💡 And this lead to the creation of many of the security product categories and products that empower (and confuse) organizations today. Not all product categories (e.g. WAF) came out as a consequence of cloud but (as you will find out soon) - most did.

We are going to talk about them in the next part of this blog series.

Conclusion

The advent (and the sheer number) of security products (and product categories) can be traced to the way enterprise architecture evolved over the years. In this part we looked at anatomy an enterprise protected by hairpinning the access.

But, new solutions were needed with enterprise architecture changing fundamentally - viz. with productivity and public clouds' arrival and their widespread use. In the part 2 we are going to delve deeper into some of these products.

Thank you for reading through, Please like 👍, share 🔗 and comment ✍ if you found it useful.

-Nikhil

Further reading / listening

comments powered by Disqus