Hey everyone, great to meet you. Very excited to be here in Berlin and meet all of you. Thank you for coming today. So I am the CEO and co-founder of Silver Fault, and what I'm going to focus on today is an area of identity security that is usually being neglected because it's very complex and it's a little bit ugly and it is the area that most of us are trying to forget about. I consider it as the blind spot of identity security. And that is how do we bring all the great modern identity security capabilities that you hear about here this week and that you all probably already know? How do we bring them to our legacy infrastructure, our legacy systems, our service accounts, all of these things that just don't support any modern security, eh? I'm going to try to dive into it and maybe at some point even get a little technical into how we can look at this problem and how we can potentially solve it. I'll try to leave time for questions at the end, so if you have any questions, hopefully we'll have a little bit of time.
So identity security, as we all know in this room, is very, very critical for today's enterprise security because identity is really becoming the the last perimeter and luckily there are already great identity security solutions out there in the market, right? I'm sure some of you already are using them in your companies. So solutions like Azure ad Okta, ping, and many others. You know, we partner with all of them and, and I think they're doing a great job at securing modern applications. So if you want to protect modern systems, modern environments, they're doing an amazing job. They have all the right features. The problem is that there are some types of systems and environments that these products just can't support, and these blind spots are really where tackles focus because they know that there is no security. I'm talking about things like legacy and homegrown applications that a lot of us are still using command line tools that attackers are using in almost every data breach and ransomware is using as well, right?
Things like remote PowerShell and other ways to access resources that just doesn't have multifactor authentication or anything like that. Service accounts are another huge problem. All these non-human identities, how do you even protect them? They can't do mfa. You know, someone told me they just don't have good thumbs, eh? What about protocols that Ransom is using to spread in the network and just IT OT infrastructure in general, right? Whether it's your industrial systems or medical systems or other things that just don't support any modern security, this is not only a security problem for a lot of companies, it's a compliance issue and it's also an issue with meeting cyber insurance requirements, right? Insurance companies lost a lot of money in the last couple of years, especially because of ransomware attacks and if two years ago they used to only require mfa, you know, just the fact that you have MFA anywhere was enough. Today they have a long list of places where you need mfa, you need MFA on your on-prem infrastructure, you need MFA for every kind of admin access. You need MFA for your switches and routers. You need it everywhere because they understand MFA only in one place doesn't help. And that is really the problem.
You know, when I started my career in cybersecurity about 20 years ago, it was in the Israeli intelligence and I was actually an attacker though for six years I was managing cyber campaigns, cyber offense. And I can tell you from the attacker's perspective, it doesn't matter that you lock the door if the window is open, right as the attacker, I get to choose how I connect to your systems. You can't tell me to use remote desktop because that's where you have mfa. If I can use remote PowerShell or wmi or other tools to connect to the same server, it's, you know, it's, it's funny because these tools are actually what attackers prefer anyway. You know, it's only the regular users that you are annoying with MFA on the on the front login screen, the attackers don't even care. Eh, same is true for accessing to a file show or using a service account to access things. As long as one of these things is open, that's enough.
Attackers know it and this is where they focused. The best example of this is ransomware, right? Why is ransomware still possible? Why if you have one infected computer, it can then spread to all the others no matter what security controls you have, because they're intentionally using these legacy authentication protocols. They know that this is like the secret underground highway where they can just move between computers in your network and nobody will see. Cuz nobody's looking at these legacy protocols. So today I want to talk about a new approach, okay, I'll, I'll try not to focus about our product specifically, but really describe the the approach because I think it's something that everyone really needs to adopt and start thinking about if we want to really bring identity security everywhere, and we call this approach unified identity protection because it's really about bringing identity security everywhere really to all these small corners and and blind spots of your environment.
And the idea, I'll also explain to you a little more technically how we do it, but the idea is sitting in the backend of the legacy identity infrastructure, because we understand that it's very hard to get rid of these legacy protocols and mechanisms. They are built into your applications, they are built into your servers. So instead of replacing them, let's allow those old systems to still use these protocols as far as they know, but actually add security in the backend of the legacy identity infrastructure. In a minute I'll explain what it actually means, but this approach allows to apply MFA on any kind of system. We can do MFA for a shared folder, MFA for mainframe MFA for industrial system. It also works not only for human users but also for service accounts, which I think is even more important. That is, in my opinion, the biggest blind spot today.
It works both on-prem and in the cloud. It even works in a, in an L gap network where there's no internet. And most importantly, from a practical perspective, it doesn't require any changes to the systems that you need to protect. Before I explain how it works, I wanna show a very quick example and I'm going to use the example of Azure mfa, which many of you are probably using great product and Azure MFA or or Azure AD condition access in general is doing an amazing job protecting web applications. But can we use that to protect a command line interface with the same kind of security, same kind of user experience, also leveraging this great product that we already have, right? We have it as part of our Microsoft package.
So in this example, you know, trying to run a a remote power show command, we can actually sign in with Microsoft, with Azure ED and even get the Azure mfa. That is just an example. Same can work with Okta, with Ping, with Duo, rsa, yubico, whatever. It's really agnostic to what is the type of mfa. The actual technological change here is the ability to inject that protection into a protocol that doesn't support it. Now how do we do it? So I'll explain in very high level, if anyone wanna get a little deeper, feel free to find me after this and I'm happy to go even deeper. But I think it's important to understand, otherwise, this presentation will be very fluff and I think it is important to understand how this actually works. So today you have a lot of endpoint servers applications authenticating with different protocols.
Some of them are modern, some of them are legacy, and it's already using some kinds of identity, you know, directories or identity providers, some of them again, some of them old, some of them new, and each of them has their own security features. So there actually two problems here. One problem is that some of these old identity solutions don't have security at all. Active directory is probably the most important example. And another problem is that even the modern solutions that do have security are doing it as a silo. Each of them has their own local security features. You cannot use the features from one modern identity platform on another because they're all competing with each other. So we want to solve two problems, bring security to the places where it's missing and unify those islands, those silos of identity. The way to solve both of them is the same.
We add something behind all these solutions that acts like a unified second opinion, okay? So whenever an authentication goes to active directory, as an example, beyond what Active directory does today, which is not a lot, it also passes it to this new system that can make an additional decision. And the additional decision can be based on risk, can be based on a policy, can be based on behavior and location and protocol and anomalies and all kinds of things that are a bit more intelligent. But most importantly it can involve modern security controls like MFA or Conditional Access. But because the MFA is triggered in the backend to an API call, the actual service and applications don't even know once this is completed, they just get the original legacy response that they're used to. So think now about an example of a command line tool or a, or a shared folder or some other piece of legacy infrastructure or resource. As far as they know, they are still using boroughs, l a, ntlm, any of these legacy protocols. As far as they know and they're still talking to the same old directory, they have no idea that behind that directory there is now an additional solution that can call Azure AD or Azure MFA or Okta or anything else. Even a Fido token, right? Triggered out of band and then they received the same response that they're used to, you know, the the K ticket that they expect or the l a or the ntlm response.
Now the example of doing this with MFA obviously is relevant for human users, not for service accounts. So what do we do with those service accounts? Service accounts take a different approach because they cannot do regular mfa. It's much more important to understand what they are doing and restrict what they are able to do. Luckily, service accounts are usually very predictable. They do the same thing every day. So the first step is to actually learn what each of them is doing, map all the service accounts, which you can do automatically. There's actually a way to find them not, not only based on the names and the attributes, but you can actually find them based on behavior service accounts behave very differently than humans with a little bit of machine learning. I'm not even talking about the things that are happening these days, but even just a little bit, you can actually detect human behavior versus machine behavior.
The machine just does the same schedule thing, it doesn't sleep at night, doesn't rest in the weekend. It doesn't act like a human in any way. Once you map all of them, you can start mapping their behavior. What are they doing? They're coming from these two sources to these five destinations every 15 minutes and they always use cables or held up and you can understand how predictable they are, how risky they are, and you can start applying a policy on them. Now, a policy for service account is much more of a least privilege or a or a zero trust policy. It basically says after we learned that this service account is only coming from here to Dell every 10 minutes, this is the, this is the behavior, this is the intended purpose, let's lock it down almost like a virtual fence so that it cannot do anything else.
Even if somebody knows the password to this account, the they can only log in from A to B, that's all this account should be doing. So by automatically finding, mapping and restricting all these service accounts, even if you have tens of thousands of them and some of our customers do, you can automatically build a baseline for all these policies, all these service accounts that only allows them to do what they need to do. Even if it's a domain admin, somebody tries to log in from another computer with it, they can't. They can only do what the service service account needs to do. So I want to also give you some idea of how people are usually using all these things because we talked about a lot of things. We talked about visibility and discovery and MFA and service account protection, a lot of things. I wanna give you an idea just for my perspective.
All the companies we are talking to, what do I see usually people doing, just to give you an idea of what I think is the recommended journey, where do you start from and what do you try to achieve? This is at least what I see in most companies worldwide. The first step for most is visibility. You know, you can't protect what you can see. So the first thing you wanna do is just discover everything, map, analyze the behavior and find issues. Issues could be legacy protocols still being used. You, you will not believe the number of companies that told me they don't have ntlm V1 anymore, they got rid of it, but 30% of the network is, is only that you can find things like shared accounts and shadow admins and many different things that first of all, you just want to know about. The second step for most is mfa.
MFA everywhere in all the places where IT metals, okay, you don't need MFA everywhere because it's a little too annoying, but you want to at least make a decision and not be forced to only protect some things because these are the only products or or applications that support mfa. That's not a good reason. You want to really prioritize your systems and decide which are the most critical ones that should require MFA without these limitations. The third step is usually protection of service accounts. Like I just explained. Step number four is not for everyone. So I have to say the first three I see in almost every company we talk to, these are almost must haves steps four and five are not for everyone. I see them usually in more mature companies. Number four is about automatic response to identity threats. So if we see lateral movement, somebody's trying to do a past the hash attack or, or any other kind of of suspicious behavior trigger a reaction, step up, authentication, block access, do something about it that is more than just sending alerts because we all know what happens to the alerts that are sent to the soc, right?
Nothing really, eh, it's really hard. It's hard to deal with so many alerts. So automatic real time response is usually the next step in maturity. And the last one, which I think is the most strategic one, but again not everybody is there yet, is real consolidation of the hybrid IAM infrastructure. This is the step where we can actually use our technology to act as a translator between legacy protocols and modern protocols. What I mean is that you can take a legacy system that can only talk to active directory. The system still thinks that it's talking to active directory, but really we can translate the protocol to Samuel so that you can connect it into Azure ad, for example. So that's why you can really consolidate your IAM and manage everything from one place in the cloud. We just have two minutes left, so I'm going to skip, you know, there are some stories of different customers. I don't want to focus there. If you want to hear more stories from specific examples, you know, come to us after I'm here all day and I'm happy to talk and I want to make sure that we have some time for questions. So let me know if anyone has any
Yes, yes indeed. Lots of positive feedback from our online audience and the audience here. So thank you. Well done you. One question from the audience is, can we say that your platform acts as an extra policy decision point with very specific behavior is the question?
Yeah, you can say that, but remember, there are two ways to use our product and I think many products you can be very specific with what you want. I mean, you can manual build a policy and say if someone from the domain admin group connect after 2:00 PM from this country, I want mfa. Or you can really use the intelligence and the AI to make smart decisions that are a bit more flexible. So there's some flexibility during the policy.
Okay, and we have another question here is how is a change in the application handled? A change can mean that suddenly the service account connects to another thought.
Not sure I understand, but hopefully I understand that what you mean is what if the service account is trying to do something a little different Sometimes instead of building a very specific policy for service account that says you can only connect from these two sources to these five destinations, you can define them based on, for example, groups, groups of systems, or maybe subnets or other attributes that give some flexibility in case it's a group of servers that are the source or the destination. There are also cases where only one side, either the source or the destinations, is actually something that you can really lock down. For example, think about a scanner. A scanner connects from maybe one or two sources to many, many destinations. There's no point restricting the destinations. They can be anything. But if we lock down the source, we at least know that this very, very powerful account can only be used from here. Nobody can abuse it and try to log in with it from somewhere else.
Okay, great. Thanks. We're at time. Please show your appreciation for head covets.
Thank you very much. Thank you.
