No matter what you sell, if you’re in the cybersecurity game, you’ll likely fall into the bucket of preventing incoming attacks or preventing your users from triggering a mess by clicking on the wrong thing. In this article, I want to walk you through history and try to shed some light on the ingress traffic vs. egress traffic paradigm and how CISO’s focus shifted from securing servers to securing users.
Ingress traffic vs. egress traffic
To provide a solid framework for later discussion, let’s first define ingress and egress traffic and their security risks.
Ingress traffic refers to incoming traffic entering your network (servers) from an external source, usually the internet. This can include incoming requests to a web server, data sent to a network from an external device, or any other form of inbound traffic.
To give you a quick overview of the security risks associated with ingress traffic: CVE exploitation, scans/scouting, or your exposed surface, credential brute force and reuse, SQL Injection and XSS, Denial of Service (DoS) and/or Distributed Denial of Service (DDoS) attacks that overwhelm network resources, and unauthorized access by hackers exploiting vulnerabilities are a few of the most common Ingress-related security risks.
Egress traffic, on the other hand, refers to outbound traffic emanating from your network (usually LAN) toward the Internet. This includes data sent out from a network to external clients, outgoing requests to external servers, or any other form of outbound traffic.
Egress traffic security risks are usually associated with data leaving a network and include data exfiltration (sensitive information is stolen and sent out of the network) and Command and Control (C&C) communications from malware within the network receiving instructions from external servers. Leaking information, whether accidental or intentional, can lead to the unauthorized sharing of confidential data. Once a machine is compromised, it can start sending out spam or phishing emails, damaging your reputation as an organization and your security posture. However, one of the most dire consequences of compromised systems is to let your user download dangerous content from unchecked sources.
The story so far
Before we discuss the ingress vs. egress, let’s backtrack two decades to understand how we arrived at this situation.
I recall being an engineer on the school bench, learning my trade in the late 90s. Teachers insisted that IPv6 was tomorrow, and we needed to prepare for it. In those glorious days, it was pretty frequent that an administrator would confuse the LAN, WAN, and DMZ interfaces and just configure the whole firewall inside out.
But what were the main challenges for sysadmins back then (we had no CISO)? I mean, apart from IPv6 mass deployment being delayed 15 years? Some brute force attacks, maybe? ‘Free’ vulnerabilities waiting to be discovered by anyone capable of using a debugger? Weak default settings?
Sneezing strong enough would grant you a free shell almost anywhere, even more so if you had some ME version of Windows. For Christ-sake, this OS thought a minute lasted 100 seconds, and the rest was even weaker.
Honestly, even some aspects of my student “sentimental” life benefited from that state of affairs. In my defense, I was left unsupervised, and university servers seemed to have an extremely strict “no cybersecurity” policy. Those were good old times, really, when even Law Corpus wasn’t anywhere near describing what a “digital” was.
It was not about ingress, egress, CVE, or user training; we were a trustable community of happy few. A client of mine who used servers for bank transfers had “Mamba” as a password… for five years! Science fiction-grade attacks were Kevin Mitnick inventing MITM and ARP-spoofing.
Internet transitioned to business
Then came the 2000’s were companies started to do business with the Internet. I was in the front-row seat during the Dotcom bubble. Infrastructures were popping everywhere, and we were missing professionals on a magnitude that changed our status from “the IT guy in that creepy office” to “gimme that corner office and a secretary if you want me to stay for 3 months”.
Companies started to expose themselves to the rigors of the Internet. They also started to put barely configured Apache servers online, totally unsecured mail servers, and halfway finished pieces of equipment and code. Money was flowing and digitalization walked its course. I was a red team pentester back then, and our success rate was north of 99%. You know, this kind of “I’m the master of the world” feeling, just without Kate Winslet, but, all things considered, a better outcome.
The real issue at that time was the lack of procedures, safe defaults, and administrator education. Back then, ingress was everything. You would want, above all, to avoid bad packets or requests flowing in the wrong places. LAN security was a futuristic concept, but we started to see people take the DMZ problem into their own hands. Where money flows, security rises.
The memory to keep here is a Matrix-like image; you’d want to dodge bullets shot at you or stop them if you couldn’t.
Then came “the user”
And with them, a cohort of new problems.
We’re roughly halfway through the 2000’s, with websites popping everywhere. We even had some inspired “authors” (developer would be an overstatement) convinced that “their security model” would be the best. Like in the “on this authentication form, I’ll download the whole user/pass list from the server and compare them locally with the user input” type of model… I should have created some form of Digital Darwin Award back then.
Beyond creative coders, we had insecure languages and poorly trained users. And PHP, and Ajax, and browsers. What could go wrong really? If any storm was ever perfect, this one seemed to have been the mother of them all.
Browsers were becoming as popular as they were vulnerable. People wanted to work in one uniform window, not switch constantly from one interface to another, and this, conjugated with the cloud, gave rise to the SaaS, but let’s not get ahead of ourselves.
A ton of effort and investments were directed into Web Application Firewalls, CDNs, RASP, and browser-side security mechanisms. The browser was the honey jar of any 2005-2015 pentester. This eventually came to an end, but boy was this party one to remember.
Retrospectively, the important momentum was social. It was to bring everyone to the internet table — the young, the old, the blue-and-white collars, everyone. It was a noble objective as such, but with many users being gullible targets with zero digital education, the browser became the main pond where to phish users.
The battle was no longer about ingress; it was about avoiding the possibility that your users would click in the wrong place, and their workstation would become the headquarters of wannabe cybercriminals.
The rise of phishing
Curiously enough, the real email disaster came after. I wouldn’t entirely understand why because, technically, what was done during the 2015-202X period could have been done much earlier. And I can testify of this directly because, with my fellow CTO (Thibault Koechlin), we were already using those phishing and spear phishing techniques with advanced homemade malware using DNS tunneling to evade any filtering back in 2010.
Yet, the real massive ramp-up of cybercriminality based on phishing struck hard after the browser disaster. You can probably find a million articles on this, but you can read a couple of good ones on Technopedia and InfoSec Insights. The stake here for CISO was to prevent users from leaking secrets, clicking on the wrong type of assets, dodging bad attachments, and all that jazz. Companies providing email security were flourishing, and rightfully so. The focus shifted from ingress even more toward egress. It wasn’t any longer about who tried to connect to your servers but much more about who your users were trying to interact with.
Brilliant protocol the email one is. Most users still think that if they received an email from neil@moon.org, it’s probably that Neil Armstrong isn’t dead anymore, so why even think mankind landed on the moon in the first place! Flat-earthers are probably just disgruntled users of the mail protocol.
Owning an infrastructure also started to make much less sense. The many-core revolution drove the virtualization of the hardware, opening the cloud era. And with it, a promise to cut your spending by 10x less facto compared to your good-old bare metal servers. Well, the first two years maybe it worked, then the trap closed on them, but everybody jumped into it head first. Remember, all the hyper-scalers are here to “make you consume less.”
Then, an evil genius decided that stealing data and reselling them was kinda lame and that monetizing this work through cryptocurrency by cyphering everything and asking for a ransom would be more profitable.
With ransomware on the rise, the CISO’s mission became mostly to “make sure John doesn’t click on a dodgy link and, if he does, that the house doesn’t turn in a data-cyphering firework.” Ingress? Nope. We don’t have internet-facing servers anymore, but we do have a firewall, thank you. Have you got a list of dangerous domain names instead?
Egress was king in the house, and CISOs mainly dealt with LAN and users in 90% of companies, even though one successful attack out of two wasn’t relying on users but on machines. Dealing with egress was similar to considering you’ll get shot anyway. Hence, the Kevlar vest isn’t helpful, so let’s focus on not bleeding out.
The omnichannel cybercriminal
But history tends to stutter. Cybercriminals, highly incentivized by the colossal amount of precious private and corporate data, are no longer betting on a single horse.
Any competent cybercriminal organization is capable of leveraging multiple compromise tactics. They will probe your organization both on its human and technical layers. They’ll try to compromise machines and employees over the internet or at electromagnetic wave range. They will target your cloud infrastructure, your SaaS, your VPNs, your users, and their emails all over the range.
This broader spectrum of attacks — what we can call the omnichannel cybercriminal — cannot be countered only by having a list of dangerous domains.
![the attacks spectrum of omnichannel cybercriminals includes ingress and egress-related attacks](https://cms.crowdsec.net/wp-content/uploads/2024/07/Omnichannel-Cybercriminal@1x-1024x915.png)
By focusing every five to ten years on a different threat vector, from DMZ servers to browser security to email security, we tend to miss the deeper trend, the fundamental concepts.
Attacks, no matter their types, are carried over through a small number of different vectors:
- Airwaves (Bluetooth, Wifi, NFT, etc.)
- Human interactions (email, text message, phone calls, etc.)
- IP addresses (extended with domain names regarding egress)
Acting on the vectors allows you to eventually not deal with the payload itself, which is a much more proactive approach. And if you have to deal with the payload because it reached your users or servers, you’re still in the fight because you significantly reduced the number of them, leaving time for your team to actually deal with them.
However, it would be detrimental to forget that north of 50% of successful initial breaches are carried against your exposed infrastructure, and ignoring that fact was the great mistake of the 2020s.
Omnichannel attackers require an omnichannel defensive approach.
Is ingress security dead?
This article could seem bitter, but it’s not; it’s the opposite.
I had a “eureka” moment recently that I wanted to share with you, fellow clients, users, and entrepreneurs. The takeaway from those 25 years on the job is that egress is a legitimate CISO concern because it’s user-originated traffic, and it can lead to tremendous damage. Apart from XL corps or historical internet players like banks, most CISOs do not have servers anymore anyway, so they don’t have to deal with ingress. They were told those were dealt with by hardware vendors and hyperscalers, so there was no reason to deal with this themselves.
As a software vendor, this changes considerably your GTM approach because if you are in the egress game, you can sell to final clients, whereas if you are in the ingress game, the Original Equipment Manufacturer (OEM) approach — i.e., integrating your software in hardware appliances — and channel strategy should be your main area of focus.
In the latter case, ingress-related work is now concentrated in the hands of hyper-scalers, CDNs, infrastructure providers, MSP/MSSPs, and hardware vendors, as opposed to egress, which is “userland” and falls under the jurisdiction of the CISO.
But by no means is ingress security dead. In fact, it’s quite the opposite. The omnichannel cybercriminal does not solely focus on your users. Their organization constantly scans the internet to identify exposed resources and services, map them, and either try to compromise them or wait quietly for a CVE to arise. Recent reports show that within the same day, a CVE is published, its exploitation starts, and our own results entirely correlate with that finding.
But beyond this, we have AI and its near-infinite scaling capacities. Take the proper models, feed them CTF logs, CVE database, cybersecurity R&D papers, and books, let it digest, and you’ll have a decent offensive AI. Plug it some controller with a reward system and your individual AI modules should perform fairly well. As long as they have no legs, those AIs will be condemned to act on distance, and unleashing their newfound creativity on your exposed services will be their 0x1 move.