Introduction (00:00) You're listening to KBKast, the cyber security podcast for all executives, cutting through the jargon and hype to understand the landscape where risk and technology meet. Now, here's your host, Karissa Breen. KB (00:38) Hey, everyone. It's KB. Thank you for being an active listener on the show. And thanks to you, we've been downloaded in 63 countries. If you haven't already, please ensure that you follow and subscribe to the show for the latest updates. Now, time to get to the interview. Joining me today is Kevin Tham, CISO from Etika. And today we're discussing ISMS, also known as Information Security Management System, and the benefits of utilising this framework. So, Kevin, thank you so much for joining. Thanks for making time. It's absolutely wonderful to have you here. Kevin Tham (01:11) Thanks, Karissa. Very happy to be here. KB (01:13) So I want to start, Kevin, with your thoughts around ISMS. Now, it's a bit of a mouthful. We've got a lot of acronyms in our space. I wanted to talk about what that acronym meant because sometimes in our space, certain acronyms actually reflect different things. So now that we're all on the same page with what it means, you are a really big believer in following this framework. And you said to me originally, it makes sense and it's a bit more obvious that people should follow the framework, but perhaps don't. So I'm really keen to hear from your perspective. Tell me all about it. What do you think about this framework? Kevin Tham (01:49) So ISMS, it's an interesting concept, and it's been around for a very long time. What it has become recently is, if you were to speak to many of my peers, is SMS is just something you do to attain compliance. Specifically ISO 27000. And that's where it ends and starts for a lot of people. However, I think that there's a wasted opportunity here that people do not realize that the SMS actually extends beyond just a compliance checkbox thing. In fact, I think it's more like a cheat sheet that a lot of security professionals can actually utilize to understand and articulate what their goals are, where they're at, and even how you're tracking, especially when you're doing some a transformation program, or even just tracking in terms of simple program of work. When it comes to security. This is something that's important. An isMS is not something that you can buy off the shelf. It is something that you really need to set up correctly, but it does allow you to utilize it for clear communication with executives of what is being done, what's the rest of the organization doing and what are the controls that you expect to actually get to as well? Kevin Tham (03:06) So I guess if I round it back again to the fact that this is a cheat sheet, mainly because this gives you the full picture of what security should be. Does it give you all the answers? No. Again, it goes back to the fact that it is a framework, so therefore it gives you the various areas that you need to keep an eye on. And it is up for you to actually set up and fill in the gaps of what and how it applies to your organization. KB (03:34) Awesome. Thanks for that. Thanks for that very clear and articulate way of explaining it. So a couple of things, speaking to people over the years now and previously working in the field myself, people said they feel overwhelmed by frameworks. There's a lot going on. Where do we start? How do we go about it? And then you said filling in the gaps. Is it the filling in the gaps part that people struggle with, perhaps, or they're like, I'll do it later, and then later just never comes? Or what are your thoughts on that? Kevin Tham (04:00) Yeah, absolutely. I think the setting up part of the ISMS is always the most difficult part. I'm not professing that this is a simple thing, but a lot of things that we do in the security world is that if you actually put a bit of effort into it, you can reap a lot of benefits out of it. And yes, the nature of our business or our job or industry is rather reactive. But what I'm saying is that there is a wasted opportunity for many other professionals to actually utilize this framework to articulate what's actually happening. So absolutely, operational security operations and understanding what's actually happening, what's the incidents and threats and everything else is actually happening is important. And yes, you do have to drop everything you're doing to focus on that. But what I'll say is that if you put the remainder of your effort into setting it up correctly, you will reap a lot of benefits out of it. KB (05:01) So maybe I have the answer to this, and you can correct me if I'm wrong. You said before, people know the ISMS is more of a compliance checkbox, as you alluded to before. Would you say that's probably why people aren't leveraging it beyond that point from the framework perspective? Because it's not really known for that, and there's a bit of an oversight there from people and not really sure about what it does. And so therefore, they don't look into it more because they just assume it's compliance framework. Kevin Tham (05:31) Yeah. And I think that's the misunderstanding of what the ISMS is. Now, I am very specific by calling it ISMS. I will not call it ISO 27000. I will not call it NIST CSF. These are great frameworks that you can actually base your ISMS on. The ISMS itself is a bit more encompassing than just the security controls that you actually apply within your environment. Now, there is wasted opportunity here, mainly because everyone looks at frameworks like ISO 27000 and NIST CSF, and they look for those controls that they need to implement. It's an interesting thing because if you actually start looking into what these frameworks give you, what they give you is ideas of what needs to be done. They don't tell you specifically what needs to be done. So it becomes a bit of an interesting portion. And part of the reason why people misunderstand what these frameworks are is because in their experience, the only time they actually deal with these frameworks is when an auditor is coming in or when they have to deal with compliance, and therefore it becomes a painful experience. And human nature, if something is painful, they don't try to do it again. Kevin Tham (06:42) And that's to be expected. The question is, can you actually utilize this and use this on your day to day basis so that when an auditor comes in, or when you actually eventually do want to look at a compliance perspective, can you utilize this particular framework or ISMS? Or when your board asks you a question, can you utilize this ISMS? And what I think the missed opportunity here is that, yes, it's massively underutilized in that sense that people only look at it as a compliance thing when in actual fact it can be used for a much broader spectrum of security activities. KB (07:18) You are right. When things are painful, no one wants to do things. Again, myself included. But you raised an interesting point there, Kevin. You said the framework does is give you ideas of what needs to be done. So can you give me an example of what some of these ideas are? Kevin Tham (07:32) If we will turn down to... I'll take for example, the NIST cybersecurity framework. You've got the Identify, Detect, Protect, Respond, and Recover. It gives you the full spectrum of what a cyber resilient organization needs to focus on. And within its own categories, you've got subcategories which actually tells you broad spectrum what other things you should be doing within those environments. Now, these frameworks are not there to understand or to say that you have all these controls in place. It basically gives you the full picture of these are the things you need to do. Now, when you actually do set up your ISMS correctly, and if you base it on something like a NIST CSF, it becomes interesting because it actually already has set forth a bit of a roadmap for you. You can actually look into what you have at the moment, what the controls you have, matched up with the tooling that you have or processes you have. And then from there you can go, Well, okay, is this mature enough? Is it not? How far along are we to finish implementing it? Do we have to do more? The NIST cybersecurity framework or even ISO 27000, or any other framework you want to come up with, works in the sense that it gives you the full picture. Kevin Tham (08:42) And then it's up for you to fill in the gaps of how does my organization deal with this? Do I have it? Do I not? And then it actually goes back to the fact that the whole isom is actually links up to things like your risk framework. If you don't have that control, what does it mean from a risk perspective? So it gives you the full spectrum. Fill it in. It's almost, I call it color by numbers in this case, and also why I call it a cheat sheet for security. KB (09:08) I love color by the numbers and I love that analogy. So I know this is a bit of a hard question to answer, but just to get a barometer, I don't know how long is a piece of string, but if you were to conduct these exercises, and I guess it depends on the maturation of the company, the size of the company, how long the company has been around, etc. If you, Kevin, as a leader were to implement these exercises, like you said, do I have the thing? Does that link up to a risk framework? What happens if we don't have the thing? What's their risk, etc. This is quite a laborious, arduous task if you want to look at it from that perspective. How long would you say that people perhaps need to carve out to implement some of these exercises? I mean, if you had to just give an example. Kevin Tham (09:47) Cool. So the reality is there is no end date to ISMSs. Just like there is no end date to a security program, I think we need to wipe that slate clean in terms of an end date. There is a point in time and that's what we need to do. And then from there we actually evolve. And again, when you actually have a framework, you can easily evolve around that framework. And at some stage, if the framework doesn't work for you, you can throw it out, put another one in again, and then try to realign everything. Now, to the question of how long this will take, based on my experience and working in a startup where there isn't a lot of business activity, this activity took two people about three months to complete. So I'm not saying this is simple. Even for a business that actually doesn't have a lot of business activities, it still takes a fair chunk of time to do. And that would give you a position of what your entire framework looks like, how it connects to your risk appetite, how it connects to your risk appetite statement, how it actually connects back into impacts to your revenue stream, how it connects back into what you're doing from a security controls, definition of your control objectives, identification of your key controls, all the way down to what are the tools that you actually want to implement or have implemented. KB (11:08) When you say two people for three months, is that two people working on this day in, day out, or a couple of hours here and then doing BAU stuff, or what are we dealing with? Kevin Tham (11:17) So basically two people with full attention onto the implementation of the ISMS. KB (11:23) Okay, so that is a big amount of time. Kevin Tham (11:25) It is a big amount of time, but it doesn't mean that it's going to be the same for a lot of organizations. Absolutely. If you were to ask me whether we can actually do this and how much time it is for an organization that's already operating, at some point in time, even in the one month or two month period or even three months, there is a position you can already take from the ISMS and you can actually start utilizing it already. I'm not saying that you cannot utilize it even in a large organization. Once you've actually put in the foundational cornerstone of the ISMS, you can start utilising it. And that's the important part of it. KB (12:02) Got you. Yeah, that makes sense. And I guess with any of these things, it's more so the effort required when you haven't implemented something like this historically. So it does take a little bit more time and a little bit more rigour to implement it correctly. Kevin Tham (12:15) Definitely. It's based on experience as well. But if you were to ask me in terms of an implementation of ISMS, the very first thing you really need to focus on is not even the ISMS. The very first thing you really need to focus on is where are your revenue generating streams within your organization? And that's literally the first step. How does your business make money? Once you actually figure that out, then you can almost go into isolation and take what you've learned from your business and try to apply it back into your ISMS or a framework like NIST CSF, ISO 27000. If you review like you heard a lot NIST 800, and then start looking at, Okay, this particular control, how does it actually impact my revenue stream for my organization? And start building around that. Now, that then naturally goes into a discussion of risk statements and your risk appetite. Now, the risk appetite is something that you would create after your risk statement. You would then take the risk to the business and go, Well, okay, I understand this is how we make money, but what do you think if we were to utilize controls in a certain way that keeps us within the risk appetite? Kevin Tham (13:32) And what are our risk tolerances? Now, this is a very risk focused discussion because this is the connection between your ISMS up into management reporting. And that is probably the part that takes quite a bit of effort because there is a lot of education and everything else. But it gives you the ability to go, that's your revenue stream. I'm saying that these are the things that we're doing or we're about to do that will control and protect our revenue stream. And what do you think your levers are when it actually comes to those controls? And what are your appetite to stay within the tolerances of not having a control that is the maturity level that we believe it should be. And that is already a very big chunk of what that implementation is because the remaining part of it is to actually look at the ISMS and go, Right, now we've got a risk stuff. What does it mean from a control objectives perspective? This is the one thing that I think we need to avoid. We do not want to implement every single security control. Understand what your control objectives are, and then from the objectives, pull out what your key controls are before you start looking into what are the actual technical controls you need to implement, or whether you've got an existing control that already applies for it. Kevin Tham (14:59) And then it goes back with that. It allows you then to go back to your tech team or anybody else to go, Okay, this is what we're trying to achieve. And when they actually finish a project, you can very quickly link it back into your isMS, which then links all the way back up to your risk statements, etc. Unfortunately, sorry, that's a very long winded answer, but that's the way I think we need to do it. KB (15:24) I love a long winded answer, but also shows a depth of knowledge and your experience, which is why I wanted to bring on the show in the first place to really talk through your thoughts. Now, Kevin, you made a really interesting statement. Now you said, how does your business make money? Now, I have spoken to several people on this show and they are of the opinion that some people in this security division don't really understand how the business that they work in and are paid the company that pays them to do security, they don't really understand how they make money. Is this a common theme that you're seeing? How can you protect a business that you don't actually know how that company makes money? Kevin Tham (16:04) Unfortunately, it is. And I think it is not to a fault of theirs. And it is because if you end up being in an organization where you are just a single cog in the entire machine, it's very difficult to look upwards and going, Well, how do we actually make money? So unfortunately, it is also my observation that there are a lot of people in my industry who do not understand that. And then what happens, the behavior we have is that in security, we then go back to the whole world. Okay, I know how I can do this. I know how to articulate threats. And then we go down a very slippery slope. In a very personal opinion, if we lead our discussion with the business based on threats, we end up really going into the fear, uncertainty, doubt side of the world by talking about things about threats and not being able to contextualize it for the organization. And therefore, it becomes a, if we don't do this, I'm just going to give you that a bit of doubt and uncertainty that this is going to be us. We end up having really broad statements like, if we don't do this, we're going to end up like optists. Kevin Tham (17:18) Why? That's not the right way to do it, and that's not the right articulation or language we should be using. Oh, my gosh. KB (17:25) I have heard these conversations far too many times. Now, you make a great point. Absolutely. You're a cog in the wheel. I've been in that position before. So it's like, oh, and there's so many different streams, especially, I mean, you've worked in the bank yourself, for example. You fundamentally, you know, but maybe explicitly you don't. So do you think maybe the fault, or well, I like to say fault, but maybe the oversight needs to be on the leader to be like, Okay, now we understand that you're a security team, we're here to protect the business, da da da da da. But that needs to come from the, whether it's the CIO, the CEO, the CSO, like yourself to say, This is the tone that we need to lead with in order for us to do our jobs better. Where does that responsibility lie in your opinion? Kevin Tham (18:07) Go into the organization and find where security ultimately sits. And that would be the leader that needs to articulate this or be able to figure out that particular position. So it could be a CISO, it could be a CIO, it could be a COO. And if it is a CIO or even a COO that has a security manager reporting to them, then it would be the security manager that needs to sit there and go, Well, how do we make money? And ask that question so that this articulation can be embedded into your ISMS so that it becomes a much easier... When you embed it in your ISMS, it basically traverses down into your security team in a more natural sense. Because if your team really wants to look into why they're doing a particular control, they can actually look into your ISMS and then trace it all the way back up to where and what they're doing and how it actually fits in in a big picture. But if they are not interested or do not want to know, then at least they've got a control objective they can hang off and not need to know the big picture. Kevin Tham (19:16) It's almost a self service model from an isMS perspective for the security team to be able to consume from. KB (19:22) Makes sense. Now, I'm a curious person, which is probably why I started the show in the first place. I have a question for you. We spoke a little bit before, we don't want to end up like Optis, for example. From which angle would you say who blows out of proportion more about the threats? Is it the business or the security team? Because I hear it from both sides nowadays, even in the business. And maybe that was because of Optis and all these other things that have happened. But who would you say really is extravagant on the threat side of things that may be a little bit over the top with how they position it? Kevin Tham (19:55) I think we all have to take responsibility, to be completely honest. And that's because this is chasm of a gap between the business and what security does that's been created over time that the business doesn't understand what security does, and therefore they make assumptions, versus security hasn't gone and created that halfway bridge to be able to articulate what they're doing in the organization that will protect the organization here. And I think there's equal responsibility on both ends that's actually perpetuating these statements. And certainly, I have seen this as well, just like yourself speaking to various people, to say that this has occurred as well. And why does the business make that comment? It does also then go bubble up towards what's said in the greater, the general media, what the government has said. These are statements that on that platform, on that level, like the media and government, the statements they make is generalized. We have to remember that. It does not automatically apply to your organization. However, when you actually consume it, we actually apply our own personal bias to it. So a business is actually going to look at a headline and go opt us breach. Kevin Tham (21:14) Immediately, they're going to go, Well, we're going to have a breach as well because we've got customers. And that's probably the only context they actually will be given. So therefore, they will end up saying things like that. And on the flip side, from a security professional perspective, if we don't have the contacts of the business, then we're going to go, Yeah, well, Optis has this breach because they have these threads, and this particular threat actor is known to be active in our industry. So therefore, the Optis breach is absolutely going to happen to our organization. Now, that's not going to be helpful. Both sides need to just build a bridge and get in and cross it. Take on responsibility and have a contextualized discussion of why something like Optis may or may not occur, or even how it might occur and how the organization can actually react and respond to it. KB (22:07) Yeah. Okay. There's so much in there. And I understand about the generalization. So, for example, the day of this recording, the other day, there was something, there was a plane, large Australian aviation carrier had to make a landing. And now people are like, Oh, I was on a plane the other day. What if this happened to me? And it may have happened, but it's probably unlikely considering the amount of planes that leave the airport every day and fly around domestically or internationally. But it's because of that one headline that people are now really holding that very tightly to be like, Well, that's a massive risk. And this is what I mean by the generalisation of how people think, which I can understand and I empathise with. But I guess maybe then it falls to the security division to say, Hey, let me break that down for you. Because it's not often, for example, a plane land randomly like that from a Mayday perspective. So you mentioned before, build the bridge and cross it. How do I build the bridge? And I know that's a hard question to answer, but it's getting people on the show like yourself to give other people insights around how they can move as more of a unification in their business. KB (23:12) We don't have to be against one another. I know what it feels like, you've been going like a decade ago, of feeling really against the business and then people almost ostracising you because you are trying to do your job. But maybe back then there wasn't a lot of unity between the business and the security department. So I'm curious to hear from your perspective, Kevin, how do we build that? Kevin Tham (23:33) Now, it is and it will vary from people to people. But what I'll say is, being in a position that I'm in at the moment as a size of four financial services company, I need to take the effort to come out from the security engineering background that I have. And my understanding of that will put it one side and take a big leap forward to actually understand how I talk like a business person. And that is already probably 80 % of the way of building the bridge on the security side. So I've taken a responsibility on myself to go, Okay, the first thing I need to go is how do I deal with the organization? Is there a particular language to the business used? This is not even rocket science. I think it's been said in the industry for well over a decade, security needs to start articulating things in the risk language. Why do we keep saying that? Because the business understands risk. They understand risk of not doing something because if you don't do it, you're missing out on profits, for example. You're not doing this because you're liable for this. You're not doing this because of whatever reason. Kevin Tham (24:47) Understand the structure of how the business language is and take your deep knowledge of the technical side in security. It could be technical, it could be not. But take that security context and then hone it into a business language of which the business can understand. And that's basically it sounds really simple. It's incredibly hard. I've been in the industry for well over 20 years and I keep needing to learn new ways to do it. And it's never going to stop. I think I still have about 20 years in my career to go. And my expectation is I need to keep evolving and understand how the business talks from things like how you structure a sentence all the way down to something as simple a terminology we use. It's always an interesting thing trying to bridge the gap between what the business understands versus what the technology or even security is trying to do. KB (25:44) Thank you. I really appreciate you saying that because, yes, in theory it sounds easy, but in reality it's quite a hard thing to do. Like engaging with human beings is hard, right? And understanding what goes through their mind, which is not made up of ones and zeros is complicated. People have feelings and emotions that make no sense half the time. So okay, you made a great point that you have to actively, and I use the operative word is actively, come out of your background of being an engineer and as a security mindset and swim over to the business. But would you say, Kevin, that not enough are taking the same approach that you've taken to get out of the mindset of being that engineer to actually be that size, though, to be that leader, to engage with the business, to drive that outcome? Would you say that perhaps... And maybe it's not people's intention to be like, Hey, I'm just going to hang in the back. Maybe that's not what they lead with. But like you said, it's hard. Would you say that people aren't doing enough of that? Kevin Tham (26:45) I would say more needs to be done, absolutely from our end. But it is not true the fault of their own. The reality is security has been a very reactive function. And through reaction, we actually end up not being able to focus on more strategic things. And what I've been talking about in terms of bridging gaps with the business, it is, you can put it into the bucket of this is a strategic thing that we need to do. So I think the one thing that is within our control is to try to put aside some time to actually do that. And even if it starts with one hour a week, do it. Put your tools down, go speak to someone in finance, go speak to someone in product, go speak to someone and ask the question, Hey, I heard about this, and I assume there are a lot of organizations where it's very consumer focus. Just go to them and go, Hey, I heard about this particular thing that we're doing. Can you tell me more about it? And they will spark a conversation because just like how you get participants onto your podcast, once you speak to someone who is really passionate about a certain topic, they will talk your ear off. Kevin Tham (28:07) Allow them to talk your ear off and then start getting all the little dots and the various aspects and their perspective of what it is and start joining the dots so that you can actually see the big picture. Wow. KB (28:24) I think that's a very practical first step to take. And I really like that you were saying that it's definitely not anyone's fault. I really genuinely do understand that. I just think it's not an easy thing to do. And a lot of people that are in these security roles are not wired that way. So yeah, it is taking a large step to actually make that active decision to go and speak to these people within organisations. So I genuinely really appreciate you sharing that information and hopefully it's something that people can take away. Now, to get a little bit more back on topic because I love a good tangent, I want to round up the interview with a couple of questions because it's been on my mind and it's something that I've spoken about with people on the show a lot. Now, you mentioned before, Kevin, two people, three months. I mean, barometer, it's not anything set in stone to implement or to start to implement an ISMS. But how can people ensure that they stay the course and not drop the ball? As you know, things pop up randomly in security that need attention, and it's easy to put something like this down and then forget about it. KB (29:28) So how do we ensure... And I've used this analogy, and I'm sorry for people listening. It's start of the year, everyone's like, I'm going to go to the gym. January 18 rolls around and everyone's at the pub drinking beers again. And the gym membership just is non existent. And it's the same thing for these things. We have the right intention as human beings, but then the follow through is hard. And it's probably even harder in security because we have all these other things that are taking away from our attention. And it's really hard some days to get ahead above the water. So how can people ensure that even if there are things that are happening around us, we continue with doing this to ensure that in the long term, this is better for our organization? Kevin Tham (30:09) So the way I would say it is like everything in security, automation. But with a very big caveat to it. Automation automatically goes into what tools that we do. But the one thing that I would say is do not buy a tool before you figured out what your ISMS is purely because you will be let down the generic pathway of utilizing whatever out of the box capabilities are for the business. And then very quickly your ISMS becomes completely out of context for the business and not relevant. So the one thing I'll say very quickly in terms of things that distract you away from implementing the isMS is that honestly, it doesn't really distract you away from the implementation of our estimates. When an incident occurs, quickly go back to what you have already done and go, what is it that we are dealing with? Obviously, deal with your containment quickly. Once the containment is done, then try to quickly understand why that's actually weak, that's actually created that situation. In fact, when you're doing containment, you need to think about that anyway because you need to be able to contain it and make sure that the situation doesn't occur again. Kevin Tham (31:30) Now, that means you will be looking at your ISMS. Whether you actually understand what an ISMS is, a lot of people already utilize it. So every time you actually do that, understand that you are already patching parts of the ISMS, the containment part, the remediation part, ultimately, even the post incident review. You will actually then look into it and go, Well, what can we have done better to prevent this from happening? And it actually goes back into the ISMS. Now, it becomes a natural progression or a natural evolution of ISMS to utilize distractions, quote unquote distractions in this case. So what I would say is don't create another PIR process or incident reporting or any of that. Use the ISMS and go, Well, okay, I'm going to take what I've learned from this incident and then put it back into the ISMS and go this is how I'm going to articulate it. Now, depending on whether you've actually finished up with the linkage back into your risk and revenue stream, but at least you're actually starting to use the ISMS to collect this information. And you collect this information over time, which actually just benefits the implementation of our ISMS. Kevin Tham (32:44) So I guess maybe I need to do the whole air quotes of implementation. What is an implementation? The ISMS, there is no end date, as I mentioned earlier. So therefore, there is no end to an implementation. So so define it, utilize it immediately. And if you can actually get all the linkages back into your risk and revenue stream protection, then you will actually reap the benefits of the ISMS very quickly as well. So yes, there's absolutely going to be destruction, but always grab your ISMS with you and go, Well, okay, what are we dealing with? And how does it impact our controls? And what is it that we're trying to deal with? And that's how... And then map it into your ISMS. Now, you might argue that, Oh, well, we haven't got to that stage or that part of the ISMS yet. Fantastic. Because now you're forced to put those controls into ISMS and go, well, that's weak. That particular control, we don't have it. So therefore, at your post incident review, take that and go, where does this fit in my ISMS? And once you find it, put it in there and go, We've learned that we do not have something here, or there's a gap over here, or our control is just not mature. Kevin Tham (34:04) Therefore, you've actually learned something from that particular distraction. Got you. KB (34:09) That makes very much practical sense. It's as you were talking, what was coming up in my mind, and I'm happy for you to correct me, it was like going to the gym. Yes, the first part is a bit harder because you're not as fit and you've got to get used to it and your muscles are sore. But then over time, you don't stop going to the gym because you've got to maintain your fitness level and your health. But it does get a bit easier. Is it the same thing with this? Yes. Okay, once the bull gets rolling, it snowballs and it gets a little bit easier because you're used to having that as part of your standard operating procedure. You take it with you in doing your PIRs and things like that. But it gets a little bit easier and you're a little bit more used to having it around and it's easier to manage and work with. Would you say that's the case? Kevin Tham (34:54) Absolutely. It makes it a lot easier. It becomes almost muscle memory. And again, I go back to the fact that the ISMS is a cheat sheet because it is that automatic. It's already defined what your muscle memory should be. So utilize it. And it's interesting. You just talk about our standard operational procedure, your playbooks, and all of that, they all ultimately link back to your ISMS. So it will naturally become a pool or a way to actually report stuff in a structured manner that can link back to the business. So, Kevin. KB (35:30) In terms of final thoughts or closing comments, is there anything specific you'd like to leave our audience with today? Kevin Tham (35:36) I've spoken about ISMS a lot, and I will actually say that it is a very old school thought. The one thing that I do want to challenge your listeners here is to go and actually evaluate this correctly. Understand what an ISMS is versus what ISO 27000 is, or what NIST CSF is. Understand how an ISMS can be the center of everything you do, and then also then push yourself to go, Well, how do I utilize this to my advantage? Like when I'm talking to the board or even when I'm talking to an auditor. Now, the one thing that I would say is that a lot of security professionals do not feel comfortable being audited. This is the one thing. Exactly. And I think the main thing here is, and if you can take anything out of this is you can actually utilize your ISMS to your advantage, especially during audit. Because if an auditor comes in, you will go, this is what you have to audit us against, this particular ISMS. Now, when you do that, you are in control of what they will be reviewing. Because if you do not have a framework, they will almost certainly go out on a limb and say, We will audit you against ISO 27000 and NIST CSF. Kevin Tham (37:13) And do you see where the problem is? If you do that, the frameworks like 27000 and CSF is not contextualized to your organization. So the one thing that I will say to your listeners to take away is that if anything else, utilize the isMS as a way to manage your relationship with your auditor. As soon as the word. KB (37:37) Audit comes into play, people get nervous. So I do understand that. And I really appreciate you coming on the show today, Kevin, to share your thoughts, your insights. You've obviously got a wealth of knowledge and is exactly what our industry needs. So thanks for taking your time out today to share your insights with our listeners. Kevin Tham (37:55) Thanks, Karissa. So thank you for the opportunity to speak with you and hopefully connect with your listeners. KB (38:00) Thanks for tuning in. We hope that you found today's episode useful and you took away a few key points. Don't forget to subscribe to our podcast to get our latest episodes. This podcast is brought to you by Mercsec. The specialists in security, search and recruitment solutions. Visit Mersec.com to connect today. If you'd like to find out how KBI can help grow your cyber business, then please head over to kbi.digital. This podcast was brought to you by KBI.Media, the voice of cyber.