And for our first speaker, we have Sarb Sembhi, CTO of Virtually Informed. So come on up. Thank you. First of all, just to mention that everything I cover is going to be in a guidance that's going to be out next year. So if you miss anything, if I go too fast, and I will go fast, don't worry about it. It's not a big deal. And the title of this wasn't my idea. I should tell you that because if I had thought I was going to do an entire session on being a cyber hero, I would have asked for more than 20 minutes for sure. And I would have covered more than just IT.
But the content is my idea, definitely. So right, with that said, the IoT Security Foundation, I've put it right at the front there. I am a board member of the IoT Security Foundation. I also am co-chair of the Smart Built Environment Group. So a lot of what I'm talking about is around the work of the IoT Security Foundation, which is quite important to all the work that I do. So with that said, let me just go through my background very quickly.
I, usually I don't like to talk about it, but I need to put it into perspective. And the reason I don't talk about my background is because I often think when people read out half a page of somebody's background, I often think, if anyone's interested, they're going to check that person out at the end, if they like them. And if they don't like them, we've just wasted that time talking about that person. So I'm going to put some context in terms of what we're looking at and why we're looking at it.
So about 2004, I'd been in cybersecurity for a couple of years, and I thought to myself, do you know what, it'd be really, really interesting if I could do some research on something that no one's looked at. So I decided to research into the vulnerabilities of network CCTV systems. And it was interesting, it was really, really good. It was so interesting that what I found, I went around talking to all manufacturers that I could find of CCTVs. And I was going around saying to them, look, do you realize you've got vulnerabilities in your products?
And amazingly enough, none of them were interested. And they all said to me, they said, well, what we're doing about security is we leave that to the network people. And I said, yeah, but hold on, I'm talking about vulnerabilities that have nothing to do with the network, they're to do with your other layers of the technology you've got. And they didn't quite get that at that time. So I started way back then, been involved in looking at these things for quite some time. And it was a while before we started to use the term IoT. It was only ever called networks this and networks that.
But a lot of the work I was doing was around systems that are used in buildings as part of building systems, which is why I'm co-chair of the Smart Build Environment Group. And that's why the document I'm going to be talking about does refer to the smart built environment. But the principles, what I'm going to be covering, actually do really cover right across the whole board. It's not just smart built environments. The IoT Security Foundation, it's been around for 10 years, we've produced a code of practice, which once upon a time became the standard.
And then it became part of the Cyber Resilience Act. So it does incorporate that. The assurance framework from the IoT Security Foundation is the most downloaded document that we have. It's a great framework, it's referenced by many standards around the world. And the foundation also leads on vulnerability disclosure policies. And we have an annual vulnerability disclosure report every single year. The recent one came out, I think, about three or four weeks ago. And we've got lots of special interest groups. That's a bit of background, do look onto the website.
There's lots of documents and guidance that's available for free. That's the whole point of the foundation that to provide guidance for free.
Okay, so see so challenges with it. So where did this this whole session come from? What happened? It came from me talking to Andrea, talking about a document that we were producing some guidance we were working on. And that original document and the thought for the document came from within the board and speaking to the managing director, where we were basically talking about what's the interest of CISOs to IoT. And I work with lots of CISOs. I chair lots of events with CISOs. I have a lot of contact with CISOs. And it's always been difficult of the last since about 2008.
I've done a lot of work around what's called the converged security risk management perspective. And the idea of converged security risk management is that rather than having two separate views of risk, you have a single view. And that single view consists of the physical and the logical. That's what you're supposed to be doing. But to get cyber people and especially CISOs to think about it that way is really, really hard. And it's not their fault, nothing wrong with that, because they've got tons of things to do already.
So what we were looking at when we were looking in the IoT Security Foundation is whoever is responsible for IoT, whatever they're doing, it's actually it should be about resilience. And we were talking about CISOs and what they are responsible for and what they're not responsible for. And we realized that most of the time, IT is the only thing they're usually looking at. That's definitely within their area of influence. But OT is not and IoT definitely isn't either, especially when you're talking about building systems.
So we were looking at how can you influence strategically, all of these things in a way where the CISO is able to have an impact and an impact over a long period of time, if they look at this strategically. And what we were coming up with is the fact that whether the CISO is responsible for these devices and systems or not, the challenge that the CISO has got is if anything goes wrong, they're going to have to deal with the attack or the breach or the vulnerability or whatever happens. That was the bottom line.
So because we felt that that was what they were going to have to be responsible for, we thought we'd use the term resilience. They are responsible for fixing something once it's gone wrong, basically. And as a result of that, what we thought we'd do is we'd come up with a guidance which is around procurement and procurement of IoT systems, building systems, any system.
But we wanted to write it, although we were writing for a smart built environment, we wanted to write it from a perspective that it shouldn't matter whether you're talking about smart built environment, IoT or other things, because a good procurement guide from a security perspective should be a good procurement guide. That's really what we're going to be covering, because we thought that CISOs could become heroes if they're able to set in place the right sort of context, the right sort of structures. And if they can do that, that mean that there can impact over a longer period of time.
So what I'm going to be talking to you about is our procurement guide, which we've got. So how do CISOs manage resilience for IoT systems? And the only way we figured out that they're able to do that is to be looking at procurement and trying to have a perspective on procurement.
Now, procurement is a big, big problem. We understood that, because it's not always centralized. Sometimes it's decentralized. Sometimes there is no policy about centralizing and decentralizing. In some places, it's centralized. Other places, it's decentralized. It could be a mixture of almost anything and everything. So we do appreciate that, and the document does try to take that into consideration to some extent. So develop structures for greatest impact. That's what we thought we should be looking at. The whole document that we've got, the guidance, is around trying to develop structures.
You know, you can't be responsible for everything. Because of that, you do need to be strategic. And to be a consultant around the organization and act in an advisory capacity and trying to feed into groups rather than be the fountain of all knowledge, it's to create knowledge pools within the organization and really help others understand their risks better, or at least to introduce those into the organization. Some of the things that are in the document, this is in the document. If you did want to take an image of this and some of the other ones I've got, please feel free.
But it's not, it is in the document, and you'll be able to get that for free. But we were looking at comparing old technologies and newer technologies and some of the challenges that we have. The old building technologies, what you'd find is that, as an example, the age that lasts between 15 and 20 years, newer ones, 5 to 10. Actual usage period, often, although we've put down here 20 to 25, we've known systems stay in the same organization for about 30 years, the same systems. And they're not considered legacy systems like they might, you know, IT systems might be after 30 years or so.
These are systems which are not considered legacy at all. But there's loads of differences, and you can go through this, as I said, when you get the documentation. We were looking at the procurement lifecycle. We didn't want to reinvent the wheel. We tried to pinch, borrow, copy from anywhere and everywhere we could. And we came up with lots and lots of things. This particular diagram, it's been adapted from the ANISA diagram. So if you've seen the ANISA document for hospitals, some of the things that we've got here, you will notice they are taken from that particular document.
So that's really the lifecycle. And I'm going to go through some of those phases. There's four phases in there. And we use all of those four phases. And we try to front load a lot of these things. And I'll cover that shortly. The smart built environment, it consists of so many different types of systems. The presentation earlier today on resilience, really, really good, good presentation, which covered a lot of the way that these systems actually do interact and don't interact, and the resilience of them and reliance of them on each other.
There are so many very, very different systems that are managed by so many different parts of the organization. But they all basically still comes under the smart built environment. Lots of regulatory and standard frameworks that are around for smart built environment. This chart is copied from an existing document. I can't remember which one. But we wanted to demonstrate that you've got sustainability and resilience sort of along here, going along that axis and going along the axis up there.
Really, you start from the guidelines at the bottom. And then you've got the strategy and so on after going up to the top there. But there are lots and we know we're going to see loads. We've got the I must have used an old one. The CRA Act isn't in here. Sorry about that. But the new I know the new document will have the CRA Act as well. There's lots of different benefits from smart built environment, especially from the building side from the side of the owners.
What you find is that there are so many benefits that they are forcing a whole range of newer and newer systems because of the benefits that they're trying to get. And some of those benefits are around sustainability and so on. So they are forced because there are there are legislation around their smart built building integrated ecosystem.
Yes, there's there's lots of benefits and lots of layers that you have there. There are lots and lots and lots of threats to the smart built environment. They're from inside, they're from outside.
And again, it's complex from some accidental some some intentional from from outside the building blocks, the building blocks we are familiar with. And we've tried to bring those into procurement that aren't used to these things. What we've seen in the building systems and building procurement is quite often what happens is it goes to the cheapest bidder. And as long as you're the cheapest bidder, you know, you're going to win. So what we try to look at is how we can bring this into procurement. And in terms of trying to bring that we had a whole range of considerations.
We didn't want to reinvent the wheel, I said that earlier, front load as much as possible. I've said that earlier as well. So really just try and share existing practices and bring those in and all the different relevant stakeholders and share the load rather than cybersecurity being responsible for when things go wrong, trying to bring security and resilience at an early enough stage. And in doing that, we the four phases that we had in the pre planning phase, really is to try and we these are nine best practices that we pulled together. You don't have to look at these in great detail.
But the key thing that we tried to do was to try to bring in almost anything that's possible for anyone to throw in to try and disrupt or anything that can go wrong. So we looked at anything that can go wrong and thought about how can you front load that and anticipate what can go wrong in the later stages that you need to look at the early stages. And the first thing really is to initiate the procurement project steering group. We know some organizations have already been doing that, but they haven't been doing it to the same extent that we're talking about.
And really sort of going from there to develop and agreeing the procurement types. And the reason for the procurement types is that you understand which ones have an impact on cybersecurity and which ones have no impact on cybersecurity and what the risks are in terms of data, non data and so on. So that's what we mean by the different procurement types. Establish the legal regulatory requirements for each of these. That includes the CRA. Establish cybersecurity and other principles and procedures.
Again, the idea is not to reinvent the wheel. Bring in and make sure you're educating the team early enough. The plan phase, as we go along, you see that there is fewer, there are fewer practices. And the reason there's fewer practices, as I said, is we try to front load as much as we could where we thought we were going to have problems. So this planning phase, it's ensuring the assessment of planned work hardware. It's the normal things that you might do in really procuring cybersecurity stuff, but it doesn't happen when it comes to building and when it comes to IoT.
You only hear about the issues, as I said, later on. And the last one there, develop eligibility criteria for suppliers based on system risks.
Again, working and speaking to procurement officers, we were finding that, yes, someone had put in the fact that there are risks to the system that should be accounted for. But when it came to actually making the decision, these things would be ignored. So all those risk things that they tried to look at early enough that somebody had documented, they would be watered down as everything went on. Two practices here at this stage, which is the sourcing phase, ensuring suppliers document any remote administration requirements.
Again, it's an obvious thing that we do in cybersecurity, but it's not something that's done at the moment, even on all the building systems that I showed you earlier on. Develop instant response plans. It's better to have a response plan early enough than too late. And that's what we're trying to encourage here at this sourcing phase. And then the management phase. This is the very last phase. Here we're talking about those things that sort of are being done.
Again, in the building systems, we know that they're not entirely being done. We've come across lots of instances where you've got the asset inventory, but the assets that's supposed to have been delivered and what's actually delivered aren't actually quite the same as they should be, and configuration management.
So really, again, it's those obvious things that many of us are used to, but we're introducing them into a part of the organisation that's alien to these things here. So these are the four phases. And really, what we've tried to do is we've tried to bring in as much as possible. We've got a whole range of documentation that we've got based on this. So this is the first document that will be coming out, and it's coming out in the, I think, before the end of Q1 next year. Have I got another slide?
No, I haven't. That is the last one. That's fine.
Yeah, that was about it. But we have got a range of other support documents that do support this in terms of how can you make sure that CISOs don't end up year to year, six months, whatever it is, having to deal with the resiliency of the system when they haven't been involved at the early stages. So we've looked at the whole of that process. We did go out and speak to lots of CISOs, speak to lots of procurement officers, facilities, how they manage even the system owners, the current system owners, and how they work within that to try and keep this smooth.
Now, this particular document that we've got coming out, it's meant to be short. It's only 20 pages. The idea of this is it's a starting point. We didn't want to make it too long. We've got other documents which we've had in the past which ended up being quite long and that they weren't used because they were very long documents. So we started small, and what we've decided to do is build the support material which would come after this on how to make this a reality.
So many of the things that are in that first phase, that pre-planning phase, those things are the things that we'll be trying to support as separate documents as we go along. So that's it. I'm in time. I've got 30 seconds left. Excellent.
Well, thank you. Does anybody have any questions? So thank you very much. I'm looking forward to the publication when it's out. One of the only technical calls out that you did in these recommendations is for remote access. So you're speaking to the choir a little bit here on that, but I'd love to know the thought process behind why that topic being pulled out to be such a clear call to action for the procurement and the smart building process.
It was considered to be strategic in that so many decisions, we were looking at IoT and the number of IoT systems within an organisation, within a normal enterprise, and within that we thought building space has the highest number of systems, the IoT systems. That was the first thing. Second thing we looked at, who do we know, because I've been sort of speaking about this since about 2008, who do we know that is responsible for these?
And since 2008, we've never come up with a single answer where we can say it's the facilities or it's this person or it's that person, and it's sometimes in-house, sometimes outsourced, sometimes it's a combination of both of those. So we felt that effectively we're in a position where we don't know who that target audience is in terms of who's responsible. We also know that because we don't know who it is, we know the CISO is still going to be responsible, how can we support the CISO role in a strategic way that we're not dumping on them? So that was another consideration.
So we looked at and spoke to lots and lots of different people and we thought to ourselves, right, what we think would be most useful for CISOs or the security team would be if we started to purchase the systems and we set up a guide for purchasing rather than anything else, because most of the other things, it would be small niche audiences is what we felt, and the rest of the cyber security team, it'd be preaching to the choir, it's the others that we need to get out to, it's the others that we want to try and involve.
And the idea in that, you find out in the document, in that steering group really is to bring in as many people as we can from around the organisation who should have an input into that, just like with data protection and you're trying to get, you know, you're legal, you're trying to get almost anyone and everyone else, and also in instant response you're trying to get everyone else. So we thought about all those and we thought we need to get them and we need to take that same approach to this. I hope that answers the question. Any other questions? Well thank you.
