Thank you for having me here today. I'm excited to talk about something which we've been working on in KuppingerCole. Introducing myself, I'm a relatively new analyst in KuppingerCole and I want to talk about the Identity First Cybersecurity Fabric. Very briefly, why an Identity First Cybersecurity Fabric? We have a plethora of tools. We have more tools than we know how to manage. Is anyone here managing a SIM and is not finding it an expensive hobby? We need an integrated defense model. So why a fabric? Why this idea?
This is something that we in KuppingerCole are working towards, but we thought it would be useful to show it to you in its early stages now. So I'd like to talk about four things. First of all, why a fabric?
Second, why we see identity at the heart of a cybersecurity fabric. Thirdly, how we move from a monolithic SIM to telemetry pipelines and obviously using AI orchestration.
Finally, I'd like to look at a roadmap and some recommendations to move towards this. So moving swiftly on, why a fabric?
Well, as I said, we have a tool sprawl. I have vendors offering multiple competing solutions. I have people come to me at conferences. I had one in Dubai saying, oh, I want to buy another antivirus. I want to buy another endpoint. What can you recommend?
It's like, if you have one, why do you need another one? The same costs are exploding, as I said. But what I really see is that we need to adopt a capability first mindset. We need to get away from the idea that we have a tool set and we will architect our requirements to fit the tool. We need our capabilities. From there, we have components. From there, we then have select tools that fit the job. And we would like, all of us in the room, I think, would like to see stability that goes beyond vendor, or dare I say, panelist bud words. So what are the five essential fabric characteristics?
Well, first, a unified approach. All data, all systems, all identities need to be part of the fabric. It needs to be pervasive.
Secondly, this is a paradigm. I'm not trying to sell you a tool. I'm trying to persuade you to a way of thinking.
Thirdly, APIs and microservices. All of the tooling, all of the components need to be able to integrate. And we are going to be looking at a many-to-many type interconnection. And then finally, let's say, comprehensive modular capabilities. And I'll mention again, segregating the requirements away from the technology. We need to get away from this idea that the technology tail wags the architectural dog.
So, identity at the heart. Seems like I've landed in a good place at EIC. Talk about this. We have the cup and go-cold identity fabric. And we know from that, we can treat identity as connective tissue. When I talk to the security managers in the cloud service providers, they say identity is a heart of what they do.
Secondly, we need to pick up continuous trust signals. UEBA, ITDR. These are signals that are constantly being fed, allowing us to evaluate the risk of the transactions being fed by specific identities, whether human or non-human. And then thirdly, if we have those signals, we can then put in place risk-adaptive controls that will trigger appropriate responses.
So, we have the capability stacks. We have the identity fabric stack. And I would suggest that there is an analogous cybersecurity fabric stack as well. And there are touch points between the two.
So, core IAM, admin, authorization, authentication, and analytics have corresponding touch points in a cybersecurity fabric control plane, which allows, of course, risk-adaptive multi-factor authentication, allows continuous authorization, identity attributes, and all the other things that we know allow us to move towards a mature security operations and indeed IAM fabric. Second, we have the idea of privilege.
Pan, session recording, secrets management. Well, of course, again, there are analogous points that can use that in a cybersecurity fabric. We can have orchestration, intelligence, making use of those IAM capabilities.
Thirdly, we start to extend the IAM capabilities into fraud detection is an identity presenting as transactions that look a bit weird. Transactions that are outside of our risk tolerance. Transactions that are unexpected for a particular type of identity or indeed peer group.
As I said, the SIM is starting to seem like an expensive luxury. But with an effective telemetry pipeline, we can make use of those to implement an ITDR, to treat that like any other high-priority signal that we need to take action on.
And then, say, finally, integrations, the SIM, which I think is starting to become a legacy. But XDR, SSE, the APR layer.
Well, again, we have an opportunity to integrate a signal to target bus. So maybe we don't need a complex many-to-many fabric. Maybe we can get some idea of a messaging pipeline. And actually, we can start getting some control over how our different security controls, our tools, are working together. I talk here about a tier two mess architecture. And the tier one architecture is one we're all familiar with. It's the block diagram. It's the one that's very simple, A to B to C. And we've all seen that. And we've all drawn those and presented those.
The idea of a tier two, which we're moving towards, is we have multiple layers of connectivity. It's actually quite hard to do in a PowerPoint because it's a 3D image. So until I can work out a way of making these things rotate, you're going to see a simplistic version of a tier two.
But again, signals mapped to targets, mapped to capabilities, mapped to services, mapped to tools. Our API and our orchestration layer coordinates that response. And of course, there's a perfect place there for advanced analytics for, can I use the AI word? Has it been used once today already? And of course, plug and play components. If nothing else resonates, I'd like this to stay with you from this talk. Zero trust is the why and the what. An identity-first cybersecurity fabric is the how.
This is how we make continuous validation at application level, at infrastructure level, at any level you care to name. This is how we make it real. I know I'm moving through these slides very quickly, but I want to try and get through this material. And please, if there are any questions afterwards that we don't have time for, please come and find me. I'm here for the conference. So thirdly, telemetry pipelines and AI orchestration. Telemetry pipelines and AI orchestration. I'd say pipelines versus SIM.
Well, SIM, you have this idea that you pull data from everywhere, from your office in Bangalore, from your engineering department in Kuala Lumpur, from your sales office in Canada, and you pull it all to one place over some very expensive international fiber. And the idea of telemetry of a pipeline is that we can stream and filter and enrich at the point of collection before we try and store. This gives, on average, a 40% cost reduction on log storage. For those of you with the Splunk Bill, this is good news. And it also gives us real-time detection.
It's something that SIMs have always promised, but never quite delivered. The idea that we can know now what's an issue that we need to respond to.
SIMs, in my view, still have a place for evidential gathering. In my former life as a forensic investigator, I spent a lot of time poring over SIM logs. So they will still have a place. But for real-time incident response, I think telemetry pipelines are going to be the way we go. I mentioned AI, so I'm going to do it again. AI-driven orchestration. I would like us to get away from the point where we are trying to use expensive, scarce, and tired human resources to correlate things.
And instead, we use some machine learning engines that correlate attacks, actually show us where we're seeing an attack path, which may be coming in by various distributed vectors. Think about the way fraud attacks work. They don't just stick to the web app. They'll call the call center. I would like us to see where we're no longer just relying on human expertise, but we have an automated playbook where we see there is an issue. We have a way to respond. And I quite like that idea I had, being able to predict the risk of a transaction, be able to predict the risk of the behavior of an identity.
I think that's quite exciting. So finally, and thank you for sticking with me, so this whistle-stop tour, let me put it all together. We have these architectural building blocks. We can ingest, enrich. We can correlate. We can reason. We have a decision engine that says, yes, this transaction is within our risk tolerance.
No, this transaction is not within our risk tolerance. Yes, this transaction is in that gray area where we need additional validation. And of course, this is where the wonderful world of PAM steps in to help us. We have a SOAR, or whatever SOAR is mutated into this week, where we can create action paths, and we can auto-generate and indeed tweak the playbooks we have to make sure they meet our immediate needs. And finally, what is IT security without a feedback loop?
Well, of course, we have a feedback loop. We need to measure the efficacy of the actions that we generate. We need to make sure we have a human supervisory position that allows us to say, yes, this action was okay, or no, we need to invoke a rollback path. And so what do we have? Some core use cases. These are use cases that I think are common to any organization. No doubt your particular organization has specifics as well. But attack path reconstruction. How did the attackers try and get in? As I mentioned, a big part of my previous role. Risk adaptive authentication. I absolutely love this.
If we're fairly sure that somebody is who they claim to be, if all the recognition signals are in place, then why throw up additional barriers to entry? Let people do their job. Let people do their job. But if we need it, we can throw additional authentication delays to meet the, again, the transaction risk. Phishing triage automation. The Nigerian prince tells me that we're still going to have phishing for some time. So we need to be ready for it. Self-healing micro-segmentation. When we see an attack on part of an application, do we need to bring it down?
Is it possible to have a partial database compromise? But certainly if we see a compromise in a part of business logic, we can isolate. We can then, the mantra of the incident responder, isolate, understand, eradicate. And finally, assume these predictive controls. So I see a maturity path here. We're starting off with something that can assist us in our jobs. We can move fairly rapidly, and I think we're at the cusp now of augmenting what we're doing. I think we're already seeing solutions in the marketplace that are promising to augment.
Fairly shortly, we're going to have autonomous capability. And again, something that we've been discussing when we've had a chance, talking with Alexei about the idea, well, actually, where does the human supervisory element fit in if we have an autonomous AI-driven incident response? And finally, we think there's some way off in the future yet, but we will get to an autonomomic autonomic self-healing fabric. So when it sees an issue, it isolates and tries to eradicate the attacker. So as I said, I started off from the point of view of the Kupinger Coal Identity Fabric.
And this is, as I'm sure you saw from Martin's presentation this week, this is the Kupinger Coal Identity Fabric. It's extremely complete. I don't propose to try and explain it in this presentation. And from here, we are building an identity-first cybersecurity fabric. I invite you to collaborate, email me, message me on LinkedIn. I want to hear any input you have as we build this and move it forward. So very simply, as I said, this is a Tier 1 diagram. We need to move to the Tier 2 architecture, the mesh architecture. We have various signals. I divided them into primary and secondary.
Why primary signals? It's a device that we can recognize. It has a machine identity. It's an identity. And of course, the question is, how much do we trust the assertion of that identity? But then there are secondary signals about the endpoint, about the environment in which the endpoint is operating, about the behavior of the entity, be it human or non-human, that is operating from that endpoint. And of course, the SIMSOR will remain, I think, a source of secondary signaling. And externally, we have the IaaS, we have the PaaS, we have the SaaS.
The applications are out in the cloud, not necessarily with the same locus of control that we would have for on-premises. And then the secondary signals from there, threat intel, HR badging information. I think we can class as an external to our, if you like, IT security world. And financial information, adversarial reporting. And finally, yes, the news. I strongly suspect that certainly news, current affairs will become an important secondary signal in these systems. So at the other side, we have a number of targets. I've heard people talking about OT.
We suddenly need to understand the very high availability requirements of OT that we're being asked to manage. And of course, we know about IT. And my favorite topic to you, which apparently has changed radically since I wrote this presentation, the world of AI, AI-driven data, models, interactions, bots, and things, autonomous agents are still out there.
And in the middle, and I say I'm just starting to map, and there's clearly much more depth and indeed dimensionality in this centerpiece, this identity-first fabric where we have some capabilities, identify, protect, detect, respond, govern, improve, recover. Recover would be nice, wouldn't it? It's going to become more important, by the way. We're not in the world where we once were, where we'd have an incident, and we'd fix it, and we could then relax, have a coffee. While we're recovering from that incident, a new one is starting.
In fact, two, three new ones are starting. So what else do we have?
Well, again, we have assets. We have motivation. We have process. We have people, location, and time. And these are all areas that we need to be able to apply degrees of control to. And I'd say I've tried to put in a couple of, really, just a couple of examples of components. I'm not even close to tooling yet.
But again, there's more dimensionality required. The most important thing, I think, is how analytics, predictive and generative AI, actually assists us and allows us to orchestrate our responses and the playbook. So I'd like to close now on an implementation plan. If you're excited by this, how would you start? Start with clean data. And there are a lot of tool components that have gone in and have, frankly, learned wrong. There's an attack in progress, and they think that's the new normal. We need to start with a clean base. We need to fuse the right models per task.
Not all models are the same. We need to build the human override switch. This is critically important. There are so many use cases where this was left out by solution vendors, by engineers in love with the technology. And all of a sudden, they haven't got an easy rollback path. So human supervisory at the right place at the right time becomes important. Instruments, everything. The one thing I learned from talking to my friends at AWS is everything can be an API. Everything can be instrumented. Everything can be monitored and measured. And finally, yeah, govern model drift, because it does.
This is my last slide. Map tools to capabilities. Prioritize that pipeline. Embed identity early. And finally, yes, low-risk tasks first. Pick the easy solutions first. And track your meantime delivery. Track your meantime recovery. The KPIs that are important. Any questions? I'm available, as I say, on LinkedIn by email. Thank you very much for your time. I've enjoyed talking.
