No. Yeah, I appreciate it. Thank very much. And thank you again for having me. Yes. So my discussion today is on driving business value with zero trust. And it's a little bit the story that we've been through getting to where we are quite literally this week as Yahoo. So I'll be discussing today, the journey that we've had, both the former AOL and Yahoo organizations, as we became a handful of companies and ended up again this week as Yahoo and the investments we've made in enterprise identity over the course of that time, discuss some of the investments that we've had and really how we took the work that we did and used it to build really, in my opinion, a world class information, technology security, and identity culture, and some of the metrics that we use and how we kind of prove that we are creating business value and operations value while helping to secure our enterprise with zero trust protocols and paradigm.
So, so a little bit about our journey in 2017, Yahoo was purchased by Verizon. Yahoo would become combined with AOL. And at the time we formed an organization called oath. The idea behind oath was really, we were going to be kind of an umbrella company, a company of brands, which at the time featured Tumblr end gadget tech crunch, Huffington post, and it was kind of a holding house for all of these brands. There was obviously a, a quite public Yahoo breach that had happened on the Yahoo side of the technology. And for that reason, then as well as many others, the decision was made to go live really with a Greenfield identity environment. So we got to build enterprise identity from the ground up 40 years of combined it infrastructure related to directories and identity services really kind of thrown out together and built from new the way we wanted to do it.
We had a combined enterprise identity team that was formed of members of both AOL and Yahoo at the time when we became oath and what came out of the woodwork right away in talking with our friends in our paranoid organization, that's what we call our it security team is that zero trust. There were several principles that they wanted to implement and zero trust immediately comes out as the driving force for a lot of what we do. And, and many of us in it at the time were even thinking, well, what is zero trust? And most importantly, I think what is zero trust to us? So we began our, our journey in the summer of 2017, trying to answer that question by 2019, we have enterprise authentication and single sign on live. That happened almost immediately. We had built not just authorization, but also identity governance.
So role-based access control. For course, screen access based on department values for the enterprise workers, legacy authentication and authorization services had been deprecated open ID connect was now our new standard, which for, for at least the Yahoo side was wildly new Yahoo had been using some, a little bit of proprietary stuff all based on SAML, just moving away from that. It, it was a big change for our application owners. It was a big change for our users that had come to expect a, a certain type of service. And here we were introducing them to the concept of zero trust in 2019 as well after we had finished identity governance, we've kind of had to put a break on everything and re really rebrand the entire organization this time. And now as Verizon media still owned by Verizon, we were Verizon was our parent company again until basically last week.
This year, the sale was announced of the, the Verizon media business unit to Apollo. And we were rebranded as Yahoo. So personally I came from Yahoo. We've, I've come full circle, but the organization is Yahoo again, as of quite recently. So again, since oath, we are managing 17 around 16, 17,000 enterprise identities in, in our environment about a thousand applications, multifactor authentication is required across the board. We have privileged access management in place for several of our key directories identity platforms and sensitive services that are help desk team uses in order to support people with identity operations, such as password reset, pretty much anything that touches a credential at this point is managed by a privileged access management solution. This year has been a very big year for us, particularly in the metrics and KPIs category of work for us. We've been really, you know, we've, we've had this vision of everything that we've been trying to do.
And our goal is very diff is very easy to say, very difficult to prove without really strong metrics and analytics behind our decision making. And so that's really been our, our driving force this year, but we're really getting to the point where we're, we're digging really deep into our data. And we're figuring out, especially on the user lifecycle side, backdated, terminations, mergers, acquisitions, all of these things that make user management challenging, especially for a media organization, we're getting really solid numbers around and using it to help drive our zero trust decision making. So as far as our investments, again, as I said, the first problem we had to contend with, with what is zero trust. And again, what is it to us as individuals? There were, there were several phrases that were thrown out. The big one that always stuck out in my mind is we're not just relying on layer three security anymore.
We're not just relying on securing TCP I P and, and presuming that that is going to solve all of our problems for, for me. It was always more, I, I always thought of it more of expansive across the entire OSI model. It's how are you implementing security and at a station across every single layer of the transaction, whenever a user accesses a resource. And so the truth for all of us, I'm sure landed somewhere in the middle. One thing that stuck out to me re somewhat recently, in fact, I had an interview with a prospective worker in our organization, and I had just asked casually, what does zero trust mean to you? And the, the response it's one I've heard, but you know, when, when somebody says it to you and you've spent to, you know, a few years trying to work towards this, it kind of punches you in the stomach a little bit.
They had, they had basically kind of dismissed it as a buzzword. And for me, it's less about the phrase of zero trust and being a buzzword, but it it's, it's very, for us, it's important, but it is a perception problem that I think we have to address. And we've been addressing it since day one. And just in what does zero trust mean to our various it stakeholders? Our, our users, our application owners, again, shifting away from network based security was a definitely a bigger leap for Yahoo for the Yahoo side of the house. So kind of working through that roadmap is something that was very close to us. And I think that's something that we contend with our considerations, for the enterprises. You're thinking about building a new identity environment. As we started off in 2017, we knew we were going to have on-prem hardware on just because we have very large data centers in at Yahoo, especially, and as well as AOL, we had large data centers, they were world class.
It's hard to get away from that as a strength. So storing some of our applications there makes perfect sense, especially from a cost perspective, but, you know, considering cloud versus on-prem obviously right out of the gate, what kind of a hybrid model where we going to be moving towards credential policies. We had a lot of conversations that first summer about how we wanted our password to be, and not just are we having enough special characters or anything like that. We started talking about entropy. We started talking about multifactor authentication and device, device policy, really as a whole, how all of that was going to start looking. We talked a little bit about protocols, eventually landing on open ID connect as really our preferred protocol. We also support Sam inside of our enterprise, but our SAML two, but open ID connect and O off to are our preferred protocols for all enterprise authentication, how security reviews were going to work Yahoo, especially coming just from my perspective was a very build it culture.
Building new applications was generally seen as the thing to do. And unfortunately, what you're often left with is several applications that have varying levels of support. We wanted regular security reviews to make sure that we didn't have applications in the wild, that one we didn't know about. And then two that we're not getting security patched. So even just putting that in place, I think was not, not unexpected by application owners. And they did have some security review processes in the legacy organizations, but there was certainly more weight put to it. When we started oath, we needed to prepare for M and a activity, being a company of brands, right? You figure you're going to purchase other brands and you're going to sell off brands. Like it could just be something that happens. So we had to prepare our user life cycle operations for that reality.
And the one that I was really pushing and from the very beginning as we go through this journey was culture. It's kind of my passion project. How does, how does zero trust? How does security engagement with your workers? How does enterprise identity and the way that you provide services to your end user impact culture? And it was just something that had dawned on me a few years back when talking with colleagues, former colleagues were now working at other companies, how different their corporate culture is affected simply by what chat platform they use inside of their company and how they interact with that chat platform. Do they have automated bots? These things like you actually get the sense that it impacts their corporate culture. And so it was something that we had been driving from the very beginning as something that was very important to us.
Yes. We wanna be zero trust. Yes. We want to make it difficult. Assuming that an attacker just using the zero trust paradigm is already behind the walls, but we also needed to, at the end of the day, serve our application owners and serve our users. So it leads to answering many questions. It's 2017. We've had a couple of months pre-sale to think about these things. We're able to begin actioning work as we became oath legally. And we start going through all of these questions. Again, user life cycle was such a big portion of what we had to do, determining what services we were going to be supporting work from home was one that I admit we got a little lucky on. We did plan very early on to be able to support remote work, just because of the disparate sites between AOL and Yahoo during the events, especially the early days of the COVID 19 pandemic.
We were pretty much out of the gate running the second. They said, you know, no one's coming back to the offices. So that just as easily could have been something where we said, Nope, you have to be on the corporate network. We're going to only support VPN concentrators in this region and that region. And now everything is in that first week of March where we all got shut down. We would've had a much larger problem on our hands. So it was, we were again, fortunate on the enterprise identity side to be able to support work from home, determining how users request, access, all of these things. If, if we look at it through that lens again of culture, how does a person's day to day look when they come into work for Yahoo? That's, that's really what we were kind of trying to keep in mind as we really designed this environment.
So I built this little model and I was using this to kind of explain cuz really what we have at the end of the day is policy layering. You have policies in your two factor authentication. You have fact policies against your single sign on your device management utilities, your directories, your identity governance, the system that's really running regular re-certification of access to ensure that users only have access as long as they need it. Kind of all, many of these things were familiar from legacy organizations and some of these things were new we're we are, re-certifying far more applications than we used to be. We used to do it under certain regulatory scopes, which was required, but now we're actually doing it just based on security risk. There are several applications that we re-certify access to simply because our paranoid team, again, our it security feels, yeah, we should be re-certifying this. So building this policy layering really is what, this is the layer where I think you're figuring out again how workers interact with your identity ecosystem. You're figuring out, at least on the technology front, what impacts you're going to have on the corporate culture in this model. I like to think about the water cooler, a little bit to workers talking at the water cooler about the difficulties they're having, getting access to a particular resource. That's not a situation that I want as a security practitioner, as a technology practitioner to be responsible for.
So building that zero trust culture, again, an organization's culture, you know, just, it affects the norms, values, and, and growth. Really. At the end of the day of an organization, we impact us across several areas. We do this with security engagement. This is mostly where our paranoid team comes in. Our fishing simulations are a good example of this. We have a very positive attitude, fishing engagement team that is responsible for educating. Really the goal of security engagement is educating and engaging with enterprise members to make everybody quote unquote again, paranoid, again, the available services that we're providing, the technology that we're using, and then always, you know, working through that balance of security and usability to build that culture. And now with zero trust, that's the tr that's really the challenge we're saying implicitly. We don't try to use the, the language zero trust when we're discussing like internal communications, that, that, but at the end of the day you are, if you've come, if you came, especially again from Yahoo and you're used to getting access to things a certain way, and now we are telling them implicitly, we do not trust you.
That's, you're running the risk of impacting your culture. You're, you're running the risk of at the very least making your workers less happy than they used to be at least on the usability front. So that was something that we had to keep in mind the entire time. And for me, it's about these four pillars of identity, user life cycle authentication, authorization, and identity governance. As we look for zero trust, authentication's the easy one to talk about, right? We're talking about client IDs and certificates. We're talking about a token based access. We're talking about ensuring that users only have access for short lived windows of time and that they have to retest regularly who they are in order to receive that access on the authorization side. It's very similar. You're requesting access. We're ensuring on a regular basis that we're reviewing what you've requested and what you're using to see if, whether or not you need it user life cycle.
I'm not really doing these from top of order. It's almost more order of importance. User life cycle is critical for us. We need to make sure that workers who are onboarded are gaining access to the level of resources. They need to do their job on day one. That is our really our, our service and goal. And then on the zero trust side of that goal for user life cycle, it's ensuring that users that are leaving the company are losing access in a timely fashion immediately, really. And then identity governance re-certification of access timebound access control, a concept we have here called elevated clearance. We are looking for ways to ensure that users are able to get specifically the access they need, and that we are always aware of how that access is growing in the legacy Yahoo environment. We had a, we definitely had issues in the past of like snowballing of entitlements and capabilities where a user could gain access to something.
And then even if they didn't need it, never really lose that access. That was something that we had to stop on day one when we built this new environment and something that just at the very least, just from data integrity reasons, you don't wanna be managing an authorization system that allows for that sort of thing. It helps keep everything just clean and neat in order to be doing that effectively. Well, so with authentication again, single sign-on from was a must for us out of the gate. Two factor authentication required in all interactions. Now, depending on where you were in the enterprise, in the legacy organizations, you ran into this or you didn't now in oath. And now today, Yahoo, this is a requirement across the board and certain applications have even more aggressive policies, particularly where two FA and re authentication is required. Our HR system being a clear example, we reforce authentication every time and we do get feedback that we are, we are too aggressive about it, but this is also the system at the end of the day, that has a lot of information about workers.
And we take that incredibly seriously on that, on that side, on a per application basis, we have built an environment that does allow us to be more aggressive on a, on a one by one basis. As we look at apps that are, are critical to our success as an enterprise, that's where we apply more of the security weight of things as opposed to usability and where we use zero trust paradigms to do so. Again, I said open ID connect, being preferred. It's really just how access tokens work and how refreshed tokens in the oof two and open ID connect protocol can be used to help time limit access of resources to ensure that somebody only has that session for as long as they need it or as really for the day generally. But if it's a more critical and sensitive application, we have the ability to adjust those policies again on a one by one basis, ensuring that if we have a highly secure system, we're revoking access in, in very short windows of time and then authentication the, the big thing we do provide corporate phones at our, at our place of business.
It, it makes device management policies a little bit easier to be more aggressive with, but the policies and posture of those devices, what you can do with them and how you gain access to enterprise resources from an authentication point of view, defining that defining the authentication part was the first part of, of 2017 for us authorization again, access people, having the right access to the right resources at the right time and thinking about how this begins to actually build value. You are understanding more about your business, the better you get at this. It's not just role-based access control. We understood the limits of role-based access control. Fortunately, very early on, we do use it for course, grained access for departmental level, but we don't assign any fine grain permissions based on where you are in the organization. Just because our organization is so fluid, we could not code roles fast enough to keep up with how fast our business moves, which is a good problem to have, but it is, it is a struggle.
We do have other methods though. We do have attribute based access, which does work for fine grain permissions. And then of course, ad hoc access request indicating to somebody you need it, getting that access request in the hands of an appropriate approver, ensuring that that access is timebound and eventually revoked. So that, that has been a large part of our culture. And again, the, the business value here, though, it's not openly apparent and clear is it was almost like building a CMDB configuration management database, where you had to understand your business in order to be able to do that and were able to provide metrics and analytics to teams that you wouldn't even necessarily think have anything to do with identity. Just because we have a lot of data on the applications that are operating in our environment, there's a lot of business value and business decisions that leadership have been able to make based on that data alone user lifecycle.
So I, I talked about this, our chief goal from user lifecycle and new hire onboarding in particular is providing people the ability to work on day one, get access to the services that they need. And, you know, we understand that there's going to be training. That's often involved. You know, you're getting used to the new company. We're not saying you have to be working on day one it's could you be, could you have access to the systems that you need in order to be successful for your organization to grow and thrive? We've seen examples of other organizations where they'll just say, yeah, it takes a couple of weeks and then you'll have all your access. And it's just not acceptable for us. It's generally not acceptable to our hiring managers. And it puts an enormous amount of strain on our service desk, our internal service desk team to be working through access requests the way at least on again, on the legacy Yahoo side, we used to be building a partnership with HR, designing, getting them involved in identity.
Our partnership with HR has been a huge culture boon in, in our time as a combined organization. And now Yahoo, today we speak the same language. We use the same nomenclature when discussing identity and user life cycle topics these days, which is just a crazy change, honestly, from where we were four years ago, they understand onboarding. They understand what we need to do. We understand what they need to do and what they're able to do as far as onboarding and off boarding workers. And it can be very tricky, especially when you're dealing with mergers and divestiture activity to keep track of all of this and the, that the it's become a strength of our organization is where I would honestly say four years ago it was a weakness. And then we talk about offboarding. We want people to know, particularly our application owners, that people are going to lose access to their resources.
The second that they leave the organization. One thing we did work out with HR was really this concept of last day of work and using that as our termination date, as opposed to the true termination date, as HR knows it, so that if people are leaving the office for the last time, but our technically on vacation for the last two weeks of their tenure, we want to be revoking them when they walk out the door. Not two weeks later when HR eventually terminates the, the user record in their system. So that that's just like one example of where we start building, where we start, started building a different culture from where we were in our previous organizations and using security goals to do it and identity governance. I talked about how many of our applications were media organizations, SOS and, and PCI honestly were very common regulations for us to be regularly audited against and applications in those scopes to be re-certified against.
We've expanded that we've expanded that greatly to several applications, even to a couple of applications of teams that just came to us and said, could you put us on this? Re-certification so people lose access on a monthly or quarterly basis, whatever schedule that is that they want. And we've, we've built that out as we're before it was more, it, it, it was more compulsory. We were telling people, yes, you had to re-certify your access. You're within a particular scope. We now have people coming to us for this as a service and security engagement. We've had to roll out. This was before oath, but we had to roll out on the Yahoo side, multifactor authentication in a very rapid fashion. And we got good fairly quickly at explaining to people why a particular change is needed when we are increasing security in areas where they weren't, where they weren't previously used to a more aggressive posture from us in that realm.
So we talk about fishing, educating, really, not even just fishing, but just educating your workforce as new security topics arise. When Sam two had a vulnerability that was identified two years ago, we put out a, a communication to most of the technology owners in the company explaining what it is that they were going to have to do to support rectifying any issues that might exist. Really it's about worker empowerment. It's about empowering our application owners of which we have 3000 individuals that are either approvers or administrators of their individual applications in our single sign on platform. We need them to know what it is we are seeing from a security perspective, and we need them to be involved in the process and be active stakeholders.
So business value, we this year, again, I said we were being very, very aggressive on metrics. We've had simple reporting for quite some time that we've been providing in order to make a lot of our business decisions. But the push for us now is not just making our business decisions, but now going back and looking at the business decisions we've made and determining what metrics make the most sense, what key performance indicators or KPIs make the most sense in terms of us being aware that we are one providing excellent security for our organization, but two making good operational decisions. We do have, again, a team we call the global service desk. They are internal help desk for workers. They are a limited resource. All human capital is a, is a limited resource. And you can't be just constantly putting things over the fence to them saying, oh yes, they'll handle it.
You don't wanna overwork people at the end of the day. So operations makes just as much sense to us as security. When we start thinking about what metrics and analytics are important to us, I have a couple of examples here that we do have live in our environment. None of these should be wildly surprising, but again, how do we, how do we use those at the end of the day? So password resets, we did have a very large problem with password resets, cuz we have a fairly aggressive policy on how quickly your password expires. So several times a year, people will or did use to reach out to our help desk in droves, just many, many people. And you could almost see the waves and peaks cuz we all started at the same company, give or take at the same time, excluding any new hires that come along, you'd see kind of cresting waves of password, reset tickets, hitting our help desk team over those regular periods of time.
It's gotten a little bit more dispersed. Now I'm happy to say four years we'll do that, but we've used patch, password reset metrics to determine day over day values. It helps identify one sec potential security issues. If there are multiple resets against an individual's account, but it also gave us enough data in order for us to help addressing the problem using that data for password resets, we were encouraged to build a bot service that interacts with the user one proactively before their password expires so that they can be a little bit more aware if they're not checking their email, which previously was the only way of communicating with an end user. And then ensuring that that account, if the account was still active, working them through that password reset, our results were 66% of account reset interactions handled by the bot were previously support tickets, their, their call queue or their ticket queue dropped by over 60%.
The first month that we went live with this and then it went to 75%. The next month we had an improved operations. We had improved security and really at the end of the day, improved culture, all based on, if you walk it back seven or six, six or seven steps, the policies that we put in place based on zero trust for how frequently we were comfortable with a user's credential lasting and how, how quickly that they were going to have to reset the password based on that credential metrics. Again, being the critical driving force behind the improvements that we wanna make both on the operation side and the security side.
So our plan really for the next several forever years, we have 90 of these metrics identified. We only have a handful of them implemented. Our goal is really to find out how far is too far. You can have too many metrics at, at a point where you're not even able to keep up with them as a human being, but we know what the important ones are. We have a planned and prioritized roadmap. And again, our goal is going to be using this new level of security engagement, this new level of really tech technology culture to help drive better decision making with good analytics and data. We're going to be doing this on a quarterly basis. And this is kind of, you know, the approaching the summit for what it is we want to achieve outside of just, you know, technology improvements, service improvements, application improvements. What, what big decisions we make are going to be data driven, moving forward. And it's a really exciting place to be.
