Standards & Regulatory Frameworks Are Static, Security Isn't

Thank you very much for the key thing. I'm gonna zoom around from topic to topic in my session and two key things to remember in case I don't mention them enough as I'm going through. One is that what's been said so far by the previous speakers is that effectively, as I was sitting there listening is that if you don't have visibility, you're not able to determine and assess whether or not you need to protect something and how you're going to detect it and so on. So the first thing is, and what I'm gonna be talking about is around visibility.

So it's important that we get visibility that's one of the drivers. The other thing is, and I know you don't need reminding of this, is that in theory there's no difference between theory and practice. Just like in theory following standards and complying to standards means that you should theoretically be more secure. But let's, let's look at that.

Okay, so I'm gonna go through, I won't go through this, I'm gonna try and save you some time. So the question is why, why should we even be thinking about analyzing any industry frameworks at all? Well the first thing that came to my mind was, you know, the CISOs and the visibility thing had no visibility of wireless communications. This was some work I was doing.

I was working with a vendor early this year and that particular vendor looked at wireless networks and picked up, the easiest way to describe their technology is if like, if we were at party and I was watching all of you, I'll be able to see who's speaking to who, although I wouldn't be able to tell what you were saying to each other. So the technology gave visibility and that's really what, what, what, where, where some of this was coming from. So it was around visibility and that was one example.

And I've always been very interested in visibility generally, because if we don't have visibility of deep fakes, if we don't have visibility of what's true and what's fake news and things like that have, if we don't have the tools to actually check that we have good visibility, how on earth are we gonna be able to move from where we are to do anything about it? So that was the first thing in terms of having that visibility.

Secondly, it was around, you know, what are we seeing that should have been covered by existing standards? And this comes up all the time, lots of events that I speak at where people talk about standards and they talk about what's missing and so on.

So it, it was coming from that perspective and that's why we should be looking at a analyzing the frameworks and then it was looking at wireless tax have been growing over the last five years but not recognized because everyone's looking at each other. So what I mean by that is if you look at wireless attacks over the last 15 years, we've been using wireless as an accepted norm. But if you look at the attacks that you see and the growth of attacks and the development of exploits and so on, most of those have been over the last five years.

And if you have visibility that the attacks on wireless are growing and they're growing fast, that's good visibility to start with. And then also what the other part of the challenge is that we're not recognizing it because everyone is looking towards each other in terms of what they should be doing.

And, and that comes from some research which was done by a UK academic, which was called Market for Lemons. Now if anyone understands that phrase, it's a British phrase, it's that, you know, the market for lemons goes down. And what this research looked at was security research, which covered I think something like a hundred thirty, one fifty CSOs and asked them when you're buying solutions, what do you look at when you're buying solutions? Who do you speak to when you're buying solutions? How do you determine whether they're good and decide which one to go for?

And it's very interesting research because it found that in a hundred CSOs between one and five will actually spend time researching and all the others would rely on each other and spreading the news effectively. When when asked a question, how'd you buy?

They say, Oh yeah, we speak to our peers. Oh yeah, we speak to our peers. So everyone speaks to each other. But the number of people that actually do the research work was few and far between. So a lot of time was being spent talking to each other. And that's another reason why I felt we should be analyzing the frameworks. Are there any requirements which are gained from greater visibility? And that's quite important if you, if if we do believe that visibility is important, then what other requirements are we going to get from it that we haven't already got from standards?

So these were some of the reasons where I, I thought we should be looking at standards and frameworks generally and what are the detection requirements. Again, if you dunno what you are trying to protect, how do you know what you're trying to detect? So all of that theoretically is at the high level in that assessment stage. So Origins, the research was, as I said, speaking for a particular org vendor.

It was to try and understand and the sales people came to me while I was there ciso, they said, Look, we're speaking to CISOs and they don't really get why we are, you know, trying to get them to look at this and if this is a space that we should actually be in. So from there this we started to look at specific controls for device communication and what the visibility do network teams aim for. So I've started to look out at the ground what is it that people were doing and what are the risks posture on device communications?

And there didn't seem to be any risk posture on device communication at all. And what do CISOs consider? And this was the sales people coming along and saying what do they consider when they're trying to explore new technology which hasn't been identified by analysts or by standards generally. And that's where that report from neons came in and which industries were the most responsive to this? And they want to try and find out should the sales people be working and focusing on manufacturing, healthcare, whatever it might well be.

And what was the inquiry that they were actually asking me to do? Really it was around what do you know to prove, Sorry, what do you know to prove if you don't, Sorry, I'll start that again. How do you know what to protect if you don't know? I don't have any visibility and dunno what's visible and what's current and what's outcoming as a type of threat. That was part of it. And secondly, what they were asking was how can you detect a breach without the right detection tools and how do you answer these questions when you're speaking to CISOs?

And if you want to look at it cynically, the same question really is the ti what's the time it takes for any technology space to have its own framework Checkbox, that was what the bottom line is. If you're gonna be really cynical about what the question they were asking me. Yeah. And I started to look at this and there was, and and I started to look at it and, and from the standards perspective and the non standards perspective and the first thing I started to question was the lags that it takes.

Now I'm not gonna go through all of these, but really there are many, many different types of lags between what the standard is, what it does, how it looks, how it's formed, the amount of time something takes from becoming standard to it being implemented. And you go through lots and lots of stages including vendors trying to identify certain things like email vendors, whether it's firewall windows, whatever it might well be. But there are loads of things that will happen in between and loads of lags in there. And there are different lag curves.

I haven't put them all together, but effectively if you start putting all the lag curves together, you find that there is a big period of time from actual discussion of the standard being developed through to it becoming implemented within the environment. And that is a long period of time. That wasn't what our sales people in here I wanted to hear. But that is the truth if you're looking at standards and getting onto a checklist of things next, I started to look at some of the standards and I started with the central for internet security.

This is one of the many sort of documents that they have. It's appearing differently. Basically what you, what you tend to get is you get lots and lots of things that they've put together, but out of those things that they've put put together, you, you, you, you, you filter out what you think is relevant. And what I pulled out as what's relevant is this next one, which is the critical security controls.

Cuz from this document there, there is a spreadsheet that they've compiled which gives you an idea of all the controls you should have from their perspective and their framework and what they've done. And what I'm gonna cover next is the mapping that they've created within cis and anyone can join and anyone can become a member and add to this mapping. So this is the version we worked on and we connected it with mappings to nist. First of all, the NIST SP 853 revision five, that was where we started the CIS document itself and the spreadsheet in terms of the way that it mapped things.

If you look at the third column, you've got asset types and the fourth column function, what the security function is in terms of identify, detect, et cetera. And then you've got the asset type, the asset types I'll come onto in a second, but they're the two main columns that I'll follow through. Then you can see the title description and what follows bit after that are all these things here, IG one, two, and three are around the different levels of maturity and the relationship to the control.

So the first half is the CIS part, the second half there that you see there would be whatever mapping there is between the two, right? So I'm gonna go through this really, really quickly.

So it, and if you worried that I'm going through it too fast, you won't get the slides and you'll realize it doesn't matter how fast I went through it and, and you will be surprised, it really doesn't matter because the results that you I show you are the same right across the board. Okay? So CI implementation, they've got all these things, these are all the stuff that they map and there's 18 groups and within each group you've got a whole bunch of stuff. Then you've got the NS framework, the NS framework, you've got the function in the second column and then you've got all everything else.

Now if you look, there seems to be a good distribution between the five functions. That's the reality that it looks like that there's a good mix. Now in terms of methodology, what I took was the two to begin with, which the CIS and Nest took the spreadsheets from the cis, looked at the mapping, analyzed them, pulled out what the mapping was and how it responded. And the two things that I've, the key things that I've I I've I've matched you'll see in a short while, which was the controls, the functions and the asset types and then looked at the number of controls and how they fit into there.

And some of the controls mapped onto more one or more than other controls, which is why the numbers don't match up to the reality because there are multiple mappings. It is, I try to avoid any subjectivity and how I try to avoid it was I took the mappings that I was provided with rather than trying to do my own mappings because my own mappings, I would definitely not have agreed with some of the mappings that they've got there. But that was me trying to be independent.

Okay, so the obvious bias that's quite important that that I state this first each, the framework mappings is attempting to map to its controls against the CIS framework. That's the first thing. And second thing is however that doesn't actually change much at all. Yeah. And that's quite important to recognize as well. So where are we gonna go to? So I said to you, I've got the five functions that the, on the left there, then at the top there I've got the different asset groups and these are the asset groups.

And what we found right across the board is that most things controls going to protect and that's why it's light green. But the the totals is where it's completely green because there is a variation between there and the amber, the top is because that how well you can do the top part will determine how good you are at all the others and effectively the detect respond and recover are red. So let's get started then. This is what I'm gonna zoom through.

So the first one I'll spend a little bit more time one because it's the first one I looked at and it's the one that I can explain where everything is the same. So if you look at the totals in the second row protect, you've got 96 out of 168. That is a high number and that's why there's, they're green there. And if you look at the network in terms of the controls that focus on the network network function, there's 15 out of that. And that's not the highest. The highest is under applications and the NA means not available or non not applicable.

So effectively you've got 16 there and you notice that under users there's zero under detect and the short smallest number in the totals at the bottom is 16 under users. Now this is one particular and the first framework I looked at. So how does the picture follow from here? So then we looked at hipaa. Now hip is great, it's very good, but what we've gotta understand is HIPAA was created to protect healthcare data and the protection of healthcare data it was looking at was encryption. So because it was looking at encryption, you see data as the highest number.

There's six and that's why you've got nine there. That's why all the others are more or less quite low because it was focused on data encryption.

However, if you then look at things like MIR and nist, both of those organizations in the last few years have produced tons and tons of data around how within healthcare the biggest risk is not encryption, it's the wireless networking devices that they're putting into their organization's. Healthcare has got big problems with that and that's lot the work that NIST and might have been doing. And the work we were doing with ail, we were finding exactly the same thing.

So this standard here as hippa, it's great achieved its aim, but is it relevant today for the the the, the threats and the challenges that we've got in healthcare? Well actually it's not PCI dss, again, if you look the highest number is 50 across at the protect you've got detect at seven.

Sorry, there's one other thing I've got to mention way back here. So under network detect, you've got 14 there outta that 14 if I remember the number correctly. 12 of them is log files.

So if, if you are relying on detection and you're relying on dog log files for your detection, how effective are you gonna be with realtime detection? You're not. Not at all. And that's the point. And most of these, when it comes to detection and we're looking at network, you have got that mistake. So going back to here then the network under P C I D says it does refer to log files there as well. We look at the, the UK's National Cybersecurity Center, the calf control analysis. So basically this is their own framework, which is their cyber security assurance framework.

And again, the same picture, it's not that different. We follow this through to the ISO 27,000 2 22 version. It's similar. It's not that big a difference. I'll wait till you've taken a photo and I'll move on. You got it. Good. Yeah. And then we look at is a, I'm, I'm, I'm a big advocate of is aca. I'm a past president of the London chapter and I've been involved in some of the international committees and I have worked with CO and the picture in Kobe is not vastly different either.

Most of the controls are focused around there and you can say yes, the function and the purpose of CO is very different and you can use it for lots of different things. Yes, totally agree with that. UK has got cyber essentials. The cyber essential scheme is, is created for SMEs before they do any work with the government.

Now, I was surprised when I saw this that I, there's 140 controls. I worked around this, this, this field some time ago around I think 10, 12 years ago. We were one of the first few bodies that certified to certify other organizations around cyber ascensions. We were shocked and surprised at the number here and what you've got there because that's not my understanding. That's why I was saying I would challenge a lot of these in some respects if they, if the numbers are that good.

In fact, next one we've got is capability maturity model controls. Again, similar sorts of numbers 200 and 152. It's not that vast a difference. So first of all, let's look at some of the observations. And the thing is, even if is more focused on protect, it really doesn't make much difference because the continued reliance that we have around log files for determining detection and what we do about detection isn't very good. If we look at the maturity curves, again, they, they, they point out to us how standards and what reality is are very, it's not, we're not months apart.

We're not a year apart or two years apart. We are many, many years apart. And if we move on from there, you know, how can you manage tr what you cannot have visibility of? You just cannot do it. You nor can you have a response or recovery plans. It doesn't work.

Lifespan, sorry, the long lifespans should actually demand assurance controls and, and really that's what we should be looking at. But we are not second lot of observations.

First, all standards take a long time to agree. You've got the fact that they're agreed by a few people. You've got once they're agreed, they take a long time to filter down. And I mean hell of a long time as we've been covering the training, the certification are all big business. So it's in their interest to carry on having them carry on for a long time. And that's a shame. And they're required by who, who are they required by and when are they required, when do they have to get done? And they are just checklists and breaches still happen regardless in the way that they work. Right.

I'm gonna go on very quickly. I know you are ready to cut me off. Give me a second. So what role should they have Now the thing is what standards ever done for us, it's a, it's a statement that comes from life of Brian's movie. If anyone's seen it, there's a pit in that bit in that movie where they say, what have the Romans ever done for us? Standards are very good. Standards have done a lot for us. So don't let me kid you into thinking standards are useless because they're not. They do do a lot, but they certainly don't do what we expect them to do.

And because they haven't done everything for us, I don't think we should throw them away. What we should be doing is we should actually be looking at how we can get more from them in some sort of a response. We've got a whole bunch of options that we have got in a way that we can break down the time period in how enterprises benefit from that in terms of the options. So what the OP enterprises should do and how we can actually think about the way that we should be responding. So I'll hand back to you. Thank you.