ERP096 - How To Think About Security

as the organization matures, you can start looking at how to script and how to automate grabbing that data in. But, you know, on that capability maturity model, the measurement and automation side is really clever, but not necessary for most companies. As long as there's some sort of process where we can track the most important things and ideally have a good understanding of the low priority things that exist in the environment. Welcome to Evolved Radio, where we explore the evolution of business and technology. I'm your host, Todd Kane. This episode is brought to you by Evolve Management Training courses, a whole series of courses built specifically for your MSP training needs. There's a project management for MSPs course, an MSP service manager boot camp, MSP security fundamentals, and an IT documentation done right course. Check out the full suite of courses at training.evolvedmgmt. com or look for a link in the show notes. Today on the Evolved Radio podcast, I'm chatting with Alex Dow, Chief Innovation Officer and co-founder of Mirai Security. Alex is an old friend and someone I deeply respect for his experience and knowledge on cyber security. He's worked in the federal security space, securing the Olympics, and now runs a fast growing security consulting firm in Vancouver. Alex is also a returning guest on the podcast. He originally joined me way back in episode 11 when we talked about drone racing. On today's episode, we're discussing the security mindset. What is a good enough cyber security strategy? The buying psychology of the business that is looking for security services and a ton of war stories from Alex's travels in the security world. We even dip into the details of the recent last pass security breach. Please enjoy my conversation with Alex. Alex, welcome to the Evolved Radio podcast. Todd, thanks for having me. All right, let's launch straight into it. I think you have a really great perspective on this as someone who has been stewing in security for for a long, long time. And also like the work that you guys do is is very high level. And you work with very large organizations and some very uh smaller organizations. So a very wide perspective on on the industry. And I think one of the things that I see a lot of and I would love your perspective and on knowing basically what enterprise good enterprise security looks like. And how you can actually properly translate that down to the organizations that don't have, you know, a half million dollar to multi-million dollar budgets to run this stuff. And MSPs often get squeezed in the space of what is good enough, right? Hopefully we're moving away from I've got a firewall and I've got an AV. Hopefully there's some EDR functionality or something like that. But I think there's still much too much prevalence around the idea of tools will save us all. And I'd love your perspective on how should an MSP or a small IT service firm be thinking about SMBIT as what's good enough? Well, I think that's keyword is good enough. My background is working in Ottawa, working in the federal space. Right out of school, taking cyber security throughout school. So I was trained on what a perfect security is. And then for the first part of my career, I I worked in the federal space where like perfect security is almost achievable. When I moved out west, it was a bit of a change because I I really thought my skill set and my experience was actually of high value. But it turns out that, you know, west of Ottawa, companies really don't care about perfect security. And sometimes they didn't even care about security at all. Even though that dogma has changed. So when we're talking about like, well, what is good enough? You know, it's like we don't want to be 11 with security because that means it's probably going to be more expensive. Then what the company can actually make from a revenue perspective. So we have to find that balance. So, first things first is understanding like, well, what's important to the business? Certainly, if you're collecting a bunch of personal identifiable information. banking information and things like that. Confidential confidentiality. is probably pretty important. But there's lots of businesses out there that minus employee data don't really collect a lot of data. And thus their the priority for them is not confidentiality, it's actually availability. And a lot of security folk really get that wrong. Uh particularly in like the heavy industry space where, you know, secrets aren't don't exist in these businesses. So, you know, the first things first is understanding how the business makes money. How does IT support that mission of making money? And what are the important things that enable those businesses to make money? Uh and again that could be ERPs, that could be an email server, etc. That allows you to really prioritize what really needs to be made secure. kept an eye on and and, you know, wrapped with some protections. So when we're we're looking at like, well, what let's build out a cyber security strategy. It's should always be focusing on how to enable that business to make money. And, you know, for the first 10 years in my career, like I actually sort of didn't do that well. I just said everything has to be perfect all the time. And I was really not getting a seat at the table with that attitude. Understanding that security always has to be supporting the business and enabling them to make money. And if I'm suggesting anything that is going to reduce their likelihood of making money. or be more expensive than anything else in their world, we're just not going to get a seat at the table. Yeah, I think that's a really important perspective. I like the idea of like what's core to making money versus like where is all the data and we need to protect that. I think that's a great way to sort of conceptualize where to start. Yeah, it's not a one size fits all situation for a lot of folks, unfortunately. Certainly. And, you know, as I started mentioned on our briefing is is like I'm I'm really trying to explore the psychology of cyber security. And the fud or fear and certainty and doubt is is clearly a a sales tactic. for convincing companies to buy more stuff. I've been consulting since the 2010 Olympic games. And the biggest frustration of mine was companies that ended up buying way too much technology. And what I call sort of like technology rich and people process poor. And I believe there's a fundamental problem with how buyers see solving solutions is they they they think that if they buy more tools or more hammers, they can solve almost anything. And in cyber security it's it's quite different than just we need more connectivity. Well, buy more internet, uh, buy more capacity. But when you're we're talking about managing risk in the context of cyber security. People and process are critical to uh not solving that problem, but at least managing it to an acceptable level. Like when I was consulting, I was getting frustrated that these companies were buying like $100,000 devices and technologies. But never told that, oh, by the way, the the total cost of ownership thing, the the maintenance, the management will be two people, you know, $50,000 a year. Like it was such a a shock to most of these companies that these technologies eventually after their their licenses expire would not be renewed and they would just become something else that sits on the shelf offline and unlicensed. And that frustrated me because some of these technologies were brilliant. and would really provide a lot of clarity to the business in terms of what's going on, that situational awareness. But they never had intended to spend so much money on these technologies and they really thought that that that purchase was the purchase to solve that problem. It was really just a down payment to solving that problem. So, I like that. And I think it it sort of gets back to the the good enough as well. is like and you see this in a lot of cases where you're doing incident response for an organization where something has has gone gone arise. So I think you understand the the threat vectors better and you understand sort of the material outcomes in a lot of cases as well based on sort of your broad approach and broad exposure to to the industry. So with that, like if it's not tools and I get that it's it's contingent on what parts of the organization you need to protect. But if there were just sort of like, what are the first three to five things that independent of what the organization is doing and what the situation is. Or more likely, like what are the areas that you would protect or systems and processes that you would put in place, like just to put that in people's heads of from a prioritization perspective. Are there things that sort of fall in line here or is it really just it depends? Uh you took the words right out of my mouth. I was going to say. Can I use what my lawyer says? Uh it depends. Why it depends is because first of all, many businesses operate quite differently than than than another. So that's going to be reflective of a cultural difference between those companies, which will relate potentially to the technology stacks they use. And and IT generally is can be quite complicated. But, you know, sort of reverting back to, well, what is what does the industry say? Lots of the standards out there are are gathered based off of industry feedback. The center of internet security's critical security controls is a great example of the top 20 security controls that should be implemented in an organization. And it's ordered by priority. So one, control one, which is essentially uh asset inventory is the most important. If you don't know what you have, it is pretty challenging to protect it. But that control alone does not solve cyber security by no means. But and here's the biggest problem is like that's the least sexy cyber security control out there. You know, it's uh do you mean build a spreadsheet and put some stuff in there? Like, yeah, well, you know, having that data. Like when we're doing incident response, knowing what systems are are legitimate systems in an environment are quite important. And if we have to start from scratch on incident response, like that is, you know, potentially hours of trying to sift through the the uh noise to understand what's important to it. So that's a good example and control one and control two are related. One is like hardware based and operating system based and the other is software based. And that's also a a major one. Because. When we're starting to look at like a company that uses a an ERP as an as an example. That's a critical piece of software. We want to know that it exists, what servers it sits on, versioning information, who owns it, who manages it, dependencies and things like that. So that if we ever have to rebuild that system, you know, God forbid you get ransomware and they hit your your ERP. We have some ability to build that up. So I would say like those are, you know, one and two are are the most important. Typically the least considered because it's not it's not fun. It's not a a flashy box, there's no nice advertising at the airport saying, improve your asset management. There there's nothing like that out there. And generally buyers don't go for the most logical, they go for, you know, dare I say it, the whizbang of cyber security. Yeah. I love this. Because I run into this a lot. When I when I'm sort of advising companies on cyber security strategy. And and basically saying. You know, okay, let's look at at some controls or Nist or whatever type of framework you want to implement here. And and let's start from asset controls. And they're like, well. RMM. I'm like, good start. Like let's do an export and do a bit of a maybe a network scan. Let's sweep some IPs, look for anything that you add there. They're like, I don't know. Feels like a lot of work for all the clients that we have, right? Like that that that leg work I think becomes an impediment to this if they can't automate it, right? So what's your what's your perspective on that? Like if they have an RMM, they they're doing some type of agent-based and non-agent-based asset collection. Is that kind of hitting that good enough portion? Yeah, certainly. And and again, even just having a spreadsheet where you sort of track what you know is the most important. Depending on the maturity of the organization, of course, you're going to run into some team deployed some laptops. They didn't know about it. But generally laptops aren't going to be considered the most critical parts of your business. And thus you really want to be focusing on the most critical. And that's typically the stuff that's in your in your server VLAN, assuming you do VLANing. And, you know, that's going to be your active directory server, likely mail. Uh and that that actually spins up an interesting sidebars, well, because we're all sassifying everything. Well, how do we track that? Right. And how do we track it as as the traditional asset? And that's where why critical security controls breaks it up into like hardware assets versus software assets, which I'll translate into software as a service assets. So certainly the agent, the RMM agent is very useful. But what about all the IoT out there? What about your printers, what about your cameras? Cameras are are a great attack factor because they do have a little bit of processing power. They're running a strip down version of Linux and likely. When was the last time you passed your cameras? Yeah. So they can then become an attack vector where attackers can pivot and. So having an understanding of of of of what's in your network. And certainly there's lots of free tools out there to do that network reconnaissance and map is is definitely a winner. There's a commercial ish product called Run Zero, which is uh very, very good at tracking assets across an enterprise. But to your point. It sort of stinks when you have different data sets that you now have to munch together. And if if that's a manual process, it means that it gets done once, maybe once a year, maybe not. And that data gets gets stale. But having that spreadsheet is much better than not having that spreadsheet. And then as the organization matures, you can start looking at how to script and how to automate grabbing that data in. But, you know, on that capability maturity model, the measurement and automation side is really clever, but not necessary for most companies. As long as there's some sort of process where we can track the most important things and ideally have a good understanding of the low priority things that exist in the environment. All right, so I'm going to swing back to governance. Because I'm going to have to get on my soap box on that one. But you mentioned IoT and printers. Like IoT is both in a lot of ways amazing and also incredibly scary to me. Certainly from a security standpoint. Like you said, like. They're they're they're not as easily or they're generally not more as as standardized as they could be. So the management of those assets I think is a lot more work than anything else in the environment. And I think they they're also they show up in a way that's a little less controlled for non-internal IT environments. Like stuff just sort of ends up, like gets added hopefully to a segmented Wi-Fi zone, but often not. Right. Like and cameras is a is a good example of that. These things hopefully start to change, but historically have had very, very lax security. Like most of these devices show up with admin admin as the username and password, right? And the other part with these devices that I mentioned, like even printers. Like I I had a client asked me like, hey, you know, we've got a fleet of, you know, these printers. It's a whole pile of HPs, we've got a couple of Xerox and maybe some other vendor out there. Is there a platform that we can go out and apply all the firmware to them in a unified way? And I was like, God, like that's a good idea. But no vendor would be crazy enough to take on the risk of doing of deploying sort of multiple firmwares to multiple vendor devices, right? So like it just doesn't feel like it's going to exist somewhere where we can end up with a unified platform that oversees all of these disparate devices, right? Yeah, uh, you know, patch management would I think be control three or four in the critical security control space. They do change in order based off of the threat landscape every year. And I know there are some tools out there that that sort of fill the gaps that, you know, Windows update and the various Windows mechanisms do. Uh like that take care of Windows stuff, Microsoft stuff. That's taken care of. Then there's the third party applications that will get your browsers, your Adobes, uh plugged in and updated. But I tend to agree that I don't think that they're going to dive too deep into the rabbit hole of like other things that have IPs on your network. Mainly because first of all, a lot of those things will just never have updates. Sure. So they're just going to live with the vulnerabilities they have. But, you know, there's a much bigger risk of bricking those devices when you're trying to if they allow for remote update capabilities. There's a risk there that you're bricking a printer and then who's responsible for that, etc. And thus they live on the internet. And that's where like, you know, coming from Ottawa, the land of, you know, big iron, data centers and firewalls and all that. I use a firewall in my house, but I don't necessarily recommend, you know, massive firewalling exercise for most companies anymore. As much as I I believe in network segmentation. It's too expensive and it's too much of a challenge for most small medium businesses to do it well. And thus. Go to the cloud. You know, skip over network segmentation, go micro segmentation. Awesome. But if you are going to run infrastructure in your office that you're going to printers and various things. Like consider the beyond corp architecture, which essentially treats the entire network like a Starbucks coffee shop. And thus, even if you have a a printer that's insecure, it can't really pivot anywhere else in the network. Like not to say that it's benign. But it's not able to pivot into the VLAN where your ERP is and start interacting with it. in in that type of architecture model. And that that sort of manages some of the risk of the various things get that get IP addresses in our network that we don't know about. Would this be a zero trust model that you're describing? Well, zero trust, you know, if you ask five people, you'll get six different definitions of zero trust. That's why I'm asking actually because like, does this qualify? I don't know. Like. You know, zero trust is uh, you know, so my my belief and understanding of it. It is really about, you know, I'm almost like, do I even want to publicly say what what my belief is? It's really about making sure that we can authenticate by directionally and that authentication is not just a a single mode of a password or something, but various other characteristics. However, you know, if you look at all the market architecture online, zero trust can be 101 different things. The beyond corp model is something that Google defined actually and just said, you know, we should be not trying to make all these like walled in gardens within our corporate environments. And really believe that all our critical data should be obviously on a separate network. But likely whether it's in the office or out on the cloud, it still feels the same for the user. Um and thus you enable your user to have, you know, high-speed connectivity wherever they are. They don't have to have all these like hoops and jumps to go through AKA VPNs to access that data. And we should be actually moving the sort of the authentication and the access control layer up the OSI stack to the application layer rather than trying to rely on on like layer three and layer four. Which isn't that great to do and we've been able to prove that now that like that type of network segmentation is not perfect. And if if you're only putting authentication and access control those layers, you will have more problems. Whereas we have to sort of, you know, to sort of replay the the cliche statement these days that identity is the new perimeter. We should be using identity at those applications to to determine whether you have access or not to those systems. You shouldn't be using what VLAN are you on, are you VPNing in, things like that because a lot of that can be spoofed. And, you know, if you have a a compromised printer in your trusted VLAN, do you now trust that printer to talk to your critical systems? Yeah. Yeah, it's tricky. It's uh I mean it's such a shifting landscape. I think this is part of the the excitement around security is is uh this is always what I've loved about computers as a whole. Is I always joke. You know, it's an industry with a six-month shelf life. Because and so you'll have to be perpetually learning in order to stay current. But, you know, like six weeks is a long time it feels like in security as well, right? You know, perpetual learner is actually an attribute I look for when I'm trying to hire people. Yeah, I bet. In our company. And maybe because like that's that's the cloth I'm cut from. I at least have a master's in YouTube University at this point in a variety of subjects well outside of uh uh computers and technology. Because I'm just very curious, I want to know, I need an inch deep knowledge of everything. In fact, uh last week I was sitting down with a CISO that's background is in meteorology. So I was like, oh, that's amazing. Let's talk. I want to know more. What's interesting about the what you said about how how the industry changes so much. This is actually a contributing factor to why, you know, there's the argument that there's a skill shortage. There's burnout, there's things like uh there's a lot of impediments to being able to run a successful team and long term. What's interesting about it is. You know, if you want to be a doctor, you go to school for, you know, seven years or something like that. It it's intense, you learn a lot, your brain explodes. But then you become a doctor. And then it's really about going to, you know, conferences once or twice a year and you get this like microscopic incremental knowledge increase. And that's what a lot of people were trained to when you go to school, you go to university, you get a job, then you just have a job. Our sector is entirely different. You do spend up to four years in school. And then you get out and you realize that you don't know anything beyond what perfect security is. Which will just shoot you in the foot. And then you have to start learning real security and real technology. And that's changing as you're learning it. So people that sort of expect the, all right, I've I'm I'm done college, I'm done university. You know, I'm I'm good, now it's just I get a job, I get a family, I get a house. You know, insert Fight Club quote here. That's not the reality. The reality is is that you actually just started learning when you got into the career. Because now you've actually narrowly focused on what you're probably going to be doing in your career. And now you need to focus on that specific discipline. And understanding what changed yesterday. And that burns a lot of people out, that that that volumetric amount of of of of not even noise signal of things that we need to care about. I tend to thrive on it, but I know a lot of people get very overwhelmed. So. potentially a great space for uh people with either uh diagnosed or self-diagnosed ADHD. Like like a lot of things, a lot of inputs kind of keeps you busy and and as long as you feel like you have some mastery over something. It's probably incredibly rewarding in that way, right? Precisely. And. I I was diagnosed as a as a child with ADHD. But it was fashionable then if you're a a young boy. You clearly had it. Um, but I do recognize those traits and I I love just going deep on something. And then moving on the next day. And and that's really why I I run a home lab, I I run infrastructure at home. So that on, you know, Thursday or Friday, I'm reading about a new open source project. Saturday and Sunday, I'm implementing and testing it out. Yeah. Yeah. All right, so we'll spin back to governance. Because I wanted to get on my soap box here. This is a this is one area that I I feel like and maybe you can back me up or correct me if I'm wrong here. Feel free. But in our industry, especially sort of the technical nature of the industry, people uh and by no means am I sort of bashing the technology. There are great technologies out there that are enabling people to do things easier, right? And so the technology is absolutely a a crucial point. But I think what people misunderstand about it is that is not the be all and end all. And and I feel like there's either not a focus, sometimes an active resistance around the actual governance. And I feel like governance is far more important than anything else in the space. Because you can set something up that's sort of secure and if you understand how it should operate. Then any deviation from that, you're looking for things like the the sort of that again, that signal in the noise of like things will be happening. Wait, hang on, we shouldn't expect this to happen. But without some type of governance around what should and shouldn't happen in an environment, I think it makes it incredibly difficult. And if people I think just really focused on the process rather than the technology of security, we'd probably be in a better space. And one of the things that really scares me is when technology people, you know, running a say like an MSP. We're they say, well, we're going to spin up like an MSSP on the other side of this business. It's like, whoa. Okay, hold your horses, like if you have great people that have been souped in technology for at least maybe the last four or five years. Then maybe that's a good idea. But, you know, this is not just simply a business approach, there's a total mindset shift as far as being good at security, right? So am I off base here, anything you would correct on that? Uh no. So, you know, governance. You know, so I'm a geek at heart. And, you know, my my GRC team will will be cringing when when they hear me say this, but governance is a bit boring. But it's it is entirely necessary because, you know, governance is a a fairly broad description. But at the end of the day, we need a a north star, we need to know what the business has said they want to do to manage risk. So in the context of I'm using governance in terms of, you know, on the policy side is this is. We understand that there's a risks, we want to manage it by having a network security policy. Hiring a CISO, whatever the case may be. That's the the high-level description of how the company wants to manage risk. So that when you're making decisions, it should always be mapping or tracing back to the policy documents, the guides and the standards. The problem is is that, you know, right, you know, having the bigger picture understanding and writing that down is not something that smaller companies really it doesn't come naturally to them. And thus, you end up with a a bit of a patchwork quilt of of strategy depending on who's working at the time, the skill set, etc. But, you know, I think it's incredibly important. And it's important mainly because there's no way you're going to be able to manage all risk to an acceptable level. Again, we run out of money. By doing that strategy. So that's not a good strategy. Businesses don't do that. But we need to have a governance framework in place so that we can have that conversation and it's pre-defined conversation. So that when we say like, do we do or do not, it can map back to what have we said we want to do to manage risk. And if we need an exception, then let's start following that accountability chain up to who signs off on those uh governance policies. Then we can have that conversation. Without governance, we don't know exactly what we're doing. And, you know, to my point earlier is we sort of them by the whizbang rather than the most important foundational pieces to cyber security risk management. I feel like that goes back to actually where we started then, right? Because I I I love this idea and sort of the way that you reframe that actually because I'm a big fan of sort of lean principles in IT because you can't boil the ocean from a technology perspective. There is literally too much to do and not enough time and resources to do it. So you really need to prioritize and figure out what are the things that will create maximum value for us. What I I understand you're saying is same thing from a security and governance perspective. It's it's much easier to protect the house if you know what doors and windows you've agreed to protect and why they're relevant and important to the business. And not that this isn't important or that it's not a threat vector. It's deprioritized, so therefore we're focusing our time and energy in this place rather than there. And I think that's incredibly important. Because you mentioned, you know, burnout and all of those issues that are prevalent in a lot of IT teams related to security. Because they're so panicked about the risk and they feel sort of this level of of of of risk is so high. Their ability to control it and to manage it and to sort of side step the risk that exists is limited. And when they try to tackle everything, that will inevitably lead to to burnout. Certainly. And there was an article last week that said, you know, like CISOs are the most unhappy people in the technology space. And, you know, I tend to agree. CISOs, you know, is a prestigious job. But it's a short time job. Because you're usually brought in, hopefully not, but potentially as a figure head. You come in, you try to overlay your experience from your past roles to protect. And you either get a lot of friction on trying to make some incremental changes to, you know, improve security maturity in the organization. Or they get breached and well, you're the fall guy or girl. So, you know, in that sense it it is a a a pretty stressful role to be in. Um that there's there's arguably never really a success point in that type of role. And one thing that's like worth conveying when you're in those types of roles is like we're going to get breached. Like. It it's sort of an inevitability. It could be benign, it could be annoying. But it also could be catastrophic. So the strategy should not be let's be secure because secure, you know, trying to chew on the what what is the definition of secure? It's like. We know it's good based off of what we've tested. Well, what have you tested? Nothing. So it it's this, you know, Schrodinger's cat problem of are we secure, are we not? So rather than trying to say we're going to secure ourselves to be super secure and never get breached. Let's just accept that breach is an inevitability. Albeit it could be super annoying and small, but it could be bad. So let's design our systems to limit the blast radius. Let's like. Let's make sure that when we are breached, we're not down for weeks. We're not having to rebuild our ERP system. We're not uh having to notify all our employees or clients that their most sensitive data is now being sold on the dark market. So. Those types of strategies I think are really critical to the organization and then on top of that is then practicing a breach scenario with table top exercises. So that we understand, you know, the pain and and what not. And really test our assumptions of are we ready, are we really minimizing the the blast radius uh that we're expecting out of, you know, our design and whatnot. So I'm I'm a big fan of that strategy rather than trying to boil the ocean and and say, we're we're 99.999% secure. Because that's not really a thing. Yeah. I love that idea. And I this is part of the reason that I love running table top exercises for these things. Is you often find people go into those exercises, especially like if they don't have a deep history on this and they're they're they're sort of getting started in their their security and and governance journey. Is they tend to default and very quickly pivot to the corrective technology of like. All right, what would we do from a technical perspective to resolve this issue? And one of the things that I often try to communicate in a table top exercise is. Don't jump to those conclusions. And there's a lot of good reasons why. Is A, you may not know exactly what's going on. B, if you start fixing things, you're protecting potentially stepping on forensic evidence. And and C, like like add to list, basically. There's all kinds of sort of issues of like containment is like the first thing that you should go to, right? So like, hang on, what is this, it's not expanding its footprint and taking over the environment. But you're not necessarily eradicating it straight off the bat either. And that a lot of that just comes down to. Like you said, being prepared for this and having some type of incident response uh that is is a playbook that you can go to. And first thing I often tell people is like. First step in an incident response is call the team that is responsible for the incident response. Like organize the group. Like don't go defaulting to like let's fix this. Like like get everybody together on a phone call or a teams meeting and be like, all right, you're responsible for this, this, this and this. You're responsible for these things. Everybody go, right? And all start reporting back. Like that that uh execution plan is so foundational to those things. But it's often overlooked for people that have not gone through those experiments and and run table tops before, right? Absolutely. And. You know, in in fact, like when I run table tops, we, you know, we'll have a preamble slide deck. That like, this is how the game will run, this is like how it should operate, etc. And I have a slide that takes a picture of the jump to conclusions mat from the movie Office space. And it's like that it's not about serving solving the murder mystery immediately. It's about testing process. It's about it's about detecting where there's flaws in process. Where an edge case can really throw you off. But generally us geeks when we do one when we do table tops that are more technically focused, us geeks just like instantly in our head go through the flowchart of like, oh. This is how we solve the murder mystery. Anytime I get a a guy or girl that's over zealous IT person that's just solving it rather than going through the process. They get uh uh a free vacation that day. And they're off. And again, that's a great test. Because it it test real world scenarios of the the smartest person on the team is on holiday. On a boat, unreachable. Well, what do you do? And, you know, you know, they're always very very frustrated that they got kicked off and they and they can't. But we need to really reflect what reality is. The other thing I wanted to mention is like. You know, a recent breach at a mining company, they had been hit by ransomware, it had hit their IT side. And it was unknown if it had hit their operating technology side. Essentially, what breaks the rocks. And they were so concerned that the malware could have gotten into the operating technology side. Which could, you know, stop the business, but more so kill people if the technology goes haywire. They ended up shutting down operations for two weeks. And the reason for that and going back to what we were discussing earlier is like they didn't really know what assets were in their environment. And they didn't have a lot of visibility of like where the malware had spread to. So in an abundance of caution, they cut off the operating technology side. Which then stopped production. Two, the, you know, the the wall between IT and OT was a firewall. But misconfigured to allow pretty much anything to go back and forth. So pretty much a very expensive router at that point. But because of all these unknowns, their containment action was to cut off the like critical part of their business to make sure that it uh that there was no further impact. Unfortunately. It still did have an impact of cutting it off because it stopped production for two weeks. And in the mining sector, that's catastrophic, that's arguably worth worse than injuries and accidents happening. When you have to stop production for uh multi-days. The millions of dollars being being lost at that rate, right? Certainly. All right, so on that, I guess, one of the other things that you kind of mentioned some experience with and and perspective on. We wanted to hit on the the last pass breach, which is just like this uh steam rolling or snowballing breach. That like every every month it seems they put out a release and it somehow gets worse. Like you think it's bad enough. Then it just continues to get worse. It's kind of like car wreck, like rubber necking amazing to to watch this continue to go on. And one of the things that you mentioned, I'd love you to sort of maybe reiterate this and expand upon it is last pass was a sock two certified organization. And if you understand the breach and maybe you can give your perspective on how this where this breach came from, what the vector was, but the fact that they're a sock two certified organization and the way that the threat actors got into this environment and squaring those two things together is really kind of strange. And gives you maybe a perspective on on, you know, again, sort of what are the limits of some of the governance and the process that you can put on protecting an organization. So I'll I'll switch it back to you, last pass and sock two. Well, I think the compliance does not equal security. will be the hill I'll die on. I think, you know, sock two has become quite popular over the last say four or five years. And. It's a little different than some of the other larger frameworks because it's I guess it's a little bit easier to digest. I think the good of it is that it helps everyone start speaking the same language. And talking about like, hey, we need to start defining processes. And. We need to document these these things and we have to actually be doing them. And sock two type two, so sock one type one says write the write what you're doing. And then type two is, let's validate that what you're doing is happening and it actually has a net benefit. So that's really like I think that's solid. Generally speaking, from service organizations, whether it's SAS or MSPs, having these process written down and validating that they're happening. I think it's really important. The bad is is that sock two type twos are sort of being considered the. Well, they're secure then. Right. And, you know, when when preparing for this this call, I'm like, I guarantee last pass was a sock two type two certified. In fact, they were also ISO 27,000, which is a much more formidable framework. And I think this really goes to show that there are going to be limitations on on governance, on what it can do and and generally it's we're not following what we said we're we're we're doing. Uh or what we've written down uh didn't really address the risks that materialize. And and that's actually a really good point. Is that policies like, you know, generally, you know, when I took my CISSP and the, you know, went to school, it was always like, yeah, policies are updated annually, reviewed, etc. The point of that is to make sure that your your governance documents reflect reality and the the threat landscape that is targeting your organization. If you're just like signing it every year without reading it. And being like, oh, are we addressing this problem? Well, that is the problem. And. You know, with last pass, you know, without going into the technical details. It was A, one of one of if not the largest password tools out there. It had been acquired years ago by a larger organization. And generally when we see that, we see the sort of innovation and knowledge, the brain trust of those organizations leave after acquisition, they go and buy Lamborghinis and drive off into the sunset. So you end up with these softwares that have legacy code, a new development team having to like learn and and generally there's no appetite to learn what is exists. You're building new features and stuff on top of it. And then, you know, there's some skeletons in the closet. And in last pass's case, there were some really poor choices from an architecture perspective. Which is what ruined my Christmas. Because when I started reading about this, you know, drinking my hot chocolate by the fire, my jaw dropped. Because for a tool that's supposed to keep things secret, it only kept the password field secret. All other fields were not encrypted. So when the vault all the vaults got stolen, the note field was not encrypted. And I don't, you know, for recovery passwords and questions, I don't put legit answers. I think Sarah Palin has learned her lesson on having questions that are answerable by Wikipedia pages. Um, so I put, you know, you know, gibberish in there. But now that was fully exposed. And they didn't even need to know my master password. They didn't need to crack anything. They just need to open it up. So I had to spend six hours going through everything in last pass, changing it. Not changing the password, but changing the password, the recovery questions and uh and then the MFA tokens. That was a slog. Um and that was prior to them learning that the the second part of the puzzle of that breach. Was that one of four developers with keys to the castle lost that that key to the castle to the master vault of all the secrets for last pass. And what's really fascinating and I I I plan on writing something on LinkedIn about it. Because it's near and dear to my heart. Is he was compromised by some of his home infrastructure not being taken care of. Uh not being updated. And this goes back to like, you know, the first few minutes of our conversation is like, are you doing are you taking care of of of the house in terms of inventory and patch management? Right. Well, wasn't. And I was able to pull up the article. So um. He was compromised by um a media streaming server called Plex. Very, very popular. Unpatched. Unpatched. And it was unpatched. It was 75 versions old. Like. At the end of the day, like generally that's considered an negligence. Right. Now again, this is a home network and and whatnot. But because the home network, you know, had access to a laptop that was a work laptop. And they were able to get in that way. It spins up an interesting conversation. Because I love building out infrastructure at home. And most of the time it works, sometimes it ruins my weekends with the users very upset. Lights can't turn on and can't watch uh Netflix and whatnot. But I have it very segmented so that my work stuff is never going to be impacted by any of the open source software that I play with. And it sounds like in this case, there was no real segmentation of that data, which then resulted in them pivoting off of, you know, essentially an open source free software. onto a laptop, put a key logger on and then intercepted the password. Yeah. It's wild. Like this this one. When when I realized it was it was like threat vector was a key logger and the guy's home laptop. I was just like, oh my God. Like. And then like the deeper knowledge of it not being patched. Like like if if you're working in this industry. You would hope you know better in these circumstances, but it just goes to show what you were saying before about the sock two piece. Is like governance and process are great, but like the human condition and the behaviors of the organization are always going to trump that, right? Like it bothers me when people say, you know, this and this isn't working in the organization. In order to do this better, we need to write a policy for it. I'm like, really? Is that what you need to do? Because if you write the policy that suddenly corrects everyone's behavior, it actually doesn't work that way. I I said. Like governance is crucial, but I think what you said of verifying that the behaviors actually match what you expect in the policy and the governance. Is far more important than the the governance and the policy itself in a lot of cases as evidence by this breach, you know? Certainly. And, you know, I I would say that yes. We need to write a policy or update our policy to address a new threat vector. Uh but also increasing awareness. Uh and you know, awareness is not just don't click on these emails, but how to do things appropriately. And and you know, companies that do security awareness once a year, throw on a couple videos, put people to sleep, are not moving the needle forward. Especially, you know, with the threat landscape changing on a daily or weekly basis. You know, I I am a bit surprised that, you know, 70 versions behind. Sounds like a server in his closet that just had been forgotten about. And. That brings up an interesting topic that of course, you know, we we're running, you know, low-end cameras and printers that are all vulnerable in our network. And and, you know, that's not going to change. Because we don't have the appetite to pay for what it actually costs for a printer that doesn't have flaws in it. So then it goes to, okay, well, how do we manage those risks with BYOD? And certainly. It was on a personal laptop that the key logger got installed on, but he was accessing corporate assets and systems through that personal laptop. And and what's interesting here is that in order to get good antivirus and EDR type solutions. You got to pay for it. And who at home is paying for any of that stuff, so you end up with, you know, random AV, free AV online or or whatnot. Which again, just really doesn't hold a candle to some of the threats out there. But and I would say the last pass threat actor is is likely a little beyond a script kitty. It's probably nation state level tactics. So you know, we we have to recognize that that that's going to be hard to defend against. Yeah. So we have to say, okay. Well, maybe we really particularly for like the keys to the castle type systems, those really can only be accessed through a corporately managed device. Or some sort of bastion host that like really reduces the likelihood of a of a key logger being able to intercept those credentials. And ideally putting uh multi-factor authentication on there. Which again, increases the cost to the attacker to gain access. Not to say it's it's creating an impossible unhackable system. Quite contrary, but at least you're increasing the cost to a point where the hacker's getting more losses than wins. So actually on that. I I you would be a great person to ask this. I I've sort of hinged on this Microsoft research that they put out, so it's probably a few years ago, two, almost three years ago, maybe, where they said, I think it was upwards of 82%. 82, 84% of attacks were limited or mitigated by 2FA. So I use this as a stat of like, like like 2FA all things. It's sort of my mantra. Because, you know, you're basically eliminating the attack surface for so many things. Someone recently told me that that number had actually been pushed down closer to 50. Is because of there's sort of more advanced or sort of better ways to to co-op or get past MFA. Is is that right? Or would you still sort of say MFA is a is a is a strong tool? Obviously it is. But 85 or 50. Where would you put that? Uh, it depends. It depends on on what type of MFA you're talking about. Saying like true true MFA. Not SMS. SMS, you like you can easily get past that. But actual MFA with a token or of of some current, right? Totally. So and that's what I mean, like the SMS stuff, uh like there are hacking crews that specialize in doing SIM swaps to be able to intercept that. Yeah, so and Twitter actually just made a decision to not offer that unless you pay for it and forcing users to use better solutions out there. So, you know, as as SMS is probably the lowest end and and has flaws in it, we've known about them for for for many years. As we start going up to, you know, one-time password authentication apps, you know, Microsoft is pushing both uh that plus also to prove that the you have the device in your hand. You have to sort of match numbers on the screen. All the way up to the actual physical hardware tokens, which we've been familiar with for uh a number of years. That gradient as you ascend that will have more resiliency against, you know, a threat actor trying to get around it. Now that said. Even last week I was reading about an MFA bypass solution because there are potential conditions where you can trick the application into believing that it you've already been approved. And like one of the ones last year or the year before was was the Golden ticket where you're able to convince, I think it was Azure AD that you already have uh been authenticated through MFA and thus you don't need to uh again. Um so there's always going to be a bit of a cat and mouse. But like at the end of the day, it's not like let's be perfectly secure and solve all all risk management, it's about increasing the cost to the attackers so that they they move on. And that, you know, equates to the Canadian version, which is you don't have to be faster than the bear, you just have to be faster than the slowest person. Yep. Excellent. This has been really fascinating, uh Alex. I appreciate your time and and your your expertise and advice here. Uh any parting words of wisdom for the security minded or the people that are trying to be more security minded going forward? That's a great question. You know, it it. I I think it's just becoming aware and making sure that like the important things in your life, you know, looking at from a personal perspective is, you know, are the important things in your life, your banking, your taxes and I guess like, you know, sadly your Gmail account. Make sure those are protected, make sure that they're protected with MFA. Because at the end of the end of the day, those small benign attacks into your Gmail account will likely equate to a larger attack in your system. So, you know, from that's from the personal perspective. From an enterprise perspective is trying to understand what is most critical to the business. And really trying to find a really good balance of that that people process and technology thing. There's some great technologies out there, but they have uh detracting value. If you don't invest properly in the people and process side of it. Very well put. Appreciate your time, Alex. Thanks. Thank you, Todd. Part of the MSP Radio Network.