[MUSIC PLAYING] Hi. My name's Todd Peterson. I'm on the Product Marketing Team for the Identity and Access Management Solutions. And today, we're going to talk about something called context-aware security.
So if you think about security, usually, security is implemented kind of in a point in time and in a specific use case or a specific system gets secured. So what that ends up being is security is siloed.
So let me give you an example. So let's say that from an identity standpoint, somebody has a role that allows them to access a system. If they have that role, they're allowed in. If they don't have that role, access is denied.
But let's say that your company has a BYOD policy that says nobody's allowed to access anything unless the company controls the device. If you're on a company-controlled device, you can access stuff. If you're not, access is denied.
Let's say that there's a certain application that people can access or other people can't access or that can access at certain times. Again, sometimes, you want them to access it. Sometimes, you don't. But you have to make a yes/no decision.
Let's say it's time of day. Maybe you have a policy that after hours, people cannot access certain applications. So if someone tries to access it after hours, the decision has to be no when maybe they legitimately need to get to it.
And then you may have a policy that says geolocation. If somebody is working remotely, you're not going to allow them in or you're going to require additional-- they have to dial in through a VPN or something. Or if they're coming from China or North Korea, you're not going to allow them in no matter what. That's all good security practice.
The problem is if any of these things results in a no, the access is going to be denied even if all the others are approved as a yes. So that means you have ad hoc enforcement. IT is involved heavily. If I need to get to something that's after hours and I'm working remotely and the policy prevents it, the only way I can do it is if somebody from IT gets out of bed, comes in, and helps me get access.
So it's a really problematic approach. But it's kind of the way the most security is implemented. So let's clear the board and talk about how we can go through an example of what we're calling context-aware security.
We're going to talk about a thing called the Security Analytics Engine. It acts as a risk scoreboard. So let's say that you've set up a risk score for a specific user of 25. Any score below 25 is approved and the person can access things.
So let's give an example of when access would be allowed. The user is the correct user. So we're good there. The person is coming in after hours. Let's say they're working at the office, but it's after hours. They're going to get a score of 10. But they're on premise. So they're getting a score of 0.
They're using a managed device. They're using the computer the company issued them. They're getting a score of 0. You add that up. They get a cumulative score of 10. Because it's below the threshold of 25, this particular user is allowed to come in.
So let's do another example-- still have the threshold of 25. The user is still the correct person. But this time, he's using his own personal tablet, but it's a tablet that the company is aware of. So he's going to get a risk score of 5 because it's not a company-managed tablet, but it's a company-aware tablet.
Time of day is still after hours. He's getting a score of 10. But now he's working remotely. So he gets another score of 10. You add up the score. He gets a 25. So there has to be a decision made.
The Security Analytics Engine can feed an enforcement point, such as an access control solution, to make a decision on this. And the policy that we've established here is that if your score is 25 or hits the threshold, you're going require a second factor of authentication.
So you will still allow this user in to access the application and the data housed on it. But you're going to require him to log in with a one-time password or a smart card to prove that he is who he says he is.
Now let's do this again and change just one other factor. So again, threshold is 25. The user is the right guy. He's now on a non-managed device that the company doesn't even know about. It's his kid's laptop at home. So he's going to get a score of 10.
He's after hours still-- going to get a score of 10. And he's still remote. He's going to get a score of 10. Now he has a 30, which is above the threshold of 25. So access is going to be denied because that's what the policy says.
Now, we could change it even further and say, what if a different person comes in and tries to impersonate this guy and get to the access? Then because the role is wrong, it doesn't matter if they're on premise. It doesn't matter if it's in hours or after hours, doesn't matter the management of the device. Access is denied.
That's what context-based security can do-- is take those real-time, real-world factors that are constantly changing and use them to evaluate and enforce the decision. So the benefits is it makes security-- becomes an enabler to business, not a barrier. You don't prevent people from doing their jobs. You enable them to do their jobs right.
It's future-ready. You can change this policy at any time. If you have another wave of managed devices you want to bring into it, that
07:11
