Cool. Thank you.
So, hi. My name is Jacob. Belfort Advisory. I'm from Belgium.
So, I'll try to put some elements of that into this. We will not be bringing a technical session here. The idea we had was to bring or to make the bridge between identity and access management, threat detection and management response, and what we call insider risk management.
So, we tried to look at the broader enterprise risk management story. The reason we do that is because a lot of sessions about identity and access management, they always go about the right person, the right place, the right time, the right system, the right application, the right access. But they often have that presumption of that malicious access comes from outside, breaches an internal account, and does something wrong.
Today, I heard, I think, almost three times the same question of, what if the bad guy is already inside your organization? We have a different mindset there, is what if the bad guy was always in your organization? What if the bad guy is one of your vendors, one of your third parties, one of your employees? They are already authenticated. They're authorized. They have their access. What if they already want to do something wrong? And their mindset, their mentality, their values, their culture is different of that of your organization, and they can potentially do something wrong.
So, what we first want to bring up is EM, and whether it's identity governance or access management or privileged access management, it's always been about control. It's always been about, most of the time, compliance. It's demonstrating compliance to internal audit, to your external auditor, to an ISO auditor, just to get that certificate. It's getting it done. Lifecycle management, provisioning, access certification or access reviews, just getting them done. Measuring what is documented, what exists, showing that you're doing the right thing, not really trying to document what's going wrong.
We want to look at this aspect as, it's also an operating system for insider risk management. But what we see is that, I think most of the people here in the room, or you have customers who have semi-mature identity governance systems, or very mature systems, but everyone is beyond that first layer of, join and move a lever. I think we've been doing that for the last 15 years. Time to go to the next level. What we now want to do is, we have a lot of data, we have a lot of systems and applications, we have all the data. We're not using it in the right way.
We're using it in a way to demonstrate compliance, but not to capture risk, or not to predict certain elements that could help within your certain organization, or within your certain teams. A bit of repetition, sorry for that. I know I'm also the last presenter before your break, so I'll go over it quite soon. Hybrid work. We've all been through COVID, everyone knows remote work, we're not on-premise anymore. There's a lot of SaaS applications, there's a lot in the cloud. Everything has changed, identity is that new parameter.
We talk about infrastructure, we talk about information and data, and identity. Everyone knows identity is the new parameter, identity is security.
Yes, I'm preaching to the choir. Can't have a slide without AI on it. I think every single presentation talked about AI, so we also have to do it.
Gen AI, agentic systems, Gen AI, agentic systems, it's all there. Everyone has Codex, Cloud AI, Gemini, we're all using it.
People, or here on the slide, we have 10 times the amount of human users, 50 times the amount of human users. I saw presentations going 80 times to 300 times. We don't know, but it's more than human users. We need to manage them.
For us, agentic AI systems, agentic bots and users, those non-human identities, we also consider them insiders. They're also a risk to your organization. The SaaS applications, it's been there for the last 10 to 15 years, it's nothing new anymore. And then we're in Europe, regulatory pressure. I'm a consultant, I love Europe. There's NIST 2, there's DORA, there's Cyber Resilience Act coming up, there's the AI Act. Endless amount of works, endless amount of consulting for us to do. And sorry for my word, but it's an absolute shitshow for companies to adhere to.
NIST 2 will tell you, look, you have to monitor your organization, you have to be compliant, you have to cover everything, you need full scope of everything and everything you do. DORA will tell you risk management, threat-led penetration testing, a lot of additional compliance for financial sector companies. And then you have GDPR, who says, yes, you can monitor, but not if it's a person, not if it's an identity. Be careful. We want to protect the privacy, even if that's a malicious person.
But we have to manage that and we have to find that small gap between all these legislations to know and to be able to do what we want to do. So where does this not always, but often fail within organizations and within companies is we're measuring hygiene. We're trying to prove that we're doing the right thing. We're trying to prove to C-level or to auditors that the money that we cost and that we spend is spent well, which is a very normal and natural reaction to do. But we're not capturing the real risk signals. We're not really using the data that we have in the right way.
Then there's also that fragmented ownership. Again, preaching to the choir, but identity and access management has never been a technology problem. It has always been a business discussion and a business problem. You're talking to business, you're talking to HR, you're talking to legal, you're talking to your compliance teams.
IT, most of the times, know what they need to do. Technology is not the problem. It's what you feed into your technology and it's what you use to get your things done.
But again, you have to bring everyone together in your organization. And then a third element, and that's one of the last slides I have, not this one, but things like eight or nine, it's communicating to the board. People who are in technology, people who are in identity and access management have a difficult time of communicating what they do and what value that they bring to a board. So we're trying to talk about risk quantification. And I know it's a bit of fluffy magic accounting, but we'll still try to do it just to show you how you can use it to bring some value.
At the bottom, you have a timeline that we use for insider risk management or a lifecycle of an insider risk management investigation. We try to predict what's happening. We'll try to detect what's happened. If something happens, we'll investigate, we'll respond, and we'll do our continuous improvement and we'll learn from what has happened. Fitting identity and access management into that lifecycle, it mainly sits in your detection. That's what we've been doing for the last years and in your investigations. Be careful in your investigations.
There is a lot of legislation that tries to limit and tries to sandbox what you can do with all the information and all the tools that you have. Europe is Europe, and then every single country has their own specific legislation on how you can manage your investigations.
Again, like I said, I'm from Belgium. End of last year, we just had a new law on private investigations, changed everything that we have been doing in the last years. Meaning that, yes, you can investigate events if they are related to cybersecurity events, but once you start looking at a specific person, you become an investigator that needs to be licensed. It makes it very difficult for organizations to actually go that step beyond in trying to find out what has happened and who has done something.
Three signals or three elements, three metrics that I want to bring up, but it's three random ones in the sense that they're not limited to three. There's an endless amount of metrics that you could and you should use to try and capture risk signals.
Again, not trying to capture compliance or trying to capture operational improvements. I just brought up these three examples just to show you that you have this data available in your systems, in your applications, in your IGA system, whether it's an Omada, a Savions, a SailPoint, whatever you're using, they all capture the same data. It's there.
It's just, are you building the correct metrics and are you looking at them in the right way? One of the examples is people, users accumulating entitlements over time.
Yes, we'll capture who gets what new entitlement or what new role in the organization. We are probably not looking at, let's say, a 90-day period where people are building up entitlements and accesses to systems. Does that map against the amount of access that is taken away? You have that data, but start looking at it because it's a risk signal trying to show you that, look, people are probably in the back end building a very nice super user and building accesses.
If your request model is built in a way that business is responsible for approving access, it's very well possible that people go throughout the organization, ask different people for accesses to systems and applications, and that all these people will not know of each other that they are approving these accesses. It's a risk signal. Is it a problem? Not by default, but it's something you need to capture and your team needs to understand what is happening. You need to start looking at it. Everyone is doing access reviews, access certifications. We have to do that. The auditor loves that.
We showed them a nice report. Look, this quarter, everyone ticked off their Excel list or ticked through their compliance exercise. What we often don't look at is how long does it take to actually go through that review campaign?
Am I, as an M plus one or a manager, just rubber stamping this improvement, just accepting everything? Or am I taking six to eight weeks to do this? There is a signal behind that. There is a reason behind that. Why people are doing it or so fast or taking so much time.
Again, you have that information in your system. I would be not very surprised, but somewhat surprised that people would actually monitor this and start reporting on this to C-level or even within their specific teams. The third example, again, not by default or not per se a problem, but something you need to look at, something you need to monitor, report and flag. Dormant accounts, dormant privileged accounts. They can be dormant for 30, 60, 90 days, maybe even a year. What happens in your organization if they wake up? What happens if someone starts using them? You need to capture that.
You need to look at that. You need to investigate that. You need to understand why something happened.
Again, it's not a problem per se. And then normally in a very mature organization, you'll have your just-in-time access for your privileged accounts. Reality is that often it's something on the roadmap, something that will happen in the future.
Again, this is just three examples. You could find hundreds of examples. The message is more you have the data, start looking at the data in a different way. Go beyond that ISO 27 requirement. Go beyond that compliance requirement. Do something, I'll call it extra useful for your organization, just to find new risk signals in your organization. A very quick one in between, just because I see it's not counting down here, so I'll go a bit faster. Non-human identities, agentic identities. I think there's more than enough sessions on these topics as well.
Common issues, no ownership, changing ownership, people leaving the organization, not handing over accounts, standing privilege versus just-in-time access, and then your accountability. But this is again, I think there are much better presentations than what I put here on the slide. This is an interesting one. And this is one where I wanted to make the difference between a technical identity and access management story versus something that links more to insider risk management, is policies and procedures that exist today in your organization. People see them as paperware.
They're a list of minimum requirements, baseline requirements, must-dos for your organization. You also have to understand that people see these as a translation of the values of your organization. It tells something about how much you trust your people, your stakeholders in your organization. It's very important to, from that aspect, to look at the friction that you create in your organization. Friction is one of those key elements within insider risk management that causes more risk than it actually tries to cover.
If your controls, if your policy statements are too hard, too complex, and the controls behind it don't work, you're probably creating more frustration and more friction and more risk in your organization than you're trying to solve. On the other hand, you also have to use your policies in a way that you can build culture and build values in your organization. The data that you capture will be able to make that bridge, make that link to the well-being of your people.
Within your IAM systems, you'll be able to capture potential burnout risks, potential disengagement, the trust of your organization that they have. People logging in from 6 a.m. until 12 at night, a higher risk for burnout. Meaning if those people fall out, there's an operational risk to that. The disengagement, people logging in from 11 till 2 during the day and not doing anything else, it's going to be a massive cost for your organization. You probably want those people to be a bit more active. You have that data. You're not looking at it in the right way.
I think this is the final important one, and then I'll try to stick to the time. If you look at these detection or threat detection, threat management, threat response solutions and systems, there's an amazing amount of tools and systems available in the world. They do wonderful things. They can capture everything you do, whether it's from keystroke logging to looking what you type into your AI solution to looking at what websites you go to. Amazing tools. I think to some extent, we have to be lucky that GDPR exists to protect us and as an employee in our organization.
But then again, from a risk management perspective, it's a burden. We are not allowed to do anything and everything. Four elements that you have to take into account when you want to use these tools, use these systems. There's a very fine line from going from monitoring to surveillance. We're not really allowed to do surveillance. We are allowed to do monitoring. We have to find that fine line. And this is GDPR 101. This is talking to your GPO. He or she will know about this. It's defining that lawful basis. It's defining that proportionality.
It's doing that impact assessment, whether it's a data protection impact assessment or an AI impact assessment. Do them. They work. They're really relevant. And then look at your retention periods. How long are you actually storing the data from these systems and applications? Is it 30 days? Good enough, but absolutely useless in investigations because your investigation will only start six months in the future. But from a GDPR perspective, there's a difficult case to build to store data more than one year. So you have to, again, find that fine line.
I'll send you or you guys all have the slides so you can look at this. This is just a final element on trying to capture or document the financial value of how expensive is my tool versus what is the potential financial cost of a risk becoming a reality. I didn't give you exact figures, so hold up, sorry, because they change. But there's a lot of reports. There's the Verizon data breach report. I think the new one just released this week or even today. There's IBM, there's Ponemon. They have great reports with actual values.
But you capture the incident rates, the cost of records, the cost of, what else is there, the detection delay. All these values exist. If people want these values, more than happy to send them to you. They're publicly available as well. But it gives you the opportunity to calculate the financial number of what the potential cost is of the risk being realized. And you set that against the cost of buying and implementing tools. It helps because your C-level, your board members don't understand what identity and access management is.
They absolutely do not understand what identity threat detection and response means. They know cybersecurity exists and they have to do something about it because there's an issue.
And then, yeah, I'll close down. But use this as well just to quantify it. I think this is the last slide. Don't use identity and access management or identity management only as a control plane. Use it as something to capture risk signals and predict risk elements and cases. And that's it.
Thank you, Jacob. Any questions from the room? Anything? As I asked my question. According to you, what is the easiest signal to capture that is ignored most of the time? It really depends. And it's the most basic consulting answer. So I know it's absolutely useless. I think the one that we've been using most recently is the access certification latency and approval latency one. It's capturing how long do people actually take to validate and or rubber stamp the approvals because it really shows the interest of the organization into these campaigns as well.
Is it just a compliance exercise or are people actually understanding what they're doing? Okay. Thank you very much. Thank you.
