Identity at the Center is a weekly podcast all about identity security in the context of identity and access management (IAM). With a combined 30+ years of IAM experience, hosts Jim McDonald and Jeff Steadman bring you conversations with news, topics, and guests from the identity management industry.
Do you know who has access to what?
You are listening to the Identity at the Center podcast. This is a show that talks about identity and access management, and making sure you know who has access to what. Let’s get started.
Welcome to the Identity at the Center podcast. I’m Jeff, and that’s Jim.
You know what I was reflecting on, Jeff? As usual, I was reflecting on something. We sit in on so many calls together, I start to pick up all of your things that you stick to, that you say over and over again. I’m sure you get the same from me, but one lately has been about best practices. We’ve gotten almost like bashful about using the term “best practices.”
But I’ve been thinking about that, and I really feel like how we ought to use the term going forward is, if you’re implementing a product, the best practices are the practices built into the product. Not necessarily that they are the best practices because they perform the best or there’s no better way to do it, but that it’s definitely going to cost you the least amount of money to configure if you stick to the out-of-the-box process versus customizing it or making it a whacked-out integrated process. So, that’s what I propose. What do you think?
Yes. It comes up top of mind — we’re always talking with folks, and they’re always asking, “What is best practice for this?” “OK. Well, there really isn’t a universal best practice.” There are foundational concepts. Should you be using MFA? Yes. Would that be considered best practice? Yes, probably, but best practice sometimes is also counter to the organization, and then being able to change their business processes to match the best practice. So, then it becomes sort of this hybrid, but, yes, it’s funny how these things go in waves and we have terminology like, “OK, best practice is the hot thing. Zero trust is the hot thing.” Whatever that wave is, it seems like it comes in bunches.
Exactly. Yes, “zero trust” means a lot of things for a lot of people, and fortunately, we have a guest on today who thinks a lot about that and has a lot of reflections he’ll share with us today.
We’ll definitely talk about zero trust, so that’s going to be the main topic for today. To help us with the conversation, we’ve got Sami Laine. He is the director of technology strategy at Okta. Welcome to the show, Sami.
Hey, thanks for having me.
Thanks so much for joining us. Definitely, we want to pick your brain around zero trust and some of the concepts that we keep hearing out there, and maybe work through some things that folks can take away if they want to get started on their journey. As is the tradition around here, the first time you come on the show, we want to find out more about your identity journey, your personal journey. What is your origin story when it comes to being in the space? How did you get into IAM? Is it something that you chose, or did it choose you?
It was actually neither of them, because I got into IAM because I spend my whole career in security, and I was always from the vendorland side, doing a decade almost at RSA on fraud and risk intelligence, and then spending another few years at the Cloud Workload Security site. I saw this fundamental shift where all of the users and all of the data escape the perimeter, and I started to realize, when I had a conversation with a friend of mine, that the traditional controls that I had been spending a decade and a half defining and defending with were kind of slipping away, and all that you have left is users going to resources that, more often than not, are in the cloud. Users are coming from a random device from their random network, going to a cloud service somewhere else, and the traditional perimeter that we spend so much time defining and defending and monitoring and assessing is gone.
It came to me in a revelation at a lunch with a friend who basically said, “The identity is the new perimeter.” All you have left is AuthN and AuthZ, and all of the traditional security controls are going to get turned upside down. So, I came into identity not by coming into identity — it’s just that security shifted around me and I found myself at a core identity company building out the security landscape at that company. So, that’s how I came to identity myself.
And that company, Okta, referred you to us as their zero trust guru. You obviously have some perspective on zero trust. I just wanted to ask, what is zero trust, in your words, and what are the major building blocks of zero trust?
It really boils down to the basic idea that the traditional perimeter is dead. If you go back and peel back on the term, it was popularized, of course, by an analyst at Forrester eight years ago, but it really goes much further back than the white paper on it. It goes back to the Jericho Forum Commandments, where they asserted that AuthN and AuthZ must exchange outside your area of control, and that white paper was written 14 years ago. It is the foundational idea that you can’t just defend your own turf. You can’t just assess users based on their network that they’re coming from. You can’t just assess any connection coming to your system by assuming that the trust is rooted in the network. Instead, you need to move to a data- and identity-centric security model.
If you look at the zero trust extended ecosystem from Forrester or Carta with Gartner or the NIST standard, they all have the same building blocks, but they really boil down to that basic idea that it’s not a product, it’s not a vendor, it’s not a technique. It’s a change in philosophy. You need to start assessing things on their own merits. You need to look at the full context of every single connection or access request. And the full context is everything that you can gain out of that, and it goes beyond “Hey, did you know the credential, or not?” It is “Are you on my network, or not?” It is “Am I recognizing you behaving the same way? Are you coming from the same device and the same context? What are you doing in my system?”
All of that becomes that rich context. So, in that sense, you can start employing zero trust from vastly different viewpoints. You can look at your network and microsegmentation of workloads, or you can say, “I need to have a source of truth for my identities before I can do anything,” and they are both equally right. That’s why it’s been such a weird term, because every single analyst and vendor has glommed down to it because that’s what gets the clicks. At the heart of it, though, you can have certain foundational principles that you can start measuring, saying, “Is this helping, or hurting, me?”
That’s a really good summary, and I think of it very much in the same way. It’s really just — it’s a mind shift of, if you were in IT 15, 20 years ago, it was about having that crunchy shell, keeping the bad guys out, which didn’t recognize the fact that sometimes the bad guys are inside, but it’s not even just about that. Even if you have complete trust of the people who work for you and sit at a desk in your office building, it’s about the fact that someone can get into your network by 50 other different ways if that shell isn’t crunchy enough, or somehow, people are able to get in, or they get in via illegitimate means — a stolen password, a stolen credential — and then change identities within the network. If you don’t have any defenses at the resource itself, you’re still vulnerable.
Yes, and it goes beyond that to the world that we now live in where, if you think about any company today where you’re managing identities and building infrastructure, odds are, if you need to start a new service, you’re going to first look at a SaaS service: Can I just spin it up and be done in 15 minutes and start using it? If not, you’re looking at platform as a service and building it out there. OK, you need to run your whole stack. Then, you’re most likely going to stand it up at either GCP or AWS or Azure, right?
In the traditional world, where you get a purchase order and rack-and-stack a bunch of servers and load an operating system on them and then slap some user repository on it, then, once you’ve deployed your software, those days are gone. You have to have, probably, a special approval from high up to be allowed to build something in your data center these days. So, in that sense, you can see that most of our users are working remotely, whether by force or by choice. Most of our workloads tend to be now outside of our perimeter. So, in that sense, the new perimeter is that AuthN and AuthZ. How do you control access to these resources wherever they are? That’s at the heart of zero trust. Yes, you can apply it to your network as well, but you should apply it to every single system that processes or accesses data, and every single user of system or process or an API code that accesses that data.
What’s really cool about zero trust is that it’s not all black and white. If you apply zero trust to a more modern web-based application, you can say, “We want to apply multifactor authentication to it,” but then there are certain areas of infrastructure or legacy applications where it gets more difficult to apply the modern IAM controls to. Zero trust doesn’t say that it has to be SAML integration with multifactor authentication to an application. But at the same time, it doesn’t let you off the hook of doing nothing just because your application’s old and maybe only going to be around for a few more years. That’s an area of risk, and if it’s got critical data assets for the organization, it potentially could end up in a data breach, or the target of a ransomware attack.
“This app is going to be around only a few more years.” That’s what we said in 1999. We’re still running that app somewhere, and Bob, who wrote it, has long since retired, and nobody dares to reboot the server or patch it, because who knows what’s going to happen? You need to apply that to all of the above, and that’s why, if you look at the resources and the protocols, that’s a great lens to look at this through, because we’ve solved zero trust for cloud applications. We’re using SAML or OIDC. Okta, the vendors like us, solved it years ago. That’s not a problem, because you can now have granular access control with the right users getting the right access to the right resource the right time. All solved — great. You can add MFA to it. Then, you can add right-size MFA to it, and then you can add risk-based MFA to it, where you only authenticate when you need to. You choose the level of friction as well.
Cloud-based apps seems easy, but what about if you have something that uses header-based authentication? The same exact principles apply there too, because it’s still an AuthN and AuthZ. In that sense, when you’re looking at your stack and you have web access, if you have old-school web access controls that you apply with TIM and TAM and whatnot, that’s a great place to start applying your zero trust too, because if you modernize that access control, you can still use access gateways. You can then say, “I want to put in an access gateway in front of that same app.”
I don’t need to touch the app. I’m authenticating it using the same header-based auth or RADIUS — whatever you have as a protocol. That’s not important. What’s important is that you move that AuthN and AuthZ to the centralized control layer, and that’s easy to do today. You can use gateways from vendors like us, you can use gateways from traditional networking vendors like F5 and gateway vendors — there are so many things that you can use for that, because then those layers themselves, they have this rich control plane. We can integrate straight from the identity source to that and say, “Hey, this user needs access to this particular URA.” We’ll just validate that they should have access to that URA authenticating using the same exact framework where you would use for cloud apps, and user experience is great, because they just access the app.
If they’re in session, they’re good to go. There’s zero friction. If they need to be stepped up or reauthenticating, we do that. It’s the same experience, because it’s the same identity, same source of truth, same process. The look and feel of how the actual security works is going to be uniform no matter whether it’s a legacy on-prem that you built yourself, a legacy ERP app from Oracle or whoever, or a cloud-based app.
You can extend it even further and talk about APIs. APIs have a huge vulnerability, like we know. You ask any CISO, “How many APIs have you exposed to your outside world?” and they say a number. Then you interview their team, and the number is 10x. You can then say, “Let’s put in some identity-centric controls on those OAuth requests as well.”
So, it goes across the whole stack all the way down to how you access your infrastructure, and you can do the same thing there and say, “Let’s move my DevOps engineer and system administrator access to RDP sessions to the Windows infrastructure and SaaS access to Linux infrastructure, and use their identity at the source there too instead of keys.” We can move to short-lived certificates, where you need to cert for access based on zero trust principles. In that way, the whole stack, from top to bottom, shifts, and now you have a single repository of who should access what, and a single method where you can do that assessment and add friction when the risk is high and remove friction when the risk is low. It’s great for the users and great for security. It’s a win-win win.
This is one of the areas where it’s why it gets so confusing for folks who are looking into getting into this space — just how involved you need to be across all of the different applications. One of the challenges that I see is, you mentioned a few different products. Obviously, you’re with Okta. There are other vendors that have zero trust somewhere in their marketing materials, and maybe they are truly a zero trust product, or maybe they’re just trying to glom onto this current zero trust marketing wave and mindshare. If I am looking to get into zero trust, or if I’m not sure, what are some of the fundamental properties of a true zero trust product versus something that might not really be in the zero trust space technically but is trying to surf that wave of mindshare?
How do you tell if the marketing spray-painted it on 15 minutes ago?
You can take a look at some of the properties of any system or process or technology. They’re like three lenses that I like to look at them through. First, is it perimeterless by design — meaning, the architecture of what you’re building should assume no perimeter that you apply and check things at.
If the solution that you’re looking at requires you to take all of your traffic from your users, whether they’re on mobile somewhere and going to a cloud app, and trombone all of that to your data center and through an appliance and trombone it back out again, then that probably isn’t a great long-term solution. It adds brittleness, and cost and complexity. If the architecture of whatever you’re looking at, whether it is a vendor’s product or a solution that they’re building for you, assumes no perimeter and can work in situations where the end point or the resource lives in the cloud or your data center and works equally well, then that’s great. That’s going to help you. You can look at everything that you already own through that lens.
The second out of three that I like to look at is, does this tool, vendor, product, process, solution add more context — meaning, does it give me better insight into the likelihood that this request is genuine and should be served or not?
For example, think of something very old-school, like an email security gateway. People often don’t think about that as a zero trust solution. But it can be foundational in that, because if something like Proofpoint can tell you right now that these seven employees out of your 7,000 are actively being targeted in a phishing attack right now, in this five-minute window, because those attacks are super short-lived and your identity system is aware of that, then you can shift those users dynamically into a different security group and require them to authenticate even if they’re on a verified machine, managed device, whatever it is, and require them to use something strong that’s phishing resistant, like WebAuthn. In that way, you can make sure that those users, yes, there may be slightly more friction for their access, but they are protecting dynamically against that particular attack right now. Super-rich context.
Same thing with things like user-behavior analytics. If you look at UBA, they can tell you interesting things. Let’s say that you have unmanaged devices because it’s your partner portal. You don’t manage their computers, but what if you could interrogate and say, “What is the end point security state of that machine? Is it actually patched, or not? Is it running end point security on that?” and there are now tools that allow you to do that. You don’t have to manage that device, but you can put a small security product app running on that end point that you request to have there the authentication, and you can get, with the user’s consent, some security context. Then you can tell the likelihood that this product, this end point, is owned.
So, those are the kinds of context that you can now add that goes way beyond “Did you know the credential?” Then the last, third, one is the dynamic access control that I already touched on. You have now rich context, but can you make better decisions with it? Can you dynamically change your policies based on the situation you find yourself in? That could be explicit policies saying, “User is under attack, so I’m going to switch them to a security group,” or it can be purely risk based, where you have a risk engine that’s assessing all of this context, and then evaluates that. If the risk is elevated, you step them up for MFA or require a stronger type of authentication factor, or just let them in without a password because the risk is low, the resource risk is low, there’s nothing in the context that raises any flag, so there should be no friction.
Those are the three things: perimeter design, context awareness and dynamic access control. You can look at everything you own through that lens, and it gives you a great sense on “Is this going to help me in the long term, or is this going to hurt me in the long term?”
What do you mean, “Let somebody in without a password” or MFA? I think that’s part of the risk calculus that gets done to say, do we care if people are looking at the company cafeteria? Probably not. Who cares if they’re having burgers or hot dogs or whatever it may be, and I think that’s an important thing, because that plays right into what you talked about earlier, around the usability.
If we can provide an environment where you’re authenticated when you need to be, and only when you need to be, and when you need to be, it is at the appropriate strength. That’s a win, then, for everybody. It makes easier for end users to get in to get the resources they need, and when there are security issues or, potentially, threats against specific identity, that, to me, has always been the challenge: What do you do with that information? It’s very much like the old days, where everything would go into like a SIM, and some poor analyst is looking at this giant log of files, and —
Seven days later.
Yes, exactly. And they’re not finding things real-time, or they’re finding it – 180 days is usually the detection of a breach. That’s six months. By that time, you’re done already. Whatever they wanted to take, they’re going to take. I think having that context and being able to help pull it forward and make it more that dynamic model where, yes, let’s leverage the tools that we’ve got. Let’s dynamically shift people between up, down, left, right, when it comes to authentication. Maybe it makes it easier for them this time, maybe it makes it harder, and it’s all risk.
Yes, exactly. If you think about like if you, the listener here, are thinking, “How am I ever going to get anybody in my organization to buy off on this?” There are two key things. One of them is that this can be transformational to the user experience, and we’re already under tremendous pressure with COVID, with remote work, with more dynamic teams than ever before in making that user experience less hateful. Let’s just call it that, because up until now, IT has been the preventer of information, of information access — especially the security teams: Stare directly into the sun for five seconds to access.
This is the kind of thing that we can now bring, which is, I’m making everybody’s life better every day, and you show it to the CEO and say, “Here’s how you log in now. It’s better, more secure than before — and, by the way, we’re not even asking for a password.” You just got yourself an executive sponsor who’s going to push this whole through right away. So, in that sense, we can now give better security with much better user experience, and that’s the lever that a lot of the IAM professionals are finding to be key.
You find a project that everybody needs, that needs good security but that also is painful because you’re MFAing them to death every day. If you can flip that to that zero trust model, you’re managing their device — they already authenticated to the device with a biometric. Why do you need a password?
That’s where I’m at. I am at there today. I logged in today to my laptop, and I didn’t use a password for it. I logged in to my corporate portal and looked up the calendar invite for our session here, and there was never a password involved. Because my company manages my device, it knows the security state of the device. I biometrically authenticated that device. What else do you need? Asking me a password reduces security. It introduces a vulnerability where I could now be fooled into entering it, but I know I’m not going to be asked that. Therefore, if I see a password prompt, I know it’s a phishing attack.
These are the kinds of things that you can move toward and that increases security, reduces friction, and that’s your lever. That’s how you can get your company to sign off on that first project. Pick something you can win, and then find that executive sponsor who wants that experience, because the positive user experience can often be the lever that makes this project actually lurch forward.
Amen to that, and that’s the quote of the week, Jeff: “Having a password actually makes it less secure.” I love it.
That’s the teaser.
Yes, that’s our teaser. Sami, it sounds to me like you’re talking about identity at the center. It’s not just your trust — it’s identity at the center. That’s why we came up with the name for this podcast. Speaking of the security strategy from risk, the Cybersecurity Framework, how does your trust and identity at the center relate to that?
Yes. It’s truly there. The name of the podcast could not be better. I draw this diagram on a whiteboard where you can’t build a zero trust program or project without having identity at the center, and that’s because if you don’t know who your users are, you can’t start solving it, because you have to give the right people the right level of access to the right resources in the right context with the right level of friction. It starts from that right people.
If you look at the analysts, they all agree: You need to have a source of truth on who those people are, and all of a sudden, it’s the IAM guys. They are not just sitting there in the basement making new leaves into the nodes of your giant forest of AD servers. They are now at the heart of your cybersecurity strategy. That’s why we see these collaborations very, very quickly form where you’re really talking to the security teams and the apps team and saying, “Hey, how do we define this?” That’s where it really comes.
You mentioned that Cybersecurity Framework from this, and that’s a great lens, because if you think about that, there are five things in that strategy. Your traditional IAM has been in that protect strategy out of the five. The challenge that we face here is that the traditional controls were often used in a silo. The silo was inside that protect strategy. Then, if you look at that Cybersecurity Framework, there’s five elements to it: First, it’s identify, then it’s protect, then it’s detect, then it’s respond, then it’s recover. IAM often was sitting there in the protect strategy.
We put a password in MFA and something like that in front of it, but then, all the detection was happening in the fancy security tools on the 17th floor, not at the IAM cave in the sub-basement minus two. Today, those two things are directly connected, because as soon as you make an AuthN decision, you should enrich that decision with this contextual data.
After that, you’ll also want to look into what’s happening in that session. If you detect a threat or you detect a breach in progress or there’s an insider attack happening right now that your UBA or SOAR or other tools detect, that should come right back to IAM, because that threat actor should not be allowed to open up another session into another resource. That threat actor shouldn’t be able to pivot from what they learn to another system.
That’s why these things are now bidirectional: It’s rich identity, the data flowing down into the security orchestration tools and SIMs and so forth, and those rich decisions and threats and assessments coming back into the identity world so you can keep continuously assessing the risk of that. Then, when you are responding to an attack, those tools need to have that identity context as well so that you can then recover back from it. So, in that sense, identity is now much more connected into these things, and not just an LDAP or AD server sitting somewhere on the sidelines.
For folks who are listening, if you look up the NIST.gov/cyberframework, there’s a lot of good information there, and I’ll put a link to that in our show notes for people to check that out, but it spells out the approach that is recommended, and it’s not a step-by-step approach. I think that’s the important thing too. There are a lot of things that run in parallel, and you may be moving around from the different areas as well.
I know we’re getting short on time, but I’d like to have some sort of tangible takeaway for people who are listening. What are top suggestions for people if they’re looking to start their zero trust journey? Where do they begin? Maybe they’ve already started — they just don’t know yet.
If you are still catching up on what this terminology is, and what do you actually mean by these terms, I would still go and look at the BeyondCorp paper that Googlers published in 2014 after their nation-state attack, where they recognized that they needed to treat every single asset in their inside network, the same way as if it was connected to the public internet. That’s a great foundational piece to read even today to understand how Google went and solved this. Now, they did it their way. You don’t have to replicate BeyondCorp in your organization, but it’s a good starting point.
I would also read the NIST document that describes this. They have not only the Cybersecurity Framework, but also a zero trust white paper, and that really outlines a lot of this in an interesting way. It allows you to look at, what are the resource protections that you need? Then you can map that in your mind better into what your assets are.
Now, selfishly, of course, Okta has built things too. We have a whole maturity model and a zero trust assessment tool that you can use. You can look at your own organizational maturity and systems maturity and say, “Where do we stand on the identity-centric maturity model on the zero trust journey?” At Stage 0, where we all started a few years ago, we had fragmented identity where there were passwords everywhere, silos of Active Directories and whatnot, no cloud integration.
Today at Stage 1, we’re mostly there, in most organizations, where we now have unified at least the IAM. We have a single sign-on across employees, contractors and partners. Hopefully, we have modern MFA — not just OTP somewhere, but modern MFA that’s dynamic, and unify the policies across the absent servers. We’re now moving toward Stages 2 and 3, where you first add that context, where your access policies are no longer explicit yes/no for this group of employees. Instead, you move to context-based access policies, saying, “If you are on a known device, you’ll be able to access this set of resources without further MFA.”
Then, this is where we also see right-sizing of the factors, like, I should expect that my end customer logging in to their portal would need less security for that than my CFO or DevOps engineer logging in to their wire transfer system or a DevOps engineer logging in to my CI/CD server to orchestrate some changes to my production. So, I would want a different MFA experience for them with a different level of security, and you want that at Stage 2.
Then last, at Stage 3, we go from the context-based policies where they’re still explicitly written out, saying, “In this context, do this,” and you’re moving on to that risk-based access where you’re just looking at the risk score, and you can start providing that continuous adaptive authentication, authorization and remove that friction where you don’t need it. I live in that dream world where if I have my finger with me when I make it to my desk, I’m good to go, I’m in.
Let’s hope your finger stays attached.
As long as my finger stays attached, I’m still good to go.
That report, I’ll put a link to it. It’s a neat infographic that Okta has on their website. So, I’ll have a link to that in the show notes, but it was interesting that it seems like it was some sort of poll — and there’s no date on it, so I’m not sure when this was, but let’s assume it’s relatively recent — where nearly every organization, 97% polled, has implemented security solutions that map to a modern zero trust strategy, but only 16% have actually defined what their zero trust initiative is.
You talked about several different capabilities there around single sign-on and MFA, and policy and provisioning, and a bunch of different things, and most organizations, yes, they’ve got some of that, and the challenge is, how do you put it together in a cohesive manner that steps up the game, but what’s the strategy? Otherwise, you may be putting in a whole bunch of stuff, and you never realized you’re actually on a zero trust path journey to get things done.
Yes — sorry for the missing attribution. We started that in 2019 and continued in 2020. The 2021 data is not out yet.
So, relatively recent, and just as a side note, I was thinking about policies and behavior analysis. You talked about that earlier. I can imagine that behavior analysis looked really weird at the start of the early last year, when, all of a sudden, all those people who were working from remote locations, their homes, and it’s probably going to look weird again in the next several months as economies and business start to open up and people maybe go back to work — maybe not. It will be interesting to see what kind of new baselines for behavior emerge as a result of this COVID shift. So, it will be interesting to watch.
Yes, and that’s something that we’ve definitely seen in our own tools that have the behavioral models. The beauty of it is that it’s dynamic. We see you on the same device, but all of a sudden, you’ve just come from the same ISP for 18 months in a row. That’s the new normal for you, and the system basically will learn that very quickly. The same thing when you then, all of a sudden, pop out in Dubai, out of the airplane, first time in 18 months. Maybe with MFA, you won’t. If we see that all the other context stays exactly the same — it is you now in Dubai — then OK, you are good to go. It learns and adapts to that based on your actual behavior. You don’t have to relearn it or reteach it or anything else. That’s why it’s important to have that ability to have that dynamic access control, that adapts the situation and learns from good outcomes and bad outcomes equally.
All right. Let’s go ahead and wrap it up for this week. Before we do that, any final words of wisdom, Sami, for folks out there who are looking to get started through zero trust or how they should be looking at things?
All I’m going to say is, pick a project that is important and find a sponsor. If you find a sponsor, you make their lives a lot easier every day through that IAM magic that you’re going to add to that. That’s your path to happiness. That’s how you get these things above the line that gets funded and gets the resources to do it.
Very good. Jim, how about you? Any final words of wisdom for this week?
I think we should spray-paint “zero trust” on the outside of the Identity at the Center podcast.
Yes. Maybe I’ll do it later.
Zero trust certified.
“Now with more zero trust!”
Yes. 100% more zero trust, or something like that. Some weird stat that nobody is going to ever fact-check, or care to. Well, let’s go ahead and leave with them for this week. Sami, thank you so much for joining us. This was very helpful for me and, hopefully, our audience as well. Some tangible takeaways — things that they can start thinking about. I think this model of authentication and zero trust and breaking down and making sure that identity is protected, wherever it may be, is really where we want to be from a security perspective when it comes to identity.
Hopefully, people are able to take that away, and don’t forget to check out the show notes for this episode. We’ll have links to that Okta report that we briefly talked about, as well as the NIST Cybersecurity Framework. Also, if you want to connect with Sami, we’ll have a link to Sami’s LinkedIn profile where people can reference and reach out in case they’ve got questions and things like that. With that, we’re going to go ahead and leave it for this week. You can find us on the web at Identityatthecenter.com, and you can follow us on Twitter @IDACPodcast. With that, we’ll go ahead and leave it. Thank you all for listening. Thank you, Sami, for joining us, and we’ll talk with everyone in the next one.
Thanks for listening to the Identity at the Center podcast. If you like what you heard, don’t forget to subscribe, and visit us on the web at Identityatthecenter.com.