I'd like to welcome max phone, the head of consulting Europe at Okta who will be talking about security and identity, how hindsight helps us plan for the future. Max phone, ladies and gentlemen.
Good morning, everyone. Yes. Good morning. You just heard, my name is max fun. I work for Okta and I lead it to consulting practice here in Amir. And hopefully, you know, that's all I'm gonna be saying about myself, about Okta. I'm very keen to talk about how security and identity have changed through the ages. And hopefully it'll be quite an engaging topic. So I'm gonna talk about the run up to the present day and what we can do for the future.
Fantastic. Yeah. Thank you for joining us on stage and we're very much looking forward to your talk without the stage is yours.
Perfect. So with no further ado, you know, we used to architect networks fundamentally differently as it was very focused on the concept of a hard outer shell. Basically you have, or you had the internet, then you had a perimeter firewall, then you had web servers, app servers, and then it was an internal firewall. And then you had a backend application servers, database servers, and other things. And this worked for a while. You know, no computer could physically connect to our network unless we gave them one to plug in. And if you were within the trusted network, if you were inside this, you know, you were inherently trusted. And that made sense, that was potentially a good model for that period in time. But we have to remember, you know, all it would've taken is one bad actor. And if you think about this from a slightly far more novel government or military or espionage perspective, essentially for a long while, they were focused on physically getting past receptionists so that they could physically plug into networks and see what was on the inside and this whole thing, this whole problem, this challenge, it got a hell of a lot easier.
Once wifi was created, you know, no more getting into the building, you just park in car parks outside. So I remember working for a defense company, a defense firm that's actually got quite a successful cybersecurity business. We had to physically plug in as there was no wifi. So clearly they had adopted this way of thinking. And to illustrate my point in maybe a more, you know, physical way, a more practical way. I was once working on a, a large industrial campus with this company who was doing all sorts of interesting and classified things, gaining access to the campus with a very mundane pass, you know, a physical pass that was checked visually. So it wasn't a turn style. It wasn't a chip, it was a visual check of a photo that was quite washed out. So I remember being shocked that this, that, you know, once I was past this entrance point and I was on this campus, I could go wherever I wanted by virtue of already being allowed onto the campus.
So, you know, there is a front gate level of security. What I would note here is I was working on some deployed energy type projects, you know, dropping generators into the field, out the back of planes. And I had once lost access to the warehouse I was working in. So I knocked on the warehouse. Next door, didn't have to show any ID. Didn't have to show any credentials. And I walked in and there were buildings houses built inside the warehouse. And there were people, you know, milling about looking at these houses, going, hanging, hanging about near them. And I realized I had heard a rumor once. So I can't confirm this, especially as this is a public forum, but I'd heard a rumor once that there was a facility for training spies to break into buildings, to BR to break into houses on this campus.
And let's just say for the sake of today, without being too specific, I suspect that I had accidentally walked into it. So this is a highly classified thing full of people that have very sensitive jobs. And I am essentially at this stage, a graduate employee with a very low security clearance and a visual pass. So the point I'm getting at here is just a front gate level of level of security was not enough. No one had verified that I specifically needed access to this building. My identity hadn't been checked, and if it had it, would've just been an employee ID card, the very same entry credential that's hardly secure. And this analogy isn't unlike having a simple credential of a username and password for accessing a network. Once you're in you're in. And that password is the same one, you've used 200 times to log into wifi to coffee shop.
So by extension that coffee shop security against hackers is now in question, is it somewhat affects your business security. If they get compromised, your first name dot last name, you know, your password, perhaps even your home address or telephone number or all out there, all right, for, you know, password spraying style attacks, or even more complex to defend against social engineering. And once you are in with those credentials, you can go places. You know, you, you can go places. You don't need to go. There are no policies around what you should be able to access based on who you are. And that's why, you know, Verizon's data breach report stated that 81% of hacking related breaches were against stolen or weak passwords. 81% of hackers, they logged in, they didn't hack in. And I think that there are many large hacks mega hacks in, in the newspapers today that make that point.
So back then the world was actually quite simple. In essence, it was an application sitting on top of a server. Then the cloud came about Salesforce, oh 365 box Workday, slack, zoom, G suite. And they took that core confidential, sensitive data and moved it outside of, of the firewall. Now I think if we had said 20 years ago, that your core strategic infrastructure, your documents, your sales data, if all of this would be outside of your network and your control, no one would've believed us. I think the reason for this great change is that people are accepting that other people can sometimes do things better than us. So then on that, you know, the iPhone came along and it created another change. It showed the world that technology could be easy. It could be attractive. It could be the thing you actually want to use.
And by way of example, you know, how many times has anyone in, in the, in the conference hall today or watching digitally pulled out their phone, even this early in the morning, without having a notification to check on sports stocks news. So technology has become an integral part of our lives. It showed us that, you know, we have to constantly seek to move with technology or will fall behind. But when we consider the iPhone, it's also worth noticing the things it can't do. So it's battery life, it's screen size, it's processing power, they're all limited. And the only way we can improve these is by getting a new, physical phone, an apple have just released a new physical phone by the way. And if anyone hasn't checked that it is so your phone isn't suitable for doing a lot of stuff, but it can connect to something much bigger using the API economy and run those tasks in the effectively unlimited cloud with unlimited processing, unlimited storage, unlimited batch, unlimited battery life.
Something like rooting you from a to B using a mapping software is actually very processor intensive. So doing it on your phone would drain the battery. We can do this in the cloud. So we've moved the workload from our endpoint devices to service in the clouds. Now we have APIs running on servers, powering things with applications on top and devices on top of that. So instead of the cloud simplifying things, we've actually made it far more complex. So there are now four layers or so that we need to protect. And this leaves out the actor as a layer, who's actually doing something some good, some bad. So now what we really have is applications and APIs consumed by devices and users that we don't trust built by developers, that we don't always trust, hosted on systems that we don't always trust, run by other departments that we don't necessarily trust we should, but we don't always run in servers that we don't control, but we still need to get the job done.
So when your app is hacked and someone downloads millions of records, for example, the developer who built, who built some of the code around the Equifax hack, you know, they don't go to the developers. They go to this group of leaders at this conference here today, cuz we hold the responsibility. We have to acknowledge that the perimeter, the perimeter approach, the perimeter is gone and we can't get it back. And if we're really honest with ourselves, it's been gone for a long time, but we just don't like to admit it. So you've got employees, customers, partners, contractors, sometimes they all look very similar. There isn't a cookie cutter, a boiler plate, a simple set of rules. You can apply to these groups because it all comes down to trust. How do you think about it? How do you figure it out? How do you apply it?
How do you revoke it? How do you measure it? So I think it's fair to say in my story, we've arrived at rather a bleak point in time, but let's talk about what we can do for the future. Cuz there are four different pillars from today. Moving forwards that we can do to address this the first and most important, in my opinion is context, context. As it relates to security, it's key. Who's trying to do what. And when, when we authenticate into a system, we have context, our credentials, username password, past years of behavior, third party intelligence, you know, we can hook out to bot tracking networks or identity proving services, the device. Is it new? Have we seen it before? Is it registered? Is it part of an MDM physical network? Is it on the office? IP? Is it on the same IP address that we've seen this user on for two years because of the pandemic to your location is this user in Russia, but most throw all of this away and just have username and password because passwords can never be compromised.
And all of our usernames, aren't firstName dot lastname@companyaddress.com. So, you know, if we focus now on the next thing, which is the device identity, is this something we've seen before? Is it recognize that part of the MDM, like I said earlier, if you always connect with the same computer and the same device, that's very interesting to know if you register with a disc device, it's valuable to know as an application from those devices should be a little bit more trusted. And if they enroll with MFA, when it's part of our managed devices, just asking these questions, improved security and within devices, you can even go a step further. You can look at the application layer. If we fingerprint fingerprint the application, is this the app we release to the app store? Or is it something else? If anyone in this room is a bank. For example, you want to know that your customers are using your app and not something else to connect to your APIs.
And if we look at the user's identity, there are certain transactions that are inherently high risk. If I can enroll as you or I can set my devices up for MFA, essentially I have that. So, you know, I have that account. So when you are doing types of things, you might want to consider, you know, locking those activities off from new unknown, unregistered devices. Most users only change their password when it expires. And if we take something like a password reset, you know, as an identity provider Okta, we would know this has happened and we can send signals downstream. For example, revoking all active sessions and things like sales force. And if you, one of these rare users who's proactively changing your password, perhaps you're not perhaps it's because you've been breached. You've had a notification, I think now apple and Google both notify you.
If you have weak passwords stored in your password locker. So, you know, if we don't revoke your sessions as a result of a password reset, then you are still breached from your perspective, maybe not from the identity providers, but you are from yours. And that's just one directional from our perspective. What happens when we think about it from the other angle of apps, they know behaviorally what you do or don't normally do for an HR person, accesses payroll at 10:00 AM on a weekday. That's fine. If the same person starts giving raises to people at 2:00 AM, from Vegas, that's not, they might have successfully successfully authenticated through your identity provider, Okta in this case, but we don't know what's going on in the app. We shouldn't, but the app can notify us that something's wrong and force additional factors, notify security teams. As you might want to do this type of thing to mitigate breaches and actions.
If we're told there is a chance of a breach, we can kill sessions. That's very powerful. So if we think about this from a cm or a B2C perspective, you know, attacking it, registration, setting a password, anything that that we're talking about right here, a user does a bot can do too. And we know we're not experts at tracking every bot network in the world or every hacker. You would need an entire company just to focus on this. And there are, we can link out to these as part of an inline hook and enrich our own data, registration authentication, and we can stop this before it happens as well. So, you know, all of this just leads to far better outcomes. And I think when we're talking about, you know, customers, we do need to provide an additional layer. We need to think about security differently because you know, someone could be doing something very normal, something mundane or someone could be updating details in a payment Porwal.
So you have to decide when and if to apply security and therefore friction based on what they're doing. And I think the point I'm making here is contextual security policy based security is fantastic for addressing this. You know, employees love it, cuz it makes their lives easier. Customers love it because it reduces friction while still employing while still creating security, which is great. You know, if you, if you're on the office IP and you know, you're on a managed device and we're doing, we're looking at an app that isn't deemed to be critical, why are we MFAing people? Those texts cost you money. So the second pillar after con context is having an open platform. The better we can create this context, the better it'll be, but it requires another step being open. So Okta's approach to this is an identity engine. The identity engine is the ability to override things in our product.
You have defaults, you can now turn these on and off. And one of the core things I guess is that we acknowledge, we don't know your context like you do. That's your job, not ours. So it is the ability to take that understanding into your business and plug it into us. We, as a provider, don't have to figure it all out. We can just let you do it. And with this context and this open platform, you can use event hooks when something happens in your app or in your network, user logging in registering, logging out, you can hook out and say, here's a piece of context on the event. That's just happened. You can start doing actions and processing it. You can have a logic function and further actions. And within line hooks, I've mentioned this earlier. You can redirect Okta and tell let's do something different from before.
If you're hooking out to, as I mentioned, you know, the bot detection partner of ours and enriching the context of a login and that enrichment detects, something's a bot. It can prevent it from logging in. Even if it's already registered this glue, lets you keep things together. And as part of a user registration, we can hook out to a, a credit checking agency. If you're doing something quite secure to provide a layer of identity proofing of registration. So the third pillar is that we need to connect everything. There is no one vendor technology or app stack that ties this all together, regardless of what vendors might say about this, there's no singular clear way of doing it. Apps need to talk better and we need to accomplish this by adhering to open standards and protocols. And on the subject of interconnection, we, the identity provider normally know things have happened before.
Most people do. You know, we know that hacking groups have released data sets. For example, we can go ahead and take additional actions like forcing password reset or revoking tokens. We can compare passwords to breach data sets and deny their use. If you know that someone is inherently high risk now because of the nature of what's happened, we can end that session. We can reset that password and you're not trusted, but you can earn that trust back. The last pillar that I want to talk about is the network effect because you know, we've got contextual security. We have an open platform and we've connected everything. The network effect of this is now critical. So this is about more apps communicating more effectively. You know, I've spoken about our network, our devices, but how many attacks actually come from someone else like a subcontractor, for example, there's a large us high street retailer, similar to many other retailers all over the world.
And they're a great example of this. They didn't secure their, their systems were fine, but a subcontractor of theirs that had access the HVAC, the air conditioning supplier authenticating their system. And that's how the customer data set got breach. So we need to think about attacker behavior, not just our own network in security, because odds are when an attacker comes along, they didn't go straight to us. You know, they went to a competitor, a customer, another vendor, a supplier. And with this network effective knowledge, we can connect everything and have an internet scale neighborhood. Watch the need, the need for this interconnectedness raises the interesting point that when you do a deploy, a deployment of a more traditional OnPrem software, each deployment is entirely custom and siloed. So you don't have the ability to do things like this. So here at Okta, we've got a great example of defending against the state level attack of another state where all the critical infrastructure of the attack state were down to our knowledge, aside from the airport, as that was using Okta, we'd spotted the state attacking other states across our global network of over 8,000 clients.
And so we're able to proactively lock it out. This is the network effect, it's called threat insights, which is part of our product. And for context, in case anyone's interested, these attacks were at the stroke of midnight on new year's Eves. You have to ask where your security team's monitoring traffic at this point in time. The last thought I'll leave. Is that doing things like this mean that we can proactively adapt and change our security posture because a different organization or a different part of the world is under attack in another industry. I think that's pretty interesting. Anyway, thanks for listening.
