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?
We’ll get through it, yes. There’s some news, so we’re going to tear down the fourth wall yet again, as we normally do. We’re recording a couple weeks in advance, but today is March 3, so we’re going to talk about some announcement that literally just broke as we were about to hit the Record button here.
Before we get to that, let’s get through a couple other items that we want to get to. We’ve got Identiverse coming up. The registration is open. It’s going to be June 21–23, at least for the in-person event, which is in Denver, and then they have an extended online event as well that I think goes a week past that. You can go to Identiverse.com to check that out. I’m still on the fence about being anywhere in person in June, but with the news that there is apparently enough vaccine supply by May, who knows. Maybe it will make sense.
The other thing that we want to talk about is Identity Management Day. It is April 13. It is the second Tuesday of April, and it is a new global, galactic holiday that we’re going to be helping celebrate and promoting, so we’ll talk about that more later but want to make sure that people don’t forget that, and take part. Other than that, why don’t we go ahead and introduce our guest for today. His name is Robb Reck. He’s the chief information security officer at Ping Identity, and he’s going to help us through a few different conversations, including our breaking news, as well as things like Solorigate and cloud security and zero trust, and, I’m sure, other things as they come to the stream of consciousness. Welcome to the show, Robb.
I think I’ve got to be careful as an executive for a public company that competes with these. I’ll just say that I was surprised, and I’m really interested to see where this goes. I think that they both have interesting strengths, and understanding how they’re going to complement each other is, obviously, what that leadership team is going to put together soon, and I, for one, am interested to see what that’s going to look like.
Yes, it’s always interesting when you have competitors that are joining forces and they have similar capabilities. Obviously, every organization has its own strength, and things like that. I briefly skimmed the article, and it’s six and a half billion in a stock deal. That’s a lot of money, or a lot of paper money, I should say. I hope Reddit gets on top of that one and pushes that one to the Moon, just like they did with GameStop.
Ten bitcoin, right?
Yes, it’s like 10 bitcoin. You can buy out Tesla pretty soon with bitcoin, too, so who knows? Robb, thanks for joining us. Usually we start with, “How did you get into infosec, and, specifically, the identity space?” but that was breaking news and like, “OK, let’s talk about that real quick.” So, let’s restart here. You’re working with Ping right now. How did you get into the infosec space and, specifically, the identity area? Is it something that chose you, or did you choose it?
Yes, that’s a great question. I’m happy to reset the clock. I was your typical IT guy. Actually, right out of college, I was in a call center, helping people make their videogames work for Electronic Arts, and I followed a path of going from that customer support to desktop support, network engineer —call it the 2003 time frame, when Sarbanes-Oxley told all of those public companies, “You need to start having controls in place. You need to be able to prove that you’re doing things like access checks and that your systems themselves have appropriate controls on them.”
That was when I got the opportunity to learn what security was, and I was at a relatively mature company, but they didn’t have a security team. They didn’t have anyone doing that type of work at all, and my way was blocked if I wanted to go after becoming the exchange admin or the Active Directory guy. But the security space was wide open, and I went after it as my area within IT and, man, I really fell in love with it, especially in the early 2000s — very immature, not a lot of well-known standards to follow, and certainly, they weren’t being followed very many places when they were there. It just gave me a chance to start being creative within IT, and I really enjoyed that.
From that one organization, which was an oil and gas company, I then went to a small company that, interestingly enough, did online mentoring for large enterprises, and I got to build a security program to meet the security requirements of the biggest organizations in the world. It’s like the who’s who of the top 100. They’re the only people who pay for a mentoring SaaS product, by the way — or, at least, they were the only ones who did it back then. And they all wanted their employee data to be protected just as well as they did internally, so I got the chance to learn that, and that was my trial by fire in security.
From there, I went over to banking and was the CISO for a couple of different financial institutions, and in 2015, I met Andre Durand, the CEO and founder of Ping, and Andre was telling this crazy story about identity becoming more personal and on your device and how we’re going to be using these devices to authenticate into the future. And I’ll tell you, he didn’t use the words that I’m going to use right now, but he sold the vision of zero trust and getting away from the network as your primary way of instilling trust and using those devices to do it. And I, for years, had recognized that my security programs with primarily network-based controls were not very effective. You just had way too many ways around those things, and showing that vision of how we can actually fix it, that got me excited, and that’s what made me come to Ping, and it’s just been an amazing run there. I came in 2016.
I’ve been there just over five years, and in that time, we were sold to a private equity, and then we went public, and we’ve more than tripled or quadrupled, and we’ve invested a ton in building our security practice that’s really heavily focused on product security and cloud security, and I’ve been really blessed to be a part of that for the last five years.
Yes, it definitely was humbling, I’ll say. I’ve been in security now for almost 20 years and IT for significantly longer, and I’ve always been the top person who cared about identity and would have good theories for how we should improve the user experience, and I come to Ping and I’m — I don’t know, am I number 300, the 300th-best identity person in the company? That might be generous. I don’t know if you guys know Brian Campbell and David Waite and Jeremie Miller. These guys — part of creating the standards across the industry, they are pillars within our company who I go to and ask for advice on how we can get better at practically doing the identity things that Ping helps companies do.
There’s good and bad. There’s number one, I just talked about that I’ve got all these amazing resources, but then, every time I want to roll out a new security thing, I get a lot of opinions: “Why didn’t we do this?” “There’s this new guidance.” “You can do it this way.” It’s not that I don’t appreciate the opinions. It’s that I don’t have time to respond to 300 people every time we want to make a change and explain why “We had to do it this way for this reason.” It’s definitely an interesting experience, and one that I wouldn’t trade.
Yes, absolutely — lots of helpers. I think you’re perfectly positioned, though, to talk to us about our main topic for today, which is the SolarWinds breach, or what a lot of people are calling Solorigate, if I got that right. We’ve already talked about this, so I know you’ve got a perspective and you’re looking at this from different angles. Obviously, you’re the CISO at a software development firm, and you do a lot of your business offering cloud services. The first obvious angle is the endgame and what we’ve all heard about Solorigate, which is the attackers getting into victim companies and taking control of their IDPs — specifically, AD FS — to mint tokens and impersonate people within the target organization to cloud services that are being federated to.
In other words, to boil this down, if I was the attacker, I could get into your organization, take over your AD FS system and then impersonate anyone within your company to your Office 365 or to your Workday. So then, obviously, I’d have access to your email or whatever else is available through these cloud services. Maybe you could take us through the anatomy of that attack. I think I hit it at a 50,000-foot level, but there’s more to it.
Yes, I think you did a good job summarizing the high-level stuff. I think of it from four different perspectives that are relevant to me, and I think they’ll be relevant to many of our listeners here.
The first thing I think about is the first one you touched on: Any company that creates software that’s going to be used by other companies becomes a potential way into those companies. I work for an organization that’s used by some very significant enterprises, and I can imagine a bad guy saying, “That’d be a good way to get in.” So, what happened to SolarWinds becoming the backdoor into the customers is highly important and worth a very significant amount of investment to ensure that my organization — and, whoever else is listening, your organizations — are also not the backdoor, the mule, into those companies.
The second element to that interesting to me is that through this process, there’s been some other rumors — and I don’t need get into the specific rumors — of other companies that may have been the way into SolarWinds, and where they were. It’s not really the point. It’s the fact that they could have been, and we all need to be looking at things like tools in our SDLC, any code pipelines you have, to say, “How do you know that that tool that you’re trusting to check that the binary hasn’t changed, how do you know that that tool itself isn’t compromised?” Each component along the way, going to the thing we’re going to talk about later, you need to have zero trust in those things that’s not appropriately earned. Start from the assumption of zero trust, that is. That’s the second area that I’ve thought a lot about — getting smarter, and how do we make sure we’re doing the right things in our code pipelines?
The third one is for everyone listening: You talked about once the bad guys are in the environment — and, to be fair, it doesn’t matter if they got in using the SolarWinds vulnerability or if they got in by account takeover or it’s an insider threat. The question is, “Once they’re in, what do they do?” You talked a little bit about what they did, and I’ll break it down into a few points. Number one, they tried to get access to your private sign-in key. So, this is like Security 101: Your private sign-in key should not be sitting raw on a file system for your federation server to read it. It should be in an HSM or some other cryptographically safe environment that you can only get to appropriately, and frankly, when it is accessed, there should be some kind of monitoring for how it’s accessed, and alerting on that.
They got in and they stole the key. Or, let’s say you happen to have done a good job putting it in an HSM, and they couldn’t get to the key. Well, what could they do instead? Do they have administrative rights on the box? In this situation, folks who had the key protected would see the attacker go onto the box and alter the running binary of the federation server, so now they own that binary — they can do whatever they want to with it. That, of course, is a risk that needs to be looked at. How do you that? Once again, traditional security controls — making sure that the wrong folks can’t get access to it, and things like file integrity monitoring on those boxes to look for any changes and detect if anything inappropriate happens.
Then, the last element of that that’s really interesting is signals of people standing up new federation servers. If you’re standing up a new federation server, that should be aligned in your ticketing system, and we should have alerts in place to let us know that that’s happening.
That’s three. The fourth one that I have to think about from my perspective is ensuring that I’m doing the right things on my own corporate environment. All these things we just talked about, it’s not just for my customers, where I have to help them and ensure our products are configured to make them successful. I also need to make sure that internally, we’re doing the right things, and work closely with my partners to do that, and I can say I’m comfortable that we weren’t impacted and all that good stuff, but there’s always room, and we’re always looking to get better.
The piece of the private sign-in key, the part that comes to mind for most folks is that it seems like AD FS was talked about a lot with this attack, and, obviously, AD FS is something that a company would be hosting themselves. If they had a cloud-based IDP solution, would this still be an issue?
I find it interesting about the whole DLL modification. I don’t know if enough people know about exactly how that works. Is that something that you could detail a bit more on?
I don’t have the forensic details and exactly what changes they made, but the intel that was shared on that was that the bad guys were getting in there and changing the running federation server to one that they had changed some binaries on so that they can make the federation server mint tokens according to their desire versus the traditional path.
Every step of the way, having good, effective security controls would have stopped this, starting off with the impact to SolarWinds’ customers. If you had SolarWinds sitting on one box in isolation, and once the application running on that box was compromised, they couldn’t actually get anything, you’ve just limited the impact of that.
Now, the problem is, SolarWinds is a network monitoring tool that’s going to have rights within your organization to see every network segment because it’s looking for all your assets across the organization, and many IT organizations, as a result, will not put least privilege in place. They’ll say, “It’s an IT tool. Let’s use this.” Maybe sometimes it’s even a domain admin account to run it, and once the SolarWinds system itself is backdoored, it’s able to get a lot more rights than it needed and it uses those to pivot internally. So, having appropriate segmentation, even if SolarWinds was popped, all they’re going to do is be able to see the inventory of your network. That’s bad enough, but it would have stopped them from being able to pivot over to your AD servers. So, there’s that escalation point — this is first and foremost.
Then, you say, “Let’s just say that we did have too high an account running SolarWinds, so they’re now able to impersonate a domain admin and get onto our federation server with that.” There should be some kind of detective controls in place on that federation server to detect when someone’s logging in and what they’re doing. If you have the appropriate monitoring in place, it should raise an alarm that someone’s making changes to your system outside of a change control ticket. Good practices in change control and asset management would prevent the vast majority of this, and I think anyone who’s been doing this for a while knows that those are incredibly hard, and it’s actually a pretty big ask to have those things done well across your enterprise.
You brought up something that I unfortunately see a lot of, which is that organizations feel like, “All right, this utility is asking for a very high-powered service account” — I think you mentioned domain admins. It just makes me cringe every time I hear that potentially, we’re creating a service account, putting them into domain admins group. I would imagine that the word to the wise would be, “Question that — use the least privilege model where possible.”
Yes, and I think it goes to the posture of if you don’t have a standard up front that says, “Here’s how we are going to provision these new servers when they come in,” and security is handing the IT team “This is the way we want you to do it” — the IT team’s just going to look for the path of least resistance. What’s the fastest way to make it work? “If I use this domain admin account, it just works. I never have any problems. Whereas, if I’m using this SolarWinds limited account, man, I keep getting these errors, I’m not getting all the data I need, it’s a struggle. So, you really have to be proactive in order to fight against that path of least resistance.
Yes, I think being challenging on those types of questions — I feel like a lot of those times, it comes down to application teams and developers who say, “Here’s how we’ve coded our application,” and they didn’t go to the effort of splitting out what permissions they actually needed and just say, “Just give me God rights on” — whatever machine it is or whatever system it is — “so that our thing will work.” I think challenging that back to software vendors and other folks who are putting things in your environment makes a lot of sense to make sure that you don’t get stuck in this. If everyone’s a domain admin, how are you supposed to protect it, and especially if they’re an application like SolarWinds, where it’s doing the things that you want it to do, but trying to detect anomalous behavior might be difficult because of what it’s designed to do just makes it even that much harder.
Yes, I think that this goes back to having a level of maturity in your IT program that many companies don’t, and investing in that. My motto for security for years has been “Security cannot be any better than the IT organization it is supporting.” And that also goes hand in hand with the architecture of the environments, but if you just try to slap on a mature security program to an immature IT program, you’re going to fail miserably, and everyone’s going to hate each other along the way.
Yes, and I think, just to pivot, this is something that we see commonly in the cloud and different infrastructures and platforms as a service, whether it’s AWS or Azure or GCP, is, a lot of people end up with more permissions than they need there and can do far more damage than they probably realize, if they know what they’re doing. That’s something that we see quite a bit with the folks that we’re talking with. I’m curious if you see and experience that same issue with some of the things that you’re working on.
The lift-and-shift problem? Is that the problem here?
Yes, that, and too many permissions — roles are not well defined or well scoped.
Yes. I feel like those might actually be the same thing — the lift-and-shift and the too many permissions — because it is a lack of understanding of the difference between your traditional data center environment and how, for example, AWS works. And it’s so easy just to say, “We’re Linux admins. We know how to use our private keys for authentication. Let’s just keep doing that,” and not really understand how moving to IAM roles within that environment can increase your security and increase your usability at the same time, and, frankly, making it so that when you have turnover, your risk from a stability perspective is a lot better as well because these folks who have these keys on their laptop — and maybe they took them to their home laptop along the way as well — you get rid of a lot of that risk.
I think with the cloud that CISOs are experiencing new challenges — not just the cloud but also in DevOps. It’s a ground shift. It’s changing the idea of instead of having servers, you have these whole new ways of doing infrastructure as code and things like that, using Docker, and what I feel like I’m hearing a lot from CISOs and from IAM folks is, we need to remain agile, we need the ability to move fast. CISOs don’t want to be the No Department. They don’t want to be the Progress Prevention Department. Developers need to be empowered to move at the fast pace that they’re being demanded to move by the business, and at the same time, information security has to ensure that proper controls are being put in place.
I’m assuming you deal with some of that as well. Obviously, you have to stay on the cutting edge of this technology, but at the same time, you’ve got so many pieces to secure. What do you think about empowering developers to move forward and providing them with a framework, but letting them have some control over security and, at the same time, layering in that watchdog layer?
Yes, and it goes back to that earlier comment around architecture. It’s making the paved road the secure road because people want to go down whatever the easiest path is — and they do want it to be secure, just to be clear. I’ve never met a developer who wants to release an insecure, low-quality product. However, they also need to get it out by a certain date. How do we make sure that we’re accomplishing both of those things? It’s going to take the security team working with whatever architecture team or development team you’ve got to ensure that the way that’s easiest is also the way that’s the most secure.
Robb, since we have a few more minutes, we’d like to talk about zero trust. I love how zero trust has been garnering so much attention. To me, it’s about that breaches can be caused by persons that we typically trust or people that we think are safe, people who are on the inside of the firewall. What are your thoughts in terms of how folks like yourself who manage information security for their organization should be thinking about zero trust and taking what’s good from zero trust and applying it to their existing framework?
Yes, I’m a massive fan of zero trust. I briefly mentioned that when I was talking about how I got over to Ping. Zero trust is the answer for the question “Network-based security doesn’t work. So, what does?” Zero trust does work, and I’m really happy to see the positive trend we’ve seen, especially over 2020, during the pandemic, where people were moving in that direction. I think you guys, when we were prepping for this, said it really well — it’s about not having trust just because someone’s on my network. That’s a really nice one-sentence summary of what this is about.
When you get into implementing it, you realize that there’s a whole bunch of assumptions and challenges built into that simple sentence that mean you have to go a lot deeper. Within Ping, as I came onboard, we created our own reference architecture for what does zero trust mean to us, and we call it RedCorp. Our logo is red, and it may be a play on Google’s BeyondCorp. It’s how we envision zero trust working for us. I think that any company that’s serious about this has to go create their own reference architecture, their own perspective, on how you do it.
The starting point is — at least, the way I look at it — there are three really important keys. Number one, you have to lock down the endpoint you’re connecting from. I get into debates with this internally and externally, but I firmly believe that as long as the bad guy owns the endpoint you’re connecting from, they can get access. Hypothetically, let’s say, “We’re going to use VDI, and they can’t get anything. They can’t download anything, but I tell you that they’re going to be accessing the nuclear launch codes.” No, of course, that’s not OK, because they see the nuclear launch codes or whatever the most secure information in the world is. All I’m saying is, every organization has some data that just seeing is bad enough, so we need to make sure we’ve locked down the endpoint, that we can trust that when it connects, that’s not going to cause us too much risk.
A second thing is, we need to have robust controls around the resource you’re connecting to, and whether you think of that as your WAF or your application security built into the thing itself — it’s your access security — those different elements are a critical point.
The third point, which is where I play the most, is this highly robust intelligent authentication that’s on a risk-based basis that says, “I have really high confidence that this is the right person, and this person, based on their role, should have access to this, and because of the activity they’ve had recently, I’m going to require more or less sign-on. I’m going to require multiple factors, all these different elements.”
Those are the three components I think of: endpoints, application security or resource security, and then the IAM stack. Coming up with your strategy for how do you tier these for this highest level of sensitivity for my data, well, you’re going to have to have this much more robust set of controls. We’re going to require that it actually be through a VPN, because I do want that extra layer, or it’s going to be these four or five other things we can require. Then, for the lower-level stuff, it could be available with just using a password. We can choose based on how highly sensitive the information is.
Just to cap it off here with, I think every organization has to go through that exercise themselves to identify, “What are the most important resources?” and then start working on a plan for “How do they roll out zero trust to those most important resources first?”
Yes, you touched on the thing that I was thinking here, too, because we get asked a lot about zero trust and “How do we do it? What does the reference architecture look like for zero trust?” It’s more the concepts and the ideas that you have to address, because every organization’s going to have different resources, different targets, different acceptable levels of risk. Sure, you need some technologies to be able to accurately identify users and make sure that you’re getting the right signals to be able to make authentication decisions and things like that. I’m glad you brought up that last point, because I feel like there really isn’t a one-size-fits-all. It’s more the concept, and then taking that concept and applying it to the infrastructure or the organization that you’re trying to protect.
Yes. I’ve now had the opportunity, talking to different customers and different friends in the industry, to see dozens of different companies’ architecture for zero trust, and I’ve seen a lot of good ones. Probably more than half of them have been pretty good, and none of them have been alike. They’ve all got their different spin, and I think it’s right. It’s how it should be because, just like if you ask me, “What’s a good security program look like?” I’m going to say, “It depends on the company.” “What does a good zero trust strategy look like?” “It depends on the company.”
Google did such a great service to the industry by publishing their BeyondTrust papers, where they showed the way they did it, and I’ll reiterate the key point to that for me: They started by saying, “What’s a workload” — a workload is a user connecting to a resource — “that’s high risk to us as a company that we want to start with? Let’s secure one workload at a time, and over time, we’re going to be able to get entire employees off of the VPN,” and that strategy really worked well for them, and I think it would work really well for just about any other company that’s thinking about doing this as well.
Yes, BeyondCorp is a really great concept. I remember seeing that at Identiverse a few years back, where they were presenting it in like 2016, or maybe even 2017.
I know we’re coming toward the end of the time, but I wanted to do a little bit of a lightning round and get your gut-feeling, no-holds-barred responses to a couple things that I hear a lot. Super brief, but, user behavior analytics and access management, how do you see those playing out in the IAM space?
I think it’s absolutely the key to success, knowing what normal looks like and being able to identify bad based on that, and the UEBA — user and entity behavioral analysis — is one side to that. I think of that as being your authenticated runtime analysis, and the other side to that is the preauthentication analysis, where we’re looking to see, “Is this coming from a bad IP address?” Do have a pattern of sign-ins from this person that looks malicious? And I think being able to match those two things together —we go from preauthentication all the way through your session — is super powerful, but there are things that are thrown in that makes this more difficult. We talked about the trends — going to the cloud, and going to the cloud and not having things in your data center, it makes this more difficult. Do you want to make people hairpin back through some system to see it? Anyway, I know you said lightning round, so I’ll stop talking.
How about blockchain identity? Where do you see that at the end of this year?
Can I pass?
Sure. I’m still looking for a use case at least in the enterprise side. I haven’t seen a good one yet but, yes, feel free to —
I’ll say blockchain is a really neat set of technologies that we haven’t yet — I haven’t seen a lot of things that couldn’t have been done just as well in a database.
All right. My last one here is, finish this sentence: “If I log in and I’m not using MFA, I am —” what?
You’re probably not you. You’re probably from a different country. If you’re not using MFA to log in, yes, you’re lucky that you’re still able to log in. How about that?
I would go with screwed, but that’s just me. You’ve been super generous with your time. I do want to talk a little about this Identity Management Day that we teased at the top of the show. I mentioned that it’s April 13, the second Tuesday of April. It is a brand-new thing, so don’t feel like you missed out last year. It is something that has been started by the Identity Defined Security Alliance, along with some help from the National Cyber Security Alliance as well. I think this is probably breaking news. I wasn’t sure if you’re aware of it, Robb, but, yes, there’s Identity Management Day, April 13. Thoughts?
Does that mean we have to sign in more times that day? What do we do to celebrate that day?
We talked about maybe doing a cake on our last episode. I think there are a lot of different ways people can get involved. There are a few different things that you can do: You can go to IdentityManagementDay.org. They have a brand-spanking-new website where you can do things like nominate an Evangelist of the Year or maybe, Robb, a Podcaster of the Year in the IAM space, and I think that would be something that people might be interested in. You could nominate an Org of the Year. I know they’re looking for content as well for blogging around identity management, and maybe doing a blog or some sort of video- or audio-type thing that they’re looking to help publish and highlight the need for IAM. Maybe that’s something that people might be interested in, and they can go check that out. Any thoughts on being an Evangelist of the Year from an IAM perspective?
That’s fantastic. I don’t think I get to win that. I don’t think I’ve been a good enough evangelist, but I do think that we do need these kinds of days to get people to think about that this behind-the-scenes, pipes-in-the-walls authentication is critical for our success, and we want to make sure that we’re getting better, so I appreciate them putting this day together.
Jeff, last week, we celebrated National Pancake Day. I think a basic question is, “Why isn’t there an Identity Management Day?”
Yes, and now there is: April 13. I think we’re trying to figure out, “What does that look like for us from a show perspective, and how can we help celebrate that?” It’s always great to get recognition, and I think the more people that are aware of identity and how important it plays in security — I would argue that identity is at the center (hint, hint) when it comes to security and being able to know what you’re trying to protect. I fully support it and, Jim, I think you do, too.
Absolutely. I think what you’re saying is right — it’s about raising awareness. We’re trying to pull more people into this career field. Like all good information security, there’s more demand than there is talent, and identity management is absolutely no exception. That is a great place to build a career, and I’m hoping that there’s some emphasis on that: “How do we bring more people into this field and get them excited about it and look at it as a great way to build a career?” There’s a lack of — not a lack of talent per se. You need experience in this field. You build experience by spending many years in the field, and so we have to start bringing new people into the field so that we start building that talent pipeline for the next decade and beyond.
Awesome. Thank you, guys, so much for having me on your show. It’s been a real treat to get to know you both.
Yes, thank you so much for joining us, Robb. I think with that, this is probably a good spot — we’ll go ahead and leave it for this week. As a reminder, don’t forget Identity Management Day. We’ll have links to a whole bunch of stuff in our show notes, and we’ll have links to Robb’s podcast, Colorado = Security. Robb, if you’re cool with it, we’ll put a LinkedIn connection there for you as well if people want to reach out. Are you OK with that?
Absolutely — always happy to connect with folks. Make sure you put a note in there so I know you’re a podcaster and not a salesperson.
Not a bot — not someone trying to sell leads, or anything like that. We get plenty of those. With that, we’ll go ahead and call it for this week. You can visit us on the web at IdentityattheCenter.com. We’ve got a handy link there as well for Identity Management Day. You can find us on Twitter @IDACPodcast. With that, thanks, Robb, for joining us. Jim, thanks for your time as well. We’ll talk with you all 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.