I don't sign s**t [The Industrial Security Podcast]

It always comes down to can I have a meaningful business discussion to talk about the risk. What's the risk that we're facing, how can we reduce that risk? And can we actually pull this off with the resources that we have. Hey, everyone, and welcome to the Industrial Security Podcast.

My name is Nate Nelson. I'm here as usual with Andrew Ginter, the vice president of Industrial Security at Waterfall Security Solutions, who's going to introduce the subject guest of our show today. Andrew, how's it going. I'm very well, Thank you, Nate.

Our guest today is Tim McCrate. He is the CEO and founder of Tailcraft Security, and his topic is the book that he's working on. The working title is We Don't Sign Shit, which is a bit of a controversial title, but he's talking about risk, lots of technical detail, lots of examples, talking about who should really be making high level decisions about risk in an organization. Then, without further ado, here's your conversation with Tim.

Hi, folks, my name is Tim McCright. I'm the CEO and founder of Tailcraft Security. This is year forty four now in the security industry. I started my career in nineteen eighty one when I got out of the military, desperina needed a job and took a role as a security officer in a hotel in downtown Winnipeg, Manitoba.

Shortly after, I was moved into the chief security officer role for that hotel and others and had an opportunity to move into security as a career path, and I haven't looked back. I decided I also wanted to learn more about cyber security Holy Smokes ninety eight ninety nine, took myself out of the workforce for two years, learned as much they could about information systems, and then came back for the latter part of my career. And I've held roles as a chief information security officer in a number of organizations.

So I've had the pleasure in the honor of being both in physical and cyber security for the past forty some years. And tell me about Tailcraft. It's a boutique firm that two of our lines. Our first line is that it's new skills from the old guard and we are here to help give back and grow.

And it's our opportunity to provide services to clients focusing on a risk based approach to developing security programs. We teach security professionals how to tell their story and how to use the concepts of storytelling to present security risks and ideas to executives. And finally, we have a series of online courses through our Tailcraft University where you get a chance to learn more about the principles of ESRM and other skills that we're going to be adding to our repertoire of classes in the near future.

And our topic is your new book. You know, I'm I'm eagerly awaiting a look at the book. Can I ask you, you know, before we even get into the content of the book, how's it coming? When are we going to see this thing?

Yeah? Well, thank thank you for asking. I had great intentions to publish a book, hopefully this year. Unfortunately some things changed.

Last year. I was laid off from a role that I had and I started Tailcraft Security. So sadly, my days have been absorbed by the work that it takes to stand up of business, get it up and running. And I hats off to all the entrepreneurs out there who do all of these things every day.

I'm new to this, so understanding what you have to do to stand up a business, get it running to market it, to run the finances, et cetera. It has been like all consuming. So the book has unfortunately taken a bit of a backseat. But I've got some breathing room now, I've got into a bit of a rhythm.

It's a chance for me to get back to the book and start working through it. And it's to me, it's appropriate. It's a really good time. If I'm following the arc of a story, this is the latter part of that story arc.

So I get a chance to help fill in that last part of the story, my own personal story, and to put that into the book. We have talked about the book in the past. Let me ask you again sort of big picture. You know, I'm focused on industriald cybersecurity.

I saw a lot of value in the content you described us as being produced. But can you talk about, you know, how industrial is the book? What you know we're talking about risk, we're talking about about leadership. How how indust field does it get?

I know, you do you do a podcast, you do Caffeinated Risk with Doug Lease, who's you know, a big contributor at Enbridge. He's deep industrial. How industrial are you? How industrial is this book?

It spans around forty years of my career and starting from you know, physical security roles that I had, but also dealing with the security requirements for telecommunications back in the eighties into the nineties, getting ready for and helping with the security planning for the Olympics in early two thousands, working into the cyber space and understanding the value of first information security, then it turned into cyber security, then focusing on the ot environment as well when I had a chance to work in critical infrastructure and oil and gas, and then finally, you know, the consistent message throughout the book is this concept of risk and that our world when we first, you know, when we first began this idea of industrial security back in the forties, bringing it up to where we need to be now from a professional perspective and how we view risk.

I do touch and do speak a little bit about the worlds that I had a chance to work in from an industrial perspective. The overarching theme though, is really this concept of risk and how we need to continue to focus on risk regardless of the environment that we're in. And some of the interesting stories I head along the way, some of the honest to God, some of the mistakes I made along the way as well. I've I've learned more from mistakes than I have from successes and understanding the things that I needed to get better at throughout my career.

I'm hoping that folks, when they do get a chance to read the book, that they recognize they don't need to spend forty some years to get better at their profession. You can do it in less time, and you can do it by focusing on risk regardless of whether you're in the it, the ot or the physical space. So there is some some industrial angle in there, but you know, like I said, industrial or not, I'm fascinated by the topic. I think we've you know, I've I've I've been beaten around the bush enough.

The title that you know, the working title is is we Don't Sign Shit? What does that mean? Can you can you talk about? You know what we're what's in the book?

What are you telling us? Thanks for? Yeah? I came up with we don't Sign Shit and it's I have a T shirt downstairs on my office so that I got from my team with an oil and guest company I worked with, and Doug Leash was in the team as well, and it really came down to this, the principle that for years, security was always asked to sign off on risk, or to accept it, or to endorse it, or my favorite, well, security signed off on it must be good.

Wait a second, We never should have That never should have been our role. We never should have been put in a position where we had to accept risk on behalf of an organization, because that's not the role of security. Security's role is to identify the risk, identify mitigation strategies, and present it back to the executive so that they can make a business decision on the risk that we face. So in my first couple of weeks when I was at this oil and guests organization, we had a significant risk that came across my desk and it was a letter that I had to sign off on.

You. A brand new staff member came in and said, high Boss, I just needed to take a look at this. I'm like, Hi, who are you team to your work on? What's the project you're working on?

When I read this letter, I'm like, are you serious that we're accepting a potential billion dollar risk on behalf of this organization? Why? And like, well, we always do this, not anymore? And we went upstairs.

We got a hold of the right vice president to take a look at this, to address the risk and work through it. And as I continued to provide this type of coaching and training to the team there, I kept bringing up the same concept. Look, our job is not to sign shit. That's not what we're here for.

We don't sign off on the risk. We identify what the risk is, the impacts of the organization, what the potential mitigation strategies are, and then and then we provide that to executives to make a business decision. So when I did leave the organization for another role, they took me out for lunch and I thought it was pretty cool. The whole team got together and they created this amazing T shirt and it's a team we don't sign shit.

So it worked right, and that mindset still in place today. I have a chance to touch base with them often, ask how they're doing, and all of them said the same thing. They said, Yeah, it's that mindset is still there where they've embraced the idea that security is rules is to identify the risk and present opportunities to mitigate, but not to accept the risk on behalf the organization. That was the whole context of where I took this book is wouldn't it be great if we could finally get folks to recognize, no, we don't sign shit, This isn't our job.

So Andrew, I get the idea here. Tim isn't the one who signs off on the rest. He identifies it and passes it on to business decision makers. But I don't yet see where the passion for this issue comes from, Like why this point in the process is such a big deal.

Well, I can't speak for Tim, but I'm fascinated by the topic because I see so many organizations doing this a different way. You know, in my books, the people who decide how much budget industrial security gets should be the people making decisions about are these risks big enough to address today? Is this? You know?

Is is that a serious bottom? Because they're the ones that they have the business context, they can compare the industrial risks to the other risks the business is facing, to the other needs of the business and make business decisions. When you have the wrong people making the decisions, you risk there's real risk that you make the wrong decisions. Because the people executing on industrial cybersecurity do not have the business knowledge of what the business need.

They don't have the big picture of the business. And the people with the big picture of the business do not have the information about the risk and the mitigations and the costs, and so each of them is making the wrong decision. When you bring these people together and the people with the information convey it to the people with the business knowledge, now the people with the business knowledge can make the right decision for the business and again the industrial team execute on it.

If you have the wrong people making the decision, you risk making the wrong decision. So let me ask. I mean, you take a letter into an executive. You do this over and over again in lots of different organizations.

How do how is that received? How do the executives react when you do that? My standard approach has always been, and I use this as my lithmus test, is if the role I play as a chief security officer or SISO and you're asking me to accept risk, I come back and the first question I'm going to ask is if this is the case, and you're asking me to do this, and I'm going to say no. Invariably, the room gets really quiet.

People start recognizing, Oh, he's serious. Yeah, because I have no risk tolerance. When it comes to work, I would be giving everybody like paper, notebooks and crayons, and I want it back at the end of the day. So I don't have any tolerance for risk.

But to test my theory is when I ask executives, if you're saying that my role is to sign off on this, then I'm not going to Does that stop the project? It never does. So the goal then is to ensure that the executives understand it's their decision and it's a business decision that has to be made, not a security decision, because my decision is always going to be I start with no and non negotiate from there. But when we look at what the process is that I've provided and others have followed, is I'll bring the letter with the recommendations to the business for them to review and to either accept the risk, sign off on it, or to find me an opportunity to reduce the risk.

That's when I start getting attention from the executives. So it moves from shock to be serious to okay, now we can understand what the risk is. Let's walk through this as a business decision. That's when you start making headway with executives.

Is taking that. Approach that sounds sim simple, but in my experience what you said there is actually very deep. I mean, I'm on the end of a long career as well, and I've never been a CISO, and in hindsight, I come to realize that blundly, I'm not a very good manager because when someone comes to me, it doesn't matter you know, anyone outside the the you know, my sphere of influence, h you know, my sorry, my spait of responsibility saying you know, hey, Andrew, can you do X for me?

You know, whenever one of my people comes to me with an idea saying hey we should do why, my first instinct is what a good idea? Yeah? Yeah, Whereas I know that strong managers their first instinct is no. And now whoever's coming at us with the request or with the idea has to justify it, has to give some business again.

So that's you know, this is this is deep. It's a deep difference between between you and people like me. It is, and there's don't get me wrong, there's an internal struggle every time when I've worked through these types of requests where I want to help people too. But but I understand that the path you got to take and how you have to get business to understand it accepted to move forward with it.

It's different, right. This is why some great friends of mine that I've known for years and they were they're technically brilliant. I have some amazing skills, Like, honest to god, I stop being a smart technic person a long time ago, and I've relied on just wizards to help move the programs forward. And you know, I've chatted with them as well, and they're similar to you Andrew.

They've they've got great technical skills. They've been doing this for a long time. And you know, one of the one of the folks I chatted with are just like, I can't. I can't give myself the lobotomy to get to that level.

I'm like, oh my god, okay, fair enough, and I get it. But the way I've always approached this it's different, right, So I take myself out of the equation of always wanted to help everybody to how can I ensure that I'm reducing the risk And if I can get to those types of discussions and have them with executives, for me, that's where I find the value. So all of the work I've done in my career to get to this space, the amazing folks that I've met along the way, the teams that I've helped build, the folks I still call on to, you know, to mentor me through situations.

It always comes down to can I have a meaningful business discussion to talk about the risk? And then it takes away some of the emotional response. It takes away that immediate I need to help everybody do everything because we can't. But it gives us a chance to focus on what the problem is, what's the risk that we're facing, how can we reduce that risk?

And can we actually pull this off with the resources that we have? So yeah, I get it. Not everybody wants to sit in these chairs. I've met so many folks in my career that they keep looking at by going Jesus timble, why would you ever want to be in that space?

You know? Why would you ever accept the fact that you're they're trying to hold you accountable for breaches or for events or incidents. And I challenge back with it. For me, it's that opportunity to speak at a business language, to get the folks at the business level to appreciate what we bring to the table.

Whether it's in ot security, it or cyber, physical or cyber it's it's a chance for all of us to be represented at that table, at that level, but at a business focus. So for me, that's why I kept looking for these opportunities is can I continue to move the message forward that we're here to help, but let's make sure we do it the right way. Can you give me some examples? I mean, you know, tailcraft is about telling stories.

Can you tell me a story? You know, how did how did this work? How did it come about? You know?

What kind of stories are you telling here? So there's a lot that I've I've presented over the years, but a really good one is I was working with Bell Canada many years ago. We had accepted, were awarded the communication contract and some of the advertising media supporting contracts for the Olympics for twenty ten for Vancouver, and I was working with an amazing team at Bell Canada. Doug Leaks was on the team as well, reporting into the structure.

So it was very cool to work with Doug on some of these projects. We decided that the team that was putting in place the communications structure, decided they want to use the first instance of voice over IP commercial voice over IP. It was called hosted IP telephony and it was from Nortel. If folks still remember Nortel, it was from Nortel Networks.

We looked at the approach that they were taking. How we're going to be applying the technology to the Olympic village, et cetera. Dug in the team. They did this amazing work.

When the risk assessment came auro us. But they were able to intercept the conversation, decrypt the conversation and play it back as an MP four like an MP three file. You can actually hear them talking. And it was at the time it was the CEO calling his executive assistant to order lunch, and we had the recorder.

You could actually hear it. It was just as if it was they were speaking to you. So that's a problem when you're trying to keep secure communications between endpoints in a communication path. We wrote up the risk assessment, we presented it to the executives.

We we presented the report up to my chain and it was simple, here's the risk, here's the mitigation strategy. We need a business decision for the path that we wanted to take, and that generated quite the steward. My boss got back to me and said, well, we have to change the report, and no, I said, no, we don't. We don't change the shit.

We just you move it forward. We've objectively uncovered the risk. The team did a fantastic job. Here's attached recording.

If you want to hear it. Let's let let's keep moving forward. So it went up to the next level of management and same thing. Would you all to report?

No? No, I would not move on. Move on. Finally get to the chief security officer and I remember getting the phone call.

It's like, well, Tim, this is this is going to cause concerns. No, it's a business decision. It isn't about concerns. This is the business decision.

What risk is the business willing to accept? So he submitted the report forward. Next thing, I'm getting a call from an executive office assistant telling me that my flight's going to be made for the next day. I'll be flying to present the report.

And I'm like Jesus King, So all right. I got on a plane headed out east, waited forever to talk to the CEO. At the time, and all they asked, all they asked was is this real? Would you change this?

I said, no, the risk is legitimate, and here's the resolution, here's the mitigation path, here's the strategy. So they asked how much we needed. What we needed for time. So it's about six months worth of work with the folks at Nortel to fix the problem, and all of that to state that had we done this old school many years ago, we would have just accepted the risk and move forward with it.

That wasn't our role, that's not our job. Right in that whole path, that whole risk assessment needed to present it to the point where executives understood what could potentially happen. We already proved that it could, but they needed to understand, here's the mitigation strategy. We found a way to resolve it.

We need this additional funding, time resources to fix the problem. So that that stuck with me. That was like almost twenty years like that was over twenty years ago, and that stuck with me because had I altered my report, had I taken away their risk, had he accepted it on behalf of the security team, we don't know what could have happened to the transmissions back and forth of the Olympics. But I do know that in following that process, you never read about anyone's conversations being intercepted at the twenty ten Olympics.

It works, The process works, but what it takes is an understanding that from a risk perspective, this is the path that we have to take. It's not ours to accept. You have to make sure you get that the executives and let them make that decision. Those are the stories that we need folks to hear now as we move into this next base of developing the professional security.

So Nate, you might ask, you know, the CEO had a conversation intercepted ordering lunch. Is this worth? You know? The big deal that it turned into?

You know? And I discussed this offline with Tim and what he came back was is was you know, Andrew think about it. Imagine that you're nine days into the ten day Summer Olympics or two week whatever it is, and someone, you know, pick pick someone. Let's say the Chinese intelligence is found to have been intercepting and listening in on all of the conversations between the various nations teams, coaches, in the various sports and their colleagues back in their home countries.

I've been listening in on them for the whole Olympics. What would that do to the reputation of the Olympics. What would that do to the reputation of Bell Canada. This is a huge issue.

It was a material cost to fix it took six months and he didn't say how many people and how much technology. But this is not something that the security team could say, Okay, you know, we don't have any budget to fix this. Therefore we have to accept the risk. That's the wrong business decision.

When he escalated this, it went all the way up to the CEO, who said, yeah, this needs to be fixed. Take the budget. Fix it. You know, we cannot accept this risk as a business.

That's a business decision the CEO could make. It's not a business decision he could make with the budget authority that he had four levels down in the organization. You mentioned stories at the very beginning when you introduced tailcraft. Can you tell me more about tailcraft?

How does this idea of storytelling dovetail with the work you're doing right now? No, good question, Thanks for that. When I was first designing this idea of what tailcraft could be. We reached out to a good friend of ours here in Calgary, Mike Diego.

He does some amazing work. He spent some time just dissecting what I've done in my career and what I've accomplished. More importantly, some of the things that he wanted to focus on from a company perspective, and one of the parts he brought up and this is how tailcraft was created. The word taiale was.

I spend a significant amount of my time now telling the stories, and it's to help educate and to inform, and stories to influence and to provide meaning and value to executives. But the common theme for all of this has been this concept of telling a story. One of the things I found throughout my career is as security professionals moved through the ranks as they begin, you know, junior levels, moving into their first role as management and moving into director positions and events be chief positions.

The principles and the concepts of being able to tell a story or to communicate effectively with executives. I found that some of my peers weren't doing a great job, or they were I don't know about you, Andrew. But if you sit in a presentation that someone's giving and if all you're reading is the slide deck, Jesus, you could just send that to me. I got this.

I don't need to spend time watching you stagger through a slide deck or the slides that have a couple of thousand words on them that you're expecting us to read from forty feet away. It doesn't happen. So what really bothered me is that we started losing this skill set of being able to tell a story and to effectively use the principles of storytelling to provide input to executives to make decisions for things like budget or resourcing or allocating staff resources, et cetera.

So that's one of the things that we do with Tailcraft is we teach security professionals and others the principle and the concept of storytelling and how the story arc. Those three parts to a story arc that we learned as kids. The beginning of the story, the middle where the conflict occurs, the resolution, and finally the end of the story when when you're closing off and heading back to the village after you slay the dragon. Those three things that we have we learned as kids, they still apply as an adult because we learn as human beings through stories.

We have for hundreds of years, thousands of years used oral history as a way to present a story from one generation to the next. We can use the same skill sets when we're talking to our executives, when we're explaining a new technique to our team, or when we're giving an update in the middle of an incident and how you're going to react to the next problem and how you're going to solve it. Those principles exist. It's reminding people of what the structure is, teaching people how to follow the story arc when they're presenting their material, taking away the noise, the distractions and everything else that gets in the way when we're listening to a story, but focus on the human.

And that's one of the things that we're doing here at Telecraft is we're teaching people to be more human in their approach and the techniques work. I just my wife is up in Edmonton doing a conference right now for the Cio Cio Conference for Canada, and she actually asked me to this is a first folks, for all those of you who are married. You know what kind of a progress I've made. My wife actually asked if I could dissect her presentation and help her with it.

I thought that was pretty amazing. We restructured it so that she was able to use props. She brought in a medical smock and a stethoscope to talk about one of the clients that she worked with. And it sounds like it worked because she got some referrals for folks in the audience and she's spending time right now talking to more clients up in Edmonton.

So yeah, I crossed my fingers. I was going to get through that one, and it seemed to have worked. But these principles of telling a story, if you have a chance to understand how a story works and you're able to replicate that in a security environment, all of a sudden, now you're speaking from a human to a human. You're not bringing in technology, you're not talking about controls, you're not spewing off all of these different firewall rules that we have to go through.

Nobody cares about that stuff. What they want to hear is what's the story and can I link the story to risk And at the top end of that arc, can I provide you an opportunity to reduce the risk and then finish the story by asking for help. If we can do that those types of presentations throughout my career, that's when I've been the most successful is when I can focus on the story I need to tell, get the executives as part of it, and focus on the human reaction to the problem that we have.

That that's one of the things that we're teaching at Telcraft. That makes sense in principle. Let me let me ask you. I mean I again, I do a lot of presentations.

I had an opportunity to present on a sort of an abstract topic at S four, which is the currently the world's biggest ot security focus conference. And you know, if you're curious, it was. The title was Credibility Versus Likelihood, So again a very sort of abstract risky risk type topic. And the the advice I got from Bill Peterson, the organizer, was Andrew, you know, I see your slides.

You can't just read the slides. You've got to come to this presentation armed with examples for every slide, for every second slide, get up there and tell stories, you know. So I would give examples. Sometimes they would be a tax scenarios, you know, is that is that the same kind of thing here?

It is, I think, And congratulations for being asked to present at that conference. That's amazing, So kudos to you. That's awesome, Andrew, that's great to hear. But you're right.

You touched on one of the things that a lot of presentations lack is the credibility or how I view the person providing the presentation. Do they have the authority? Do I look at them as someone who's experienced and understands it. And you do that by telling the story and providing an example for let's say unattacked scenario where you saw how it unfolded, how you're able to detect it, how you're able to contain it, eradicate and recover back.

Those are the stories that people want to hear because it makes it real. For people providing nothing but a technical description of an attack or bringing out us as an example, a CB and breaking it down by different sections on a slide, oh my god, I would probably poke my eye with a fork. But if you walk me through how you identified it work that you guys did to identify, to detect it, to contain it, to eradicate it, and then recover if you can walk me through those steps from a personal example that you've had.

That to me is the story. And that's the part that gets compelling is now you've got someone who's got real world experience, expertise in this particular problem. They were able to solve it, and they provide it to me in a story. So now I can pick up those parts.

I'm going to remember that part of the presentation because you gave me a great example, which is really you gave me a great story. Does that make sense? It does to a degree. Let me let me distract you for a moment here.

I'm not sure this is the same the same topic. But I've again, I've I've written a bit on risk, you know, I've tried to teach people a bit about about what you know, what is risk? How do you manage risk in especially critical infrastructure settings? And I find that a lot of risk assessment reports are you know, it seems to me not very useful.

They're not useful as tools to make business decisions. You get a long list of you know, you still have eight thousand unpatched vulnerabilities in your OT environment. Any questions yes to me? To me, you know, what what business decision makers understand more than you know a list of eight thousand vulnerabilities is attack scenarios.

And so what I've argued is that every risk assessment should finish or lead if you wish with you know in physical security, you're probably more familiar than I am. The concept of design basis threat a description of the capable attack you must defeat. You're designed to defeat with a high degree of confidence. And you look at your existing security poster and decide this class of attack we defeat with a high degree of confidence.

These attacks up here, we don't have that high degree of confidence. And what I've argued should tell the story, go through one or two of these attack scenarios and say, here is an attack that we would not defeat with a high degree of confidence. Is it acceptable that this attack potential is out there? Is that an acceptable risk?

Is that the kind of storytelling we're talking about here? Have I drifted off into some other space? No? I think you've actually applied the principles of telling the story to something as complex as identifying your particular response or your organization's response to either an attack scenario or a more sophisticated attack scenario.

So no, I think you've nailed it. What it does though in the approach that you just talked about, it gives a few things to the business audience. One, you have a greater understanding of the assets that are in place and how they apply to the business environment, whether it's in a physical plant structure for ot, or whether it's a pipeline, et cetera. If you understand the environment that is being targeted, you understand the assets that are in place and the controls that you have there in place.

That gives you a greater understanding and foundations for what is the potential risk. By telling the story then of what a particular attack scenario looks like, and if you have a level of confidence that you'd be able to protect against it, you'd be able to walk through the different parts of the story arc. This is the context of the attack, this is what the attack could look like, Here's how we would try to resolve it if we can. And then here's the closing actions that we would be focused on if the attack was either successful or unsuccessful.

So all of those things I think apply to the principles of telling a story. What you've given is a great example of how to take something that's very technical, or you know, the typical risk assessment I've seen in my career where you know, you nail that, Andrew, here's your two hundred page report, the last ten you know, the last one hundred pages, or all the CVEs we found, and let us know if you needed help. But that doesn't help me. But if you walk me through a particular example where here is in this one set of infrastructure we're liable or we're open to this type of attack, I think that's amazing because it gives the executives the story they need.

You understand the assets, here's the risk, here's the potential impact, Here's what we can and cannot do to defeat or defend against this, and then we need your help if this is a risk that you can't accept. So no, I think you've covered all parts of what would be an appropriate story arc for using that type of approach, and honest to God, if you could get more folks to include that in reports, I would love to see that because I'm like you, I have read too many reports that don't offer value.

But the description you just provided and the way we break it down that offers huge value. To executives moving forward. All right, Well, Tim's spending a lot of time emphasizing the importance of storytelling and conveying security concepts to the people who decisions. Andrew in your experience, is this sort of thing something you think about a lot.

Do you frame your information in the same ways that he's talking about or do you have a different sort of approach? This makes sense to me. It's sort of a step beyond what I usually do. So I'm very much thinking about what he's done and you know how to use it going forward.

But you know, just to give you an example, close to a decade ago, I came out with a report the top twenty cyber attacks on industrial control systems. And it wasn't so much a report looking backward saying what has happened. It's a report looking at what's possible, what kind of capabilities are out there? And I tried to put together a spectrum of attack scenarios with you know, a spectrum of consequences.

Some of the attacks were very simple to carry out and I had almost no consequence. Some of them were really difficult to carry out and would you know, take you down hard and cost organization billions a dollar or you know, dozens of lives and everything in between. And I did that because you know, in my experience, business decision makers understand attack scenarios, you know, better than they understand abstract numeric risk metrics or lists of vulnerabilities. And so, you know, I described it as the tax scenarios.

In hindsight, you know, I think really what I was doing there was telling some stories, and you know, I need to to update that report. I'm going to do it by updating the the it to read in more of a storytelling style, so that you know, people can hear stories about attacks that they do defeat reliably and why, and attacks that they probably will not defeat with a high degree of confidence, and what will be the consequences, so that they can make these business decisions. Yeah, and that sounds nice in theory, But then I'm imagining, you know, you tell your nice story to someone in the position to make a decision with money, and they come back to and say, well, Andrew, your story is very nice, but why can't we defeat all of these attack scenarios.

With the amount of money we're giving you? What do you tell them at that point? Yeah, and that is a very common reaction saying, you know, you've asked us where to draw the line. We draw the line above the most sophisticated attack, fix them all, and then I explain what that's going to cost.

You know, they haven't even really paid attention to the attack scenarios. They haven't even asked me about the attack scenarios. I've just explained the concept of a spectrum. They said, yeah, put it on, put the line on the top.

Fix them all. And then you have to explain the cost, and they go, ohh okay, so what are these and they ask in more detail, and you give them the simplest attack, the simplest story that you do not defeat with a high degree of confidence, and you ask them, you know, is that something we need to fix and they say, yeah, that's nasty. I could see that happening. Fix that.

What else do you got? And you work up the chain and eventually you reach an attack scenario or two where they look at it and say, that's just weird. I mean, let me give you an extreme example. You know, imagine that a foreign power has either bribed or blackmailed every employee in a large company.

You know, what security program, what policy can this the CEO put in place that will defend the organization, Well, there isn't one. You you know, your entire organization is working against you. Is that a credible threat? You know the business is probably going to say no, this is why we have background checks.

This, you know, a conspiracy that at large, the government is going to be you know, going to come in and you know, arrest everyone that's not a credible threat. And so you know the initial reaction might be yeah, fix it all. Draw the line across the very top of the spectrum. And when that becomes clear that you can't do that, this is where you dig into the stories and they have to understand the individual scenarios and they will eventually draw the line and say these three here that you told me about, fix them.

The rest of them just don't seem credible. That's the decision process that you need to go through. And you know, you need to describe the attacks, and I think the right way to describe the attacks is with storytelling. If you know, I don't know a big business is CISO says, you know, tailcraft makes sense to me, and they bring you in, what do you actually do?

Do you do you run seminaris. Do you review reports and give advice? What what does tailcraft actually do? If we if somebody engages with you.

Good question and thank you for ashing that. I appreciate it. So there are a couple of things that we can offer to organizations that bring us in from Tailcrest perspective. First, what we offer, let me talk about storytelling first.

What we offer from the storytelling approach is we will go to the client site. We will run workshops anywhere from a for our workshop to a two day workshop. We will bring team members from the security group as well as others that the security team interacts with. We'll go over the principles of storytelling and the concepts of storytelling, how to be more mindful in your public speaking and in your preparation.

And we'll spend the first day going through the theory and the concepts of telling a story and becoming a better public speaker. Then on the second day of the workshop, we then ask all participants to stand up for up to ten minutes and provide their story. At the end of each one of the sessions, we provide positive feedback and provide them opportunities to grow and experience more storytelling opportunities, and then we close up the workshop, we provide reports back to each of the individuals on how we observed them absorbing all of the content from day one, and then offer opportunities for individual mentoring and coaching along the way.

So that's one of the first services we offer. The second as we can come into organizations. If a CSO or CSO contacts us and ask us for assistance, we can do everything from helping them redesign their security program using the principles of enterprise security risk management, review the current program that they have today, assess the maturity of the controls that they have in place, identify risks that are facing the organization at a strategic level, and then we can come in and help them map out and design a path the greater maturity by assessing the culture of security across the organization as well, where we go on and interview stakeholders from across the organization, from different departments, different divisions, and different levels of employees in the organization and identify their perception of security, the value that security brings to the organization, and how the security team can become greater partners and trusted advisors to the company.

That's part of the work that we do with tailegraph security. I understand as well that you're working with professional associations or something. I mean, I know that in Canada there's the Canadian Information Processing Society. It's not security focused.

Security is an aspect of information processing in the IT space. In Alberta there's a PEGA, the Association for Professional Engineers, Geologists Geophysicists. Did I get that right? Yeah, Okay, we'll cut this out.

And you know, to me, industrial cybersecurity is increasingly becoming part of the engineering profession. I would dearly love to see, you know, these professions embrace cybersecurity and you know, established professional standards for practitioners for you know, what is considered acceptable practice, so that there is sort of a minimum bar. So tell me you're working with these folks, what what is it that you're doing. How's that going?

Yeah? So this and I've been thinking about this for probably the last twenty some years, and it always bothered me that the security you know, the security director, the CISO, et cetera in an organization, if they did get a chance to come to a board meeting or to be invited to act to executives you got a forty five minute time slot. Most times it was less. You had a chance to drink the really good coffee and then you were asked to leave the room and that was your time.

Where your peers who were running other departments across the organization in legal, finance, hr etc. They stayed the entire weekend to help map out the strategy for an organization. Yet we weren't invited to that party, and that kind of annoyed me for the last sun years. So I took it upon myself to begin a journey, and I brought some folks along with me.

There's about fifteen of us now that are working on the concept of designing and developing the profession of security, focusing on Canada first and then working through the Commonwealth model to all those countries that followed the Commonwealth parliamentary system. And it made sense to me. I couldn't do much work when I was the President of ass twenty twenty three. I didn't want to have any perceived conflict of interest or anything that I was doing.

But what we looked at from this concept of designing the profession of security, it's an opportunity for those who call this our profession and want to be recognized as such, to borrow some of the great work that kIPS has done and that a Pega has done here in Alberta, kIPS across the country, to recognize the path that they took, how they were recognized and established, how they developed their charters, etc. So we've had an opportunity to chat with some folks from kIPS, but also to look at the work that they've done.

And I've had a chance to review a Pega and it made sense to me. So now spin forward to twenty twenty five, we have a group of individuals who are focused on designing and developing what we consider to be a model that will provide a professional designation for security professionals in Canada. It's an opportunity to demonstrate your expertise and your body of knowledge. It's an opportunity to take all of the designations that you've received from groups like ISIC Square, at ISACA Asis etc.

Use them as stepping stones to the next level where you're accepted as a professional designation, so that a security designation, whatever we can land on for the postnomenals, would be recognized the same as an engineer or as a doctor or as potentially a lawyer. It gives us the validation of our work that we do. It gives us the recognition of the value that security brings stro an organization, and it ties together OT, it, cyber, physical, all of the different parts of makeup security, and it's a chance for us to come under one umbrella.

So the way I describe it is that you know, for years I said I ran a department, it just happens to be security. Now we can say I'm a security professional and my expertise is in OT security, or in forensics, or in investigations or in crime prevention. Through environmental design, it gives us an umbrella designation for security and a chance to specialize. So a good friend of mine is a surgeon.

He started off as a doctor and now he's a thoracic surgeon. So whenever he recognizes himself is that you know he's a doctor. My specialty's thorastic surgery, and now he's Chief of thoracic Surgery at Vancouver General Hospital. Super great guy.

But the path he took was become a doctor, demonstrate your expertise, spend more time to create your specialty, focus on that be recognized for that, and now that's his designation. I want to do the same here in Canada for security. The reason why is, look, you and I both know this, Andrew, and we've seen this. If I go do a risk assessment for a client or internally, and if I do a bad job, I just go to the next client.

But if we have a doctor or a lawyer who mishandles a file or mishandles an operation, or is liable for their actions, they're held accountable to it. We are not. What I want to be able to do is put in the standards that demonstrate the level of our expertise, that we're held accountable for our actions, that we maintain our credentials throughout our career, that we're able to give back to the profession of security, and that if something does happen, we're actually accountable for the work that we do.

And I think that's important. Right here in our new house and engineer stamped our plans, he's accountable for the work he did. Why can't we have the same for security. I think we need to because then that provides executives a greater understanding of how important the work that we do every day to secure your organization so that you can achieve your goals and objectives.

That's what I've been doing on the side of my desk for the past twenty years. I finally got some breathing room to do it now with Teilcraft giving me the space to do it. So I'm looking forward to trying to roll this thing out between now and the end of the year, at least the structure of it, and then you engage more people to get their comments and their perceptions so that we're trying to reflect and represent as many folks as we can across the security profession. Well, Tim, this has been tremendous.

Again, I look forward to your book. Hopefully you find some time to work on it before we let you go. Can I ask you to sum up for us what are the what should we take away from the discussion we've had in the episode here and use it going forward. Thank you for that.

I appreciate it, and yeah, fingers crossed. I can get working on the book over the summertime, that's my goal. But for this particular episode, I think a couple of things. One, as security professionals, it's not our job to accept the risk.

It's our job to identify it, provide a mitigation strategy, and present it back to executives. So that's that's one of the things that I want to keep stressing for everybody. Our role is to be an advisor to the organization. It's not to accept the risk on behalf of the organization.

Second is, we all have a story to tell. We all understand the value and the power of a story. We all see how important it is when we tell a story to our executives, to our leaders, to our teams, and to others. You need to focus on those skill sets of how to tell us story, particularly in the role of security, because not everyone understands the value that we bring.

And the second and the last point for me is that you need to continue to look for mentors, for instructors, for trainers who can offer you these skill sets and you can provide this type of training for you so that you can continue to build your career. We can't do this alone. You need to make sure that you have an opportunity to reach out to folks that can help you, whether it's looking at your security program and trying to build it on a risk based approach, or teaching people the value of telling a story and then applying those skills the next presentation you give to executives.

If folks remember those things, that'd be terrific. So for those folks listening to the podcast today, if those points resonate with you, and if you're looking for opportunities to learn more about telling a story, of how to be effective doing that, how to look at your program from a risk based approach, and how to find mentors that can help you in your career path, reach out to Tailcraft Security. This is what we do. It's our opportunity to give back to the professional security to help organizations build their security programs and to grow the skill sets of people who want to learn more about telling a story, becoming a better security leader, or understanding the concepts of a risk based approach to security.

That's what we're here at Tailcraft for us to help to give back and to grow. Andrew that seems to have done it with your interview with Tim. Do you have any final word you would like to say us out today? Yeah, I mean, I think this is a really important topic.

I see way too many security teams saying this is my budget, this is all I have budget to do. I do not have budget to solve that problem. Therefore, I will accept the risk of that problem. And you know, especially for new projects, for risks that you know we've never considered before, that is often the wrong decision.

You know, when we have new kinds of decisions to make, we need to escalate those decisions to the people who assign budget. We need to tell those people's stories so they understand the risk. We have to get the right information, the right stories, to the right people so they can make the right decisions. Saying I have no budget, therefore I'm going to accept the risk.

Many times is the wrong decision for the business. And we cannot afford to be making those wrong decisions time again. As you know, as the threat environment becomes more dangerous, as consequences of you know, industrial cyber attacks increase, we need to be making the right decisions. And you know this seems an essential component of making the right decisions.

Well, thanks to to mc create for that. And Andrews always, thank you for speaking with me. It's always a pleasure. Thank you.

This has been the Industrial Security Podcast from Waterfall. Thanks to everyone out there listening.