Have you ever found yourself, you know, struggling with a really complex industry standard. You see all the requirements the once, but you just wish someone would clearly lay out the hows.
Yeah, that's a common frustration, absolutely, and today that's exactly what we're diving into information security and specifically how you actually implement ISOIE two seven thousand and one point two zero one.
Team, the big standard for information and security management systems or an isms.
Right, it's the benchmark. It's comprehensive, really critical stuff, but it often leaves people asking, Okay, great, but how do we do this in practice?
That is the key question, isn't it? ISOSO one two seven zero one tells you what you need to do perform risk assessments, produce that statement of applicability, But it's not prescriptive on the how.
It describes the destination, not the root precisely.
And that's where our source for today comes in doctor David Brewer's book. It's incredibly valuable because he offers this really fine tune, actionable methodology. It fills in those practical gaps.
Okay, So our mission today is to unpack doctor Brewer's approach for you. We want to take what can feel like a daunting list of rules and turn it into a clear, confident way to manage your information security risks.
So you walk away knowing the practical how to.
Exactly ready to tackle this with real clarity. So let's just ground ourselves again ISOIE twenty seven sous or one point two zero one team. It's all about helping organizations put controls in place to get information security risks down to an acceptable level.
Right. But the thing is every organization is different.
Your business, your environment, the tech you use. It all means your.
Risks are unique, absolutely, and the standard reflects that. It requires you to define your risk appetite basically, how much risk are you okay with?
That's your threshold exactly.
Then you do a risk assessment to figure out which risks go over that threshold. Then you start risk treatment, applying controls to bring those.
Risks down, and the end result of that is the statement of applicability.
The SOA at your documental list of controls, and doctor Brewer's method gives you a really systematic way to get through all that, offering practical steps where you know other guidance might be a bit theoretical.
Okay, But before we jump into the how of doctor Brewer's method, let's just get really clear on what we mean by risk here.
Good idea doctor Brewer uses the definition from ISO thirty one thousand. Risk is the effect of uncertainty on objectives.
Uncertainty on objectives and effect here doesn't just mean bad stuff.
Correct An effect is just a deviation from what you expect to be positive, could be negative.
Risk can have an upside, But for today, for ISO twenty seven and thirty zero one, we're mostly focused on managing the negative side.
That's our focus here, Yes, managing those potential negative impacts, which leads us nicely into doctor Brewer's preferred way to do the risk assessment, the event consequence method. His approach is also backed by ISO thirty one thousand and BS seven seven ninety nine three point two zero one team, and honestly, it's a big improvement over older ways of doing things.
A big improvement. You say, what was wrong with the old asset threat vulnerability method that was common in say the two thousand and five version of ISO twenty seven thousand and one. What made this shift necessary?
Well, it had some real drawbacks. For one, it really struggled with things like zero day vulnerabilities.
Because you wouldn't know the vulnerability existed yet exactly.
The model kind of implied you needed to know the vulnerability to assess the risk related to it, which isn't realistic. It also tended to frame risk in very technical language, making it.
Hard for maybe senior management to connect.
With precisely, hard to grasp the actual business impact sometimes, and it could miss broader risks, societal things, operational issues that didn't fit neatly into that ATV model. The event consequence method is simpler. It focuses on things that can actually happen, events and what the fallout would be, the consequences. It's much more relatable, much more comprehensive for everyone involved.
That makes a lot of sense. Accessibility is key. So how does this event consequence method work? You at four steps?
Yes, four steps, pretty straightforward. First, you identify risks. You do this by pairing an event with its potential consequence.
Okay, give us an example.
Doctor Brewer uses this one. A laptop is stolen. That's your event. The consequence undesirable disclosure of personally identifiable information PII.
Okay, clear, event consequence, got it? What's step two?
Step two, assess the severity of that consequence. Doctor Brewer suggests using a monetary scale, but crucially a logarithmic one logarithmic. Why logarithmic because it lets you handle a huge range of impacts consistently. You could have a ten pound consequence or one hundred million one. A log scale lets you map both onto a single comparable scale. Value like ten k might be a three to one million might be
a five. Even values in between like four point seven for five hundred pounds are meaningful.
Ah okay, So it compresses the range but keeps the relative differences meaningful. It makes very different scales of impact comparable exactly.
It ensures you can properly compare and priority whether it's a small hit or a catastrophe. Step three you assess the likelihood of the event happening the full four row frequency or likely?
And is that logarithmic two?
Yes, also a reciprocal time logerowidth mix scale. Think about it. How else do you consistently compare something that might happen once a century versus something happening I don't know, thousands of times a second.
Right, that's a vast difference.
This scale gives you that range. Once a year might be scale value two, every minute could be seven point eight. It standardizes frequency assessment across wildly different scenarios.
That standardization seems really powerful for making comparisons.
It is, and it leads directly to step four to termine the risk level. Because you're using log scales, you don't actually multiply likelihood and severity in the usual sense. You just add their scale values.
Oh, a simple addition.
Simple addition, a likelihood of three plus a consequence of two equals a risk level of five. Super easy to calculate and compare different risks across the board.
Now, to make this really practical for you, doctor Brewer doesn't leave it there. He actually identifies twelve standard events. These aren't just abstract, they cover common, realistic scenarios.
You need controls for things you're actually worry about, right.
Like S one theft or loss of mobile devices. It's a classic S nine hacking, obviously S three acts of God, vandals, terrorists, and maybe S eight fraud or error. Things like that.
And he even helps categorize how you determine likelihood. Category are for random events you can't influence like acts of God E where you have little influence but some experience maybe like common malware, and O for opportunity dependent events like.
How often a laptop actually leaves the building. That influence is the likelihood of it being stolen outside exactly.
It adds consistency to assessing likelihood and all this data. These scales, they allow for what doctor Brewer calls risk squares.
Risk squares like a graph Yeah, basically.
A graphical way to plot your risks likelihood on one access consequence on the other, both using those log scales. This lets you visually represent that huge range we talked about once a century to thousands of times a second, ten pounds to one hundred million, all on one chart. Wow, okay, And you get these lines of constant risk. You can color code them green for acceptable, yellow for borderline, red for unacceptable. It gives you this immediate visual snapshot of
your risk landscape. Very powerful for communication.
That sounds incredibly useful, especially for talking to management and throughout this whole assessment. You're not just getting numbers, you're also identifying the risk owners.
Right, absolutely critical. You need to know who has the actual accountability and the authority to manage each specific risk.
So if that risk happens, everyone knows who's responsible for dealing with it. No confusion.
Precisely, it assigns clear responsibility.
Okay, so we've identified the risks, we've quantified them, we know who owns them. Now we need to figure out what to do about the unacceptable ones risk treatment. And this is where doctor Brewer gets quite creative with his tell it like a story method.
Yes, it's a brilliant intuitive approach. The idea is, for each of those twelve standard events, you imagine it like a short movie playing out in three scenes. Yeah. Scene one is preventative. What measures do you have to stop the event from happening in the first place? Think strong building, security, clear policies, good training.
Okay, stop it before it starts.
Scene two is detective. If prevention fails and the event does happen, how do you detect it quickly? That's your alarms, your monitoring systems, your audit logs catch it in the act. And Scene three is reactive. Once you've detected it, what do you do to limit the damage the consequences? Data backups, encryption on stolen data, your incident response plan kicking.
In prevent, detect, react.
It's a sequence, it is, and this ties into something doctor Brewer calls the time theory, which is I think quite profound time theory.
Yeah.
It basically says that an effective control system is all about time. It's about detecting opportunities for bad things or the bad things themselves early enough to do something positive about them. Okay, So preventive detective controls they operate before the full impact. They give you a time window to change a likelihood. Reactive controls they happen after detection to lessen the severity.
So it forces you to think about the timing of your controls, not just whether you have them. That really does shift the perspective.
It does. It's about building resilience through timely intervention.
Let's make that concrete with the stolen laptop story again using this three scene approach. Okay, preventative might be say a strict policy no company laptops leave the main office period enforced at the door.
Good preventive control.
Detective could be maybe a GPS chip in the laptop that sends an alert if it crosses a defined boundary, a geofence.
Quick detection if the prevented control fails or is it used.
And react it well. That's things like having strong encryption on the hard drive so the data is useless to the thief, or having the ability to remotely wipe the device once you confirm it's gone.
Exactly you're writing script for how you'll handle that specific event seen by scene.
It makes it very practical.
And he goes further categorizing how different controls behave within these stories. There are in factor controls like passwords. Their strength depends on how hard they are to guess. They reduce likelihood by a factor of n. Then there's excess. That's where we replace one consequence with a smaller one, like insurance paying out after a theft. You still have the disruption, maybe a deductible, but the main financial loss is covered, right.
You swap a big loss for a smaller, manageable one.
And strangulation. This is where a control works fine up to a point, but gets overwhelmed if the event happens too often or too intensely. Think of one person trying to handle a sudden flood of security alerts. They just can't keep up. The control effectively fails.
Understanding those failure points is crucial, so doctor Brewer calls this storytelling the optimum approach.
Yes, because you use it as a design tool. You're proactively designing your response, constantly asking okay, but what if this part fails, what's next?
It sounds like it really builds security awareness across the organization much better than just ticking boxes on a control list.
Absolutely foster's genuine understanding of how security works in your context. The goal is always that happy ending where the risk left over after your story plays out, the residual risk is actually acceptable to you.
Okay, so you've done the assessment, You've designed your treatments using these stories. How do you package all this up? That brings us back to the statement of a peck capability the SOA exactly.
The SOA is the formal output. It's your comprehensive catalog, your inventory of all your information security controls. It's a mandatory document for ISO twenty seven thousand zero one.
And what has to be in it.
Several key things. All the necessary controls you decided you needed based on your risk treatment stories. Okay, you need justification for why you included each one. You need to state clearly whether each control is actually implemented or not right. Status is important, and crucially, if you decide not to implement any of the controls listed in and of the standard, you have to justify those exclusions too.
Let's just quickly clarify ANXA for anyone who might not live and breathe this stuff.
Good point. ANNXA is basically ISO twenty seven thousand zero one's big reference list of common security controls. Think of it as a library of good practices, covering everything from access control to cryptography to physical security.
It's the standard's baseline checklist, right.
It provides that common language a solid starting point, but relying only on NXA has a weakness, which is, if your risk assessment, your storytelling identifies a control you absolutely need, but that control just doesn't happen to be an ANXA, just comparing your list to ANNEXA won't tell you you're missing something important from your own assessment.
Ah. I see ANNXA is a reference, not the definitive list of your necessary controls. So how does doctor Brewer handle that potential gap?
Through what he calls the cross checking process. It's vital you take the necessary controls you identified yourself through your event consequence analysis and storytelling.
Your optimum approach.
List exactly, and you compare that list against NXA. It's not about replacing your list with ANXA. It's about validating your list.
Against NXA, like checking your work.
Precisely a smart cross reference. And during this you might find different types of controls. You'll have your necessary controls that do map do NXA. Yeah, you might have custom controls ones you need that just aren't in NXA at all. You might find obviated controls. This is interesting. Say you implement a really strong custom control, like completely banning removable media. That custom control makes the standard ANXA control about managing removable media unnecessary or obviated.
Right, Your custom control super sees it exactly.
And then you have variants which are just your specific way of implementing a general ANXA control.
That level of detail ensures a really accurate picture. And I remember you mentioning. Doctor Brewer goes even further with a reference control superset.
Yes, this is really forward thinking. He doesn't just use NXA as the reference. His superset includes controls from NXA, but also anticipates controls likely to appear in future versions of related standards, like ISO twenty seven thousand, and two, and it fills in gaps he identified in the current standards, especially around detective and reactive measures.
So using his superset makes your ISMS more robust now and potentially saves you work when the standards update later.
That's the idea, better security for you now and less rework down the line. And importantly, using these extra reference controls doesn't add burden to your SOA documentation because you only need to justify excluding controls that are actually in the current NXA. Got it.
So the SOA itself, how does it look? Does it have to follow the NXA structure?
Not necessarily it can. That's the traditional layout, but you can also use a more modern layout, maybe grouping controls by pillars like organizational people physical tech controls. The key thing is clarity and accuracy because remember auditors, they view your SOA not just annexday and isolation.
The SOA is the real evidence of your system, it really is.
It's accuracy that justifications. That's what demonstrates your conformity.
So you've built the system, you've documented it in the SOA. What about keeping it alive? An ISMS isn't a one time project.
Right, absolutely not. It's a continuous cycle. Maintaining and improving it is crucial.
What does that involve?
The standard requires regular reviews, scheduled reassessments of your risks. But also you need to react quickly to significant.
Changes like new tech, new services, maybe new regulation.
Exactly anything that can materially change your risk landscape. And there's a fascinating aspect here. The isms kind of has a self healing.
Property self healing how so well think about it.
If a review shows changes are needed, maybe a control isn't working, or risks have changed and you don't make those necessary updates, that inaction itself creates a non conformity against the standards requirement for maintenance and documented information being accurate.
Ah, So estimate itself forces you to fix it to stay compliant.
Right. It pushes you to ensure your documented system always reflects the reality on the ground. It's a built in driver for keeping things up to date.
And that ties back to doctor Brewer's approach being future proof.
Yes, especially using his broader reference control superset. By thinking ahead, anticipating changes, addressing gaps, now you're better prepared for when ISOI E seven thousand zero one gets its next revision it should mean less frantic scrambling for you later.
You're building on a more solid, forward looking foundation.
That's the goal.
Okay, well, we have certainly taken a deep dive today. We've unpacked isoie C twenty seven hours zero one, seeing how doctor Brewer's methodology really tackles that how to problem head on.
From the event consequence method for risk assessment to that.
Really intuitive tell it like a story approach for designing risk treatments.
And understanding how the SOA becomes your living blueprint for security.
The takeaway for you listening is hopefully real clarity, an actionable, structured way to get a better handle on your information security.
Making it less daunting, more manageable.
Definitely. And as we wrap up, maybe here's a thought to leave you with, Building on that idea of proactive design. As threats keep changing, how much is your organization really thinking beyond just prevention?
Yeah? Are you actively designing systems not just to block attacks, but assuming some things might get through and focusing on robust detection, swift reaction, effective response.
It's that whole story. Prevent, detect, react, It's not just about what you managed to stop, but how well prepared you are to handle what you don't something to definitely mull over. Thank you so much for joining us on this deep dive today. Keep learning, keep questioning, and stay proactive out there. We'll catch you next time.