WEBVTT 1 00:00:00.160 --> 00:00:02.640 Welcome to the deep dive. We cut through all that 2 00:00:02.720 --> 00:00:06.160 information noise to bring you the insights you really need. Today, 3 00:00:06.320 --> 00:00:09.359 we're tackling a topic that, let's be honest, often feels 4 00:00:09.400 --> 00:00:13.720 like this huge complicated puzzle, cybersecurity for businesses. It can 5 00:00:13.759 --> 00:00:17.800 seem overwhelming, right, constant threats, it's always changing, super complex. 6 00:00:18.359 --> 00:00:20.640 But what if there's a simpler way to look at it. Okay, 7 00:00:20.719 --> 00:00:23.079 let's unpack this. We're not just diving into the tech 8 00:00:23.160 --> 00:00:27.399 side of things today. We're looking at enterprise cybersecurity from 9 00:00:27.600 --> 00:00:31.320 well a business perspective, how it all fits together. Our 10 00:00:31.359 --> 00:00:33.560 guide for this deep dive is actually a quick start formwork. 11 00:00:33.560 --> 00:00:36.359 It's designed to give businesses something practical, something they can 12 00:00:36.399 --> 00:00:39.840 actually implement for security ops. So our mission for you, 13 00:00:40.000 --> 00:00:42.640 our listener, is to cut through that noise. We want 14 00:00:42.640 --> 00:00:45.280 to give you the key takeaways on how businesses can 15 00:00:45.359 --> 00:00:50.119 genuinely protect themselves, maybe even streamline things, boost the bottom line, 16 00:00:50.320 --> 00:00:53.200 all through a smart security strategy. And you don't need 17 00:00:53.240 --> 00:00:55.320 to be a hardcore cyber expert to get it. 18 00:00:55.439 --> 00:00:57.840 Yeah, and what's fascinating here is just how often cyber 19 00:00:57.880 --> 00:01:01.320 professionals feel like they're out there alone. You know, they're 20 00:01:01.320 --> 00:01:06.000 the protectors, but they're battling internal politics, budget cuts. It's 21 00:01:06.439 --> 00:01:09.879 tough and the core issue this guide points out a 22 00:01:09.920 --> 00:01:14.519 lot of the existing security frameworks. They're good, but very theoretical. 23 00:01:14.680 --> 00:01:18.439 They often lack that practical how to guidance. So you 24 00:01:18.480 --> 00:01:21.719 see businesses doing things in totally different ways and sometimes 25 00:01:21.760 --> 00:01:24.519 well it's just not enough. That's really where ZORMA comes 26 00:01:24.519 --> 00:01:28.959 in the enterprise security Operations risk management architecture. It's designed 27 00:01:29.000 --> 00:01:31.920 specifically to bridge that theory practice gap. It gives you 28 00:01:31.920 --> 00:01:35.840 a uniform, adaptable system that really focuses on the practical implementation, 29 00:01:36.400 --> 00:01:39.200 you know, for businesses of all shapes and sizes. 30 00:01:39.159 --> 00:01:41.840 That business first angle and ISZOMA really does sound like 31 00:01:41.840 --> 00:01:44.319 a potential game changer. But I'm wondering how does it 32 00:01:44.359 --> 00:01:46.959 fit in with everything else You've got NIST ISO twenty 33 00:01:47.000 --> 00:01:50.560 seven zero one, all those big certifications. Does thesearma replace them? 34 00:01:50.760 --> 00:01:53.400 No, not at all. It's designed as a practical layer 35 00:01:53.400 --> 00:01:56.799 on top. Think of it like this NIST or ISO 36 00:01:57.000 --> 00:02:00.640 might be the architectural blueprints for your house is more 37 00:02:00.719 --> 00:02:03.319 like the detailed construction manual that tells you how to 38 00:02:03.319 --> 00:02:06.519 actually build it step by step. Its main purpose is 39 00:02:06.560 --> 00:02:10.000 really empowering those cyberfolks to talk the language of management, 40 00:02:10.520 --> 00:02:15.120 not just tex specs, but risk versus return dollars and cents. Basically, 41 00:02:15.599 --> 00:02:17.560 that's how you get past that talking to a brick 42 00:02:17.599 --> 00:02:21.240 wall feeling sometimes and at its core, ESORMA uses these 43 00:02:21.280 --> 00:02:24.280 eight practical domains. People often picture it like a star, 44 00:02:24.400 --> 00:02:26.719 and right in the middle, the very center is scope. 45 00:02:26.879 --> 00:02:28.840 Okay, scope at the center. If we connect this to 46 00:02:28.840 --> 00:02:31.800 the bigger picture, that sounds foundational. So what's the main 47 00:02:31.840 --> 00:02:34.719 idea there? Why is getting this scope right so so important? 48 00:02:34.879 --> 00:02:38.560 Well, scoping is all about identification, but it's continuous, it's 49 00:02:38.560 --> 00:02:41.639 not a one off, and it's vital because frankly, it 50 00:02:41.719 --> 00:02:44.479 saves time and money down the line. It helps break 51 00:02:44.520 --> 00:02:49.120 down what feels like this massive, overwhelming job into manageable chunks. 52 00:02:49.439 --> 00:02:52.800 It starts simply what do you actually need to protect? 53 00:02:53.599 --> 00:02:56.280 And nine times out of ten, that starts with your data. 54 00:02:56.879 --> 00:03:00.360 So two key steps here. First, you categorize it. Is 55 00:03:00.400 --> 00:03:04.759 it personal data, is it sensitive company secrets or just 56 00:03:04.840 --> 00:03:07.840 general internal stuff. Then you classify it based on how 57 00:03:07.840 --> 00:03:12.240 critical it is strictly confidential, confidential, internal, may be restricted 58 00:03:12.479 --> 00:03:15.560 or even public. That classication tells you how much effort 59 00:03:15.560 --> 00:03:17.280 you need to put into protecting it makes sense. 60 00:03:17.319 --> 00:03:19.039 You wouldn't guard a public for sure, the same way 61 00:03:19.080 --> 00:03:21.120 you guard customer credit card number exactly. 62 00:03:21.560 --> 00:03:23.879 And the guides suggest some really practical tools for this, 63 00:03:24.000 --> 00:03:27.400 like an information asset register. It's essentially a detailed list 64 00:03:27.599 --> 00:03:29.840 what's the data, who owns it, what's it worth, where 65 00:03:29.879 --> 00:03:32.159 is how's it classified? All in one place. Then there's 66 00:03:32.159 --> 00:03:35.800 a geomapping tool super important. Now with cloud storage, right, 67 00:03:36.080 --> 00:03:37.280 data can be anywhere in the world. 68 00:03:37.439 --> 00:03:38.319 Yeah, definitely. 69 00:03:38.560 --> 00:03:41.599 An information flow map helps you see how data actually 70 00:03:41.639 --> 00:03:44.759 moves around your systems, where does it go. You've also 71 00:03:44.800 --> 00:03:48.039 got things like a corporate role calculator helps figure out 72 00:03:48.080 --> 00:03:50.840 if you're a data controller or a processor under laws 73 00:03:50.879 --> 00:03:54.639 like GDPR, and even a simple fishbone diagram can be 74 00:03:54.680 --> 00:03:57.479 great for digging into the root causes of potential risks. 75 00:03:57.599 --> 00:03:59.479 A fishbone diagram interesting. 76 00:03:59.680 --> 00:04:04.080 Yeah, and the source tells this great little story about 77 00:04:04.120 --> 00:04:08.639 a haunted telecoms room in a modern government building, classic 78 00:04:08.680 --> 00:04:12.080 legacy system, totally forgotten, full of risks nobody dealt with 79 00:04:12.240 --> 00:04:15.080 because it was never properly scoped, just sitting there. 80 00:04:15.120 --> 00:04:17.480 Wow, Okay, that really paints a picture. 81 00:04:17.639 --> 00:04:20.480 It does, and it shows scoping isn't just for the techies. 82 00:04:20.720 --> 00:04:25.040 It's fundamental governance, especially vital. If there's an emergency. 83 00:04:24.759 --> 00:04:27.079 That haunted room story is brilliant. It makes you think 84 00:04:27.120 --> 00:04:29.319 what else is lurking out there, doesn't it? So once 85 00:04:29.319 --> 00:04:31.839 you've done all that scoping mapped everything out, it can 86 00:04:31.879 --> 00:04:33.800 still feel like a huge amount to deal with. So 87 00:04:33.879 --> 00:04:36.519 what's the next step? Anysorma, how do you know, cut 88 00:04:36.519 --> 00:04:38.680 through it all and figure out what to focus on first? 89 00:04:39.040 --> 00:04:43.480 That leads us straight into Domain two priority perfect transition. 90 00:04:43.680 --> 00:04:47.279 I mean, think about it. Businesses face thousands of potential 91 00:04:47.319 --> 00:04:51.319 threats every day. You absolutely have to prioritize. Otherwise you 92 00:04:51.319 --> 00:04:53.879 spread your resources too thin, waste effort on things that 93 00:04:53.920 --> 00:04:57.000 aren't the biggest risks. It's about focusing on the essentials. 94 00:04:57.160 --> 00:05:00.720 Right focus is key. How does the framework suggest measuring 95 00:05:00.839 --> 00:05:02.839 risk to help with that prioritizing? 96 00:05:03.240 --> 00:05:06.160 It talks about two main ways. First is quantitative. That's 97 00:05:06.160 --> 00:05:07.879 where you put a number on it, usually a currency 98 00:05:07.959 --> 00:05:10.800 value like dollars or euros. How much could this risk 99 00:05:10.879 --> 00:05:14.279 cost us? It's precise, good for comparing things, but it 100 00:05:14.279 --> 00:05:17.399 can take more time and effort. The other way is qualitative. 101 00:05:17.959 --> 00:05:21.120 This is more based on well human knowledge and intuition 102 00:05:21.480 --> 00:05:25.519 your rank risks like small, medium, large, or high medium low. 103 00:05:25.920 --> 00:05:28.360 It's faster, often less expensive to start with. 104 00:05:28.480 --> 00:05:31.680 Okay, numbers versus judgment calls essentially sort. 105 00:05:31.519 --> 00:05:34.079 Of yeah, And when we talk risk, we have to 106 00:05:34.120 --> 00:05:38.040 mention human risk factors. There's this common idea that people 107 00:05:38.079 --> 00:05:41.920 are the weakest link in security, but honestly, more often 108 00:05:42.040 --> 00:05:45.279 it's the processes that let people down, or maybe they 109 00:05:45.319 --> 00:05:47.879 just don't understand why a security control is there, so 110 00:05:47.920 --> 00:05:51.480 they find a workaround for innocent reasons, just trying to 111 00:05:51.480 --> 00:05:52.199 get their job done. 112 00:05:52.319 --> 00:05:55.120 That's a really important distinction. It's not always malicious intent. 113 00:05:55.240 --> 00:05:58.319 Sometimes it's just friction in the system or maybe confusion. 114 00:05:58.959 --> 00:06:02.560 And here's where it gets yearly interesting. The framework suggests 115 00:06:02.639 --> 00:06:05.839 ways to tackle that human risk without just throwing expensive 116 00:06:05.879 --> 00:06:06.399 tech at it. 117 00:06:06.519 --> 00:06:11.480 Right, absolutely, and they're often surprisingly simple. Process changes. Think 118 00:06:11.480 --> 00:06:14.800 about least privileged access. Just give people the minimum access 119 00:06:14.839 --> 00:06:17.639 they need to do their specific job. Nothing more like 120 00:06:17.639 --> 00:06:20.000 giving someone a key card that only opens their office, 121 00:06:20.040 --> 00:06:20.839 not the whole building. 122 00:06:21.040 --> 00:06:23.000 Simple but effective, definitely. 123 00:06:23.560 --> 00:06:26.639 Then there's job rotation or cross training. This does two things, 124 00:06:27.079 --> 00:06:30.000 builds backup so you're not relying on one person, and 125 00:06:30.040 --> 00:06:32.720 it helps prevent fraud or collusion because different people see 126 00:06:32.759 --> 00:06:37.040 the process. Job segregation is similar. You separate key tasks, 127 00:06:37.600 --> 00:06:41.160 like the person entering invoices shouldn't be the person approving payments. 128 00:06:41.480 --> 00:06:44.199 Basic check and balance makes sense. Someone that's often missed, 129 00:06:44.319 --> 00:06:49.000 but absolutely critical employment termination procedures. A former employee who's 130 00:06:49.040 --> 00:06:51.680 unhappy and still have access or knows all your secrets. 131 00:06:51.800 --> 00:06:54.879 That's a massive risk. The GUIDO really stresses immediate access 132 00:06:54.879 --> 00:06:56.639 removal the second someone leaves. 133 00:06:56.920 --> 00:06:59.680 Yeah, you hear horror stories about that. So it's smart processes, 134 00:06:59.720 --> 00:07:03.240 clear policies, not just tech. But I also saw the 135 00:07:03.279 --> 00:07:06.319 guide mentioned putting actual numbers on risk. How does that 136 00:07:06.360 --> 00:07:08.199 calculation work? Why is it so useful? 137 00:07:08.360 --> 00:07:10.519 Right? This is where the quantitative part comes back in, 138 00:07:10.839 --> 00:07:14.639 and it's powerful for talking to management. It translates threats 139 00:07:14.720 --> 00:07:17.759 into potential financial impact. It breaks it down. You've got 140 00:07:17.759 --> 00:07:21.720 the asset value AV, what's the thing you're protecting actually worth? 141 00:07:22.079 --> 00:07:25.519 Then the exposure factor EF. What percentage of that value 142 00:07:25.560 --> 00:07:28.360 would you lose if the bad thing happens? See fifty percent. 143 00:07:28.839 --> 00:07:31.600 Multiply AV by EF and you get your single loss 144 00:07:31.600 --> 00:07:33.680 expectancy sl E cost of one incident. 145 00:07:33.720 --> 00:07:36.519 Okay, AV times EF equals sl E. 146 00:07:36.839 --> 00:07:39.519 Got it. Then how often might this happen? That's your 147 00:07:39.519 --> 00:07:41.879 annual rate of occurrence ARO? Maybe it's once a year, 148 00:07:42.120 --> 00:07:44.879 AR one, maybe once every five years AR point two 149 00:07:45.199 --> 00:07:48.680 multiplayer sl by the RO and big O annualized loss 150 00:07:48.680 --> 00:07:52.800 expectancy ALI. That al figure gives management a clear idea. Okay, 151 00:07:53.079 --> 00:07:55.800 this risk could cost us X amount per year on average. 152 00:07:55.959 --> 00:07:58.000 It makes investing in a safeguard that costs less than 153 00:07:58.040 --> 00:07:59.759 the ale a much easier decision. 154 00:08:00.079 --> 00:08:02.319 Really clarifies the business case exactly, and. 155 00:08:02.279 --> 00:08:05.399 You manage all this information and risk registers plural is important. 156 00:08:05.439 --> 00:08:08.000 You might have different ones for different areas or sensitivity levels. 157 00:08:08.040 --> 00:08:10.360 It gives you that clear, up to date big picture. 158 00:08:10.560 --> 00:08:14.160 That's a really powerful way to frame security decisions. So, Okay, 159 00:08:14.199 --> 00:08:17.680 you've scoped things out, you've prioritized using these methods. Now 160 00:08:17.720 --> 00:08:20.319 you need to pick the right solutions. How does ESORMA 161 00:08:20.360 --> 00:08:21.560 handle that evaluation? 162 00:08:22.240 --> 00:08:24.319 This raise is an important question, doesn't it? How do 163 00:08:24.360 --> 00:08:28.279 you choose controls effectively without just reacting to the first 164 00:08:28.319 --> 00:08:33.000 problem you see? That's domain three. Evaluate. It's all about 165 00:08:33.080 --> 00:08:36.919 systematically comparing and selecting the right controls. It's not just 166 00:08:37.039 --> 00:08:41.279 fixing things, it's balancing governance, risk and compliance. 167 00:08:40.840 --> 00:08:43.519 Needs, okay, balancing react. What tools help with that? 168 00:08:43.679 --> 00:08:46.279 A really critical one here is the business impact analysis 169 00:08:46.320 --> 00:08:49.399 the BIA. Now this isn't just another inventory list. It 170 00:08:49.480 --> 00:08:52.519 details everything essential for your business to run. Assets, sure, 171 00:08:52.879 --> 00:08:58.000 but also key people, processes, stock, suppliers, everything. Its main 172 00:08:58.039 --> 00:09:00.559 goal is to understand timing. How long can a critical 173 00:09:00.600 --> 00:09:03.519 process be down before it really hurts your clients before 174 00:09:03.559 --> 00:09:07.360 they notice, and that understanding helps you prioritize recovery efforts 175 00:09:07.600 --> 00:09:10.080 based on what matters most to your customers, not just 176 00:09:10.120 --> 00:09:11.360 internal costs or risks. 177 00:09:11.600 --> 00:09:14.799 So it connects security back to the customer experience precisely. 178 00:09:15.399 --> 00:09:18.559 And the ESORMA approach is really pragmatic. Here it says, look, 179 00:09:18.639 --> 00:09:22.120 get a basic BIA done quickly, like in days, not 180 00:09:22.279 --> 00:09:24.919 months or a year, because, as the guide puts it 181 00:09:24.960 --> 00:09:27.960 so well, having a plan is always better than having 182 00:09:28.080 --> 00:09:31.200 no plan. Even an imperfect plan is a start. 183 00:09:31.600 --> 00:09:34.000 I like that agile approach. Bete's getting bogged down an 184 00:09:34.000 --> 00:09:37.080 analysis paralysis. You've got your BIA, you understand the timing. 185 00:09:37.360 --> 00:09:38.960 What else feeds into evaluation? 186 00:09:39.399 --> 00:09:42.159 Well? The guide recommends using a form driven approach and 187 00:09:42.240 --> 00:09:45.039 interviews it's an efficient way to gather info and bonus. 188 00:09:45.080 --> 00:09:48.120 It's workings. You often spot ways to improve processes generally, 189 00:09:48.440 --> 00:09:51.320 not just for security. Then you need to understand your 190 00:09:51.360 --> 00:09:54.279 risk appetite. How much risk is the business actually willing 191 00:09:54.320 --> 00:09:56.840 to accept? Is there a budget limit for losses? Has 192 00:09:56.840 --> 00:09:59.440 the board metter decisions would have passed? Practice is shown. 193 00:09:59.240 --> 00:10:01.600 So defining the tolerance level exactly. 194 00:10:01.840 --> 00:10:04.200 And then there are more timing concepts linked to the BIA. 195 00:10:04.759 --> 00:10:08.720 Maximum tolerable downtime MTD the absolute point of no return 196 00:10:08.799 --> 00:10:12.879 for a process. Recovery time objective RTO how quickly do 197 00:10:12.919 --> 00:10:15.360 you need to get a service back up? This dictates 198 00:10:15.360 --> 00:10:18.120 whether you need a hot site ready instantly, warm site 199 00:10:18.159 --> 00:10:21.919 needs some setup, or cold site just infrastructure and recovery 200 00:10:21.960 --> 00:10:24.919 coint objective RPO How much data can you afford to 201 00:10:24.960 --> 00:10:28.240 lose an hour's worth a day's worth. That determines backup. 202 00:10:28.000 --> 00:10:31.440 Frequency MTD rt RPO key metrics very key. 203 00:10:31.600 --> 00:10:35.159 And finally, evaluation leads you to choose your risk treatment strategy. 204 00:10:35.600 --> 00:10:39.080 There are four main options. Acceptance, you know the risk, 205 00:10:39.159 --> 00:10:41.799 You consciously decide to do nothing, maybe it's too costly 206 00:10:41.840 --> 00:10:44.519 to fix. Avoidance you change hey, you do things to 207 00:10:44.559 --> 00:10:48.480 eliminate the risk entirely. Mitigation you put in countermeasures controls 208 00:10:48.519 --> 00:10:51.159 this is the most common one. And transfer you shift 209 00:10:51.159 --> 00:10:53.960 the risk, usually through insurance or outsourcing. 210 00:10:53.440 --> 00:10:56.039 Contracts except avoid mitigate transfer. 211 00:10:56.159 --> 00:10:58.879 Okay, And the upshot of all this evaluation, it's not 212 00:10:58.960 --> 00:11:01.519 just about better security. You almost always find ways to 213 00:11:01.519 --> 00:11:05.799 streamline things, cut costs, improve efficiency alongside security benefits. 214 00:11:05.879 --> 00:11:08.840 That's a great selling point. Okay. So from evaluating, the 215 00:11:08.919 --> 00:11:13.519 natural next step is actually doing something, putting plans into action. 216 00:11:13.639 --> 00:11:16.360 That sounds like domain for enable exactly. 217 00:11:16.480 --> 00:11:19.279 Enable is where the rubber meets the road. You authorize 218 00:11:19.279 --> 00:11:22.799 the activity, you implement the controls you chose, you test 219 00:11:22.840 --> 00:11:26.879 them rigorously, and then you reevaluate its decision and action time. 220 00:11:27.240 --> 00:11:29.759 What's involved in getting started with enablement? 221 00:11:30.039 --> 00:11:33.559 A key first step is often a gap analysis where 222 00:11:33.559 --> 00:11:35.639 are we now versus where do we need to be 223 00:11:35.840 --> 00:11:39.159 based on our evaluation, And crucially, you need buy in. 224 00:11:39.399 --> 00:11:42.440 You have to consult with stakeholders, your staff, management, maybe 225 00:11:42.440 --> 00:11:45.000 even key clients to make sure everyone's on board with 226 00:11:45.039 --> 00:11:45.559 the changes. 227 00:11:45.679 --> 00:11:47.559 People need to understand the why. 228 00:11:47.440 --> 00:11:50.960 Absolutely, which is why effective risk communication is so important. Here, 229 00:11:51.159 --> 00:11:54.080 the guide suggests using a simple risk awareness checklist too, 230 00:11:54.519 --> 00:11:56.960 just to make sure everyone understands their specific role in 231 00:11:56.960 --> 00:11:59.840 the security posture. The goal is really to weave security 232 00:11:59.879 --> 00:12:02.879 into the fabric of the organization right from the start. 233 00:12:02.960 --> 00:12:06.720 This domain also heavily features the PDCA cycle planed oh, 234 00:12:06.840 --> 00:12:09.960 check act. It's a classic continuous improvement loop. 235 00:12:10.200 --> 00:12:14.120 Plan do check act. Can you break that down quickly? 236 00:12:14.200 --> 00:12:18.840 Sure? Plan design your security program or control, Do implement it, 237 00:12:19.000 --> 00:12:22.279 execute the plan, check aut of it, measure its effectiveness, 238 00:12:22.320 --> 00:12:25.919 see if it's working. Act, make improvements based on what 239 00:12:25.960 --> 00:12:27.840 you learned, then start the cycle. 240 00:12:27.559 --> 00:12:30.840 Again continuous improvement. How do you measure if it's actually working? 241 00:12:30.840 --> 00:12:31.559 In the check. 242 00:12:31.399 --> 00:12:35.039 Phase, you use various metrics, things like key goal indicators 243 00:12:35.159 --> 00:12:38.960 kgis or we achieving our overall security goals, Critical success 244 00:12:39.000 --> 00:12:41.919 factors CSS what needs to go right for us to succeed, 245 00:12:42.399 --> 00:12:46.360 and Key performance indicators KPIs specific measurable metrics that show 246 00:12:46.360 --> 00:12:49.240 how well controls are performing day to day. These give 247 00:12:49.240 --> 00:12:52.519 you that visibility those real time alerts if something's off right. 248 00:12:52.679 --> 00:12:53.679 Metrics are essential. 249 00:12:54.000 --> 00:12:56.559 Yeah, and resource management is also a big part of ENABLE, 250 00:12:56.840 --> 00:13:01.200 especially managing security across older legacy systems alongside maybe newer 251 00:13:01.240 --> 00:13:05.000 cloud setups. It can get complex and you'll be implementing 252 00:13:05.039 --> 00:13:09.440 different types of controls. Preventative ones to stop bad things happening, 253 00:13:09.679 --> 00:13:12.840 detective ones to spot them if they do, Corrective ones 254 00:13:12.840 --> 00:13:15.960 to fix the damage, compensating controls as workarounds if a 255 00:13:15.960 --> 00:13:19.840 primary control fails, and deterrent controls to discourage attackers. 256 00:13:20.080 --> 00:13:21.639 Lots of different control types. 257 00:13:21.440 --> 00:13:25.279 Yep, all guided by those core principles like least privileged 258 00:13:25.279 --> 00:13:28.080 and segregation of duties we talked about earlier. Of course, 259 00:13:28.200 --> 00:13:31.600 Enable isn't without its hurdles. You often face common challenges, 260 00:13:32.200 --> 00:13:35.360 resistance to change in the organization people seeing security is 261 00:13:35.480 --> 00:13:38.879 just a roadblock, the difficulty of proving value with subjective 262 00:13:38.919 --> 00:13:42.759 measures sometimes and will sometimes plans just fail. This domain 263 00:13:42.799 --> 00:13:44.759 helps you anticipate and navigate. 264 00:13:44.360 --> 00:13:47.000 Those Okay, so Enable gets things running. Then comes to 265 00:13:47.039 --> 00:13:51.039 main five Harden. This sounds like building stronger defenses. What's 266 00:13:51.080 --> 00:13:51.879 the focus here? 267 00:13:52.000 --> 00:13:56.200 Harden is exactly that, actively protecting against attacks. But it's 268 00:13:56.360 --> 00:13:59.639 more than just tech defenses. It's about building genuine business 269 00:13:59.639 --> 00:14:02.720 resils millions. The goal is to ensure the business can 270 00:14:02.840 --> 00:14:06.559 keep operating, keep serving customers, protect its people and income 271 00:14:07.000 --> 00:14:08.120 even when things go wrong. 272 00:14:08.279 --> 00:14:10.320 So resilience is the key outcome. 273 00:14:10.360 --> 00:14:13.240 How do you achieve that pre planning is absolutely essential? 274 00:14:13.360 --> 00:14:16.320 You use that business impact analysis from domain three as 275 00:14:16.360 --> 00:14:20.679 your foundation. Understanding your critical processes and recovery needs lets 276 00:14:20.720 --> 00:14:24.000 you build resilience in from the start. This naturally flows 277 00:14:24.000 --> 00:14:29.799 into creating solid business continuity BC and Disaster Recovery DR plans. 278 00:14:30.000 --> 00:14:34.080 And here's something the guide really emphasizes clarity in your 279 00:14:34.120 --> 00:14:38.120 documentation in your training. Absolute clarity is crucial. Why because 280 00:14:38.120 --> 00:14:40.480 when people are under pressure, like during a real incident, 281 00:14:40.720 --> 00:14:43.440 that's when mistakes happen. Instructions need to be so clear 282 00:14:43.480 --> 00:14:45.360 a total novice could understand and follow them. 283 00:14:45.399 --> 00:14:48.679 That makes perfect sense. Reduce panic, reduce errors exactly. 284 00:14:49.360 --> 00:14:52.879 The guide also brings in the Capability Maturity Model Integration 285 00:14:53.200 --> 00:14:56.759 CMMI scale. It's a way to benchmark how mature your 286 00:14:56.799 --> 00:15:00.720 processes are from level one unpredictable, chaotic up to level 287 00:15:00.759 --> 00:15:05.399 five Optimize Continuously improving ESORMA helps you climb those levels, 288 00:15:05.519 --> 00:15:08.759 making your security BC and DR process is more reliable 289 00:15:08.919 --> 00:15:11.679 and effective. So it provides a path for improvement right 290 00:15:12.039 --> 00:15:14.960 and let's face it, disasters happen. The stats the guide 291 00:15:15.039 --> 00:15:18.200 quotes are pretty stark, something like ninety percent of businesses 292 00:15:18.240 --> 00:15:21.720 don't have a proper disaster recovery plan, and maybe even scarier, 293 00:15:21.919 --> 00:15:24.120 forty percent of businesses that have to shut down completely 294 00:15:24.120 --> 00:15:26.679 for just three days are likely to go bust within 295 00:15:26.720 --> 00:15:27.200 three years. 296 00:15:27.240 --> 00:15:28.600 Wow, forty percent. 297 00:15:28.679 --> 00:15:31.360 That's sobering, it really is. It highlights why BC and 298 00:15:31.399 --> 00:15:32.840 DR are an optional extras. 299 00:15:32.960 --> 00:15:35.919 So what do the actual processes the life cycles for 300 00:15:36.120 --> 00:15:37.480 BC and DR look like. 301 00:15:37.759 --> 00:15:41.159 The guide lays them out. The Business Continuity Management life 302 00:15:41.159 --> 00:15:45.480 cycle BCML involves things like scope and plan initiation, what 303 00:15:45.639 --> 00:15:50.399 we're protecting the BIA, understanding impact and timing, plan development, 304 00:15:50.600 --> 00:15:54.679 writting the actual plans, validation and monitoring, testing and updating 305 00:15:54.720 --> 00:15:57.960 and embedding it making it part of the culture. Similarly, 306 00:15:58.279 --> 00:16:03.159 the Disaster Recovery Plan life sie DRPL covers defining requirements, 307 00:16:03.519 --> 00:16:07.559 documenting the plan and training people, testing it regularly, knowing 308 00:16:07.639 --> 00:16:10.799 how to activate it, and then maintaining and optimizing it 309 00:16:10.840 --> 00:16:11.279 over time. 310 00:16:11.519 --> 00:16:14.320 So it's not just right and forget. It's a living process. 311 00:16:14.399 --> 00:16:18.080 Absolutely. It's all about proactive steps, constant revision based on 312 00:16:18.200 --> 00:16:20.799 tests and changes, building that muscle memory. It gives you 313 00:16:20.840 --> 00:16:24.840 a fighting chance to survive, minimizes downtime, and ultimately builds 314 00:16:24.840 --> 00:16:25.840 that crucial resilience. 315 00:16:26.000 --> 00:16:29.799 Okay, we've hardened the systems built resilience, but we can't 316 00:16:29.840 --> 00:16:31.480 just set it and forget it. That must be where 317 00:16:31.559 --> 00:16:35.120 Doomain six monitor comes in, keeping a constant eye on things. 318 00:16:35.480 --> 00:16:39.759 You got it. Monitoring is absolutely mission critical. It's how 319 00:16:39.840 --> 00:16:45.279 you assure those core security principles confidentiality, integrity and availability. 320 00:16:45.720 --> 00:16:49.000 And it spans everything operations, compliance, governance. 321 00:16:49.159 --> 00:16:51.000 What's the main challenge with monitoring? 322 00:16:51.279 --> 00:16:55.000 The biggest challenge The threat landscape never stands still. It 323 00:16:55.120 --> 00:16:58.679 changes daily, even hourly, and a security control that stops 324 00:16:58.720 --> 00:17:00.879 working may be due to it system update or a 325 00:17:00.879 --> 00:17:04.519 contiguration error. Well, that instantly becomes an unmitigated risk, even 326 00:17:04.519 --> 00:17:06.359 if you think it's still in place because it's written 327 00:17:06.400 --> 00:17:07.079 down somewhere. 328 00:17:07.279 --> 00:17:09.680 That reminds me of that example you mentioned earlier, the 329 00:17:09.720 --> 00:17:13.720 CEO and director sharing credentials, a control on paper but 330 00:17:13.880 --> 00:17:16.039 failing in reality. How is that caught? 331 00:17:16.680 --> 00:17:20.319 Exactly that case, the company had a policy, an administrative 332 00:17:20.319 --> 00:17:23.599 control for segregation of duties, but it wasn't being followed. 333 00:17:23.880 --> 00:17:27.279 Effective monitoring, specifically regular auditing in this case brought it 334 00:17:27.279 --> 00:17:30.599 to light. It wasn't sophisticated hacking, it was just well 335 00:17:30.920 --> 00:17:35.039 laziness and a poor security culture undermining a written control. 336 00:17:35.559 --> 00:17:38.599 So monitoring reveals the gap between policy and practice. 337 00:17:38.759 --> 00:17:42.799 Precisely, it's critical for verifying that controls are actually effective 338 00:17:42.799 --> 00:17:46.559 in the real world. Any SOORMA borrowing from NIST standards 339 00:17:46.599 --> 00:17:49.240 like SB eight hundred and point thirty seven simplifies the 340 00:17:49.240 --> 00:17:52.839 monitoring approach into something called SPAR. SPAR stands for strategy, 341 00:17:53.039 --> 00:17:55.519 What are we monitoring and why? The program? How are 342 00:17:55.519 --> 00:17:58.359 we doing it? Analysis? What are the results telling us? 343 00:17:58.480 --> 00:17:59.799 And response? What do we do about it? 344 00:18:00.119 --> 00:18:03.720 Our strategy? Program analysis? Response? A neat framework. What kind 345 00:18:03.720 --> 00:18:05.119 of tools help with the program part? 346 00:18:05.160 --> 00:18:07.279 There's a whole range of tools. A big one is 347 00:18:07.519 --> 00:18:11.720 sign security information and Event management systems. These collect logs 348 00:18:11.720 --> 00:18:14.640 from all of your network and use clever analysis to 349 00:18:14.680 --> 00:18:19.519 spot suspicious activity. You've also got continuous audit modules often 350 00:18:19.559 --> 00:18:23.680 called c AT's Computer assisted audit techniques embedded in systems. 351 00:18:24.319 --> 00:18:27.200 Even manual audit logs, though they can be tedious to review, 352 00:18:27.400 --> 00:18:31.599 are vital for forensic investigations. Then there's heartbeat monitor and 353 00:18:31.640 --> 00:18:33.680 simple checks to see if systems are up and running, 354 00:18:34.240 --> 00:18:39.319 Penetration testing, ethical hacking basically hiring experts to proactively find 355 00:18:39.319 --> 00:18:43.119 your weaknesses before the bad guys do, and control objective evaluation, 356 00:18:43.240 --> 00:18:45.599 which is more of a manual process reviewing if a 357 00:18:45.640 --> 00:18:48.480 control is designed and operating effectively to meet its objective. 358 00:18:48.559 --> 00:18:50.720 So a mix of automated and manual checks. 359 00:18:50.799 --> 00:18:53.839 Yeah, you need both. It's all about getting that continuous 360 00:18:53.839 --> 00:18:56.160 assurance that your defenses are working as intended. 361 00:18:56.480 --> 00:18:59.680 That makes sense. So from monitoring we shift into the 362 00:18:59.759 --> 00:19:03.039 data today grind the rhythm of security. That sounds like 363 00:19:03.119 --> 00:19:06.359 Domain seven operations. What does that look like? Especially for 364 00:19:06.400 --> 00:19:10.359 businesses maybe without a huge dedicated security operation center? 365 00:19:10.519 --> 00:19:13.640 Sooc right, security operations is really about that constant cycle 366 00:19:13.720 --> 00:19:17.400 monitoring for events and then responding appropriately when something happens. 367 00:19:17.559 --> 00:19:20.279 And you're right. Big companies often have these dedicated twenty 368 00:19:20.279 --> 00:19:23.799 four to seven scs, but even smaller businesses need someone 369 00:19:23.880 --> 00:19:28.160 responsible for managing the operational basics. The guide shares another 370 00:19:28.240 --> 00:19:32.039 powerful story here about a bank during a crisis, operations 371 00:19:32.079 --> 00:19:34.880 completely failed because the person who knew they needed to 372 00:19:34.920 --> 00:19:37.000 shut down the network, well, they didn't actually have the 373 00:19:37.039 --> 00:19:40.359 authority to do it in the documented procedures That hesitation. 374 00:19:40.519 --> 00:19:43.839 That untested operational structure costs the millions. 375 00:19:43.400 --> 00:19:45.920 Ouch a failure in the how. So, if you don't 376 00:19:45.920 --> 00:19:49.559 have an SC what's the practical alternative for managing operations? 377 00:19:49.880 --> 00:19:53.519 A really well defined information security policy is key. Along 378 00:19:53.559 --> 00:19:56.680 with those solid business continuity and disaster recovery plans we 379 00:19:56.720 --> 00:20:00.359 talked about in Harden. They provide the operational framework, and 380 00:20:00.640 --> 00:20:03.839 ZORMA breaks down managing operations into what it calls three 381 00:20:03.880 --> 00:20:08.680 basic elements, simple but effective. First, the who. This covers 382 00:20:08.720 --> 00:20:12.599 all the people aspects, staffing, defining roles, clearly hiring the 383 00:20:12.640 --> 00:20:16.559 right people, onboarding them properly, ongoing training, regular security meetings, 384 00:20:16.599 --> 00:20:20.359 retaining good staff, and even considering the psychological side. Are 385 00:20:20.440 --> 00:20:25.920 security measures usable and accepted? The human element again crucial absolutely? Second, 386 00:20:26.079 --> 00:20:29.920 the how? This is about having clear written processes. Your 387 00:20:29.920 --> 00:20:32.799 information security policy is central here, but also things like 388 00:20:32.839 --> 00:20:36.000 employee handbooks that spell out responsibilities. Everyone needs to know 389 00:20:36.000 --> 00:20:39.480 how things are supposed to work. And Third, the what? 390 00:20:39.480 --> 00:20:42.559 What exactly are we measuring and responding to? This includes 391 00:20:42.599 --> 00:20:47.160 potential losses across different categories, legal finds, contractual penalties, failing standards, 392 00:20:47.319 --> 00:20:52.039 direct financial loss, damage to reputation, or just disruption to business? Who? 393 00:20:52.039 --> 00:20:55.839 How? What? Simple framework, simple, but it covers the basis 394 00:20:56.119 --> 00:21:01.559 the ultimate goal good security operations should almost feel invisible 395 00:21:02.359 --> 00:21:05.000 when it's properly integrated into how the business works. When 396 00:21:05.000 --> 00:21:08.400 it becomes second nature, it just happens. It's about aligning 397 00:21:08.440 --> 00:21:12.160 security ops smoothly with the overall corporate strategy, not having 398 00:21:12.200 --> 00:21:14.200 it feel like a separate, bolted on function. 399 00:21:14.480 --> 00:21:17.559 Invisible security. I like that call okay that brings us 400 00:21:17.599 --> 00:21:19.160 to the final domain, the one that sends to tie 401 00:21:19.160 --> 00:21:22.599