Security Market Watch
SMW # 9 - Transforming Compliance into a Business Enabler Ft. Ethan Altman, Anecdotes
What if you could reverse the high costs of expanding your Governance, Risk, and Compliance (GRC) program? What if compliance could become a business enabler, not an expensive obligation? This week on Security Market Watch, we've got Ethan Altmann from Anecdotes to shed some light. We explore the complexities that come with global business expansion, the burgeoning expense and how innovative tools like Anecdotes can streamline processes - transforming compliance from a burdensome cost into a value-add for your enterprise.
Security and compliance teams often operate in silos, but pairing them can unlock a world of potential. Ethan guides us through the dynamics of this partnership, the challenges it presents, and the rewarding outcomes of a collaborative approach. We also uncover how AI is revolutionizing the GRC space and how it can bridge the gap between these two key teams. Also on the agenda is the increasingly popular NIST CSF framework, its benefits for continuous control monitoring, and the growing demand for risk quantification support.
We wrap up our chat by focusing on risk and vulnerabilities. Global business decisions can have a significant impact on these, and Ethan emphasizes the need for a comprehensive perspective to assess risk. He introduces us to tools such as risk registers and highlights the OWASP's top 10 threats. We also discuss the upcoming NIST CSF 2.0 framework, and how it can help organizations monitor their controls more effectively. Lastly, we stress the importance of uniform risk language within an organization and how vital training is for risk mitigation. Join us for an enlightening discussion, we promise you won't leave without some valuable insights.
What if you could reverse the high costs of expanding your Governance, Risk, and Compliance (GRC) program? What if compliance could become a business enabler, not an expensive obligation? This week on Security Market Watch, we've got Ethan Altmann from Anecdotes to shed some light. We explore the complexities that come with global business expansion, the burgeoning expense and how innovative tools like Anecdotes can streamline processes - transforming compliance from a burdensome cost into a value-add for your enterprise.
Security and compliance teams often operate in silos, but pairing them can unlock a world of potential. Ethan guides us through the dynamics of this partnership, the challenges it presents, and the rewarding outcomes of a collaborative approach. We also uncover how AI is revolutionizing the GRC space and how it can bridge the gap between these two key teams. Also on the agenda is the increasingly popular NIST CSF framework, its benefits for continuous control monitoring, and the growing demand for risk quantification support.
We wrap up our chat by focusing on risk and vulnerabilities. Global business decisions can have a significant impact on these, and Ethan emphasizes the need for a comprehensive perspective to assess risk. He introduces us to tools such as risk registers and highlights the OWASP's top 10 threats. We also discuss the upcoming NIST CSF 2.0 framework, and how it can help organizations monitor their controls more effectively. Lastly, we stress the importance of uniform risk language within an organization and how vital training is for risk mitigation. Join us for an enlightening discussion, we promise you won't leave without some valuable insights.
Welcome to this episode of Security Market Watch. I'm your host, Josh Bruning, and I'm here today with Maggie Dillon and our guest, Ethan Altman. Ethan is the compliance product owner over at Anecdotes. Ethan, welcome to the show. Can you give us a little bit of background and tell us a little bit about Anecdotes?
Speaker 2:Sure, absolutely so. Anecdotes was founded a little bit over three years ago. We're based out of Tel Aviv and Israel, also with offices over here in the States, where I am right now, and really we aim to help organizations automate their entire kind of all of their GRC processes, be that passing audits, be that really moving into the realm of data-powered risk management. Recently we've really pushed into that direction and really we're aim is to remain at the cutting edge of tech and data-powered GRC, being that, in my opinion, it's probably kind of the straggler in the cybersecurity world when it comes to staying at the forefront of tech. That's really where we operate.
Speaker 1:Maggie, what's new in your world? Do you have anything to say?
Speaker 3:I have a lot of questions already out the gate, but I guess the first one that I wanted to ask you about we're seeing a lot of fiscal year end coming through with companies. I'm already getting asked kind of what I'm seeing in the market. So I'm going to turn that question on you, ethan, with maybe current customers that you're seeing you're doing a lot of these audits. What are some of the biggest challenges for your current clients? Could you just maybe even give us a case study or something to that magnitude?
Speaker 2:That's an interesting question. I think more and more this isn't so much this year, but here's a kind of more over the past few years with some of our larger clients is naturally in a globalized world you want to work with more and more customers and gain more and more customers across the world, and naturally that exposes you to broader regulations, compliance obligations and things like that, and therefore organizations that previously would have been perfectly happy with just having ISO 27001 certification or a SOC2 type 2 report now find themselves thinking I need 10 different things If I want to have to service all these markets, I need 10 different things, and more and more organizations seem to be realizing that their GRC program is going to need to expand significantly. So that's really what I understand.
Speaker 3:And as far as the hiring needs, for maybe, like a chief compliance officer or CSOs of that magnitude, are you seeing customers wanting to bring maybe just a little bit more subject matter experts to the table as you're performing some of these projects?
Speaker 2:Absolutely. I mean, before I was an anecdote I was a GRC consultant and the number of you know, V-CISOs, csos, the service, whatever you want to call it, the number of those kinds of customers that we were starting to see was really rapidly growing and I have no doubt that's continued and undoubtedly for the larger organizations that won't be consultancy based, that will be they're looking for in-house CSO and growing. You know we're seeing more and more titles coming in. You know, obviously compliance managers have been around a long time but you know, security compliance engineers, more and more technical people moving into the GRC realm as well.
Speaker 3:Absolutely.
Speaker 1:Are you seeing customers spending more money on compliance, or is the trend to cut as much as possible over time?
Speaker 2:I would definitely say spend more money. I don't think there's any question there. And ultimately it's an interesting question because on the one hand, you look at the market we're in right now, when everyone's looking to cut costs, but on the other hand, compliance, done effectively, it's supposed to be a business enabler. So where it's a business enabler it's you know you're going to need to spend money in order to enable that business. So I suppose it's kind of what comes first, the chicken or the egg thing with cutting costs, versus you don't want to cut costs from compliance if it comes at the expense of enabling further business.
Speaker 2:And that's why I don't sit on any boards and make those decisions? Yeah, because they seem like very hard decisions to make it is.
Speaker 1:It is very hard, and especially if you're a vendor and you're looking to make to add value to your product and add value to the market through innovation. Yes, you want to sell more software, but the value proposition is you don't want to have, you know, a million pieces of software doing a million things. You want one piece of software that's going to do as much as it possibly can. We see a rise in integrations. You know everything has to be pretty much integrated, which is aimed at cutting costs, really right? So you would think, over time, as innovation grows and as these companies tailor their offerings to their market, you would think that the aim would be for customers to, you know, cut costs and to become more efficient and to spend less. But do you attribute that rise every year over year in cost to just the threats that are out there, or is it due to complexity? Why do you think that, over time, companies are spending more on compliance rather than you know? Why is the? Why is the spending outstripping the efficiency?
Speaker 2:So well, I think saying that the spending outstrips the efficiency might be the case in an inefficient compliance program.
Speaker 2:The hope is and here I'll plug anecdotes for the first time that if you, you know, if, you have a tool like anecdote, then you put, you turn that on its head, the logic being, like you said, you find yourself spending more and more money because there are more threats out there, your compliance obligations are more complex, your tech stack is more complex and therefore, as a combination of all of those things, your ability to monitor your current you know compliance posture becomes increasingly challenging, borderline, impossible.
Speaker 2:So they know, if I, if I think of the most simple ROI, you know calculation I could do I could say, okay, anecdotes costs you X.
Speaker 2:And then if I say to you, you know, if I take the most basic you know core functionality of anecdotes we integrate with your entire tech stack and we consistently collect evidence and analyze it, you know, for all of your different compliance frameworks. If I say to you that twice a year to four times a year some organizations do it more frequently you have to reach out to all the stakeholders in your organization who own the various products within your tech stack and ask them for evidence and have them send over configurations and screenshots of configurations and things like that to you. The amount of time that that takes and the amount of friction that that causes with your within your organization, you could quantify quite easily. You know how much do you pay these people per hour, how many hours are spent on doing this, and once you get that number, you compare that to the X you spend on anecdotes and my guess it's going to be X times 3, 4, 5, whatever it may be. That's the simple ROI calculation that you could do.
Speaker 1:So if I were to recap and summarize what you're saying, it seems like companies are becoming more dense as innovation increases, so the value becomes more concentrated. So you have the ability to. The idea is, if security is going well, the company is more profitable. They can spend, you know. Their tech stack becomes more complex, their business needs become more complex For innovations like innovative technologies, like anecdotes, you are stripping, you know. Pardon the expression, but stripping the fat and really getting down to what's important. Is that a good summary?
Speaker 2:Yeah, I would say absolutely, but it's more than stripping the fat, because stripping the fat implies you had access to the full body in the first place. But the first problem is you can't even access the full body in the first place. You know the ability to reach those stakeholders. That's the first problem you're going to encounter. How do I, as a CSO, grc manager, compliance manager, whoever I am how am I getting you know the configurations from AWS for my production environment? No, that's something that I'm almost certainly. Well, not almost certainly, but a lot of organizations.
Speaker 2:I'm not going to have access to that, but I need to not be able to make changes there, but I do need to be able to monitor it, to know that I am continuously in compliance with all of my various obligations.
Speaker 2:And in most organizations today I can't do that. But you know, if I have a certain tool in place that enables me to do that, then not only am I going to have a much easier time come audit time, because I'm going to have everything ready. I'm also not going to have be sitting there nervous thinking are the screenshots that I'm about to receive going to dam me in front of the auditor? You know, are they actually going to be what I'm expecting to see? Are they going to be good? You know, I already know in advance exactly what's going on and I'm continuously monitoring it through the year. So I suppose what I'm saying here is you know, the programs are becoming much more dense and therefore the ability having the ability to unpack them and analyze them continuously is that much more important. Because if you try and unpack them once a year come audit season, or twice a year, whatever it may be, you're going to you're going to struggle.
Speaker 1:With great visibility comes great responsibility, that's terrible.
Speaker 2:Oh God, All right.
Speaker 3:So I have a question. I'm going to go back to something you just said there. How could companies do a better job of giving you that information so you're not spinning your wheels waiting to get access to the full body, so to speak? You know, some companies can only afford to hire a fractional CCO. Not everyone has access to exactly what you're talking about and there is so much time that's wasted trying to gather data to really trim fat. You know everything that we're talking about here. How could companies do a better job for someone like you to come in and streamline this process for audits and whatnot?
Speaker 2:You simply you come, sorry to say it you cut the human element. You know you create a integration between two products one product that the compliance team uses and the other products, which is the entire organization's tech stack. And by doing that, you know you have a one time friction and I put friction there and inverted commas because some organizations it will be in order to set that up in the first place. You know to perform some kind of technical integration. But once you've done that, you're done, and then you have the data that you need on demand and you no longer have to go, you know, chasing up stakeholders that you know they're European in the, in the, who are for them.
Speaker 3:Definitely Well, and I want to switch gears a little bit. You've got such a lovely accent. I know you have a lot of international experience. We're dealing we're dealing with a lot of people here in the United States that are wanting to expand internationally and there's a lot of compliance regulations that can be very intimidating when they're wanting to expand, you know, all over the world. What advice would you give? Obviously, that was a great response and I appreciate that that was a very direct response, saying the human element and that's not going to be everyone's favorite thing to hear, quite honestly but understanding that. How do we take, if we're going to eliminate a human element, human element there, how can we then bring other people on board to expand internationally? Because there are some things you will need humans for.
Speaker 2:Oh no, absolutely. If we stick really within my remit, which is security, compliance and even some elements of privacy, if we begin to compare CCPA or CPR8, gdpr, for example, and you're going to need specialists involved. But at the end of the day and this is really something that I spend a lot of time doing in my day to day you take all of these different regulations, all of these different frameworks. There's definitely regulations that can be standards, whatever they are, and the delta between them is not that significant most of the time. So what you really need to be able to understand is just take a basic example if right now, I undergo some kind of ISO 27001 certification every year and next year I want to do a SOC2 type 2 report, what's the delta? What am I missing? What's the gap I need in order to get there? That would be an example of what you just said, where I'm used to working predominantly in Europe, but I really want to begin serving customers in the US.
Speaker 2:Let's say I'm a SaaS product. I'm going to need that SOC2 type 2 report, bridging that gap and discovering where the delta is. I hate to say it, there are products out there like ours, but that's exactly what we specialize in. So I'm going to be talking to you at the end of the day in order to satisfy these controls and those controls, in an audit, you are actually providing, let's say, 100 different evidence artifacts. Well, actually, the hundreds you used here, 95 of them you can use here and there are only 15 more that you're going to need in order to complete the pie over here in your SOC2. The knowledge that's needed to do that is something that again lives within these products and also lives within in lots of consultants. If we bring back the human element, lots of consultants are now to do that as well.
Speaker 1:Where do you guys stand in the development life cycle after a compliance? Do you or I was going to say the development life cycle? Let me rephrase that question when do you stand after a compliance? So the customer? You're in the tech stack, you understand and the customer understands where they need to be compliant. You have full visibility, you've got all the evidence for the auditor. There are some things that you need to do and some controls that you need to remediate. Does anecdotes do any of the remediation or are you just providing visibility and sticking to the G, the R and the C?
Speaker 2:That's a great question and we take a very specific approach towards that.
Speaker 2:And I think there's a broader question here, which is what's the relationship between security and compliance teams? Because, ultimately, if I'm a compliance professional looking to gather evidence, artifacts towards an audit and to continuously monitor my compliance, I need to have that visibility. Is my security team going to want to give me access, right access, as in W R I T access in all of these production environments? The answer in most organizations is going to be no, unfortunately, and therefore we take the path of when we develop integrations, we're asking for read-only access, very professional in terms of principle of lease privilege, and only asking for the things that we need in order to gather the data so that security teams stay happy and they don't see the compliance team as a burden or, even worse than that, a risk. So we really stay there and we're collecting the data and analyzing the data so we're able to serve up on a plate to the compliance team.
Speaker 2:This is what needs to be remediated, but then we'll give you the tools to go and use your existing workflows to initiate that remediation process. That might be opening tickets on JIRA tickets or all kinds of ticketing systems for security and IT teams that might even be initiating an automated workflow if you use automation tools like, I don't know, talk and times and those kind of tools. But again, from within anecdotes, we're not going to perform that remediation for the exact divide I spoke about in terms of compliance versus security. Thank you, thank you.
Speaker 3:I apologize ahead of time. I keep having to put you on mute because I have a dog whining in the background and this is live podcasting.
Speaker 1:Wait, can we see him?
Speaker 3:I feel good, come here, let's see he's probably going to be selfish and stay off camera, so I apologize, but if you come, over.
Speaker 1:Oh, he's camera shy.
Speaker 3:His name is Achilles Tiberius Maximus. He gets a huge name. He's a little dog. I want to. I asked this in a lot of our podcasts, but I want to keep getting more and more opinions on it, because everyone has different experiences, different types of clients and territories and whatnot. Security sees compliance as a risk. Compliance sees security as a risk. How do we make them friends and bridge that gap in your opinion?
Speaker 1:Cage fight in Vegas. We talked about this.
Speaker 3:Wow, this is the season's party. On the VIP list we're going to add you. We'll tell you about it later. It'll be great.
Speaker 2:In Vegas, in Rome. That's the new thing.
Speaker 1:There you go. I've done it up, we'll be there. I've got money. I'm placing bets.
Speaker 2:Well, so I got lost. The question is okay, how do we really build that trust? I think this is maybe when you start to talk about the future of what our industry looks like in terms of, I'll say, the magic word AI, as in maybe and here's a trend that I'm seeing and I might be wrong about this, I usually am wrong If we think about traditional GRC, where a lot of the practitioners are very focused on writing effective policies, or policy is the main idea Governance more the G than the RMC Income's generative AI to some extent is capable of doing a lot of that. I think and I already see this there's going to be an increasing trend in very technical people entering the GRC space.
Speaker 2:I said before security and compliance engineers. I think when security and compliance professionals begin to speak much the same language because compliance professionals are becoming increasingly more technical then as the language begins to be the same, then I think the trust will come together with that. I think part of the division until now has been the GRC professionals are more traditional and people who are better with words, whereas the security teams have been to some extent. You can call them computer scientists. All of a sudden now that gap is starting to look less large. They're starting to become more similar personas. I do think that will help bridge that gap quite significantly, I agree.
Speaker 1:Are you guys doing anything for the upcoming NIST CSF framework? Do you have any information that I don't have? I've been trying to figure out exactly when they're coming home 2.0.
Speaker 2:Yeah, I've already received so many customer requests I can't even.
Speaker 2:I was saying to you this week that I really bogged down. It's because of the combination of NIST 2.0 and Federa was shifting to Rev5 of NIST 853. All these things have just made we have so many frameworks to be pumping out and it goes into the product. We guarantee a very quick turnaround time on these things. It's very important to me that we deliver on that. One thing I will say about NIST CSF is I was really interested to see about six months ago and I really didn't expect this that it's our third most adopted framework amongst all of our customers.
Speaker 1:What's your first? What's like number one and number?
Speaker 2:two Sock 2, type 2 and then ISO 27001 and then NIST CSF. The reason obviously that's really surprised me is because it's not an audited framework. Our customers are using that for the purpose of continuously monitoring their controls. They have Anaglut is built on a cross-mapping architecture and they know that if they stick with NIST CSF and they focus on that framework and that will be the best way to focus them on framework and automatically ensure that they're also meeting their requirements in their other frameworks. I think NIST CSF has received such popularity because it's so good at establishing that really good baseline. It's equally prescriptive and non-prescriptive. I was really surprised to see quite how popular it is. I'm a big fan personally.
Speaker 1:NIST CSF I would say for us on the trust map side we're more of a maturity shock, more than GRC. We're not a GRC tool and we tell, we're very upfront with our customers that we're not a GRC tool, we're a maturity governance, business cybersecurity, business tool. So you can't really, when you want to break things down into sort of business, speak maturity works really well. We've seen NIST CSF. The adoption of NIST CSF has been number one for us, I would say, probably followed by ISO 27001 and SOC2. We've also seen quite a few CIS assessments. But maybe it's because it speaks more to security and it establishes that baseline and maybe CSOs and security leaders are turning to something like NIST CSF because you can really break that maturity model into the subgroups and you can tie costs and investments into that. It's very simple to digest by the business from a security perspective. But if that makes sense, that from the compliance side, if you're being audited, you want to have that SOC2. So I'm not surprised that NIST CSF is like your number three.
Speaker 2:For us it's our number one and so that all sort of tracks yeah, what's interesting is you mentioned the idea of being able to tie hard numbers to NIST CSF controls. I hadn't really given that much thought because the other really big trend that I'm seeing amongst our customers is increasing requests for support for risk quantification. Now this has been a hot topic for a long time, but I think now people have more and more organizations are starting to feel unsatisfied with. I'm going to calculate risk on a five by five impact by likelihood matrix, which is like throwing dots at a dartboard. In some cases. The idea of starting to trickle in quantitative elements is something that really is. We hear it all the time. We're also working very hard to push those elements into our product. It's interesting I haven't really explored the NIST-DSF types of that, so I'm going to have to go and explore that.
Speaker 1:Yeah, it's really interesting. I mean, I'm happy to always talk about it. Do you guys include as a part of your offerings you create a risk register for your customers? Is that built into anecdotes?
Speaker 2:I mean, let me do a really quick overview of how our product is built.
Speaker 1:It's data collection.
Speaker 2:It begins at data collection, which is really what I said before integrating with the tech stack, collecting all the relevant data to security and compliance frameworks from the entire tech stack. That's the data collection layer. Then it's the data analysis layer. We're not just collecting the data, we're also analyzing it. The simple thing would be we're collecting all of your password policy configurations and then we're analyzing them and saying are they secure or not? Do they require a minimum of eight characters, up or lower case characters, and so on and so forth. So that's the analysis layer. Then the top layer is applying that to a specific context. The context is our application layer.
Speaker 2:It might be frameworks, it might be all the frameworks we've discussed, but our other key applications are risk manager and user access reviews. So our risk manager application is an application that really has progressed significantly this year. We put a lot of resources and time into developing it. These days it's a product in and of itself, and I've been fortunate enough to work side by side with the product manager and the product team that lead the risk manager application. It's been so interesting to see how organizations of all shapes and sizes are completely varying levels of maturity when we think about it, the frameworks that they do and the customers that they serve. There's absolutely no correlation between everything I just said and where they stand in terms of risk management. You can have these massive enterprise organizations with quite scary risk management processes and then you can have these small startups who have efficiently and properly implemented the fair methodology, so it's been a really interesting experience when it comes to risk management.
Speaker 1:Well, the risk quantification piece is sort of what we do best. Do you guys have the risk register? We've got the risk quantification and the investments estimates according to NISCSF or SOC2 or whatever. We should fairly know.
Speaker 2:It's definitely further discussed.
Speaker 1:Yeah, it sounds like a match made in heaven. Oh my gosh, who is that guy?
Speaker 3:This is Achilles. Sorry, I had to hold him.
Speaker 1:He is just whining.
Speaker 3:He's going to say hello. He's so interested in this conversation, by the way.
Speaker 1:I love him. He is so cute. He's a Chihuahua, correct.
Speaker 3:He is a Chihuahua, but he is nothing like the breed and he's really friendly and sweet. And he just had his 14th birthday, so he probably can't even hear half of what we're saying.
Speaker 1:But it's all right. Oh my gosh, he looks like a young man.
Speaker 2:He looks like a boy, he looks like a young man. Admittedly, he's quite blurry.
Speaker 3:He has a lot of energy. He really does. But I have one last question for you, Ethan. I know you have a lot of different types of clients and customers. One of the biggest things that I've been seeing a lot is with governmental entities and their frameworks or lack thereof, or just really having to mitigate quite a bit of risk as they're getting things coming down from the hill. What challenges are you seeing with any of those types of clients? Is there anything you could speak to with that regard?
Speaker 2:It's an interesting one. Admittedly, we're talking about government clients. We don't service many, if any at all, but the biggest challenge that I see is not so much in the realm of frameworks or things like that. The biggest challenge I see is effective risk management. Time and time again, the most common thing that I hear people saying is oh, we're just in the process of redoing our risk management program. We're just in the process of setting it up from scratch because we weren't happy with the previous iteration. Time and time again I hear that excuse of we're not effectively managing risk in a minute. So that, I really think, is the biggest sorry for the background noise there. That I think is the biggest challenge facing large organizations and small organizations alike.
Speaker 1:How do companies define risk management? So if you're saying we're trying to get our arms around risk management, how do you know when you're successful?
Speaker 2:Well, that's a great question. It's a little softical kind of. Yeah, it's definitely a philosophical one and it's sad to say, but you never really know until it's tested right. But the first thing is, everyone calls something. Everyone has a slightly different idea of what risk is. So are we talking about purely cybersecurity related risk? Are we going into the realm of enterprise, broad risk management, business risk, corporate risk? And practitioners in each of those realms will tell you something completely different. Even within the cybersecurity realm, one person might call a vulnerability something that appears from a tenable scan. They might call that a risk, and I always say, well, I don't really see that as a risk. If that occurs, what's going to happen? And so the first thing is one of the biggest challenges I see is how do we define what is a risk?
Speaker 1:What would you say a risk is? And I've got my philosophy and I've seen what customers come up with. But I'm really curious how would you define a risk?
Speaker 2:So I probably, with my definition, I probably wouldn't pass a CISSP exam. But one thing that I really think is significant in a risk OK, a risk might be a data breach, let's say, but I always think it's completely irrelevant if you don't go one level deeper and apply it to something specific within the context of your organization A data breach arising from database X containing PIR, for example. I like to go that one level deeper because I think only then do you have something that's a little bit less general and a little bit more applied to your organization. And our approach has been to simply take open source, reputable risk registers and implement them within our product. So SCF, the Secure Controls Framework, publish a risk register called the SPRMM. So we draw a lot of risk from there.
Speaker 2:We also draw things from in the realm of CI-CD. We OWASP top 10s. There's now OWASP top 10s for privacy. The CSA, the Cloud Security Alliance, also publish a top 10 list every year. I think they actually explicitly call them threats, which is interesting top 10 threats to cloud computing. But you can take them as risks. I think a lot of our customers choose to take those as risks as well. So it's a slightly roundabout answer there.
Speaker 1:Yeah, you want to think and I just had to switch cameras because one of them died when you think of risk, sort of and I can see the confusion between risk and vulnerabilities, because if somebody is equating a vulnerability to a risk, here's what I think they're really doing. They're going okay, a vulnerability is something that has a likelihood and an impact, right. And they're going back to your fair, you know heat map, sort of matrix, and so in their minds, well, what is the likelihood of a risk happening? So, if you're thinking about insurance, if you're getting into a car accident, what is the impact and likelihood of crashing? How much is that going to cost and how likely is it? So they would say, well, that's a risk, right. So I think people, when they're starting to think of likelihood and impact, they're thinking that a risk is anything that you can quantify by likelihood and impact, which, coincidentally, is the way that you quantify a vulnerability, right, that's how you can tell what vulnerabilities you have. So the way that we've sort of thought about risk is to sort of wrap it all into one package, and so we're looking at, let's say, instead of looking at, you know, getting hacked or ransomware as being a risk, we look at that as a vulnerability. And then when I say we, I mean like kind of our philosophy at Trustmap, but we kind of package that vulnerability into a larger risk and that risk may have a lot of vulnerabilities.
Speaker 1:But let's say, outsourcing our sock to India, right, or outsourcing it to anywhere outside of the United States, so that could be the risk and within that risk you might have, let's say, tie that to. Because we're outsourcing, we might have to adhere to certain data regulations or data controls or security and awareness training. It opens us up to a whole bunch of just outsourcing, opens us up to a bunch of risks, right, there are all these little risks that it can sort of this giant risk opens us up to. And so you can say well, here are all these things that you know, like security awareness training. That has a set of controls. What is the impact and likelihood of getting a ransomware attack? Because we didn't train these new sock people overseas on our internal processes and they don't adhere to our company's security.
Speaker 1:So you're basically taking a vulnerability and you're taking a larger item, some business decision, and this is kind of what ties it all back into the business. You're taking some business decision and you're saying what are the vulnerabilities that are inherent to making that decision, so that overall business decision is a risk? Anytime I step outside of my house, that's a risk. But you know, getting hit by getting into my car and driving on the freeway at 90 miles an hour, that's a vulnerability. And so there are things that I can do to control or mitigate the impact of getting into an accident when I'm in my car at 90 miles an hour, according to that risk of leaving my house Does that make? Is that convoluted enough for you?
Speaker 2:It's a different approach to what I think of, and that's exactly it. It kind of strengthens the idea that we will have a different perception of how we view this.
Speaker 1:Exactly.
Speaker 2:In your example I would say the risk is getting hit by a bus. The risk, you know the vulnerability is leaving the house in the first place and the mitigating control I should have put in place is just not leaving the house or reducing the amount that I leave the house in the first place. Or maybe that's wrong.
Speaker 1:Well, I mean that's a really good, so that's flipped right. But if you say the vulnerability is leaving the house, well, you can't apply.
Speaker 2:The vulnerability would be that the traffic lights don't work, or something like that, in my opinion.
Speaker 1:Yeah, what is the likelihood and the impact of the traffic lights not working?
Speaker 2:Yeah, something along those lines. Right, I don't know, it's hard for me to think of these more abstract examples, and maybe it's the opposite they're not abstract because they actually make sense.
Speaker 1:Yeah, but the point is and the reason I made it so convoluted is to illustrate your exact idea that it's a philosophical idea and it varies from person to person. So I think, at the end of the day, what you have to do is talk to the business and say what are your risks, what are risks to you, what do you think of as a risk and how do we mitigate those risks, how do we reduce the impact and the likelihood of those risks? However we define it, but it has to start with the business.
Speaker 2:Absolutely, and I think the main thing I took from your example which I absolutely agree with is ultimately, in my opinion, a risk register needs to include a direct reference to those unique business decisions. So for me, a risk in the example you gave would be okay. I need to evaluate, perform analysis of the risk of a data breach due to outsourcing my SOC to India, and the mitigating controls I'd expect to put in place would be, like you said, awareness, training, signing all the employees on NDA, whatever it might be, encryption, so on and so forth. That would be my approach. It would be okay. I take these classic risks non-compliant data breach, whatever it may be and then I attach to it some kind of business specific decision, which is the reason I want to analyze the risk. It's the context in which I want to analyze the risk. That's what makes this risk interesting. Right, that's my approach and, like I said, it's a philosophical thing. Everyone seems to have their own approach now.
Speaker 1:Well, this is a good place to discuss it. This is a really good conversation because we don't really. We always feel like we need to get it right, we need to have the correct answer, but I think in having these conversations we sort of tease out the different perspectives and then we sort of condense. What is important, which I think we could both agree, is the business.
Speaker 2:Absolutely. And to come full circle here, it's another security versus compliance discussion. The security team are going to deem something different to be a risk to what the compliance team is going to deem to be a risk. The finance department has a whole different set of risks that they're interested in and ultimately you're all aiming to deliver some kind of globalized risk report to senior management so they have a good understanding of the organization's risk profile. And so long as all the departments are speaking the same risk language and reporting in the same way, what you call a risk at a micro level probably doesn't really matter, as long as at the macro level everyone speaks the same language.
Speaker 1:Exactly, yeah, brilliant, I think that that's. I think we figured it out, ethan.
Speaker 3:No no, no, no, I have a curveball, so hold on. Oh man, no, I'm sorry I got to. I got to interject here on behalf of team women and moms everywhere, because I'm hearing a lot of logistics and logical thinking here and what I'm thinking from my HR heart is saying it starts with the training and the biggest risk is humans. And if you're going to go philosophical, we got to talk about it's the same premise I got. I got my kid, my fur kid, here whining the whole time. We're talking about this. So this is kind of where this is coming from.
Speaker 3:But if we are not raising a child properly, they're going to become a huge risk factor as an adult, many areas of their life, right. Same thing with this. You're going to implement a brand new framework, anything to this magnitude, let alone. You start a company and you say I want to become the next Steve Jobs and you're going to go international right. If you are not starting with risk training, human risk training out the gate properly, all of this could be for nothing with one push of a button.
Speaker 3:And this is the biggest thing that I'm seeing with so many conversations, because we are having board of directors, ceos, top C suite executives opening phishing emails and getting hacked because they didn't. They didn't pay attention during compliance training or any of the security training, and so I love everything that you've said, because I don't think like y'all. But maybe now I've provided a perspective too, because, especially as someone who's worked in HR before, we're not sitting here saying I want to go out and train everyone today. But also, how do we make it fun, how do we make it interesting and, more importantly, how do we make it compliant, so that both of you aren't wasting your time, whether it's in sales or GRC. So there's my two cents and I'll step off the podium, thank you.
Speaker 1:Well, I love it because that is you're right. You're right, the biggest risk haben slaughterers, and that's something that is intuitive, right. The beauty of what you're saying is that if you walk up to somebody and say, well, leaving your house is a risk or driving on the highway is a risk, there's a million things that you can come up with that are risks, right, and you're not going to be able to quantify it all, but what you're talking about is a single point of failure. That's the biggest. The human is the biggest.
Speaker 2:The human element. As I said exactly, it's always the human element.
Speaker 1:Yeah, hats off to you, Maggie. Well done Well played.
Speaker 3:We should all just be in bubble wrap the rest of our careers and then we'll be okay, it'll work out.
Speaker 1:That's the ultimate risk mitigation right there.
Speaker 2:Nobody's touched anything. Risk avoidance it's not mitigation, it's risk avoidance there you go the bubble wrap.
Speaker 1:So the bubble wrap would be avoidance, not mitigation.
Speaker 2:Exactly because you just delete the risk, it doesn't exist anymore. Nothing can happen. I mean bubble wrap.
Speaker 3:Are these human? Yeah, we just came up with a name for your next product. Okay, ethan, bubble something.
Speaker 1:Bubble wrap, bubble wrap Bubble Dots, bubble Dots, love it All, right. Well, this has been a really good conversation and I want to keep it going. I love the conversations around risk and I love the conversations that we get to have in security, where we don't have to get it right. I'm not an expert, I don't call myself an expert and I don't even play one on TV, even though right now, technically sort of, I'm on TV. But I'm not an expert and we're just sitting here trying to figure it out.
Speaker 1:And this is how I think you help control for the human element. We transfer knowledge, we tease things out, and technology is a good. You can have technological controls, but I'm always in favor of human controls and I'm hoping that these conversations for those who are watching or those who are listening, that these kinds of conversations help contribute to making our world a little bit safer and reducing risk, just through information sharing, and that's what we're trying to do here. So, ethan, maggie, y'all are great. Ethan, thank you so much for taking time out of your busy day. I know, like you said, you guys have been just really busy over at Anecdotes with the upcoming frameworks. Oh, by the way, did you say when CSF is coming out 2.0?
Speaker 2:I didn't. I'm not really on top of it. I ought to be, nobody is.
Speaker 1:This is the thing, nobody knows.
Speaker 2:It was published. I just need to double check if it's the absolute finalized version. But yeah, it's been published.
Speaker 1:Okay, well, I'm not going to say that it's final Until it's final, because we saw what happened with the SEC rule. Exactly Right. They were like, yeah, everybody prepare for this. And everybody was just throwing everything the kitchen sink, the baby, the bath water, everybody's throwing everything at the SEC rule. And then, last minute, three out of five, they said you know what? The certifications? You don't need it. The expert on the board? Oh, you don't need it, but what you do need is four days to report incidents when they happen.
Speaker 2:There was a really in the document about the, you know with all of the comments. You know they responded to all the comments and I can't remember what the document was. One of the really interesting things there was about risk quantification. People had commented that these kinds of organizations ought to be practicing risk quantification and of course that didn't gain traction for obvious reasons. Organizations are just not there yet. But yeah, there's a lot to say about that as well.
Speaker 1:Great Well again, ethan. Thank you so, so much. And where can people find you online if they're looking for you, if you want to be found?
Speaker 2:I know you know more than welcome to have me on LinkedIn, ethan, without the MA double N at the end. And, yeah, thank you so much for having me?
Speaker 1:Maggie, where can people find you?
Speaker 3:LinkedIn as well. Also on Instagram under security market watch. We are on there. We would love your subscriptions and our YouTube. Subscribe to our YouTube.
Speaker 1:Yes, yes, please, and I'm Josh Bruning. Again, thank you for watching this episode or listening to this episode of security market watch, and you can also find me on LinkedIn Josh LinkedIn dot com. Slash Josh Bruning. Thanks again, everybody. Goodbye, all right, all right. Well, that was more than half.
Speaker 3:Amra's cutting out. I had a thunderstorm going on, trains going by, a dog whining. I think we did pretty good.
Speaker 1:Yeah, yeah, we nailed it. Yeah, okay, well, goodbye.