Listen to learn about how to create an operational approach to cybersecurity.
Cybersecurity and risk management are often tossed to technical teams, but when these are driven by operations, the entire organization.
Grant Elliott (CEO and co-founder of Ostendio, and Adjunct Professor at the Pratt Institute in New York) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to discuss:
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. If you have been listening for a while that you know we we cover a lot of different topics.
If you're brand new, welcome. Thank you so much for joining us. We have a huge back catalog of all kinds of topics. The topic today, I'm very excited about, because it speaks to one of the challenges that a lot of organizations run into, which is how do IT and the business side communicate together?
It can be a super challenge, on both sides. And the the man I have today to talk to me, about it has a lot of experience in this area. His name is Grant Elliott. Grant is the CEO and cofounder of Aspendio, a people first risk management platform.
Aspendio works with hundreds of companies and thousands of users to build security programs that are always audit ready for complex audits such as SOC two, HITRAMP, and HIPAA. He's a thought leader in enterprise cybersecurity and speaks regularly about how organizations can implement effective cybersecurity programs.
Elliot is the former COO and CSO of Voxava acquired by WellTalk, an integrated messaging and patient engagement platform, and a former business executive at AT and T. He has more than twenty years of experience developing and managing cybersecurity programs and supporting regulatory audits. He's also an adjunct professor at the Pratt Institute, New York, where he teaches management theory and leadership. Thank you for joining me, and welcome to the show.
I'm delighted to be here. Thank you you for inviting me.
I'll bet someone else wrote that for you. Did I miss anything important?
No. It is all it's all good. Yeah. It's been a while. It's it's always it's about the mouthful, I'm sure.
So, the the topic is, and anybody who has been either in IT or in in senior management is we have these, security needs that have to be addressed, and then we have, money that needs to be managed, people, time, you know, the organizational resources that need to be to be managed.
And yet the conversations between these two groups of people can be a super big struggle.
How do we quantify security and compliance in ways that allows our c suite to take it in? So I know that is a great big vast question I just asked you, but give it a shot.
Sure. I mean, look, there's there's a lot to unpack there and there's a lot of kinda, I guess, historical reasons why we're gonna have this kinda, difficulty to communicate. You know, a big part one of the things I talk a lot about is this concept of operational security versus technical security. Security.
And part of the challenge here is that if we can look at historically how we go about managing our information security programs, typically, most organizations have a technical side and they have a kinda operational management side. The technical side goes out the tech, goes out the equipment, goes out the infrastructure, and we tend to think of security as being such a technical incident or tent technical. And and probably twenty years ago, that was maybe true. Mhmm.
Today, you know, when we think about how organizations operationalize themselves, most data is in the cloud. There's not as much need for, you know, sophisticated technical management in our organization.
But we still recruit ourselves from the technical side of the house. We still tend to look when we look for a a security, resolution, we'd look at our technical folks to do this, and and we promote our technical folks up to the information security officer or or our our chief information security officer.
And the the thing about technical folks is, they're obviously super smart and they they understand technology, but they tend to look for technical solutions to the problem regardless of what the problem actually is. And what we've evolved to today is that, you know, close to eighty percent of of of security incidents are actually procedural rather than technical. You know, people aren't physically hacking your your AWS environment today. Right?
They may they might have been brute forcing something before. And they're using things like social engineering. They're using things like phishing scams. They're they're using things like, you know, lax password, right, and and and maintenance.
There's a lot of operational things that people are are taking advantage of to the operational lapses, which is where most security violations actually occur. Yet we still think we can solve all those problems by just implementing more and greater technology. And I think that's where some of the disconnect comes into, you know, you've got an operational leadership team looking and measuring things around ROI, looking around things with the profitability.
And then you get a technical team who are looking at things like, you know, what's the coolest tool that can implement to try and automate or or integrate a solution here. And it's very difficult for the both of them to, you know, talk in the same language.
Right. Exactly. And and one of the things that I find interesting is that often, we still put, tasks on our technical folks that they are not trained or equipped to do, like, a risk management or excuse me, risk, risk analysis of the organization.
So they might have insight into some of the risks related specifically to technology, but the entire risk process is often put on technical teams. Is that have you seen that?
All the time. I mean, I think, again, it comes to this kind of default perspective that, you know, the technology team are the ones that cannot manage security. And I don't know if you ever heard of the concept of the Peter principle. Right?
And this is not meant to be disparaging of of of of of of technical people, but I think that we see how in an organization all the time. You take someone who is really good at the job. Right? And you so you promote them because, hey.
You're so good at your job. We're gonna promote you, but you're gonna start a job. Yeah. And maybe they're good at that job as well.
Right? So if they're really good at that job, then we promote them again. You know, you're really good at that job. Right?
And we keep doing that until they're no longer good at the job. Right? So we basically promote them to a level where they can't do that job anymore. And then we keep them there.
Right?
And and and they might not even enjoy that.
There's so I I talked to a lot of technical people who the only reason that they took the the promotion was because there was also, a raise attached to it.
Exactly. We did that a lot, especially with technical people with IT folks who basically really enjoy. I've got a good friend of mine who spent many years, you know, originally, coding and built a really successful management career. He's now in his fifties, and he's taken another job now.
He's just back coding again. And he he he enjoys it immensely. It's gonna enhance first love in what we do. So we tend to take people with these kinda really, really great technical skills, who are really talented at what they do, And then we put them into management.
We put them into leadership. And that's not to say that technical people can't perform these roles. Absolutely many, many can. But it's a different skill set, and we don't we train them.
Right? We don't train them in the business language. We don't train them in the management. We just assume because they're smart technologists that they can somehow adapt.
And then we have this other as I said, it's the whole Mars and Venus thing. We have this other executive group of people that typically risen up through a different management track. Right? They're more business operational focus, and they typically tend to the ones that end up becoming the chief operations officer, the CEO.
They join boards.
And somehow these two individuals have to find a common language, and that's very, very difficult to do. Look. Security on its own is very difficult to talk about because there is no endgame. Right? Security is a is something that you have to do and and continually evolve. You've got threats and you've got ways to try and defend against those threats.
But business leaders need to have some sort of ROI. They need to have some sort of understanding or quantification. Right? And let me describe how a typical a typical business case review will go with this the system of an organization and executive team.
The system will be pitched a really, really nice new technology that's recently on the market that someone sold and was basically gonna cure world peace, hunger, and everything. Right? Mhmm. It's gonna solve it.
They also know that, but they really like it's cool tech. And then they go in and it's, like, two million dollars or three million dollars, and they put that into their budget review for that year. And the executive team or the management or the CFO looks at that and says, okay. What does that do for them?
What's gonna solve all these issues? Now when they say it's gonna solve these issues, the CFO and management team don't know the universe that you're talking about. They just know, hey. That sounds like a good history to solve these issues.
They don't know if that's one issue of a hundred or ninety nine issues of a hundred. Right? They don't understand the universe. But they understand it's expensive.
And so then they make the system will make all these promises. Well, if it's gonna do this, it must be really good. Is it gonna make us you know, it's gonna take away all our risk? Well, not all, but a lot of it.
Okay. Right. We'll invest in because you've just a huge amount, and you spend all this money from a budgeting perspective. Now the problem with that situation is the systems typically had to invest too much time and effort to persuade the higher ups that this is a valuable expenditure to make.
The higher ups think it's gonna do more than it actually does. And so when inevitably have they have some sort of security incident in a different part of the business with a different area, The executives look at the system and say, what you do, you promised us everything was gonna be good. And the system, well, I know that was just for this part of the business, and there's gonna disconnect there. So the system gets fired.
Right? Right. And so they're really talking very different things and, you know, you you mentioned it in a row and You know, we need to look at you know, the conversation needs to be a holistic risk across the business, and there has to be a common acceptance both at the executive level and at the security level. You're never gonna eradicate risk.
It's all about what is your risk appetite. So understanding how you quantify risk and then having a conversation about, okay. If I invest this amount over here, what is the net return for a reduction risk I'm gonna get? And is that enough?
And it it never is, But then there has to be an acceptance on both sides of the house that you're accepting risk.
So that when something ultimately does happen, both sides of the house ultimately feel responsibility for it.
Maybe still results in the system we've barred, I don't know. Right? But at least this is so as a more defense argument, say, look, I didn't say I was getting ready to get a hundred percent of risk. Mhmm. I just told you, it's a really good to to and it's made of the day I didn't eradicate five percent of risk.
Right. And and so this is a this is a conversation I have almost every week with people because there will be, some super on fire IT or security guy, which are great. You want these people in your organization, but saying, you know, I've been raising the red flag. This is problems and nobody's listening and I can't get the budget for this. And and, my answer typically is, alright.
How are you presenting an understanding of the risks that you believe need to be addressed right now? And second is you need to know that you are not the one responsible for making the decision. You're responsible for, presenting the issue. You're also probably responsible for for coming up with more than one answer that could serve. So is it a tool? Is it people? Is it a change of processes?
But you need to be able to present different options.
And then and then there are other people whose job it is to be responsible for the decision that is made. And so those those conversations on who who quantifies the risk and then who makes the decision on the risk, a lot of it comes down to, you know, they're they're siloed when they actually come up with the risk register in the first place. So so here here they are, okay, who's coming up with the risk? Well, who are the people in the room?
And have the conversations happened that help level set what the risk really is? A lot of times that isn't happening when there is that vast disconnect in between the people who believe there's a huge risk and the people who are maybe going to come up with the funds to address the risk. This episode is brought to you by our security metrics penetration testing team. They do a lot of pen tests.
They do a lot like network layer, application layer, segmentation checks. They're very, very knowledgeable and, some of them have even won, like, competitions at Defcon. So you can rely on these guys to know what they're doing. Head over to www.securitymetrics.com/penetration-testing, learn more about pen testing.
Yeah. Look. Risk management is super hard. Yeah. And I think let's cut out there. Right?
I would probably say that most of the organization I speak to, two or three percent of them effectively do risk management. Probably eighty percent of them do risk assessment, in some sort of form, and, you know, we'll we'll talk about whether they do that well or not.
But, you know, the vast majority of the organization I speak to do risk assessment. They don't do risk management. And what I mean by that is that we can assess risk, you know, you know, I'll I'll be amazed how oftentimes I'll see an IT department build a a risk register, which is a list of assets. Mhmm.
And then you can try and have a list of risks against those assets. Well, I don't know how you can even assign a risk to an asset. Right? An asset is just a thing.
Yeah.
Right? Exactly.
What is the impact that that asset's gonna have? Right? So, you know, we have to assess, risk scenarios more than, you know Mhmm. Ask those of the scenarios.
And then, you know you know, risk itself is not just a single thing. You have to look at the what is the impact if something goes wrong? Balance against the likelihood if something goes wrong. Right?
So, you know, let's take something really all this right. If we think about the risk of a natural event like a like an earthquake.
Clearly, if you have an earthquake in an environment, it it can be devastating to your organization. Right? But if you're living in Virginia like I do, the risk of an earthquake or a category, you know, five is is is is pretty low. Right? And so how much time and investment should I be investing on securing my infrastructure, securing my facilities, securing my backup specifically for that risk? Because, sure, the impact can be catastrophic, but the likelihood of it is super, super, super low. Right?
Different if I'm living in California or if I'm living somewhere that's proven, then I might have a slightly different calculus. I might want to say to invest a little bit more. And then you start looking at mitigations. Now that's just one environment.
Right? Or what so one scenario. But then I have to spread that scenario across the rest of my people, the rest of my assets, the rest of my finances, the rest of my business. And all of a sudden, you start seeing that, like, when you look at a typical organization that probably has thousands of assets, hundreds, if not, thousands of people, and you only different scenarios we talk about in terms of, like, you know, environmental impacts, physical impacts, security or or cyber impacts, you certainly realize that any organization is actually dealing with tens of thousands, maybe not hundreds of thousands of risk scenarios in order to do this properly.
You can't do this by simply giving you a list of your assets and trying to have it and you're asking right. Now that's hard. You can't do it. You need a tool.
You need some sort of platform, some sort of capability to basically do this properly and assign it. But then, ultimately, what you can do is you can start getting to an aggregate an aggregate risk view that gives you data that allows both sides of the fence to start talking, okay. What does this data mean? How do we interrogate this data more?
And how do we go about trying to what are the ways that we can build risk mitigations in to try and look at where we have the biggest risk areas? And it's a constant evolution and a constant review. And you notice I've not once talked about some form of cyber tool, some form of malware device. They're all just mitigations.
They're all potential mitigations, that maybe go towards mitigating some form of risk rather than, hey. I've just bought this tool because this tool is gonna do x. This tool has to apply some sort of value to your risk mitigation strategy.
Right. And so, I I think that's why it's so important not to limit risk, the whole concept of that risk assessment to your IT team. Because that's when you get that, asset based risk response instead of having the the risk scenarios that come up from the larger conversation.
And so having peep having that that balanced conversation from the business and technical side of the house, I think, is where you really get the value in that risk assessment.
Yeah. No. Completely. And I well, especially in your bit of mind, as you said, direct you know, obviously, you have a big component of what you're doing in terms of IT risk.
You've got socially social risk. You get environmental risk. You've got all sort of different risks in the organization, but may or may not be more impactful to your business. You know, the challenge we have today as well is that, you know, we've evolved quite significantly from an environment where we you used to have this castle in more sort of protection Mhmm.
And talent.
We we could secure our data because we kept it inside the perimeter. And as long as we secured the perimeter effectively, then we could theoretically secure the data, keep the bad guys out and, you know, and we're good. And then make sure that the people inside the the castle, right, are, again, trusted people that are within the site. Well, guess what's happened in the last few years. Right?
With the advent and the cloud, you know, the vast majority of data is not within our our castle. Right? And we're using all these third party cloud tools. We hosted AWS or Azure, and we used at least third party collaboration tools. The finance package we use is a cloud based package. Right?
Our data is literally everywhere, and the vast majority of that is even if we have a lot of it, is either duplicated or stored elsewhere. Mhmm. Well, so the evolution of protection was, well, we know where our people are, so let's secure it based on where people that secure access. Right?
So we go to access control. Right? Well, guess what? Since COVID, we don't even know where people are.
Exactly.
All over the place. Right? So we can't even relocate our Jira source, right, and and and and then the ways to basically secure our people as well. Yeah.
So the only way that we can start thinking about how we protect data is to be, like, to actually think with data itself. Right? Where is the data? Who has access to the data?
And how do you protect the data from that perspective? And then not all data is equal. Right? There's some data that take way more than other data, so you have to wait that data as well.
And that whole comes into the whole concept. So you start realizing, again, the entire language I'm using here, none of it is technical. None of it is the software development. None of it is tools and technology.
It's all just organizing a business problem.
Right.
And that's business people do really, really well. And it's not to say that technical people can't do that, but I can tell you right now the answer for a daily technologies is gonna be there has to be a tool that does that. And I can tell you that does that. And the reality is tools and technology can definitely help you, but they are themselves not gonna be the, the single solution.
Yeah. Absolutely. And I think on on, something you said earlier struck me, which was the the, security is an ongoing thing. It's not just a a single thing.
But sometimes we wanna wrap it up in a package and go, look, I did this thing. You can't fire me because I did I I proved that we were good. And and so people will often use compliance in that way. And I'm not saying compliance is is a bad thing.
I think compliance can really help lift security. It because it it creates those conversations and helps people look at the different, layers of defense that are related to whatever that compliance is geared towards protecting, whether it's a specific type of data or whether it's, systems themselves. So so, but but just doing a one and done compliance, that's not the way to go. You've gotta look at, like you were saying, what are the operational processes that support security?
But how do you think maybe, maybe compliance can fit into that?
So I think that I think the problem for me is that people think about compliance the wrong way. Right? Compliance, Security can can exist without compliance. Compliance can't exist without security.
Right? And what I mean by that is that the whole point of compliance, right, is you're trying to determine as an organization operating against a particular security standard. Mhmm. Right?
Then there's lots of standards out there. Right?
Yeah. Sure.
I we, you know, our regular adviser. I it's less important what standard you're picking, whether you pick a standard. Right? Yeah. And, you know, the standard you're probably gonna pick is not gonna be the same, but you're just gonna be the same with your client, So your customers are whoever, they're gonna tell you what standard they want you to use.
Being compliant is usually basically taking a point in time measure that says, yeah. I'm operating against the standard that we determine is the standard that we want to measure ourselves against. And and but compliance somehow has evolved to its own thing. It's almost evolved to be like, let you know, compliance is the thing. Compliance is is basically doesn't exist without the security standards.
Absolutely. Mhmm.
I think that's also evolved in the industry. Now you see a lot of, organizations out today offering automated compliance, for example. Right? And and I kinda think that's like an oxymoron in terms of the fact that the whole point of compliance is to verify that a lot of your technology and a lot of your processes are doing what they say you do.
Right. You can't automate compliance. You just create another point of failure when you automate. It's not can't use tools to automate collection of data and collection of evidence and simplify but, you know, this whole concept about putting compliance on autopilot Mhmm.
Is just ridiculous. Anyone who can advise into that really is gonna show in their kinda immaturity in terms of the kinda security journey they're actually on. And so the idea is, by all means, I think it's really important that organizations seek some sort of third party independent review of a security program because I do enough, independent assessments of organizations.
And, you know, people want to be correct. Right?
People that self certify will are always gonna give them some They're always gonna get all the answers right.
Mhmm. Yep.
And you talk to any auditor, a big part of, you know, their conversation with the clients always is the client says and what really? I really need to do that much in order to yeah. That's the standard that you've signed up to. There's a reason why you need to do it to this extent.
Right? We talk a lot about, the whole concept of what really compliance is and, you know, different standards of a more specific or explicit, determination depending on the standard itself. But for the most part, it's about, you know, basically saying what you do and then doing what you say. Alright?
That's the whole concept of what you're trying to do. Yep. And what happens with a lot of organizations and what happens is especially with a lot of technologies or IT folks is, you know, they've been trained from an early age that, look, I need I know I need to encrypt my database. Right?
I know that I need to probably have some sort of endpoint protection. I know that I have malware protection. They cannot come in with this kind of default perspective of things they need to do that they've heard or someone's telling them they have to do, and they go and build all these technologies.
But step one actually has to be you have to write down what is your intending to do. Right? When you decide to use AWS and your hosting environment, what you don't realize is without even thinking about it, you're already predetermining a whole bunch of policies that you're you're you're writing down here without even really thinking about. It.
You're realizing that quality needs to be physically secure. It needs to be safe from farm water, and needs to present physical access. It needs to be have have have continual uptime. You sort of know that AWS is gonna give you all those things.
Right. Right? And so you're intuitively just making that decision, but you're not writing it down. Mhmm.
And what I know it wants you to do is just, well, why did you choose AWS? Well, because I want, you know, ninety nine point nine nine percent uptake. Right? I want to make sure we get fired for that.
You have to just determine right those things down. And then when the audience comes in, he says, okay. Let me look at your your production hosting environment. Does it do all these things?
Does it fireproof protection? Whatever. It does great. Now you've met that standard simply by the moment you chose to go with AWS, but but you haven't written down the reason or rationale why you've done it.
And that's gonna work on organizations and I'm feeling the security of it.
Yes. And and I I've seen that I mean, I just before I got on this call with you, I got off of a call with some a team of IT and security guys who were kind of sour on the whole concept of PCI, which, of course, is the the credit card security standard. And and they they wanted some, assistance in making sure that they were using the right compliance report. And I said, okay.
Well, let's talk about your scope and that's all determined by how data flows in your systems. Suddenly, they started getting interested in it because I said, I'm not even gonna talk to you about the compliance standard until we first start talking about, do you know where information is? Do you know your systems? And do you know how you're securing them?
Because if you're not secure, we're not even going to start talking about the compliance standard. And when they realized, oh, this is about security which they were interested in and the compliance was just demonstrating that, it turned around the entire conversation into an interesting puzzle rather than, something that some check boxes that they had to check off. And, it wasn't making sense to them originally because someone had told them, you need to assess against this, the set of of questions when that wasn't even the scope that they had. So, of course, there's gonna be frustrations if you if you if you don't take into account what's the underlying purpose of whatever compliance or regulatory standard we're looking at.
If you don't know why it it was created in the first place, it's it makes it very hard to to, to compare it against the security, program that you have in place and understand how to speak to the compliance standard that there's a lot of guys out there who are doing great and and girls, guys, you know, general people who are doing really great work in in the security space who once they understand the the purpose of the compliance that they're trying to attest against, then they start getting interested in it. Because then they can show off, look at the good work that I'm doing. And and and, really bring value to the efforts that are already in place and just demonstrating that, proving that they're that they're doing it using that compliance.
Yeah. And and, you know, if we have given this talk a few times about operational versus technical security, sometimes they've been accused of being up on the technical folks. And, actually, I think to your point, it's exactly the opposite. Right?
This is a way to demonstrate the value of what they do and the value of the protection they provide. Right? Actually, a lot of our customers tend to be, you know, technology cloud providers. Right?
You know, a lot of those organizations, as I mentioned, that we don't have a lot of data they have to protect. And you have a conversation with their team, and they get very defensive. Right? And and rightly so because they've built probably a really good tech stack.
Right? They've they've done a lot of the things the right way as I said. Because I think, you know, most most people go through college, most people are trained in this issue. You know, security technical security is built into the a lot of the training.
So they know natively what they need to do. The challenge is that when you look at compliance, compliance is, again, is about, you know, you know, see what you do and then do what you say. Eighty to eighty five percent of a compliance order is administered. Right?
I mean, it's not about coming in and assessing. Right? There's things like pain tests and stuff like that when they assess the technical capability of your environment. But most of your audit is basically have you documented the rationale and the reasons for why you do things, how you define how you you know, things like how are you giving access, how you do change control.
All of these things are all procedural. Mhmm. And that's always the kind of part that can really shock people. It's like, you may think, well, I can just go and buy a technology server.
Again, go back to these, you know, automated compliance tools.
They're still not providing that procedure. And, you know, I came to this because, you know, in my previous organization, I was both the chief operations officer and the chief information security officer. I wasn't the CI the the the the the CTO and the system, I was the chief operations. I've always been very operational in the way I look at things.
Mhmm. And so I was looking for a way to implement an operational security program. And even our platform that we have in in my company, even though that we get labeled into this kind of GRC space, government system, We always say we're not actually really a GRC. The problem with GRC tools is that these kinda, like, inefficient tools that sit on the side of your organization that people have to spend extra hours updating or feeding information to, and they're kinda really glorified reporting repositories.
Right?
What I was interested in building was a security operations platform, a platform that's used every single day by people across the organization. So the data that you're collecting and managing is actually real time ongoing data. And we just and as we build this out and we use this platform as a security management platform, the great thing is we're just naturally creating this amazing byproduct called compliance data Mhmm. Which is all the evidence that, yeah, you are responding to those tickets.
You are managing that change control. You are onboarding that individual or offboarding that individual correctly. People are taking training. Right?
All these things that you have to demonstrate you do as I keep them back to this, see what you do and do what you say. We help these organizations build out to say what you do, and then our platform helps them track that they're actually doing what they say, which is the element of the whole concept of compliance is to make sure that people are operating the way they're supposed to be operating.
So that that is, I I think, a a really good summary of of how to to put operational, aspects of security first. And and, it it brings to mind so I was on on an audit the other day where I had to look at onboarding and offboarding, what that process was. And the IT team talked to them about it, and they they were kinda bored by the question because they're like, well, we we we put them into, you know, this access management program and, you know, this is how we sign them up and this is how we take them out. Okay.
Well, how do you how do you know that you're supposed to put them in there? And how do you know that you're supposed to take them out? And then when I got, the HR team on the phone, I said to them, how do you get verification that they have put these people in properly? And how do you get verification that they have taken them out again?
What's the communication there? So that process of communication, they had not even considered that that was part of a really actually, the probably the most important part of how you manage access in an organization.
This is this is this is a great example of the rhythm we're talking about. About exactly that. So an organization has one login or they have an Okta. They wanted these kind of, you know, access management tools. And and and I've asked people this bill, do you really want Fred, right, who's your engineer who manages your Okta environment, being the one who's making the decisions over what level of access privilege everyone within the organization is gonna have. Right?
No. Because what how do you learn? Well, we create a ticket in Jira. Right? And it goes to Fred, and it basically outlines in some sort format all these different things.
Okay. Now so now Fred has to basically make sure that all these different things. So that means you now want your HR director to be the one who's saying who is responsible for everything within well, no HR director doesn't know who should have access to the CRM or who should have access to the production data. Mhmm.
So how do you so right now, that's the only two people involved in the onboarding. Right? So how does the manager get involved in that? And you think this is complex when you're actually onboarding someone.
Right? The great thing about onboarding is when something goes wrong, you a new really enthusiastic employee put their hand up and basically saying, I don't have access to x. I don't have access to y. And, of course, their manager jumping up and down why there wasn't provisioned.
But when that employee leaves, there's no one putting their hand up. Uh-huh. Right? Yeah. And so it's not just a question about basically having that process that allows you to track and manage.
Right? Mhmm. The onboard process with appropriate approvals and the appropriate authority.
Now you have to off board that user. How many things did it happen in an organization? They they can't even remember what systems just removing them from their SSO capability. People think that just because the switch will hold up.
Well, how many systems actually sit outside of Optum? Yeah. Right? If not, everything says and even if you just remove them with it, you've not actually removed them from the core system.
Right? So you're gonna have to still you're still paying for a user account within your CRM system. Just because you switched off access to the alter doesn't mean to say and look, there's a lot of these tools today as well that that whilst you can control some level of access from your SSO, there's still backdoor user ID password access. Mhmm.
And so when that individual leaves the organization when I left the previous organization before, there's a cloud based tool called DNS Made Easy. And DNS Made Easy, for those out there that that don't know, is a tool that basically manages all the domains within our organization. So, you know, all your your dot coms, all your dot nets, etcetera, within your entire environment. So it literally controls access to every single system that you have within the the organization.
I when I left, they did not switch off my admin access to that for two years.
Oh my goodness.
I could have literally logged in. That's what she was doing at any point I wanted, and I had a lot of fun.
Right. You could've well, you could've taken them down. Yeah.
And then every traffic, right, to these different things. And so it shows you just how important it really is. There's there's cases and cases and cases of ex employees that leave an organization who are then able to do something. Because oftentimes, employees aren't always leaving in the best grace. Right?
That's right.
And so okay. It's motivated. And, you know, as I say to some, some some people, if you have an if you have an employee that works for you and you've trained them effectively, you've given them policy and procedures, you've told them what the job is, and they make a decision, for example, you're just gonna take all your production data and dump it on the web.
Sure. You're gonna be liable on the hook for some of that degree, but it's mitigated by the fact you can demonstrate, look. They knew they weren't supposed to do that. You know, they had access for their job. They were trained. This is just a disgruntled employee that's behaving in a way that's unreasonable. And that will form some level of defense within a court of law and regulators.
And so as long as before the Friday afternoon you sack them, that's when they do it. You get some defense.
They do that in Monday morning after you fired them and walked them off sale on the Friday.
Yeah.
It's on you.
Exactly.
Right? It's all on you. Mhmm. And, again, I want to just point out is we keep saying none of this is technical.
Yeah. This is It's all operational.
And it's about trying to manage those operational workflows and those automated. You know, the other one that I love is the background check one. Right? So that you see some of these tools today that talk about doing automated background checks.
Now to this day, I never understand what automated background check is because if you've used these background check companies, you realize how frustrating it can be because they're only gonna call an employer up three times before they basically give up. They're only gonna call an education establishment three times before they give up. Right? So whenever you do any of these background check within these third party organizations Mhmm.
You're not always supposed to define, you know, how many employers, how many, how many educational establishments, how many certifications, how far back, all this stuff. You have to define this in your policy, what you're supposed to need. Does this does this employee have to have the back project complete before they start or after the start, before they've accessed the system data after right? All of these things are things you have to find as a policy within your organization.
Mhmm. None of that's what the background check company, that's just to do with your policy. And then you basically give it to the background check company and they said they have all these issues. And no background check, in my mind, ever comes back clean.
There might be issues, but someone can't be contacted. Some telephone number is wrong. Right? How do you simplify that down to checkbox?
Right? And you look at some of these automating tools out there that claim, hey. We automate the background check for you. We'll give you those one as part of your compliance project.
We and you look at it as a checkbox. And they're trying to say binary, a background check was done or a background check was it's just not that simple. Right? Oh, you know, you can it's very difficult to try and minimize this down to technology or to tool or to an IT solution.
This is about a combination of tools. But, again, eighty percent, eighty five percent process, and over fifteen percent technology.
Right. And kind of along the same topic of access, where you said, well, when does the manager get involved? Who who decides what level of access?
That's, I think, where a lot of value comes in. Those conversations internally, here's a role. What is this role supposed to access? And and who decides that? Let's let's talk about what are what are the operational needs that create these operational accesses.
And and that's not something that I often see that level of thought put into it. You know, another thing that I that I ask is if if you if somebody set up an an account with, elevated privileges let's say you have somebody who's an admin who who can set up another admin, and he does.
And, who knows that this new account got set up? Yeah. Like, what's what is what happens then?
You know?
Well and then so so so, again, the way our platform handles that right now is platform handles that right now is not just the on onboarding, offboarding, but we create a cadence. You get to set up a cadence that allows you to do what we call data access audits. Right? So the work around the system, every depending in the severity level of the of the of the the the the technology of what the data is managing. Every month every quarter has to go and review. Right?
Yeah.
So our part is showing exactly who's supposed to have access and they can review that with who actually has access to to that exact point because things change all the time.
The other thing that changes, I think, is really interesting is, you know, as as you mature or as you grow or as you change as an organization, things are dynamically changing at that point as well. Right? So, for example, we say to a lot of smaller organizations to your point of access, you know, if you're an organization of ten people, as long as you write in your policy that all ten people need admin access because of the nature of the job, you're a small organization. You get away with that.
Right? You can probably get away with all ten people in the organization saying you need access to that. When you're a thousand person organization, you can't do that. No.
You can't see thousand people. So now you're starting down to this concept. Okay. Right. You know, what job roles, what job titles, what levels, etcetera.
You have to start getting far more granular about access level, access rates, and access privileges, and you have to define that in order. And, again, this is all process. This is all procedure. The technology is what you switch on and off based on the policy and procedure, and the technology makes a lot of these things a lot easier Mhmm.
Than they ever have, but you still have to have a policy and procedure. The simplest one I like to give in this one just in terms of the way technologies evolved is, like, laptops. Right? I remember I'm old enough to remember ten, fifteen years ago, if you had sensitive data on a laptop, you had to implement a third party encryption capability on the platform.
Right? I did buy it Microsoft so that it wasn't cheap. Right. You pay on a third device perspective.
Every laptop today comes automatically with encryption. Mhmm. You don't even have you just have to make sure it's switched on and you get someone managing it. So technology has made things easier and easier, and it's not that important.
It's just that the tools and capabilities of technology have shrunk the impact. Mhmm. Right? The percentage of your overall program to the point that that most of your challenges today are managing the technologies and procedure and administrative.
And to the beginning thesis of the of the conversation, this is why, the conversation gets broken between the executives and the IT organization because the IT organization are always talking about tools, always talking about technology, always talking about third party devices. They're not talking about process.
Right.
And then they they we have to start setting targets around. We're gonna use this framework that we're gonna measure ourselves. We have to have this percentage of uptime and availability. Right? We have to this percent update a loss. You have to set these procedural targets from an operational perspective, and that's gonna lessen the the evolution of the IT, a manager has to make.
So for groups that currently have that fracture that we were talking about, from the beginning, is that is that where you would have them start? Is looking at what are their operational targets? What where would you have people begin who currently don't have good communication between technology and and the operational side of the house, who don't where cybersecurity is not integrated with operations?
So I think you have to teach your IT people to be more operational. You have to kind of find the ones that are. Right? To put the point in the beginning, who wants to be.
Right? Don't take Peter, who who really just loves coding, and then make him in charge of everyone because he's a good coder. Right? Good coders don't necessarily make good managers.
Right? It's not to say that they don'ts. Right? But, you know, being good at coding doesn't automatically so you have to train your staff.
Right? You have to train them in management. You have to train them in in with the ability to do things that are why. You have to chain train them on, you know, the importance of processes.
So that's gonna, you know, that's the kind of evolution they have to make. Or what you can do is you can actually put, you know, instead of basically putting your CTO in charge of the security program, put your chief operations officer in charge of your security program. Right? Mhmm.
And how to make this manage the CTO from that perspective as well. To operational people in charge of an operational problem. Right? Actually and and I think the executive team have to think of security as an operational challenge, not a technical challenge.
Technology is part of it. Right? It's not all of it. You have to think about security and risk management as being operational nature, not technical in nature.
I think I might steal that phrase, put operational people in charge of operational problems. Love it. That is, excellent advice. And it's been I really appreciated the conversation today. If people wanna learn more about this idea or or connect with you, where where is the best place for them to go?
Sure. So they can go to our website, which is ostendio dot com. That's o s t e n d I o dot com. Or feel free to email me at at grant at ostendio dot com.
Great. Thanks, Grant. Good to talk to you.
You too, sir. Take care.
Bye bye. Thanks for watching. To watch more episodes of Security Metrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
