Securing Financial Services Workforce with Zero Trust

Sai Maddali: Awesome. How's it going, everyone? Welcome to Oktane20 Live, the first one ever. We're super excited to talk about zero-trust and passwordless today. My name is Sai Maddali, and I'm a product manager here at Okta working on our devices' ecosystems, so device identity, passwordless on Mac and Windows. I'm super excited to talk to you guys about this today.

Sai Maddali: Before we dive into all the good stuff, a quick forward-looking statement. As you know, Okta is a public company, so any forward-looking statements in here are subject to change. Feel free to read this at your own time.

Sai Maddali: What we're going to talk about today, three main things. The first one is we're going to talk a little bit about what we see [inaudible 00:00:47] Okta from [inaudible 00:00:49] customers [inaudible 00:00:52] zero-trust and passwordless and things like that. We're going to get into the importance of understanding and trusting devices and enabling and building a secure workforce for the world today. Then I'm going to pass it off onto Chris and team where they're going to talk a little bit about how they tackled this problem at Capital Group. It's a pretty fascinating story.

Sai Maddali: The first one that I'm very interested in talking about is what the world is like today. Talked to a lot of customers, a lot of companies over the last three years here at Okta, and there's a few patterns that have started to emerge. I think some are more true today than ever.

Sai Maddali: The first one is multiple resource types. If you look at your enterprises and how most of the enterprises are there out there today, one thing that becomes extremely apparent is not only your cloud footprint is growing from an app and resource perspective, but you also probably have a lot of legacy on-prem applications to deal with. You are in this hybrid world where your cloud footprint is growing faster and faster, but you also have to worry about how to figure out and deal with that legacy on-prem footprint that you have.

Sai Maddali: The second piece is multiple networks, and I don't just mean your internet, like your enterprise internet, but you also have a growing cloud footprint too. You probably have some mixture of like AWS, GCP, and Azure where you're running different workloads for different use cases. That's only going to become more true as you grow over the next couple years.

Sai Maddali: The third one, I think it's more true today than ever, especially within the last couple of weeks because of COVID, is a distributed workforce. That is like you have your employees and contractors and partners that are accessing your resources from not just their home but also multiple other locations.

Sai Maddali: The fourth one, I think it's also getting more and more true every day because of breaches, is that there are compromised credentials that are sprinkled and sprayed everywhere.

Sai Maddali: The fifth one, this is one of my favorite things to think about because I do work on devices is that there's thousands and thousands of devices and millions of signals because you have your end-users connecting to your resources from multiple different locations but also from multiple different devices. All of these devices have various signals like what operating systems are they running, are they jail-broken, what unmanaged signals do I need to think about, does it have a TPM, stuff like that. Making sense of these signals and understanding how to deal with this device management from a security angle is going to become really hard and really important.

Sai Maddali: Related to that, BYOD is becoming way more prevalent because it's not just my personal laptop or my work laptop that's managed, but I'm also accessing a lot from mobile phones, from iPads, from a whole swath of personal devices that I have.

Sai Maddali: You also probably have a lot of security tools. I think this one's very interesting because you probably have a couple tools for your endpoint security management, something for your mobile MBM management. You probably also have multiple tools for managing devices, different types of devices. You're continuing to use something like SECM for Windows, maybe something like Jam for Mac and maybe Intune or VMware for any of your mobile workloads. It the mixture of devices all achieving similar goals.

Sai Maddali: I think something that's also very real in this world, and I briefly touched upon this a little, are passwords. Passwords are everywhere. That's just the reality of the world that we live in today. No one really likes passwords. I definitely don't like passwords. I'm sure not a lot of you also like passwords. The only people that really like passwords, really, are hackers.

Sai Maddali: Passwords are interesting because it puts a lot of trust on the end user. It puts a lot of trust in ensuring that they are careful about which passwords to pick, what the password requirements they choose. Yes, you can impose some restrictions on them, but ultimately, it's on them to figure out what password they're using. That's a really hard proposition for us to have because, chances are, I will be reusing my passwords. Chances are, I will be using something that's not very secure.

Sai Maddali: It is really important, especially in this evolving workforce, to extend that trust beyond the user because compromised credentials are a reality, and it's important for us to understand how to be proactive about making sure that'll never be a problem, or how do you reduce the risk from that problem? That's the core message of this presentation is that enabling device trust is a very crucial step in getting to that world of passwordless and laying the right foundation for your zero-trust architecture. What that really means is how do you extend that trust that you put in an end user today and take it beyond them, take it to the device that they're accessing it from, which is almost always how resource access happens.

Sai Maddali: This is a very interesting and a new paradigm too because one thing that becomes very apparent when you start thinking about this problem is it's this age-old challenge that you have of how do you balance user experience with security? Okta did a survey last year called The Digital Enterprise Report, you can find it on our blog, where we interviewed a lot of enterprise companies in understanding how are you approaching zero-trust, how are you approaching digital transformation, and what are your biggest concerns, what are your biggest challenges?

Sai Maddali: Something that's not very surprising from a remote work... How do you enable a zero-trust and passwordless for an evolving workforce? Number one is security. That's definitely not a big surprise. What's more curious and what's more interesting is efficiency is quite literally right after that. They're equally a big concern for a lot of enterprises.

Sai Maddali: I think that's very fascinating because it does bring to light this age-old challenge that all of us have is how do you balance user experience with security? Because you can't impose too many security restrictions, the cost of losing efficiency, especially in this evolving remote workforce that's inevitably going to happen because, on one side, you have your end users, and your end users are very much about, "Hey, I want access to everything that I need as soon as possible, and I want to go through as few steps as possible because I don't want to add any friction to the work that I'm trying to get done." That's a fair concern.

Sai Maddali: Similarly, if you're an admin, you do want to enable an experience like that. Your question is how do I enable an experience like that but do it at a low risk and low-effort manner? Because you don't want to spend multiple cycles solving for a need that's not going to have a high ROI.

Sai Maddali: Similarly, a lot of the CSOs and VPs are thinking, "Okay, I do want to enable this secure, efficient, collaborate workforce for my company, but I also want to do it in a secure and compliant and a regulatory manner." Very different needs but similar goals that all of them have. It's definitely not easy to achieve something like that, and it's definitely not an overnight journey.

Sai Maddali: The first one to really think about is understand the lay of the land, especially now with how things are changing, is understanding what are the user's needs when they do need to work remote? You probably are doing a lot of this today, but it's really understanding and laying out the journey that the user would need to take and opening their laptop all the way to accessing and doing recovery to enrollment because it's a very interconnected journey where you can't really have any edges or gaps.

Sai Maddali: The second piece is start authenticating everyone and everything. If you don't have multi-factor today, that's like steps ago. That's the first thing you need to get on. The second thing you want to think about now is how do you also extend that into the devices world? I highly recommend joining and watching the Device and Security Roadmap sessions where we talk a little bit about that.

Sai Maddali: The third piece is, in parallel or you can do it after, is really setting a roadmap for how you can achieve passwordless and also a strong MFA enterprise. What I mean by that is really thinking through the different assurance levels that each of the factors that you have in your enterprise are. How does SMS compare to things like [WebAuthn 00:09:28]? How does that relate to email or TP versus a password and really setting these buckets of high-assurance to low-assurance factors so you can really think through what it means for your password list journey. Also, I highly recommend going to the Security and Device Roadmap because we'll talk a little bit about the frameworks and how you can think through it in the long term.

Sai Maddali: Then, eventually, you will be able to get to a place where you have a single place to really understand that device and user health risk and how they're interconnected so you can actually drive intelligent workflows and intelligent remediations for that journey that you're trying to create.

Sai Maddali: The big takeaways are enabling zero-trust. Sorry. Enabling device trust is a crucial step in achieving passwordless and zero-trust architecture. That's really the core message of this entire presentation. Really, when you go back, please experiment and understand how you can think through and play with and roll out these phishing-resistant and device-bound factors like WebAuthn or FIDO or FastPass. FastPass is a new Okta experience we're releasing, and that's something you should go check out in the devices roadmap. Once you understand this, really lay out your roadmap and plan for how you're going to achieve that in a phased manner over the next couple of months and years.

Sai Maddali: These are a couple of sessions that I highly recommend. The first two are the Device Identity and Security Roadmap. The third one is Okta plus Microsoft. The interesting there is we'll talk a lot about also onboarding and how you can do things like take advantage of things like Autopilot and Okta to really drive that day-one experience for devices. I also highly recommend The Future of Continuous Authentication by Okta's chief product architect Karl McGuinness where he's going to talk about how we're thinking about continuous auth and what that means for your enterprise over the next couple years.

Sai Maddali: Now, that said, I talked about a lot, but I want to keep it real, and I want to pass it on to Chris who's going to talk a little bit about how they've achieved this at Capital Group in a very innovative and creative way.

Sai Maddali: Chris, I'm going to pass it on to you.

Chris Miller: Thanks, Sai. Thanks, everyone, for joining us today. My name's Chris Miller. I work at Capital Group. For a little background, Capital Group is home to the American Funds, which was founded in 1931. It's one of the largest investment management firms serving over 55 million investors worldwide.

Chris Miller: Like many organizations, we started our cloud journey with a few SaaS providers, which quickly drove our need for an identity federation solution. Today, where we're at is we actually leverage a large number of SaaS providers, and we take advantage of a number of the different cloud platform services like Amazon, Microsoft, and Google.

Chris Miller: As a financial services organization, security is really at the forefront of how we make our technology decisions. As we look to zero-trust... and there's been a lot in the news, and the analysts have talked a lot about zero-trust. It can mean a lot to a lot of different people, but for us, it's really become a core part of our forward-looking security strategy. As Sai mentioned, we really believe that applying more rigor to how we validate both the identity of a user as well as the trust level of the device that they're using is really going to position us the best to provide, really, the highest level of security for our investors and our associates.

Chris Miller: Passwords alone are dying, as Sai talked about, and we really think that the ability to move away from just using passwords and, as I mentioned, really focus on better identity validation and as well as the trust level of the device is really where the future is on how we continue to protect identities and our company and our investors and our associates.

Chris Miller: I'd like to go ahead now and hand over the presentation to Brian Svidergol who's going to walk through how we've been partnering with Okta on our zero-trust journey.

Brian Svidergol: Hey, thanks, Chris. I first want to break down our Okta environment, kind of give you guys a background of what we have here and how long we've had it.

Brian Svidergol: We first deployed Okta in 2015, so we've had it for about five years. The initial deployment was fairly limited, just a couple of apps. Today, we have three production tenants, two are customer-facing, and then our corporate tenant. Today, we're going to focus on the corporate tenant.

Brian Svidergol: We have 21 non-production tenants. This is your typical [DevTaskQA 00:14:12] environment. Then we have some dedicated developer tenants. Then we have a few sandbox tenants like for a specific team that wants to experiment.

Brian Svidergol: We have added over 200 apps to our Okta corporate environment. In 2019, we added 81 new applications.

Brian Svidergol: This is an app breakdown. We have a lot of [SAML 00:14:37] based apps. When we first started with Okta, I'd say 95% of the apps that we were adding were SAML-based, but we do see a big uptick in OIDC-based apps, and we think that's going to be a big growth area for us.

Brian Svidergol: Then here's our app distribution. Right now, we're sitting at about 83, 84% of our apps are in the cloud for Okta. Most of those are SaaS-based, but we do have some on-premises apps, and we're looking to expand that as needed.

Brian Svidergol: Okay, so let's look at our initial configuration. The first thing to know is that we had a need to minimize data exfiltration and adhere to our existing security policies, so when we implemented Okta, we needed to still meet those requirements for all the Okta-based applications.

Brian Svidergol: We started with IP-based restrictions and group-based app assignments. What that meant is, if you're on the Capital Group network, then you can get to our Okta apps. If you aren't, then you can't unless you VPN in first. Well, what we figured out is there's substantial overhead in managing IP-based restrictions because, as a big enterprise organization, we're routinely adding new offices. We're adding new wireless networks. We have subnet changes. We're doing IP re-architectures. We're adding vendors or vendor networks. Those restrictions became a bit of an operational overhead for us.

Brian Svidergol: Then, second, we started with a single MFA. This was a legacy MFA, the kind you might carry in your pocket, or maybe you have a virtual MFA app on your corporate-issued laptop.

Brian Svidergol: Let's talk a little bit about the user challenges. First things that we discovered, users wanted to use more personal devices. That initial configuration with the IP-based restrictions, well, you couldn't put a personal device on the Capital Group network, and so a lot of people couldn't get to any apps from their personal devices. Then, for all of the cloud-based apps, the initial configuration dictated that you have to VPN in to Capital's network and then go out to the cloud-based apps from there. That was a performance degradation. The experience was a little bit slow. A lot of times, people wanted to just take their laptop home, boot it up, and connect to a couple of things, but once you added in the VPN, it really degraded the user experience.

Brian Svidergol: We had a couple of other initial configuration challenges I want to bring up. One is we ended up adding a guest network for employee personal devices. Up until a couple of years ago, everybody that had a personal device, they had to provide their own connectivity for it, so we didn't really have to account for it with Okta. Then we added a guest network and, suddenly, that network was part of our IP-based restrictions, and we had to go in and change all of our applications because we didn't want any personal devices getting to apps at that moment.

Brian Svidergol: I think what we discovered was... one more thing I want to add, actually. We had on-premises proxy services. For all web traffic, everybody goes out through our on-premises proxy. Those were working fine, but we decided to move proxy to the cloud through a cloud-based proxy service. What that meant is we no longer controlled the IP addresses for the proxy. From an Okta perspective, we couldn't really limit the IP addresses just to Capital Group anymore. We would have to include the cloud-based proxy, and the provider shares those IP addresses with all of their customers, and so we really needed a new way to handle app security. We decided to look at Okta's Device Trust.

Brian Svidergol: Okta Device Trust to the rescue, so a couple of things. We had a few questions first when we looked at Device Trust. First, how do we maximize app security? We still need to minimize data exfiltration. We want to simplify the user experience because, with our initial configuration, people had to think about who owned the device, where the device was, and which network they were connected to.

Brian Svidergol: Then we want to make the apps more available, so what we started discovering is more people are working remotely, on the road for example. More people are working at home. People's expectations in 2015 compared to today in 2020, they've changed a lot. They expect at least basic app connectivity from personal devices and from every location. Maybe it's HR-type stuff or it's approving CRQs or something like that.

Brian Svidergol: Okta Device Trust, we decided to check it out. Initially, what we did is we looked a iOS only. iOS, at the time, was our prevalent mobile platform out there. It was in high demand, and we already had the devices under management. What we did is we configured Device Trust for iOS, and we configured just a couple of key applications, two, in particular, that people were clamoring for. One was ServiceNow, and the other was Jabber.

Brian Svidergol: Then we started looking at other platforms. We had pretty good success with iOS. Users were happy, but how do we expand it? What do we look at next? We started looking at the Android side, and we got in on the Android beta. Then we started looking at Windows and Mac. We started small pilots for all three of those, got a few users in IT, got them up on a couple of apps and sort of... we'll call it kick the tires.

Brian Svidergol: As part of that, we were noticing an improvement in the user experience. Things were simpler. People were reporting that they didn't really have to understand as much as they did in the past. They were working in a similar way whether they were at the office, at home, whether they were on their device or a different device, laptop versus phone, for example.

Brian Svidergol: Then, on the admin side, what we found is, with rolling out Device Trust, we wanted to include our help desk a bit more. We wanted to offload some of the... we'll call it level one support onboarding, and so we started rolling out help desk, limited admin rights to do some of the basic stuff to help with this roll-out. That was a good experience, but we also wanted to expand that with self-service.

Brian Svidergol: Eventually, after the pilots ran out, we experienced really good success, so we decided to go all-in across all four platforms. First, we did all of our Windows endpoints. Today, right now, we're sitting at over 15,000 Windows devices. Then we looked at Mac. We have a smaller footprint of Macs, but we're currently on 88% of our Mac devices as well.

Brian Svidergol: At this point, we've really reached a time where we're looking at expanding from our initial set of apps, and we've been doing that one at a time, typically a couple a week, two or three a week based on usage. High-usage apps are apps that people find a lot of benefit from when they're coming from different devices in different networks. We took a lot of end user input for that, and we've really hit our core apps first. We still have a bit to go. We do have over 200 apps.

Brian Svidergol: Then this really brings us closer to zero-trust, as Chris mentioned. At CG, zero-trust means... or it means we never trust. We always verify. Our initial configuration was we inherently trusted every device that you connected to our network. We're no longer in that position. Now we trust devices based on Okta's Device Trust, and we can authenticate devices and users.

Brian Svidergol: That's our Device Trust overview. I do want to turn it over to Kelcey now to talk about out automation and our self-service efforts.

Kelcey Lorenzo: Thanks, Brian. Hi, everyone. My name is Kelcey Lorenzo, and I'm going to talk a little bit about our self-service and automation efforts at Capital Group with Okta.

Kelcey Lorenzo: When we talk about self-service, what our team is focusing on currently is an automated self-service platform for application onboarding and application administration in addition to a self-service method for user login profile management, particularly with multi-factor authentication for our associates.

Kelcey Lorenzo: When we were taking a look at the different areas that we could potentially expand and develop self-service portals or different frameworks in the space, we targeted a few different challenge areas that we wanted to tackle. Like Brian mentioned earlier, we have multiple different tenants for Okta in our environment in over 200 applications. Since everything is being done manually, currently, without an automation framework or a method for managing our applications, there is just a big lack of consistency across of our environments. This is due to the fact that everything has to be done manually whether it's applying a sign-on policy to an application or promoting an application across our different tenants and environments. This just leads to a big operational overhead for our support and operations teams.

Kelcey Lorenzo: If you take a look at the chart on the right hand of the screen, you can see this is just a general breakdown on the different types of tickets that our Okta queue gets on the average month. You can see the biggest section of the pie chart is for troubleshooting. This is generally just login failures, application assignment failures, one-off errors that we need to work with individuals or teams on.

Kelcey Lorenzo: Then the next biggest sections are application onboarding and configuration. The tasks that fall under these two categories are really just talking to teams, getting their application configurations and manually inputting those configurations into our environment in addition to making slight changes to maybe a redirect URI or an authorization server as teams are developing.

Kelcey Lorenzo: In theory, those two sections for application onboarding and configuration could be completely removed from our queue if we had a self-service way for teams to handle the onboarding and configuration of their applications. Then our team, as Okta admins, and our operations team could focus more on doing user or customer-to-customer interactions and helping people out with more details instead of being bogged down by these additional tickets that need to be processed.

Kelcey Lorenzo: The last area that we wanted to focus on developing self-service is for new users and onboarding devices. While Okta does have this capability for self-service out of the box with their application dashboard, not many of our users interact with this dashboard on a daily basis. Some may know how to reset or re-enroll their factors through the dashboard, but other users never see the dashboard at all. This is due to the fact that we implemented Okta as more of a background authentication engine in our organization, and so, to some users, it's virtually invisible, and they don't notice it all. That was definitely with intention, but now that we're looking for more self-service opportunities to develop better company, we're looking for a way to provide that cleaner user experience or a user experience that just aligns more with the way that our associates work.

Kelcey Lorenzo: This brings me to one of our examples of an application that we developed in house at Capital Group, a self-service portal that we call the CG Okta Portal that primarily focuses on self-service for multi-factor authentication management. There is a few different key targets that we wanted to hit with this portal.

Kelcey Lorenzo: The first one was definitely alleviating help desk calls. Prior to this portal being available in our environment, if an associate, say for instance, got a new cell phone and wanted to re-enroll their new phone in Okta Verify, they would have to call the help desk and get connected with the help desk and then go through the process through a third party with a help desk agent instead of being able to just do it themselves. These calls could typically range from either maybe 15 minutes or maybe up to 45 minutes depending on how busy our help desk agents are.

Kelcey Lorenzo: This leads to the second point that we tried to... or the second target we tried to satisfy with this portal. It's just to save our associates more time. All of our associates are doing amazing work at Capital Group, and their time is very precious to all of us. An associate may be able to just reset this on their own in five minutes, the same amount of time it would take to even get connected to a help desk agent. Providing this portal for associates would just, again, save them more time. They can manage their factors when they want to and wherever they want to. Then they can ensure that they can access all of their applications either on the network or if it's available through Device Trust.

Kelcey Lorenzo: Then, again, with all of our self-service and automation efforts, we're just trying to provide more accessible options to our users to ensure that we provide them with ways that work best with how they're used to working in our environment.

Kelcey Lorenzo: Now I'm going to go through a high-level architecture of the CG Okta Portal. Then we're going to go through a demo and to see the portal in action.

Kelcey Lorenzo: Starting at the top left of the diagram with the end user, so our end user will access the portal through a web browser. Our web portal is built in AngularJS, so they'll be single signed on through Okta into the portal. During the single sign on, we'll use the Okta Angular SDK to pull in their login profile. This login profile will provide us with some general information on the user in addition to their factors and the enrollment status of each of the factors we make available to them.

Kelcey Lorenzo: Say, for example, the user wants to enroll in SMS text message as another factor. They'll initiate that change through the front end, and it's going to be send to a back end intermediary server built in [Node.js 00:30:31]. Then, before anything is changed or even sent to Okta, we're going to follow that zero-trust methodology that Brian mentioned earlier at Capital Group, how we never trust and always verify and challenge them with a second identity verification challenge just to ensure that they are who they say they are and there isn't some attacker or another person trying to enroll their device on a different user's profile. This can be done either through any previously or current enrolled factor that the user has in Okta, or we also have an in-house identify validation API at Capital Group.

Kelcey Lorenzo: Once they complete that challenge and we confirm, okay, the user is who they say they are, the change to update their enrollment status for SMS will be sent to Okta. The user will satisfy any confirmations in order to enroll their number. Then, once everything is registered on their login profile, the information will be relayed back to the Node.js server and to the front end and updated in real time, so the user can immediately see that their status in SMS text message was immediately confirmed. Then they can go about their day and now use SMS text message and their MFA factor.

Kelcey Lorenzo: Now we're going to take a look at a demo. After the user is singled signed on in, they're going to be presented with this dashboard. At the top, you can see that we pulled in the user's name. For this example, we're going to use my user. You can see the different factors I have available to me to enroll in and the enrollment status of each.

Kelcey Lorenzo: For this example, I'm already enrolled in Okta Verify, and I'm going to enroll in SMS text message as a second factor. When you click enroll, this is the second identity validation challenge. I'm going to use Okta Verify to confirm I am who I say I am. A push notification is going to be sent to my enrolled device. Once I confirm that, yes, it's me making this change, I'm going to be presented with this form to input my mobile number that I want to use for SMS text.

Kelcey Lorenzo: When you input the number, a verification code is going to be sent to your phone from Okta. Once I put in the verification code and I verify that it's correct, there's going to be a message displayed to the user, so me, saying that I successfully enrolled in SMS text message for MFA. They also provide a little instruction blurb on how to use it on your next log in.

Kelcey Lorenzo: When you close that window, you can see that my status for SMS text message updated automatically, so I can visually see and confirm that, yes, I am enrolled in SMS text message and, the next time that I go to use an application that requires a MFA, I have both options of Okta Verify and SMS now.

Kelcey Lorenzo: That was just one of the examples of different projects that we're working on here at Capital Group in the space of automation and self-service with Okta. Now, looking forward, what's next?

Kelcey Lorenzo: The main focus area is that self-service application onboarding. Since our teams are definitely exploring the OIDC space and the OS space, as Brian mentioned earlier, these application configurations are a little bit more nuanced than, for example a SAML application, to be onboarding into Okta. With this self-service application onboarding platform, we can allow and enable our application teams and developers to onboard an application when they want to and then also make changes to that configuration in Okta as they're developing in order to get their applications deployed and tested with the least amount of friction as possible.

Kelcey Lorenzo: To go along with that, another area that we're looking into and designing and researching is an automated application administration platform. This will definitely offload a lot of that operational overhead that I mentioned earlier and save a lot of our operations and admins teams a lot of time. For example, if we wanted to apply a sign-on policy across our entire organization, right now, one of our operations engineers would need to go onto the Okta admin console, click into the application and apply that policy by hand for every single application, the hundreds of applications we have across the various tenants in our environment.

Kelcey Lorenzo: That's just opening up for an opportunity for some mistakes to be made, misconfigurations to be put in place, whereas if we had an automated platform or an automated method to handle these sort of tasks, we'd be able to create a configuration file in one place, have multiple people check it to make sure that it's correct, and then push it out automatically to our entire environment. This will save, also, a lot of time with debugging, troubleshooting, some head-scratching that our applications teams go through whenever they encounter an error that they've never seen before.

Kelcey Lorenzo: At the end of the day, with these two methods in addition to the CG Okta Portal and other automation self-service methods that we're working on at Capital Group, the end goal is to enable our application teams to be able to move faster, get their applications set up with the least amount of friction, especially as they're moving toward a more agile methodology with DevSecOps. Our team doesn't want to be the force that's holding them back.

Kelcey Lorenzo: Then, also with this, our team can then take more of a backseat or a step back and just provide more expertise, troubleshooting and guidance for these application teams as we all work together to secure our environment at Capital Group.

Kelcey Lorenzo: Now I'm going to pass it back to Chris for some key takeaways.

Chris Miller: Thanks, Kelcey. If we want to look at our key takeaways here, I would suggest three things here, so from a... get my slides to change. All right. There we go. The key takeaways that we have here are... okay, there we go... is really kind of, as we started the conversation around zero-trust is that strong identity plus Device Trust leads to better security as well as a better user experience. Hopefully, between the conversations that Brian and Kelcey have shared, that's becoming obvious. The idea that a single password being lost or compromised could cause a problem in our environment is going down due to zero-trust. If you're not thinking about this, it's something you definitely should be thinking about because it's just better security and a better way to protect your company as we look at mobile and cloud activities.

Chris Miller: The second takeaway is that Device Trust works and it's easy to get started. As Brian mentioned, we didn't do a all-in right away thing. It was really easy for us to get started with this. Pilots and prototypes are easy to do with Okta, and I think you see the value right away both in terms of how easy is it to set up and how much the users actually enjoy working this way.

Chris Miller: The last takeaway that I would highlight for everyone here is that smooth adoption requires thoughtful user engagement. As Brian walked through all the technical pieces on what we've done, I think, hopefully, you've heard from Kelcey that there's a lot of things you can do with Okta in terms of how you provide that user experience because the last thing you want is to have folks that are frustrated [inaudible 00:39:01] usage is a lot more behind the scenes for Okta, so providing a really clean, simple user experience for them to adopt this and to really be able to get the benefits is important.

Chris Miller: On the back side of things, the DevSecOps, I'm assuming many of you are somewhere in your journey of DevSecOps as a company, really putting all of this in the hands of the developers to move fast and to be able to do what they want to do but have security just built into the process of how they do it is really important. If you think about adoption, you want to think about your user bases, your developers, your associates. Think about what's most meaningful for them and how they work, and make sure you're keeping that in mind as you go through your adoption.

Chris Miller: Device Trust, zero-trust. Strong identity is better. It's easy to get started. Think about user experience. Those would be the three things that I would leave you with for today.

Chris Miller: That concludes our presentation around zero-trust at Capital. If there's any questions as we go on to the live sessions, we'll be happy to chat about that. Hopefully, this has been interesting for you and has inspired you to go do something in the zero-trust space. If you've been thinking about it or considering it or haven't yet decided, hopefully, this helps you at least get a perspective of how a financial services company like ourselves are adopting these technologies successfully.