Thank you, so my name is Martin Sandren, I work as the product lead for IEM at Intra-IKEA which is the mother company in the IKEA group and I'm going to talk about ITDR and this talk is a bit of an intro talk so we're going to give some some background what it is and also talk a little bit about what our output is from having run this for a couple of years now. So first question, ITDR, what's it all about?
I think the acronym is really bad really because people see it and then they say oh disaster recovery, IT disaster recovery, that's us but it seems to be the acronym that's sticking for this space so I guess we have it So identity threat and discovery and response, so what we basically want to do is that we want to discover where something bad happens with identity and we want to do something reasonable about it and to our help here we have Mr.
Blåhaj which you can go buy at your IKEA store, he is the patron saint of people who get lost at IKEA as well as trans people so you might see him showing up every now and then. So why are we talking about ITDR? Well there's a very simple reason that a lot of attacker has discovered that this is the easiest most cost-effective way to break into systems. Today a lot of the big attacks are ITDR based or some part of your identity attacks have been used as part of the attack life cycle.
So if we want to protect our enterprises from attackers we need to figure out a way to discover when the attackers are successful and then hopefully kick them out of the systems. So what is that makes this interesting? Well we have a attack pattern called adversary in the middle, just because man in the middle but it's no adversary in the middle, just also be mig in the middle for a while.
So the idea here is that you send a phishing email in some form or some format and then the one of your users sees that I should react to this and they click in and they ask to do a login and then the attacker has your session cookie at the end. And there are some really interesting frameworks for handling this. EvilGNX there in the lower left corner. I would recommend looking at some youtube videos on this on how you can install it.
You can also have one of your interns or junior staff persons that likes tech do an installation and you can do extremely interesting demos for people, see how easy it is to lure people to fill out. Just click on the link and then hey your session is gone. So how do we protect? To conclude that it is today AI makes it possible to write really really nice phishing emails, we can conclude that there is really easy and cheap products available to facilitate these attacks.
Because if you look at it like once the attacker has the identity they are the user, there's no way that the system will be able to distinguish between you and the person who has your session cookies. Well we kind of look at other things. So we say okay this user has this session cookie, is it really the same user? Well we might, if you're a little bit more advanced, we might have compliant devices. So we might say okay this device is not right or we might at least register what kind of device you have and suddenly you're a completely different device.
That could be an indication that there's something phishing going on. We could look at where you're coming from your IP. If it's inside of your network, fair chance that it's still the same person. If the person usually comes from Sweden and suddenly come from Russia, might also be an indication. Not always that reliable because a lot of users go on vacation and then they sometimes use VPN. So suddenly they flip from Thailand to Sweden very quickly and then the your ITDR agents is going to react. You might look at the applications.
If it's this user, someone that normally works in a factory making really bookshelves, suddenly has a need to go to the the treasure applications. Okay that's a bit strange so that we probably shouldn't take a look at. We can also connect to the dark web and basically see has this user's identity been for sale. If this was for sale, it is not impossible that someone bought it and then attacking it. So then comes the next part which is the react part and of course you know you can shut down everyone's identity and then the system is extremely safe because no one can use it.
But what you usually want to do is to do something reasonable. So you might say okay there's a good chance that you compromise so I'll force a re-authentication with MFA. And then suddenly the fact that the attacker has the session cookie doesn't really matter because the user has now a new session cookie. So the system will go like hey you're presenting the wrong session cookie. You might just exchange the password and force a self-service password reset. Then you also in some systems have the advantage that that will de-risk you. So you fix both problems.
You kick out the attacker and you automatically resolve the risk user status in one go. Fantastic. But the idea is that we try to look at a broader set of signal and start to see okay you look you're compromised and if so can you do something that can tell us if you are compromised or not. And to achieve this the actually the biggest problem that we have is that it requires the identity teams to talk to the cybersecurity teams.
And the previous speaker here said a very interesting thing that he said that a lot of his career has been to translate nerd to non-nerd and nerdish to non-nerdish to the business. It's a little bit like IEM has its own language and CyberSec has its own language. And it can be quite hard to have these two teams work together. And you also have that they operate in different time zones. IEM usually operate in normal office hours. A CyberSec team operates 24-7. So how do you handle that?
But the important thing is to at least have the two teams talk to each other and not be like people from another galaxy. So we conclude that probably in most enterprises you're going to have situations where the attacker is successful in taking over identity. But in most cases this is not the end goal of the attacker. Because they want to get to privileged access. They want to get into your treasure system. They want to get into your central system and either steal data or encrypt the data or do a ransomware or something similar.
So how do we give the cybersecurity teams enough time to discover and do something about it? Well we start installing some nice speed bumps. And none of these steps are things that you know a good attacker can probably get through. But it will take them some time. And time is what you need to discover and kick them out as well as signal. So to do this a good visualize the attack path. Sorry. And try to figure out the attacker. Is this working? Yeah. So we try to visualize the attack path between the vast majority of accounts.
Because when the attacker does phishing it's highly likely that they get a normal account as part of the attack. So you try to visualize the attack path. You try to put in a little bit of speed bumps. Your typical area is to try to apply least privilege for your tier zero and tier one system. If you have been running an AD for you know 5, 10, 20 years. You probably have a lot more entitlements running around in your company than what is actually needed. Because people acquire attentive and over the years. So if you suck in the entitlements and just give out what's needed to do your jobs.
You make it a lot harder for attacker. Because then you have to find someone with high privilege. And if you put the high privilege in a PAM system you make it even harder for the attacker. And one important part of this is that you really want to have your tier zero and tier one admins. Not just their tier zero and tier one accounts for doing their normal email. And put them on phishing resistant MFA. So that you minimize the risk that attacker is lucky and managed to compromise one of these accounts. Then discover and react.
So when the attackers are kind of you know do the initial compromise. You may or may not detect them. They start kind of circling the interesting targets in the company. If you don't have any form of integration with SIEM. If you don't alert the SOC team when the attackers gets close to the targets. And when the log starts showing errors. You would probably have problems. Because then they will break in. So the first part is to see okay how do I onboard these systems into my SIEM.
And the second which actually is much harder problem is to see how can I formulate good use cases for discovering real attacks. How do I see that there's a compromise happening. The other problem is that you need to figure out how what is your ability to actually react. And this can be something very practical. If you require that you have a SOC team. You have an outsource SOC to cover that. And they run 24 7. But the people who can actually kind of react to this. They go home at five o'clock on Friday. Come back again on Monday. Go to some meetings.
They start looking at what the SOC team was screaming about. And then it's 10 o'clock. That gives the attacker quite a lot of time to get through. So how do you handle this to have capability to act also outside of normal office hours. And once you have all of these things in place the next part is to say okay I have a ITDR system and it's covering my primary IDP or I can have my core systems. I can detect attacks. I have an ability to react to it. But okay let's say that you're a Microsoft centric company.
How do I handle all of my AWS functionality or my SAP functionality or my GCP functionality? What we do see as the next step is to start looking at I need to be able to not only suck in telemetry. So tuck in signals from lots of different places to determine if an account or identity has been compromised. I also need to push out that information. It could be pushing it to my IGA systems. I start shutting down other access that is outside of the primary IDP's range. It could be to send it out to the system that does my NHI, my non-human identities.
So these AI agents for example that the user uses that have been compromised also are shut down. So it's not only primary identity of the user. And to connect to the previous speaker automation. Well the first part in many companies is that after all most companies have kind of a core suite of products and in many cases they come from the same vendor. And here we see quite good outcomes. If you are a Microsoft shop for example and you have kind of taken the buy everything from Microsoft you will get decent outcomes. They are decently well integrated.
You'll be able to share information inside of that bubble. If you are not a company who has a best of suite, you're more of a best of breed. Well one option is of course a massive system integration effort which your consultants will love you for. Probably not your shareholders or similar because it's going to be very expensive. But most systems do have APIs that you can leverage in different creative ways. So at least you can kind of target the stuff that is really really important and try to integrate that.
We do see that the standards, so ShareSignal's framework and CAPE for example, are getting a lot of traction. It is still kind of stuff that is you know very advanced. So and with all standards you know like XAML or IDC it's only really useful if there's a fair chance that both sides speaks it and that they speak it in the same way. I don't think that we're there yet but I think we're a lot closer now with SSF for example being viable in an enterprise environment than we were a year ago.
We also do see some proprietary integrations for example Microsoft announced an integration into the main PAM vendors and also to Silverfort. And if you happen to have all stuff that that is in this relatively short list it's definitely something worth looking at. So how to not drown in false positives? So what we have seen when we configured our ITDR platform is that if you do tune it, it is actually giving a lot better results than what you get if you work out initially.
So one thing we saw was that trying to look at trusted IPs, so the IPs that come out of your network, either if you have a piece out of the on-premise office sites or if you have a product in place that sends the all the traffic through and then you get a pool of IPs for the egress, actually does work quite well. But it takes a bit of time to make it work. There are some quite good tutorials also on YouTube for this where the Microsoft teams have been providing some really good information so definitely worth something worth looking at.
It is not going to be that fast so if you tune it well then it takes a few weeks for the thing to become better but it's definitely worth the investment. What we also saw was that self-service downgrade, risk downgrade methods are very good. So for example, consider having if your Microsoft shop SSPR is great because then not only you remove the risk because the user has to reset the password, you also downgrade the user from a risky user and that really helps with having to avoid that your entire socksets and just chases ghosts in the false positives.
When we do the rollout it's important to think about the fact that if you do roll this out on a broader base there's a very big risk that you were going to get a lot of screaming from your sock and a lot of screaming from your helpdesk and then you have to roll back. Some of our cousins did this and had to roll back actually several times. What we did was which has been decently successful was to try to take a risk based approach.
So you take the tier zeros and tier ones they're not that many of them you can actually talk to them and make sure that they understand this and they have a better understanding for the fact that hey you know you're doing important stuff so perhaps we should make sure that your identity is not compromised and that might mean that you have to do assessors pass a reset you know once a month or once a year. So well what should you prioritize if you're starting out on ITDR program? I think the first part is that accept the fact that you're going to get identities compromised.
The user training is extremely useful because it means that some of the users are going to tell you when they get phishing emails and then they can follow up and figure out who else got it and clicked on the links but it won't stop it to 100 percent. Put on the attacker hat and figure out who is how is the attacker going from a base account to a privileged account and try to make put in some good speed bumps for attacker that really can save your day.
And finally once you have the primary ITDR in place it's good to start having the conversations with the people who are a little bit further away from you so the AWS platform team or the GCP platform team or the SAP team and say hey you know ITDR would be good we have gotten quite good results can we have a conversation about how we integrate the world or potentially you want to run your own ITDR locally that's also an option but starting that conversation is early because you know we're all on enterprise time so if we start thinking about something then you know we have to get money for next year to do it.
So thank you very much for listening and if you have more questions there's my contact information. We actually have one minute left for questions and anybody from the audience because we have one from the online list but the question is very simple so who should be the primary driving force so we talked about the conflicts between IAM and cyber security so who should own this in the perimeters?
So what we have done is that we say it's a common interest between the cyber security and the IAM team of course it helps a lot in our case we both report to CISO so CISO doesn't care who does it but one should do it but I think that's a discussion that you really need to have with between the IAM teams and the cyber security it is more cyber security in most companies I would say but you need to be able then to kind of support cyber security with identity knowledge. Okay thank you very much.