I would suggest taking a look at Hybrid Cloud Workload Protection.
I can break down the buzzwords a little:
- Hybrid Cloud = Works in an on-premises DC and public cloud(s)
- Workload = Works on bare-metal servers, virtual machines, and containers
- Protection =
- Distributed micro-segmentation (enforced via host firewalls, as close as possible to the app, sometimes integrated with the app)
- Vulnerability analysis (build time and/or runtime)
- Exploit detection
This is typically achieved via a small agent that runs on each "workload" backed by some type of centralized control appliance.
Guess who one of the innovators in this space is? You might not believe it...
Cisco.
Right?! What goes around comes around.
The CWP market is still somewhat nascent, but in my opinion, it is poised to explode.
Like the parent pointed out, the days of traditional hardware firewalls - or even worse "virtualized" versions of said boxes - are numbered, like it or not.
Disclaimer: I work on Tetration, Cisco's 3-year old in-house developed Hybrid Cloud Workload Protection product. That's right, not an acquisition.
Oh, and did I mention, the whole thing is a SaaS that requires zero hardware?
As you know Tetration has been around a number of years. While it may be one of the few in-house products, on the security side, that Cisco hasn't acquired it's very akin to Cisco ISE in my opinion. Cisco drives hardware through software because that's (still) where the margin can be made up. Tetration isn't all that different in that line of thinking. Let's look at the data sheet to find the hidden, proprietary link to hardware, shall we?
"The Cisco Tetration platform is designed to fully address these challenges, using comprehensive traffic telemetry data collected from both servers and Cisco Nexus® switches." [0]
And there it is... Also it looks like Cisco wants to sell you Tetration hardware clusters. To be fair it looks like you can also run Tetration-V on your own, but you'll still pay for licensing.
Regardless I still think this is a miss for the next decade. Partially because the solution is dependent on proprietary hardware and partially because the solution is "agent" based, which is a legacy approach to security spun out in Tetration by ties to hardware and a bundled data lake (Elastic, I assume?).
Your comment is accurate, but I would add some extra clarifications, since we run very much like a start-up, you can imagine things have changed a little over the three years!
True, you can use the Nexus 9000 switches to generate flow telemetry, however, neither are they the recommended or most popular data gathering point, that would be the software agent which has no hardware dependency.
This interestingly links to other discussions in the thread re: keeping the run-rate business strong while growing an innovative business in parallel. In Cisco, everything pays tribute to the switch, but that does not mean we are dictated by it ;) - a reasonable compromise to foster innovation.
Also true, you can buy Tetration in a physical appliance format (many customers want this for their reasons), but the majority of customers actually go for the Tetration-as-a-Service option which has no hardware dependency.
Agent based is always an interesting topic. For us, it is about getting as close as possible to the application we are to protect, and being agent based is about as close as you can go before getting into the code path, in a cross-platform, cross-infrastructure way. What this allows us to do is apply proper security controls like zero-trust that we take for granted in newer environments (like Kubernetes, which also often uses agents, they just named them sidecars) to legacy environments, where the bulk of today’s business applications still run.
+ Yes, Elastic is part of our stack, alongside a lot of other interesting technology. We process millions of events per second from all sorts of sources, like campus user logons, process executions, and new flows all in short order, detect how we should mutate the state of the "data centre" security based on the new information, then take actions like dynamically updating ACLs across tens of thousands of workloads to allow a new administrator SSH access since they logged onto a desktop in the London branch, while at the same time updating rules on the shared databases due to an application that just failed over to the secondary DC in Ashburn. I could talk on this topic for a long time as I find it highly interesting, but I'll hold on for another post.
https://chrome.google.com/webstore/detail/recipe-filter/ahlc...