I've been knocking around identity management for quite a while. Actually I was a, a way set sun Microsystems and Tivoli, and I was the CTO sale point for 12 years. And for the last five of those years, I was actually the CSO. So I can honestly say I've, as they say done my time in the barrel been been there actually been a deployer and user of technology rather than, than a seller of that technology. And the beginning of 2020, I retired from SalePoint, great time there.
Lots of friends still, but I'm now an independent advisor and I work with investors and clients to design a model the next generation. And in September, I'm very pleased to have joined my long-term friends here at co Cola as a, as a research fellow.
Now, my topic today is IGA and a fire. Recent breach events have certainly highlighted the identity management in general, the solutions in infrastructure that we are here to talk about today.
They are a strategic attack vector and in today's super complex and highly distributed enterprise security supply chain. The question really is are you adequately protecting the identity and access management capabilities that are now absolutely at the center of your security architecture?
And so my goal today is to really highlight how IGA is vulnerable and help those of you that are new to the topic of threat modeling, to think about IGA specific issues. And in that, hopefully we can devise a better strategy for preventing detecting and mitigating the risks. And it may be no surprise that I'm gonna open this conversation with the solo winds breach. I'm pretty sure that this now, you know, highly publicized incident, major newsfeed, and as the forensic analysis and resulting disclosures have unfolded, it's been said by many that ate as it's become known, it really is.
And really was a game changer.
The extent of this vulnerability and attack and exposure was just absolutely huge. And at the last count, it was 18,000 networks that were fully infiltrated, not just suggested, but infiltrated. And this included 18 us government agencies, right? Department of state Homeland security, the Pentagon, the treasury.
I mean, this was just huge commercial organizations and software providers obviously were hit badly too. And I think Microsoft has been admirably open and forthright in their investigation and disclosures.
And apparently as I'm sure you may have read, most of the Microsoft source base was accessed now, although nothing was changed, it's reasonable to assume that the nearly 30,000 Microsoft exchange server attacks that started January 6th, oddly enough, that particular time in us political history, very important day, as I'm sure you'll recall, but that event may have actually been made worse by the bad guys, actually getting a good look at how things were put together.
And so the methods employed here, I mean, if you study forensics, it was just breathtaking.
The, the level of sophistication and attention to detail that these guys had. It was without doubt a nation state attack. I don't believe there's any doubt in that. That was directed at what we now understand is a very complicated and highly vulnerable security supply chain. The forensic evidence has now clearly shown that the strategy to attack centralization has now been extended and identity management is clearly in the playbook. I don't think there's any doubt.
And as I'm sure you read forged SAML tokens and weak authentication played a big part in how this all got started at solo winds and, and more importantly, how it escalated out in their customers. And, you know, let's be absolutely clear. The Sam protocol, the Sam itself, isn't broken a lot of very smart people have looked back over the two specification.
And the conclusion is that the protocol architecture itself is, is, is still sound.
But my, I think it's true of, of all complex systems. It really comes down to how that is being deployed and operated. And in this case, we do know that weak IDP, key management and bad overall system security led to the generation and use of fake Sam tokens. And this directly facilitated the escalation of administration privileges. Now we could spend the rest of the day here on this topic alone, cuz this is just such a cool if you go look at the forensics, but my goal is to talk about IGA. So let's look at the implications for us here.
Well, this attack tells us that IGA is without doubt under fire. It tells us that we need a big or renewed focus on IGA specific threat modeling. And I myself foresee a huge demand for the further unification of IGA and security into a single single approach because identity has been the attack vector.
I'm little plug there for my book and colleague of my self wrote a book on identity attack vectors. It's been true for some time because if you're looking for a high value, high impact target, you gotta look no further than the IGA system. Right?
And I hate to say it, but this is one big fat juicy piece of hanging fruit, right? What does it contain the keys to the kingdom who uses this system everybody? And is it secure?
Well, that's an interesting question because in just about all instances, a deployed IGA system is a big attack surface. This is huge. These systems cross cloud, and on-prem, they're often deployed as both SAS and software and they cross both application and infrastructure boundaries. And IGA certainly has a very broad user base of administrators and users, right? And it clearly covers a huge range of security related use cases, you know, by design it's highly integrated with all the things that the adversary wishes to control and, you know, boy, is it ever complex?
And I've spoken about that many times is, you know, I'll no doubt say several times again today complexity is the enemy of security. So what could possibly go wrong? Right? What could possibly happen here? Net is IGA is just a super high value target and it's a hundred percent in scope for the adversary. So the question really importantly becomes what is the appropriate threat response? What should the teams listening in here today, the teams responsible for designing, building, deploying and running these identity governance systems. What should they do?
Is there a threat mitigation playbook for IGA? You might say, well, sadly, no, there isn't, but there are some, as they say in the us, no brainers, right? Some really simple things that, you know, just, just look at two of them that I, I would hope that everybody listening today is already doing. And the first of these, yeah, no brainers is strong authentication.
You should already have MFA in front of anyone doing IGA administration. I think there's no doubt about that.
You know, taking a very diligent and one might even say paranoid approach to contextual authentication to that IGA core is, is absolutely essential. If we look at ate and the forensic analysis readout here, you have to take a very close look at where your Sam signing, keys are being stored and importantly, how your handling key and secret rotation for its supporting infrastructure goes without saying, but much closer to home here, right? This is IGA is an access review. And I would hope that everyone that has an automated IGA system is actively using it to audit itself. Right?
This usually includes end users. We quite often do that, but we need a super focus on the highly sensitive areas around administration. So a very strong review change based cha contextual review on the IGA system itself is, is an absolute must.
And today that probably also means doing usage analysis too. In light of what we've seen, you have to start to build usage baselines for the IGA system itself, you know, for forget role mining and next generation cohort analysis and all the things that we do for the end target apps.
I'm talking about understanding when a Russian state actor is using your IGA system to provision accounts across the enterprise. That would be a really good thing to know is happening, right? But beyond those, as I say, no brainers, the MFA and access reviews there's are there soft spots in IGA today?
Well, of course there always are all systems have them. There are always lots of them. So where do you start? How do you approach understanding and mitigating these risks and a great place to start is with some basic threat modeling. So regardless of, of whose software you're using and how you're running it, this is a process of understanding threats and building a mitigation strategy, which is absolutely key.
Now there are lots of threat modeling approaches.
And if you are, if you're in pure InfoSec, it's probably not news to you, but maybe it's new to some of us that own the, the IGA systems. Obviously we don't have time to get into the real details here, but let's just say that there are lots of different methodologies out there. And each is really designed to help you identify the system assets, the inner system assets, to understand the data flows and to rank the threats that exist and define mitigations, a simple methodology.
And regardless of which one you choose to follow, most of this really comes down to understanding system and data flows. And so this means mapping out the, the data in the process, the ingress and egress each of the specific IGA processes and use cases that you use. So data flow analysis for a complex system like IGA is a big topic.
So in order to sort of break it down, obviously we can't cover it all, but let's just take an example of what this entails.
And let's look at a subset of the data flows by walking through the threat models that are associated with IGA data sources, with the specific data sources. And this will give us a feel for how things work and, you know, data source, threat modeling, great place to start because to just to highlight, this is authoritative data we're talking about here. This is the stuff that comes in and drives an IGA system. The idea is to list out, list them out, right, brainstorm the threats and map out the mitigations. So that's cracking.
And we can obviously start here with the inevitable overuse of the comma and the CSV. It's a startling reality of most IGA systems today that lots of the data flows are, are basically via comma, separated value files still, and the CSV and, and there's a, many of you will know, Ian Glaser used to be an Analyst Analyst ever at Salesforce running identity.
There, he, once jokingly said that the single greatest invention of identity management was the comma. I thought that's just, just hilarious, but, but absolutely true. And the threat modeling questions here is how would you attack that? Right.
You know, are these input files in integral secure, right? Are they somehow authenticated? And how do you verify the, the malicious input hasn't been inserted in those files? Right. So how do you validate that the feed is correct and exactly as intended and that's tricky, right? So threat modeling for Ida simply asks these questions and it does it in order to understand the risks and plan for the mitigations. Another key area of source data is direct connectors. IGA is connected to everything, right?
I mean, that's kind of the goal. So inevitably there are lots of proxy, admin accounts and privileged user credentials that get used by the IGA connectors every day is this specific privileged access properly vault and rotated over time.
I hope so many of the systems allow that, but you have to consider how would an adversary change the access privileges of a connector in order to carry out some nefarious action or intent, right? You have to ask the question, how could I therefore track the behavior of the connector itself, right? How would I baseline its activity and look for anomalies?
And so threat modeling means listing out how a connector normally behaves, how often it connects and from where, and, and, and building that profile and looking for attack. And of course you have to consider the actual identity sources themselves, right? HR systems, our next generation access management and Siam platforms. And often we see, you know, custom developed contractor and non-employee data sources, all of these things flowing into the system.
And again, you know, what are the threats scenarios here that help us ensure integrity?
If a new bond trader for example, gets auto provisioned based on an HR feed, are we sure of its Providence, right? How would the adversary, if you like mess with this context in order to propagate or escalate an attack vector. And that's pretty interesting, cuz the attack may flow in from HR in order to attack our IGO. And that's what IGA threat modeling is really about. Or perhaps the role or group membership feeds that drive so much of what we do in IGA today, complex hierarchies, right?
Nested and imported group memberships, imported from an authoritative and very external system feed, right? I mean what could possibly go wrong?
So again, you have to consider the strategies to mitigate these threats, assume the compromise of your group, inheritance feed, assume just for a second, it's owned by somebody list out the implications model, what the threats are and plan how you would do verification, reconfirmation, basically mitigation for, for these feeds.
We could of course continue this process for quite a while cuz there's, you know, know that's what ongoing threat modeling is all about, right? We, you, you do this continually, but for now let me finish with the source data threat modeling topic. That's actually very relevant to other areas of the identity management infrastructure and that's attributes and tokens, cuz this is a big one cuz it crosses over not just what we do in IGA, but how we build applicators and infrastructure and, and how privilege is access will stop.
And everyone today makes decisions based on attributes, the groups in AAD D or the roles in something like a sale point or a saving.
And the just in time tokens that get issued by a ping or an Okta, right with so many complex feeds, driving entitlement, giving attributes and with so many IDPs and tokens, picking up those attributes and relaying, transferring them and moving them around this space can be pretty complicated. This can be really quite tricky.
And, and for some folks it's a bit of a mess to be honest with you. So you have to sit down and work through these data flows. You have to build in Providence, as we say, right, you have to know where things come from, how secure they are and overlay assurance and validation into this process, short cutting services and re-validating, but in summary that means, you know, modeling dependencies really and modeling the attack vectors that exist in those dependencies and, and planning, mitigation, understanding how to, to mitigate.
Cause like I've said several times and I'll no doubt say several times again, complexity is the enemy of security.
And like I say, this is one big complex integrated system and the bad guys know it. There's no question. So hopefully that doesn't sound too complex or daunting is really not that bad. And the trick is you've just got to get started and you've got to make it an ongoing part of how you build and deploy, deploy. It's early, here in Texas, your IGA and in practice that threat modeling and IGA really is a shared responsibility. You're not on your own with this.
You absolutely should look for help from your software vendor or, or your SAS provider, right? They, they own the technology. They should be doing this themselves for their own internal systems and absolutely take the time to reach out and engage your identity deployment and security consulting partners in this process too. Cuz as I say, this should be how we build and manage over time. And with that I'm about out of time. So let me just say thank you for listening and I'll pass control back to the moderator.
