Zero Trust and Conditional Access: Uncovering Hidden Threats [Intermediate]

Yeah, this is working. I see faults are yet coming, so I'll just wait 30 seconds.

Yeah, initially this was planned for 40 minutes, but I have to make it compact in 20 minutes. Let's see how fast I can go. Before I start, so you would have guessed like this will be focusing mostly on intra-ID and conditional access. So how many of you are using intra-ID?

Yes, yes, almost everybody. And how many of you are using conditional access or working actively with conditional access?

Wow, that's quite a bit of hands. Yeah, yeah.

So OK, I don't have that. Yeah, that's here. Press the next button. No. OK.

Yeah, something about me, Manish Periwal, working as senior security engineer for the Sovereign Oil Wealth Fund of Norway. Like you would have heard about the Pension Fund of Norway. So I work as a senior security engineer there. So I started my career as a Java developer, moved to application security, pen testing, cloud security, and of recently three, four years, I'm quite focused on identity area, identity security, and identity governance and administration.

So yeah, you can say that now I'm a Norwegian because just six months ago, I got my Norwegian citizenship. So thank you, thank you.

So yeah, a Norwegian citizen born and brought up in India. I have close to like five years worked in India with multiple US-based clients like Apple, Sony Pictures and all, and then moved to Norway and have been in Norway for seven years. And this week I completed actually seven years. And you can see like I'm quite almost working in Microsoft technologies now.

And yeah, when I'm not working, this is my ski, I'm just trying to learn. I'm not a professional ski driver yet. And when I'm not working, I devote all the time to my son who is two years old.

And yeah, we spend time around. And today's agenda, it will be facing registration and authentication, something about groups, and do you have control over them, and something about applications. So focusing conditional access on three parts, users, groups, and applications. Moving to phishing-resistant authentication. So how many of you are still using passwords? Not on your personal, maybe on work context. So that's quite a lot of hands.

Guys, we are in 2025, and Microsoft says that go phishing-resistant, go passwordless, go passwordless. And I was quite impressed with the session which Siemens had today, like considering the lot, the amount of users they are having. And they have mentioned that more than 70% are using Windows Hello for Business to sign in. So that was quite an achievement, like compared to Siemens, we are quite small, but we can say that we are 95% passwordless in our entire org. So how do you achieve it? So I assume everybody knows the concept of phishing resistant authentication or strong authentication.

So I'll not get into more details of it, but Microsoft State of Security Report 2024, they state that out of the 600 million daily identity attacks, 99% are based on passwords. So this single line should motivate you to move towards phishing-resistant authentication. Imagine 600 million daily attacks, and 99% are password-based. And with AI evolving and that kind of password tracking thing, quantum computing, what all can happen? So why phishing-resistant authentication? No more password nightmares, you don't need to remember passwords.

Superhero-level security, because this TPM thing, your credentials are bound to your device, they are stored there, so it's much secure. Time-saving, don't need to enter a password and then wait for a prompt in Authenticator or any 2FA which you are using. Open your phone, unlock it, lock it, and do the stuff there.

And yeah, in Microsoft world, it's like Android Ifedo, Windows Hello for Business, or Passkeys, something like that. But yeah, I came across a lot of vendors also who are also offering their phishing-resistant solution. So this can be also a potential way. And I actually had also planned a demo for this, but owing to the time constraints and me moving back and forth with my laptop, so that was not a good idea. But if you want to see a demo, please catch up with me, and I'll be more than happy to show you a demo of how we can do it.

Yeah, how to and best practices. So authentication methods. So first thing is, when you go into the conditional access, or first thing is, in Enter ID Protection, you go to authentication methods and set your different policies there. So one thing you can do is you can segregate your users, like say a normal account can use Windows Hello for Business, and an admin account can use Feedo way of logging. So just segregating different users. And those users you put in your different conditional access policies.

Policy as code, like it's always recommended to have a complete state of your policies and minimal impact, minimal users who can change it. So redeploy your policies or deploy your policies using Terraform. I guess Bicep yet does not support as code, but Terraform supports conditional access as code.

Yeah, of course, report only mode first. You don't want to activate the policy at one go and somebody say, I work in investment banking area. So somebody, a trader from New York just comes, I am not able to log in. And I want to do a trade of $5 million. And what the hell have you done?

So no, that's not a good idea. Always do report only, analyze the impact, and then roll it out. Rollout plan. So like when I started my career, so my manager always used to tell like, people process and technology, you can solve, you are the technology person, you can solve the technology part, but people and process are the most important also. So rollout in phases, communication is the key. You cannot expect a trader or a business user or a finance guy or say in HR to understand every integrity or every detail of this conditional access or how it works.

So you have to understand or you have to tell them in a plain language what they need to do, develop user guides and use the three concepts, people, process and technology and rollout in phases, say department wise or user wise, groups wise, whatever suits your organization. And if somebody from Siemens is there, I would like to really know about how did they deploy it. If somebody from Siemens, raise your hand.

No, nobody. Yeah, they are quite advanced, I guess now. Yes. And what if my authentication does not work? So what if I just forgot my FIDO key at home or what if my passkey is in mobile, I forgot my mobile and it's not working or there has been some problem with hello for business. So what do you guys do? You cannot ask your user to just wait one hour, we are trying to troubleshoot, fix the issue or something like that.

No, here comes the IGA part, like the identity governance and administration part. So if you are using intra-ID governance, there is a functionality there, which is yet not up to the mark, but you can use it like request on behalf feature. So in IGA and intra-ID you can, a manager can request an exclusion group for you, which can be an auto approved way and you get membership for one day and you can use your password and authenticator form just to log in and then service desk can help you troubleshoot or the issue for any phishing registration authentication you are using.

And why I say intra-ID governance is maybe if you are using some different IGA tools, so there is a much more advanced, I guess, request on behalf feature where a service desk person or an IAM person or a security person can just request like an exclusion group in the condition access policies for you and you get automatically membership for one day, do your work and in the meantime your issue gets resolved. So that's the way we should do it.

And application exclusions, so certain application which use like say native browsers or something which are not able to send the authentication information to intra-ID, they should be excluded. There is no other way out. Yes. Next point. Do you have control over groups? So how many of you are using group owner or group admin feature in intra-ID? No one?

Wow, that's nice. Because why I say so? Because any identity, be it user, be it service principle, be it like non-human identity, if they have group read write all permissions. So it can be through group admin rule, it can be through group read write all permissions, it can be a group owner. So they are as good as global admin. Why I say that? Because they can change your groups in condition access, they can change your groups for enterprise apps which are being used, which are being used, and you will never get to know that.

Like how you as an identity security professional will get an overview of what changes or what controls are in place so people don't do unauthorized changes to those groups. So yeah, as I've written like it will be a major impact on condition access policies and enterprise applications.

Yeah, of course, like you can set up monitoring alerts whenever your policies are changed, some sort of these things. But what happens? Group changes. How do you do it? So what I'm discussing now is more of a reactive solution, it's not a proactive one. But a reactive one is like, okay, so I've just listed different entities and those are just changing some group part of condition access policies and how do you are managing the control. So solution can be like any alert on group using Microsoft Sentinel.

So you see the audit logs, you get the data from the audit logs whenever a group is changed, you run analytics query on Sentinel and then get the alerts on Sentinel or incident on Sentinel, whatever suits you. Or you can also get an email notification, Teams, Slack, whatever. And a break glass account, best practice, should never be in groups. It should be always excluded or included in whatever policies on an individual basis.

Restricted management administrative unit is also one way of doing it, like you make your groups part of AU, RMA AU, and then it becomes very much less restricted for people to change. So this would be a solution for monitoring your groups reactively. So what I'm here doing is I'm using a logic app, calling the Microsoft Graph API, putting all the groups which are in my condition access policies, like inclusion, exclusion groups in a watch list in Sentinel. So it runs, say, every day, finds out if any new groups have been changed, removed anything, and my watch list gets updated there.

And using that watch list, I query my audit logs using a KQL and see in the audit logs if there have been some membership changes to the groups. And whenever it detects it, it just sends me an incident to Sentinel. So that's how it is done. And this is just a KQL example, not worth it to show now. And this is an example of incident you will get, like, OK, this and this group has been changed. Please take action or just review it. There are also solutions available in Sentinel itself also, like the Content Hub and different workbooks are also available, similar solution.

So those can be also used. But you should keep in mind, like, we need to monitor the groups also.

Next part, workload identity protection. OK, so we have covered users and groups. What about workload identities? How do you protect them? Service principles, non-human identities, like those are existing in your system with different permissions, different permissions, and all.

Yeah, one catch here is even if you have E5 licenses or P2 licenses, you will not be able to protect them because you need to buy a separate workload identity protection license, which is per app based. And it costs three US dollars per month.

So yeah, if you're having a lot of apps in your tenant and you want to protect them, it can be quite costly. So yeah, Microsoft has a standalone per app license scheme based on it. So even if you have an intra-ID suit also, like the newest offering, you will not get this. It's a standalone product and you need to use it. So recommended approach is, yeah, use it only for your high valued service principle application, not for all, of course. Cost has to be kept in mind.

Yeah, conditional access for users and also how do you protect them? So custom security attributes. How many of you have heard about custom security attributes or using them?

Nice, nice. Yeah. So what you do here is, so this was actually part of demo. So what I do is I use a kind of automation like a logic app, which again calls graph API. It like enumerates all the applications in my tenant and finds out which application has a privileged permission, say group read write all permission, user read write all permission, policy read write all, whatever permission you feel is a more privileged one.

So it loops through all the applications, find those applications which are quite privileged, and then apply custom security attribute on those service principle or enterprise apps. So like a custom security attribute can be like, yeah, it's privileged app is equal to true or has group write permissions.

Yes, something, any custom security attribute which you are free to configure. And then you apply conditional access policies, something similar, which I have shown here, like workload, you use the workload identities feature. And then in your configure, like you can see that any application, any service principle, which has a custom security attribute, which is true. And mind you, this only works on string. This will not work on Boolean. So this will work only on string. You give it as true.

And yes, and then whatever block policies or whatever controls you want to place, like coming from a trusted location, coming from different like these particular IP ranges only. So you can do that. So that's part of protecting your service principle or high permission service principles. And that was all. Thank you. Thank you very much, Manish.

As usual, if you have a question, please raise your hand. Kai, do we have anyone online?

I have, again, a question of my own to start the discussion. So this seemed a little bit complex, even in a short introduction. How do you monitor this? How do you govern this? How do you ensure coverage, there is no drift in configuration, that policies are not conflicting with each other? So we deploy policies as code. So that actually say you deploy your policies every day, every night. And the alerting is quite like you say you run your alerting mechanism every 15 minutes to just detect like no changes are done.

And also like no unauthorized user or the identity team only has those privileged permissions, say, global admin, security admin, such kind of roles. You don't give it to like just everybody in the team or everybody in the org.

So yeah, there is a quite a lot of things which you need to do, but it's doable, manageable. I think we had a question from someone. I've seen a hand, definitely.

Well, in that case, Manish, thank you very much. Again, it was really thought provoking and hopefully it will make more people to actually consider this and come in to you asking for guidance.

Yeah, I'd be happy to maybe answer or discuss more better ways if there are. Thank you.