[podcast] IDSA Report-Identity A Work In Progress
In this episode, Jim and Jeff talk about some of the findings in the recently released Identity Defined Security Alliance (IDSA) report "Identity Security: A Work In Progress".
We hope you enjoy this episode and please subscribe to our podcast for updates on new episodes!
LISTEN HERE or read the full transcript below.
*Disclaimer from Identropy: These transcripts are produced using automated tools, so may not be an exact word-for-word transcription. (i.e. - if you read something that sounds wrong, it's the tool's fault!) As always, for a better experience, please listen to the actual podcast.
Podcast #44 Full Transcript:
Identity At The Center #44 - IDSA Report-Identity A Work in Progress
Jeff: Welcome to the Identity at the Center podcast. I am Jeff and that's Jim. Hey, Jim.
Jim: Hey, Jeff. How are you?
Jeff: I'm doing OK. It's a Thursday. So one more day to the weekend. If there is such a thing, I'm not sure at this point.
Jim: When's the last time you've gone outside?
Jeff: Oh, I've gone outside. I took the dogs for a walk yesterday, went around the block. So does that count?
Jim: That is part of outside, yeah.
Jeff: I've been to the grocery market, so, I'm out there, wearing a mask, doing all the right things, trying to stay clean and healthy.
Jim: I feel like I'm clean and healthy, but I have not been wearing a mask that often, honestly, and I feel like we're I think things are moving in the right direction toward getting back to normal.
It's such a political hot button, Jeff, this is not a political show. I think we should stick to our sweet spot, which is identity at the center.
Jeff: Danny at the center IAM. That's something that we do. I'm not sure what. What is I IAM?
Yeah, that's the question. Well, speaking of IAM. There was another report that came out today, one from our friends at the Identity Defined Security Alliance. They commissioned a report taking look at the different benefits, challenges and different enterprise efforts that have been going on for companies looking to adopt an identity centric approach security. Looks like they surveyed around 500 people or so and they were looking at companies that had a thousand or more employees. So this is kind of fresh off the presses. So we're kind of scanning it and reading it here as we're talking about it. But they had some interesting findings, just kind of a first glance. I think the most important one and probably one that lead off with is 94 percent of these respondents have said that their companies had experienced in identity related breach, which, that's everybody.
Jim: It's a high percentage. And the other thing on top of it is, I think to back they train lovin. You talked about who complete the survey, and these are people who were in the trade. These are people who are security professionals and kind of would 94 percent, and of those it was 74 percent said it was within the past two years.
So I guess 20 percent of those were two years or older. But a large majority of having identity related breach within the past two years. That number, they really floored me. Well, what I would say is that almost any breach that exists is identity related. I mean, can you talk about a breach? There's not identity related. Yeah. There's some, brute force attacks and denial of service attacks that can lead to, systems becoming comprisable. But for the most part, it's usually you got some form of credentials for some user account person, human or non-human, and you're able to log in. We had that one slide that we use all the time, Jeff, which is, a quote that we heard at Gartner. Hackers don't break in the log in.
Jeff: Yep, that's totally true, right? It's not was that 80 percent or something like that? Go back to some sort of credential that is usually the way that people get in, it's unfortunate sometimes that it takes a breach to get something done in an organization. Right. I mean, there's forward looking, there is neutral and there's kind of like reactive organizations. But it's we're still in this mindset of where. Well, we'll deal with that when it happens. Maybe not by choice, but by budget or by timing. But that's still kind of where we're at. And yeah, you're right. I mean, it's seventy nine percent have had an identity related breach within the past few years, so. Ninety four percent overall, let's say. Seventy nine percent over the last two years. That just means that it's still a very common thing and there's a variety of different methods that people are here and to do it. But phishing seems to still be the most Parap predominant, with about two thirds of the people saying that was the most common reason for or the most common cause for the different types of breaches.
Jim: Kind of hedge factor in the way. I mean, it makes change because it's like. Tricking people into coughing up their credentials seems really a good thing. That's the easy way to do it. But it's also a thing where, gosh, you multifactor authentication sure would take care of most of these problems, even if you have my password.
If you can't get in, there's kind of two things at play here. One is that, we think of your mind when you hear about Identity breaches your mind immediately goes to or some nefarious hacker in a coffee shop somewhere. And he's got his hoodie on those weirdo masks.
Jeff: Guy Fawkes mask.
Jim: Yeah. But I know we have another one of our favorite slides is the percentage of breaches that occur through that are internal. It's a really high percentage compared to what you might expect is something a 35 percent.
Jeff: It's like two thirds are external. A third is internal. And you know that when I say internal, it's employee, internal contractors, vendors, people who are not necessarily on the outside the firewall, so to speak. So by internal and insider threat thing is definitely a vector. Now, it'll be interesting is, are those truly insider threats, people on the inside who are doing bad things or someone who has gotten a hold of an insider credential and is then using it? Right, to do things that they should be doing. So their number maybe askew a little bit, but the other day, it's still an identity.
Jim: There's a mix. And then when you think about MFA, you think in terms of priority protecting the outer shell of the organization. You have a VPN or you have VDI. You definitely, definitely need to protect those using multifactor.
But, one other seniors are going to point back to Gartner again because is a lot of good stuff in their conference this year.
But one of the quotes that really stuck with me is that the new baseline norm is that MFA everywhere. So what does that mean? It doesn't mean that every time you go to a new application, you have to use the authenticator app or something like that. But what it does mean is that you have a session that has gone through MFA. So. If I go over to your desk and see you on your credential, want a piece of paper and they go back over to my desk and I go to log in with your credentials is going to see the new device, Herman, adaptive perspective. I need to prompt you not only for your credentials, but also for your second factor. And so should stop.
So really, it's a combination of factors that go into this. But MFA has got to be at the core of the solution here.
The thing is, it can't just be piecemeal, a piecemeal approach or you're not really solving this entire problem.
Jeff: Yeah, MFA should be standard, but it's still surprising to me how many established organizations still just don't have it ingrained, as prevalent as it probably should be at this point. I can understand smaller teams, especially with the rush here to work from home. Smaller organizations, with a pandemic and having to work remotely, etc. having to scramble if that's not something that was part of their daily life before, but still surprising how many big organizations just don't have MFA to the level that you would think they would at this point, one of the kickers here is as we're kind of looking over the report. And ninety nine percent of the people believe their identity related breaches were preventable.
So, yeah, that tells you that it's like, OK, yeah, we should have done something about this, but we didn't or we hadn't yet. Or something along those lines. So I don't know that's good or bad. I guess it's good. The fact that there was an answer bad in the fact that, nobody decided to apply the answer in the time before the breach hit.
Jim: Well, how does that quote go? Hindsight is 20/20, and you know. I mean, MFA could have prevented things you obviously would have done and I think what happens is a lot of times we in the security field, we're going to point out this is what we need to do, but we're not the ultimate decision makers on whether or not to spend the money for that.
When I saw that number, the ninety nine percent I didn't know whether to look at, it was like, wow. Or, well, it's almost everybody or feel like, what's up with that other one percent?
What are these facts that have these creatures that happen that could not be prevented?
And I came down is that I think how people you know, these are human beings that are filling out the survey. And we've run into people all the time who what I mean with what you and I do is we work with clients all different industries. And for people who represent different parts of business. But let's just talk about information security and people even within the same organization. But, as we go from place to place, some people are very optimistic and some people are very pessimistic. That's one of the things. But, 99 percent is almost 100 percent over 100 percent of these breaches. People felt like could have been prevented. But one of the things that's kind of the next level in this document that talk about what was the main thing that they thought could be done to prevent breaches or something like 75 percent of the people selected user education, awareness training.
Jeff: awareness training is the biggest one.
Jim: Yeah, there's kind of a hook within the document, which was like, all right, guys.
So what you're saying is I thought that this talking is really well written because it wasn't like, hey, we're just going to take it. And whatever people say, we're just going to accept. That is a kind of said. All right, guys.
Seventy five percent, you're saying that it was the users fault for falling for this, another other. Yeah. We should done more training because these stupid users went and got phish.
There's other way. What about MFA? If you have a MFA in place and the person coughed up, their credentials are really well mannered. Yeah. So I thought it was kind of cool that this document just didn't accept the answers as is but on the same token, I do think that security awareness training is critically important because.
as much as Gartner's the new baseline year MFA everywhere, I hardly ever see organizations actually achieve that.
Jeff: Yeah. Dollar for dollar security awareness training has been, at least for the last several years, the most effective way to improve overall security. Does it solve all the issues? But pound for pound, that's the way to. That's the way to go, and, I should note that, we'll put a link to this report in the show notes so you can drill down into the details wherever you're listening to this. And there'll be a link in there for that identity defined secure line of support. I think what's nice about this report, too, is that, it's vendor neutral. It's not spun by, not to pick on anybody, but like, you know, CyberArk, who is looking to push PAM products, on somebody. This is more of a, neutral alliance, and they're not pushing any specific technology stuff anymore informational. So I think that helps quite a bit with the messaging. But, yeah, they did a really good job with it. I'm just looking at the chart here for the. The question was, in retrospect, is there anything that your company could have done to prevent or minimize this breach? And seventy one percent, better security awareness training for our users, that was the number one answer on the board. And, some other things on here, too, like improved internal processes, better integration of existing technology, better in-house expertise around identity and security, better or wider implementation of technology that we own. And the last answer, really, they had any kind of measurable number two. Thirty one percent said purchase and deployment of new technologies. So it seems like the answer out there is use this security awareness and things before saying, oh, yeah, we need to go out and buy something because we don't have the tools or methods to to prevent breaches. So I thought that was interesting.
Jim: Right. One thing I was thinking is, as I was reading through this report, because we made a good effort to point out privilege access in this whole thing, because what's important, I think, is the Joe Schmoes login. The amount you can do with his or her logging is limited. Right.
You have to then try to figure out how to escalate privileges. And usually that I got into the network with Joe Schmoes account. Now I'm going to try to get a privilege account. And that's how hackers usually work with these data breaches because Joe Schmo knows he's a DPA is not going to be able to go in and get that honeypot.
And my experience and working on a PCI project, PCI being the payment card industry, PCI ID. So it's basically the standard rate and regulatory framework for management of credit card data.
And the idea was that, most of the controls are focused on the ability to dump credit cards, not to go from screen to screen and get one at a time. It was about being able to steal large numbers of credit cards in time, because that's really your big risk is if someone walks away with, like, twenty five credit card numbers or twenty five piece of personal data. Again, there's still a little bit of a black eye. But it's not like a total, like, disastrous event when someone's able to download, you know, millions of records and just offload them from the company and throw them out on their or whatever. So what? That's why I think that, if you're taking a risk based approach, focusing on this privilege accounts and one of the things that I thought when you go off a little bit of a tangent here, I read somewhere that these respondents talk about implementing leased privilege for privilege to account.
And one of my hang ups, I always have when I read information security policies for organizations and they say at least privileged least of which, and then they talk about we need to have role based access control and the approach, a role based access control is we're going to create a role and we're going to Gennaro's size access. In other words, we're going to give people access, that they don't need because they're a type of person that they are faced those most. And within that, we're going to group access. And ultimately what's going to happen is some of these people are going to have some access that they don't need. And, my personal feeling is this probably. All right. If the risk is appropriate, however, when it comes to privilege access and the risks is not appropriate of giving somebody too much access. And that's where you really need to know are down the channel if you're using a privilege access management solution and you can control the authorization of the entitlements that somebody has. They can only, one certain commands at certain times through the control of their privilege access to them. That's where you get to the point of the Nirvana state.
And so all of that combined, I think it's all about managing your risk and putting your investment in the areas that pose the most risk and the most risk comes from people be able to accelerate large amounts of data in the Joe Schmo account. Can't do that. But privilege identity sure can.
And that's where you have to have tools to manage that. Then to have this privilege. And also you have to have really strong authorization. And multifactor authentication is an absolute minimum when it comes to those accounts.
Jeff: Yes. I feel like identity breaches are a numbers game. It's a volume business. You're not going to dump five or 10 people their information unless it is a targeted, probably more of an espionage type thing. You know what, it's corporate or government. They want to go after the tens and hundreds of thousands or millions of records. And because those are so cheap, it doesn't make any money, typically to breach and say, oh, yeah, we got twenty five credit card numbers, those are pennies and dollar in the dark web. So, if they're going after the rights and permissions that are let them dump thousands, hundreds of thousands, millions of records, entire databases, etc. And that stretches and the privilege access base and their role based access control in the privilege access base should not exist. It should be maximum of least privilege at all times. And even that might be more on demand, if you've got the capability to swing it, but it should not. I feel like Rule-based access control does not apply to privileged workers. Makes sense, for standard kind of Access's that are out there, but definitely not in the private space. that's sometimes something I see you say, oh, yeah, we used up a vault and we gave everybody who is in this team access to this vault in case they need it. Well, that's not great. That's not the way that I would do it. And you're right.
Jim: I think you made a really good point there around that espionage piece, which is that, everything I said can be taken with a grain of salt. If you got certain use cases where you're protecting very sensitive data or the Joe Schmo account now has access to health care information system, and I can go and see, kind of find celebrities within this system and start, actual trading ones. You choose your records. That is a big deal in certain industries.
So, before we get a bunch of hate mail, which we haven't got any hate mail yet. I'm like, I guess we could be the biggest celebrities if we haven't gotten any hate mail yet.
Jeff: That's how, you've made it when you get the haters.
Jim: You know, you have some haters unless nobody. And that's what I hear anyway. But. Yeah, but that's where it all comes back to exactly what we're stating, though, which is risk. You have to know your risk. You have to know your risk.
And if a single individual accounts do pose high risk and they shouldn't be every account, right. You shouldn't be every account in your active directory poses a huge amount of risk. I guess that's possible. But it seems to me that there's going to be levels of risk. And what we're talking about here is the ability to prioritize.
We're not saying you shouldn't go as far as your account to secure your network, but assuming you have limited reserves, which seems to be the case for everybody, you have to decide where to put your paintings.
Jeff: As a good point, I think, knowing where your secrets lie and what's important is a big part of being able to protect it, if you don't know what those are, that's probably one of the first things you work on is what are we try and protect and doesn't make sense. There's an article today I think I saw in the paper today, which is May 14th. There is some and I'll butcher this, I'm sure, because I have in front of me. But there was a law firm that got hacked and apparently they fell victim to this ransomware and have had some other data dumped, including, contracts and things like that. And apparently they do work with celebrities. So I'm sure there are probably sensitive things in there. Right. Attorney client privilege type things. And maybe something comes out of it. Know, maybe not. Who knows? But if it's, could be five clients, it could be five clients, too many, especially if they are very high profile celebrity type people. That's a much different use case then. Yeah, I'm just trying to break into Capital One. Right. Or Experian and get records for hundreds of thousands of users indiscriminately. Right. I'm not targeting any specific individual.
I was gonna kind of pivot to the change in how these breaches tend to lead to. Let's say management changes, right, or ownership changes.
And that was one of the things that the report identified was that 71 percent of the organizations had gone through some sort of ownership change of IAM within the last few years. And that was pointed to as one of the reasons why I think it is. I mean, look here. Forty six percent of the reasons why there was a change in ownership of identity management was attributed to a security breach. So they were responding to security breach in assigning new ownership because of that.
Jim: Yeah. And then if you look at a lot of charts in there. But one of the things I saw is to better align IAM with information security.
So there is a recognition that, management of who has access to what is critical to securing the organization.
That information security is, the folks that we've tasked with running security and securing their organizations.
I am. Well, all right.
Every organization I mean, we have all the time. What's the best practice or, where shall we organize IAM. And I think there's competing interests. I think that IAM is closer to application development than any other area of information security. There's a lot of business logic, a lot of all the times custom code. There's a lot of interfacing with applications and a lot like middleware and a lot of ways it's security, but there's a lot of operations behind it. And information security is usually, in a watchdog. Right. Let me say, my experience, along with information security, manages a lot of security, infrastructure, firewalls and monitoring logging type platforms. And then IAM becomes kind of a different challenge. It becomes probably the most complex thing in a CSO's portfolio. And so it's it becomes a challenge from that perspective.
And that is not the traditional role of the CSO to run something like that, on top of that, ISS role, relative to business applications is kind of as a watchdog to make sure things are being done according to security protocol, according to security policies and standards. And what you have is a potential conflict of interest or you have application middleware that you're the owner of and you're the watchdog for.
And so I've always felt like that was a bit of a conflict of interest.
I'm not saying that should prevent you from keeping IAM in information security. In fact, that's typically where I tend to think it does. Alone the most. But I can see that being a you know, I feel like we need to have that conversation more often because I don't think it's something that should be glossed over.
Jeff: Yeah, I agree mostly, maybe partially what you're saying, my viewpoint is that and we've talked as far as where should where should IAM belong to? I don't necessarily care as long as there is an owner and that person's aware of it. It's been defined. I tend to think that IAM easily broken up into more of a planned build run type approach because of what you just said. Some security teams are really good and have good operations and good developers. And, that's part of the process. And they're equipped to support that. Others, not so much, they rely on an infrastructure team to stand up technologies and tools etc. So I feel like the planning, the governance kind of the oversight security is a good spot for it. Generally speaking, although, like I said, not right for everybody and passing out the build on the run, potentially keeping in security or letting other organizations run it as long as, you know, they're following the rules of the road. The reason I say that is because I feel like security has a better understanding of the security challenges around identity and access management. Again, not always the case, but you would certainly hope that security has some capability in that regard to be able to guide people along the right way.
Rather than developing processes or standards that are insecure or not as secure by design. So even if, let's say, IT security is not part of the IAM planning or governance model, they should at very minimum be part of the stakeholders, like a steering committee or, a key influencer in how those things get developed and implemented. The organization, whether it is policy, standard or even technologies.
Jim: I actually agree with what you're saying and you're both a really good point there, that information security groups are evolving and do have a lot of the personnel now that maybe traditionally they didn't have. But the security tools are evolving and they do have developers within InfoSec now.
Jeff: It is a kind of newer thing, right? Yeah.
Jim: Yes, the anther thing is like I think you can be flexible in terms of how they can be flexible in terms of delivery. Not, you know, organizations don't have to have everybody reporting to one person in order to work on that one person's project. Or you can have a kind of a Matrix organization. You can use developers from other organizations to work on IAM. And so IAM organizationally fall into information security.
Jeff: But it requires really good coordination between groups and a very clear understanding and, of the racey of how that's going to work, because when every time you have shared resources, there's always a competition for time.
Right. And whether that's there or not, if an individual feels like they're splitting time in two different things, sometimes it doesn't work out as well. So I agree that it should be there, but it requires a lot of coordination between the teams that are sharing resources and really having an understanding of what's the priority for individuals working on.
Jim: Absolutely. And one of the things that it's an area that requires experience, you can't just sort of like custom development where you can swap resources in and out. It's more like ERP where, you have to. And usually IAM gets very platform specific after you get on to whatever vendors you're going to move forward with. And then you need people who really understand how those systems work. And so you can have new developers kind of coming and going all the time. Otherwise, without that continuity, you're not going to have a whole lot. So I don't think so.
Jeff: Yes, exactly. I think those were the highlights for me when it came to this report. Are there any other highlights or any other comments you want to bring out there before we wrap it up for this week?
Jim: I'm not sure I really understood this coming either for how they determine what a forward thinking company was, but one of the things they talked about was that companies that are forward thinking, I'm doing the quotes, I know this is audio. The four think companies were much less likely to have had a breach within the past year. I think that's indicative of, what justice to be as companies that invest in and planning and getting ahead of things are less likely to be breech. That certainly makes sense intuitively. Again, there's so many factors that go into building a survey and like how they classify what a forward thinking company was, simply that they asked the respondent. Are these your company forward thinking? Which isn't very scientific. But at the same time, I think if you know, you're in a company that doesn't invest in technology and is now out of reach within the past year, that's maybe how it was developed. Do you know more about how they came up with that?
Jeff: Not specifically, but I think the same thing. Is it yours? It's the way I interpret it. It is more of a you know, here's a reason to justify making the investment in identity. Whatever that investment looks like. Right? It could be. Oh, yeah. We really should put MFA in place. Or maybe we do need adaptive authentication or do maybe we do need, automated onboarding, off boarding. Whatever your problems are, if you are at least thinking about it and making investment to solve it. It sounds like there's a payoff there. I would want to probably read the report a little bit more and try to discern it. But the way I saw that question was, here's if you're looking for some justification to make an investment, here you go. Investing does have a measurable impact on breaches. I'll let you invest in, what that impact is, is probably open for debate, but there is some correlation there that can be derived.
Jim: Yeah, that makes sense. Makes a lot of sense.
Jeff: That's me, full of sense.
Jim: 50 Cent, we're going to start calling you 50 Cent.
Jeff: Please don't.
Yeah. I don't think I've ever been in DA Club or anywhere near that. That's never been my scene. But more power to those that are. I'm definitely more, it's like a straight laced, I guess would be the right word or boring. Maybe as people would say.
Jim: You know what, though? You're comfortable in your skin.
Jeff: I am who I am. And that's I am.
Jim: That's Popeye. I am who I am. And that's all I am.
Jeff: Yeah. And then you then I squeeze a thing, a spinach and eat the whole thing at once.
Jim: Never seem to do that.
Jeff: All right. We've got really crazy here. So was probably a good spot to leave it for right now. We'll go ahead and wrap it up. you've been listening to Popeye and Jim. I am inside.
Jim: That makes me Wimpy, right? Popeye and Wimpy.
Jeff: Yes. I don't know. You've seen an awful lot about it. So as the foremost expert on Popeye, I'll defer to you. All right. We'll go ahead and leave it for this week and we'll talk with you all in the next one. Thanks for listening.