Yes, as was mentioned, I want to discuss a little bit today about enterprise access control for Zero Trust. Really this is about authorization and bringing authorization principles up to speed as you transition to Zero Trust and as you transition to other ways of managing authorization. I'd like to discuss a little bit about what I see as far as the A, what objectives we have for managing modern Access Control to support Zero Trust. I want to talk about roles and the, the industry's transition away from role based access control to attribute or policy-based access control models.
And then I want talk a lot about what policy-based access control and Zero Trust can really do for your enterprise to provide you kind of that unified frame of authentication and authorization services, tying context to users, to devices, and really bringing business value at the end of the day to your enterprise.
I if you're trying to protect it in these manners.
So, so objectives for zero trust, Access control first, the first objective is the objective of authorization that we've always had enabling known identities to access resource with various capabilities. And it's the capabilities part of this that's, that's key. That's really, it really speaks to least privilege. It speaks to what it is we want to do, not just for the resources but within the resources themselves and in the enterprise environment. This is particularly challenging for a couple of reasons and we're gonna go into at least one major example a little in a little bit.
Second, we wanna support methods of regularly verified authentication. This is very important obviously in zero trust main, ensuring that we have time-bound access control in place against resources we're trying to protect commensurate with the level of access that an individual or service requires.
That of course translates to session policies and token policies, making sure that we know how long somebody should be able to connect to a resource to handle a particular function, whether or not somebody needs to always be connected to that resource or whether or not it's the type of thing like an administrator would only need to access for up to an hour maximum. Those are two fairly big use cases in our individual enterprise environment in, in Yahoo.
So we, yeah, we're, we're very kind of cognizant of that in terms of how we manage our policies, establishing least privilege. Obviously our, one of our core tenants is zero trust in general, but extending that to the authorization, not just what resources do you have access to and limiting those, but also limiting the scope and capabilities within those resources. Ensuring again that the work that an individual or a service is doing is commensurate with the level of work that they need to achieve and what, what is assigned inside of the platform.
And most critically ensuring that that access is removed when no longer needed and not just defining that by when the user leaves the company or when the service itself eventually gets sunset. But in intermittently as well, I'll facilitate implementation of authentication and authorization services. So this one is the objective that for the past five years I've been extraordinarily passionate about, We have, depending on your definition, about a thousand application owners that manage internal or enterprise applications at Yahoo. And we're a fairly small identity team.
It is important for me to be able to handle not just authentication offerings, but also authorization offerings that those u that those workers can and engineers and architects can easily use in order to gain access to our enterprises A services. And then to go along with that, educating enterprise workers on their, on our offerings for a, ensuring that people know how they receive access and how they can determine what access they have and are they aware of how our policies work.
So role-based access control handled some of this role-based access control here.
I kind of set up just kind of this diagram for an example. This involves a user named Jane who works in finance in the accounts receivable department. And this is kind of the ideal version of role-based access control, right? The HR data store is handing your identity store attributes that tell you what role or roles they should have. Jane is an employee, she is in finance, she is explicitly in account receivable that grants certain downstream entitlements to various applications potentially. She's not a hiring manager, so she does not receive that role that that association is.
And in this example is shows that the HR system does not recognize her as a hiring manager. She does not have those fine grained capabilities inside of the finance app or inside of any other HR apps to do things that only hiring managers would be able to do.
Unfortunately, the, the reality is that ideal scenario is very difficult to build and even harder to maintain as Jane's job changes changes.
Let's say it's something as simple as she gets promoted to Analyst two, nothing has necessarily changed, but now you need coding logic against every single role in order to maintain effective downstream management of all of those entitlements. The first thing that tends to go, or what tended to go when we did it at Yahoo was you're not able to to do dynamic role-based access control and then you move to more of a request and approval model, That's fine, but it creates a lot of overhead.
So you're requesting and you're approving assignment to finance general Jane has to request this, she has to request finance and accounts receivable. That works okay as long as your regularly re-certifying that access. But if you're not, you could end up very quickly with role explosion where Jane is accumulating more and more roles over time as she requests things. Perhaps even the approval process is kind of being glossed over if her hiring manager is approving that access endlessly, whether or not she needs it.
Something else we saw in our environment that we wanted to prevent that those are obviously things that you wanna avoid and unfortunately the kind of the path that role-based access control puts you on.
So when I think about roles in the enterprise, I kind of think of this in in a two-tiered model. We have the concept of an enterprise role, which could have an association, association with a user attribute or an association with an access request. Jane works in accounts receivable, she has requested accounts receivable work.
But as we move to policy-based access control, clarifying this shift is the challenge roles still exist for a lot of enterprise applications, roles as an object, roles as a construct, especially for a lot of enterprise apps off the shelf and and I could pick almost any vendor supported application just as an example, but you'll find that in a lot of these vendor supported apps, they were built around role-based access control to begin with and many of them were almost built to be a smaller version of an identity provider themselves.
This makes it a little bit challenging to just kind of completely throw out role-based access control even as you're trying to transition off of it. So that's kind of the slide is really more of like that word of warning.
You, you will be wanting to manage policies which grant access to resources. Those resources may require roles and capabilities in downstream platforms or enterprise related apps. That's okay, but it's something that you want to document and it's something that you want manage. Our roles are going to be, unfortunately your bridge in order to transition from role-based access control to something like policy based access control.
So with policy-based access control, what are you getting if you, if you don't want to have those same problems that I had just mentioned in that previous diagram.
So the first one happens a little bit more implicitly and it involves less dependency on organizational groups versus functional groups. Accounts receivable may be a team in Jane Smith, the examples company. It may also not be a team. She might be on a general finance team that happens to have an accounts receivable group of employees working inside of it. That's actually very analogous to a lot of use cases we have at Yahoo.
Our teams are not as individually divided by role from a human resources perspective as you would hope for in order to easily implement role-based or even policy-based access control, frankly. But there is less dependency upon organizational groups and hierarchy in order to establish policy-based access control policies can be extended to multiple resources.
The way I just commonly describe this is templating that the, when you build a policy around the accounts receivable process, it's very easy to then duplicate that policy for other purposes.
You're assigning different resources with that policy template, but the policy of the policy control points of how long that access should be maintained for how often it has to be reified, that's a template that you can now reuse as where with common role-based access control platforms, you're having to recode duplicate logic a lot and this is across multiple methods of doing so. You have some ability to copy and template with a lot of those solutions, but as those, if that business changes around that role, it then gets more custom and more complex as time goes on.
And then all of your rules are different and you're managing them all very independently. And then policies have that control of being able to handle varying levels of access for the same enterprise worker, which better supports these privilege overall.
So receiving finance access in policy based access control, if we have a policy rule that indicates all finance analysts reporting to Jane's manager are able to receive that access, Jane is able to request the access intermittently to, let's just say the policy really, or entitlements related to the policy of being a accounts receivable.
Analyst policy points being she must be level two or greater check there that we know that team is in New York City, people should not be trying, people that are not in the New York City office for example, should not be trying to request that access check. There must report to finance. That's a given. And then we establish that that access only lives for one hour. You cannot access accounts receivable data in the finance application example that we have here without for, for longer than that time period.
Now, as I said, roles might still be your bridge as you're transitioning to policy-based access control.
Let's say you build this account's receivable policy, that's wonderful, that's great, but your HR system might still be dependent upon your legacy understanding of role moving to policy based access control. I guess the long, the long and the short of it is it's not a rip and replace type activity.
You're not going to be able to just simply one day build all of the policies and move all to them and all of your enterprise apps, again, especially you're off the shelf apps that are kind of dependent upon the concept. They're going to need to be kind of scaffolded and maintained during that time as you transition one by one. And as you solve those problems, it is kind of a little bit more of a migration effort.
So with policy-based access control, we start thinking about how we, we tie this to zero trust and for us at Yahoo the the phrase we use a lot is really risk-based access.
So we have two, just as our example, we have two broad categorizations of data classification. We have security data classifications and then we, we have regulatory classifications and these will at the end of the day become the intersection for our policies. Data in a particular resource or platform might be public, private, or confidential. Those are our security designations. They might also hit several regulatory components such as sox, pci, ISO 27 K, gdpr, there's a handful of others.
This is just a small example of kind of the way we manage individual access, how we think of policy control and really how we tie that to risk. At the end of the day though, you still require policy ownership.
People have to own that policy. They have to be able to approve changes to that policy if changes are needed.
We did have an example at Yahoo where we, we went for an extremely, a aggressive access control policy against a service and we found that the service actually took longer to run than the aggressive policy than that we wanted and the service would fail because we would remove the access. We had to extend that ever so slightly in order to ensure that that job could run full time.
But with, with a strong policy control and a well documented approval, you can do that.
So context is really where once you've gone through the effort of beginning to move more of your access from role-based to policy based access control is where you can kind of connect all of the dots really and realize the true value of managing a zero trust strategy in an identity based strategy layered on top of policy based access control and device context to really deliver results for your information technology business as well as your security business.
So establishing I think first and foremost that regular baseline or posture of users and hardware accessing enterprise resources, does Brian always use this laptop always to access these same applications? Always at about this time of day can you gather information about the state of the hardware? Is this hardware on the same operating system that it needs to be, et cetera.
Allowing authentication, which we all, which we often think about in terms of zero trust, but more importantly, well for this talk at least authorization to also be contextually aware allows us to verify and then most critically re-verify and re-certify access to enterprise resources in a far more effective way.
So this is that same example with device context layered on, So we know Jane, we know Jane has the access to that policy. She's a prop properly authorized for these two entitlements based on being defined inside of the accounts receivable policy.
But now we have other layers here as well. We have her attributes, those attributes are coming forward to inform the policy. We now have device context, which is also informing the policy. We know that she's connecting from, well this dummy IP that I just typed in here, but she's, she's coming from the same IP that we generally see or IP or IP range that we generally see Jane coming from. She's coming from her Mac os, she, it is up to date, It is a managed device that is critical I think for a lot of enterprises.
The the ability not just to establish a relationship between the device and user, but the ability to manage that device responsibly in a way that protects both the privacy of the, the worker on the machine and the enterprise data that they might be working on on that machine.
So layering confirmation that yes, not only do we have it to the Jane's laptop, but we have it detected in our hardware device management platform and use the policy framework in order to ensure that we are capturing, yes, this is Jane, this is Jane's device.
It is managed once all of those conditions and it is connecting from New York City where we generally assume Jane is travel. Travel control policies are extremely popular and powerful in order to capture a lot of the types of attacks I think that we're seeing today. Even one's proxy, you can, you can gain a lot by knowing the device posture and the geolocation of the machine. If that's data that you are able to manage, at the end of the day it results in Jane being able to receive tokenized access to the resource that she requires for as long as she requires it.
So as you transition to policy-based access control and really as you continue your zero trust journey, the real trick is there's very few platforms that can do obviously all of this at once. You require multiple policy management layers and points of enforcement. I just talked a little bit about device management that would go along with device health checks. That is something that we do at Yahoo is maintain.
Yes, again, this is the device that we have for this user, but also is it up to speed? Has it been patched? Is it on the appropriate version or at least a version n minus one of what we expected to be. Are they using appropriate second factor off? Is it phishing re, is it a phishing resistant factor or is it not factor strengths, especially important as you look to write policies that involve step up rules, Okay, this user's connecting from somewhere.
We're not familiar with if Brian's traveling for a conference for example, but can we step them up to a stronger factor of authentication or at least just re-verify via second factor or primary authentication. Your authorization and authentication applications and platforms might be different. They might be the same. So you might have multiple policy points that you have to control there.
And then of course if you are still managing a firewall or a web application firewall for any reason throughout the course of your transition to zero trust, you have to consider what those policy points may, how they will impact an end user that is trying to access your platform. And then most importantly, document, document, document. Because this is going to be, it's a confusing transition enough for us technologists, it's gonna be even more confusing for your users.
So in conclusion, by moving to policy-based access control, by improving those authorization offerings and thinking of them in terms of zero trust, you can better improve how your application owners gain access to your resources and protect their applications with those as well as how your workers and as well as the user experience of how your workers actually access that information.
I would say migrating off of role-based access control, especially if you are deep into it and thankfully at Yahoo we were not, can be potentially costly, but it can greatly reduce your exposure to role explosion and really an endlessly accumulating and snowballing mass of access grants That's very difficult to uncouple once it gets out of control.
And establishing common policy based and context based security frameworks is probably one of the most efficient things you can do to improve your zero trust posture and really provide a level a platform with which you can engage your users to educate them about how all of this at the end of the day works. Thank you very much for your time. I think we're right at time, so I'm glad we were able to wrap up right here.
Thank you Brian.
Yeah, we have time maybe for just one question before we jump into the panel session. Anyone from the audience?
Yeah, thank you.
Great presentation. The good question. How long did it take at Yahoo to cover the 1000 business application owners? I don't know if it's represent 1000 applications, but you have a
So it it, I don't know if I can provide you a single timeframe because there were, there have been several efforts that we've done across identity. What I would say is we have a very, well, we have a distribution list that helps. It is not 1000 owners to 1000 applications.
It is a, thankfully we do not, we consider it a single point of failure to have only one. So we do have duplicate U owners in there so that we always have somebody to contact should an application go wrong. That's more for incident management and operations purposes for getting them all on authentication. And that's actually something I can speak to. We recently migrated from one tenant of our identity service to another same service, but all application owners had to do something. The process took about six months and that had more to do with application owner resourcing.
Obviously you're asking people to do something, so it's something that they have to schedule longer than it would've taken us individually to just do it. But we don't, again, least privilege, we don't have the rights to make changes on their platforms without, you know, a a lot of approval. So we don't, we didn't take that approach. That was a little bit more of a migration for that timeframe. I think six months of engagement, if you have a strong relationship with those application owners, isn't unfeasible.
