S2 E7: The ghost in the machine: why OT is everyone’s blind spot

Speaker A: You deserve to be hacked.

Speaker B: Not because you're weak, but because you're worth, uh, attacking. These are real conversations from the front lines of offensive cyber security that will challenge how you think and show why the only way to stay ahead is to stay on the attack. Admit it. We all love efficiency. We love that we can walk into the office, swipe a pass, and the doors just open. We love that the lights know when we're in the room and the temperature adjusts automatically. We've all spent the last decade making our businesses smart and efficient. We've connected what was once purely mechanical to our wider IT networks, often to the Internet, all with the aim to save money, move faster, and make life easier. But there is a catch. We treat these systems like furniture. We assume the smart elevator, the connected h ah vac, and our automated warehouse lines are just appliances. But they aren't appliances. They are computers. And unlike the laptop on your desk, which gets updated most Tuesdays, these invisible computers often haven't been patched in a decade. This operational technology, or ot, is the blind spot we will be exploring in today's episode, because whilst we spend billions securing our data, we often leave the keys to our physical operations under the proverbial doormat. Joining me to discuss this are, uh, two OT experts from opposite sides of the cyber dividend. In the blue corner, Amy Brooks, a Chartered Engineer with 15 years experience navigating the trenches of, uh, operational technology security. She's the one figuring out how to secure and defend the critical infrastructure that keeps our businesses running.

Speaker A: Amy, welcome.

Speaker C: Thank you, Anders.

Speaker B: And in the red corner. Well, to keep us honest about the real risks being faced, we have James Smith, a hive leader at Covert Swarm. James specializes in offensive security, finding the paths attackers take from a corporate network breach into their physical operations and proving it before the real adversaries do. James, it's good to have you.

Speaker A: Thanks, Andy.

Speaker B: It's great to be here. All right, so let's strip away the jargon. Amy, um, I want to start with you. If I'm m a CFO or an operations director, listening to this, I might think cybersecurity is just about protecting. Emails and spreadsheets Help us understand the physical stakes here. When we talk about the invisible attack surface in a modern enterprise, what are the things surrounding us right now that are actually vulnerable?

Speaker C: It's, uh, a very interesting space because you need to define what operational technology is. I like to see it as any piece of equipment that will have some form of electronics or connectivity that can physically change the environment around you. Or, or trigger physical changes. We're used to big industrial definitions of operational technology, like, um, your oil and gas and water and electricity supplies. Those are really big. I want to stretch that definition to, okay, big networks of traffic cameras, traffic lights, the motorway gantries. These devices control the flow of traffic. So it's a form of operational technology. And then to shrink it down into what's in your local area, what can you see out the window, whether it's buildings with connected ventilation, access control lighting, to hospitals where you no longer need to travel from one part of the hospital after you've had your diagnostic scan back to the triage room, uh, with a folder and a file saying, this is what I've got. It's already been sent via email or some other electronic mechanism. And then to think about scale differently, a lot of property management companies now who rent out their buildings with inclusive services, they're still monitoring what resources you're using, how often are you turning on the heating, how long are you running the shower in the morning? Because actually, their bottom line is to make sure that you are using reasonable resources, but also their responsibility to make sure that if the heating goes down, they are there to fix it. If they want those services to be automated as part of a service plan, they are now part of this operational technology supplier. They are responsible. So in terms of visibility, we've made it so efficient that it's so invisible. We only see the consequences when it fails.

Speaker B: Great opener there for James to step in. James, when it fails is often because of genuine failure, but sometimes it's because somebody nefarious is deliberately seeing what they can do. And, um, that very much is your world.

Speaker A: Yeah, exactly. And it can happen very easily with OT and IoT. They were often built with no security in mind. So it makes attacking those networks and those devices very easy. They're not, they're not patched. Um, sometimes there's no availability to patch, sometimes they're legacy and there's no support there for them to be patched, which leaves them open for new exploits that aren't going to be fixed. So they can lay within systems and be unknown for a certain amount of time when it comes to the blue team as well.

Speaker B: So those defending.

Speaker A: Yeah, those defending, it's hard to monitor those because most of the time it's, it's the IT networks that are being monitored and not the ot networks. And nine times out of 10, you can't even perform a simple vulnerability scan on a piece of OT just because IT can't handle the traffic. Or for other reasons, it will just stop working.

Speaker B: So, so when I asked the question to you both around the invisible attack surface, it's not even for the, as I said, the CFO or the operations director that it's invisible to them, but it can be that, that the OT layer of technology within an organization, enterprise, business is even invisible to the technologists within that business. So they are used to monitoring, maintaining the traditional IT network. But what I'm hearing being described as something that really sits to one side of that, but is increasingly being connected to that. Is that your experience?

Speaker C: It is normal now for services to be built into the fabric of a building. No longer is it just behind the plasterboard. It is behind the steel and concrete of the superstructure. And these are things that stay there for a long time. They are part of the fabric of the building. You will inherit a building kind of. You buy it bricks and mortar. You know when to change the roof tiles or re render the surface. Do we talk about when cables fail? If it's got networked Cat 5 rather than Cat 6, which is what you want in. If you like want the faster data rate. Are you ever going to think of rewiring a building because it's got copper rather than fiber? I started my career wiring aircraft. I kind of appreciate the thing that scarily there is some aircraft still flying with wiring that I put in some two decades ago as a technician. But certain sectors are used to uh, and plan for that longevity. You do not design a helicopter to last for five years. You design it to last for 10, 20, 30. We design some buildings to last for 10 years. We design some to not last as long because we consider them disposable. And we need to start thinking about what technology we're embedding into these buildings.

Speaker B: I love this point about inheriting the technology of your building. So thinking about it as someone that runs a business and not that long ago moved into the facilities that we're recording within today. You said something earlier which struck true, which here in London, we had a really cold snap a couple of weeks ago and all we wanted to do was turn up our heating in the office. And the office manager told us, well, we can't do that. I'm afraid it's run centrally. So to your point, um, yes, the landlord being kind of responsible for the building management system was a genuine inconvenience. But it never crossed our mind when we were selecting this office to be thinking about the, the underpinning OT infrastructure behind it. You think about what's the it that you can bring when you move into a place, you know, the routers, the switches, et cetera, but not the underpinnings. The fact you talk about them being in the walls and so permanent in that sense must be an attacker's dream because there's all this hardwired capability just off the bat there, regardless of who's occupying a space. Tell us about some of your experience around exploring that sort of technology and its vulnerabilities.

Speaker A: James it's so true that most organizations didn't design their OT environments. They bought a building, merged it with a company like Amy said, or upgraded a process, and inevitably inherited, um, every risk that came with it. And for me, and real attackers that don't care who installed it, they just care that it's there. I've seen various pieces of OT that when we've done a simple penetration test, not even a test, uh, where we've aimed at OT or IoT, and we found just via a, you know, simple port scan devices that, that the owners of the business didn't even know were there really. And they were connected through switches that were inherited and they had basic WI fi, which was open, so it was, it was beaconing out, um, and anybody could connect to that. And they're on that flat network, which was really scary because it was, was a health foods processing plan. And on, on that network you could, you could go anywhere just via an open wireless network. It's, it's scary to think that there's things out there that people don't know about which can be used in a malicious attack.

Speaker B: Certainly a food preparation, you can imagine that sort of allergens that might be, you know, have to be very carefully controlled. If you can interfere with the, uh, production line and the introduction of unknown substances into a recipe or whatever that example was. Amy, you mentioned in your opening statement the sort of medical world and the fact that within the hospital environment, I think we're all used to exactly as you say, we go in for one test and then we walk from, uh, a scanner into a consultant's room and lo and behold, they've got all our information there. I guess that's less surprising because that's the more traditional IT connectivity that we'd expect an image going from point A to point B, whether it's via email. But those, those devices themselves I know you've had some experience with historically.

Speaker C: Yes, this comes back to that, widening that definition of operational technology to something that, um, can change its physical world. So a hospital scanner may have a large Moving magnet in it. It might have um, an X ray source that kind of needs to be safely controlled and there's going to be an operating system, there's going to be a user terminal. Behind that there's a user interface. Given the safety implications, should a non qualified operator have handle something that they shouldn't, that terminal is still the vector uh into something which can do physical harm to someone or its environment. All of these equipment need to go to somewhere to be calibrated because you don't want to be doing the wrong dosage. And one of these uh, large devices. I don't want to kind of ruin people's trust in these things because we rely on them, we rely on them heavily. But it just come out of calibration. It was open, I could have a look at it. I had the people responsible for the equipment in the room and I was just browsing through the user terminal kind of. This is where you set the thing, this is where you set thing else. I've got an open browser there just from browser connected to the Internet. We're in the UK BBC.co.uk. can I get to IPO? Should I be able to access something, a uh, large streaming network source on a device that is also controlling a radioactive source or a very large magnet or something that. Yeah, just again that translation of enterprise IT services and connections to something that actually has far more implications should it go wrong. But that's how it's configured, that's how it's monitored remotely. Certainly.

Speaker B: James, you mentioned earlier that much of this operational technology was built without security in mind. And that takes me back to the start of I guess modern personal computing. It's kind of in the same bucket for a very long time and rapidly had to catch up. Is that a fair analogy that you feel that there is that OT typically is on the back foot and that security by design just hasn't been there perhaps until more recent times.

Speaker A: Yeah, I think that's correct assumption really. And even though it's really important and you know it impacts our daily life, people don't realize how much we use OT in the background and, and I think that's what it is. I think people concentrate far too much on the IT side of things because it's there in front of them daily.

Speaker B: Yeah.

Speaker A: That they can see, you know, iPhones and things like that. If you look at the security on phones there are. They're much better now with biometrics and things like that. But with the OT side a lot of this equipment was built A long time ago, but it's still there. It hasn't been upgraded as fast as mobile phones, for instance. So I think that security side has been forgotten because it's, because it hasn't been replaced. Um, it's still there and the people that developed that the software or the hardware are retired or no longer with us. Um, and that's where it gets inherited. So they've got to deal with it and it's more of a case of it's working, let's just not touch it, let's leave it there, it's safer, uh, um, just to, just to leave it and forget it as long as it's working.

Speaker B: I love the examples that we've used so far, from medical scanners to office facilities. But of course you know, a great scale you've got, I think you mentioned oil rigs and kind of energy at start and you'd be like, I think, I think I hail power plants. You can imagine how well I would hope this is certainly not intending to um, scaremonger or create fudge that there is consideration around those technologies employed at that sort of scale and around critical infrastructure.

Speaker C: Absolutely. And I think it's important to point out mainstream ot follow regulation, they follow health and safety guidance. They have just different principles embedded into them. So as I mentioned, I started working in aircraft and aviation. The amount of testing you have to do that uh, a uh, software update doesn't exist because the code has been meticulously checked, that they actually want to set it in stone because that's part of the safety. When I was looking into curbside electrical vehicle charging, when we're seeing all these newcomers on board and they're trying to innovate in a space and kind of it's great to uh, see new people on board but, but they may not have had those same design principles as such as physical security kind of a, uh, plastic box is not going to cut it throughout all the weather. The hardware you're designing, if you are even designing your own, you might just be repurposing a single board computer that is meant to be development. But actually no one's given the right guidance to say you should design your own PCB because you need to remove the test ports, you need to remove the SD card slot where you can just pop it in and out and just replace it on the fly. These are uh, things where again we're seeing software being repurposed onto operational technology consequences and actuators and things that affect our physical world without necessarily going through the robust testing and consideration, it's not necessarily even security based. It is about a different threat. That's the thing going back to do you design something for 10 years or 20. I want to reassure people that kind of your really big traditional OT is really good. But there lies the legacy problem. Because they're so good at what they do. They are now operating in an environment where the threat has changed, kind of things have moved on around them and, um, that equipment is no longer capable of protecting itself. We need to find ways of doing it and building that bridge until we can build the next good piece of operational technology.

Speaker B: So, Amy, it sounds like we have a bit of a legacy time bomb from what you described that. Well, there's almost a legacy infrastructure crisis that is brewing behind the scenes here.

Speaker C: Yes. And, um, we probably don't know the whole picture either because a lot of this equipment is using older protocols. They're not necessarily always on because they're more power efficient or they've just been designed to last longer if they're not on all the time. Um, to discover that, you either need to have the engineer who was there and kind of hope that it's on the drawing somewhere. If you have got scanning tools within your operational technology management service that can trigger it, can it find out all the details, like when was it last serviced both physically and electronically? Is it still operating normally? We have this thing of meantime before failing and we look at how often equipment needs to be replaced before it fails as a preventative measure. These are all really useful things, but we're not necessarily using them to understand the threat and the attack surface that our OT environments are, uh, prone to. And another thing around these specialist protocols is the maintenance and do we have the skills and the people around them because that's an extra cost. I have this, um, lovely little anecdote of, uh, a factory engineer retires and they come back as a consultant to fix the machinery and charges an astronomical amount. And the factory goes, well, how can you charge us this? Give me an itemised belt. Right. Use of a hammer, one pound a minute. Knowing which or where to hit the hammer.

Speaker D: So.

Speaker C: So that the factory carries on working. Insert kind of what your expertise is worth. And I think that's the thing. We are running at the risk of trying to push the problem down the line and saying, we'll have these people and, um, we'll have these services, but not really understanding how do we move on from this.

Speaker B: So sitting more on the IT side of security in my career brings to mind banking and mainframes and the need for increasingly aging consultants to be wheeled in to support banks on platforms that nobody gets trained on anymore. And again, as you say, charging probably rightly extortionate fees for the knowledge that they do retain because it's literally in someone's mind as opposed to something that continues to be taught. So it sounds like OT's is as as much a hostage to that uh, reality as we've seen in it. James, talking through now about the maintenance and access problem that has come out in this conversation as well. Again, drawing on your experience, I imagine you've seen some pretty interesting weaknesses and vulnerabilities when you've been engaged to help appraise the security of these platforms.

Speaker A: Yeah, definitely. And it all comes back to, like you said, the access side problem is physical access. Yeah, the physical. Right, that's it. Um, with HMIS panels, with that human interface, let's take something I do which is a little bit naughty, but when I'm staying in hotels I get quite hot. So the um, the air conditioner system only allows it to go to a certain, um, a certain degree temperature. But with a little bit of research you can find out what, what is the default way to change that? So with a, with a small sequence on the screen I'm allowed to change that to whatever I want it to be, which is only a couple of degrees lower. But it just proves that with, and this is a large chain of hotels that it's just been overlooked. It's just a default configuration that's been installed and every room that I've been in has that same, that same sequence of authentication. Uh, I've seen production plants with operational technology panels, interface units that are uh, they're just there for anybody to press any buttons. And if they do have a pimco, for instance, which I have seen, um, the first thing I always try is four zeros or 1, 2, 3, 4 and 9 times out of 10 that's going to be correct. And that's the thing that really needs to change with. Yeah. In the future.

Speaker C: I think it's worth pointing out that the reason they have that is because in an emergency anyone needs to be able to access that piece of technology and turn it off. And I think that's why access control around operational technology is a very different mindset compared to security and data management, because it's not about restricting the access of someone to confidential information. It is about restricting an authorized person from changing settings or from, worst case scenario, everyone should be able to turn it off. And that's a really difficult one to manage because you have to start using different security protocols in order to protect that access control and not rely on it being a secret or something you have in terms of preventing someone from accessing it.

Speaker A: Now that's a very good point.

Speaker B: I also imagine certainly in industrial environments that we work with a food business, um, there's a lot of shift work that occurs and there can be quite a high degree of churn as well within that workforce. And so maintaining default credentials is also easier. It's just, it's a bit like putting the post IT note with the password on the thing that, you know, that most people are going to be using. But if there are fresh faces often turning up, um, you're deliberately bypassing something that's there to try and cover off elements of risk, which at the same time has a tension with the health and safety side, which you mentioned, Amy, is about, you know, in an emergency we need to be able to stop these things. So it's almost as though it's getting in its own way this, this layer of technology security to, to, to preventing that. The IT world is used to inventories knowing where the assets are. You hear these acronyms. CMDB is one, you know, configuration management database, something that every IT ops manager is always proud to maintain and hopes represents the IT estate that their and their teams are ultimately charged to look after. It sounds like the OT world is a far more fragmented place one, because I'm not hearing of clear ownership certainly within business environments that tie back to the organization themselves. Sometimes it's a remote party. What can you bring to help us understand, I guess some of the gaps that exist. So some of the insights as to how people could start thinking about building up an asset inventory for their OT

Speaker C: environments over time, IT has shared a lot of its protocols and wrappers to the operational technology world in this attempt to make it more easily connectable, discoverable. And there's a lot of gateways and wrappers around. Traditional non, uh, packetized information gets wrapped up in an IP wrapper and shipped across so that it is discoverable. That's good, but we're also starting to see the misuse of that. Wrapping up everything and not really thinking about does it need to be, does it need to be always online and discoverable and connectable, or actually did it have a specific purpose? That its robustness and kind of the longevity and the trustworthiness of that piece of equipment means that actually you do want it offline? I think having the tools to discover it and there Are tools that have always been in the operational technology sector that can be repurposed to give that information. For example, there is a health and safety legal requirement to have, um, a historian, a server, uh, um, a file store that is constantly taking the measurements, recording it so that in the event of an incident you have something you can backtrack to see. Was there a trigger? Can we do that kind of analysis? Should we be connecting everything? I think insulating operational technology from unnecessary IT enterprises and that segmentation of both laterally and vertically is something that needs to be thought of as a process. You don't just connect it up to discover it.

Speaker A: Great.

Speaker C: Do you need to think about really disconnecting it for the longer term? Um, what is the pattern of life?

Speaker B: Interesting idea. So you don't push a default. Everything should be connected. As we seek to modernize, it's fine to discover but not remain connected to

Speaker C: if that is what your risk and appetite is okay with. I mean an admin for a large service doesn't necessarily need admin all the time. We've seen our process systems bring in role based admins or context based admins so that you limit the exposure to one to harm. Those principles can be transferred over toti for that discovery phase. Then think about moving it back. What do we need to kind of risk manage?

Speaker A: Do you think that with we uh, go back to legacy ot and that's a big problem, the fact that things are getting more connected now. What do you think? That legacy OT isn't insecure because it's old, but it's because of the fact that it was never meant to be defended because it wasn't supposed to be connected.

Speaker C: Definitely the latter. It was never, never meant to be ubiquitously connected. Like connected to the Internet. There's different levels here. Much like your car is a network on wheels. Some might say it's fine because it just looks after itself. But would you want to connect a car to the Internet? Discuss separately.

Speaker B: That's a whole podcast. Just the last.

Speaker C: But that's the thing. We're talking about systems of systems. Then that level of connectivity, what level do you want to allow that lateral access should it happen? I'm talking about segmentation, definitely. That must kind of be a nice stopper for you if you come across it.

Speaker A: Yeah, I mean segmentation is definitely up there. Um, with one of the things that can help, but one of the things that we don't see and is one of the reasons why we get to find those systems within a normal IT penetration test. For instance, or red team is because of that segment, there's more lack of segmentation.

Speaker B: Could you bring that to life for us? So how, in the engagements that you've been involved in, how easy is it to pivot from an IT network into a connected OT environment typically?

Speaker A: Well, very, very simple. You could be on a flat network and realize whether it's a route for another system, an unknown subnet. And then when you start exploring using, using the tools and techniques that we use, you come across these systems. One of the easiest ways is I Normally look for HTTP ports, so 80 and 8080 or 443 and looking for those management interfaces. And normally they just tell you what that system is anyway, um, and then we probe further. But most of the time you come across these management interfaces. I'm trying to think of a system off the top of my head, but um, it can visually represent what it's actually doing, um, in real time. Sometimes it does, you know, it's actually got animations of what you're actually doing, um, with big buttons that say stop and start and things like that. And they can be just open with no, um, no, no profile and user account or anything like that. They just made for a, um, an operator to, to watch. And that's what it was designed for and that's that where that lack of security comes in.

Speaker B: But yeah, I know this, this is, this is a, uh, veiled compliment, but there's, there's real skill in knowing how to ethically attack OT platforms. I know that even a single packet sent to a platform that was never designed to receive that type of information can cause it to fail. Obviously that helps ensure that we train and upskill ethical hackers to do a brilliant job when they do engage and not inadvertently bring down systems as part of a test. But it also highlights how fragile these systems can be. As you said Amy, they're just never designed to be probed. They were designed to be set up, do the one or two or ten things they do perfectly and reliably over a lifespan. But going back to risk and risk appetite, I guess if an organization doesn't understand the infrastructure it's inherited or it relies upon testing, has to form a component of it understanding its risk profile. So I guess James, that's why you and your team really do exist and focus so much on ot is to make sure you bring that experience to the table. That helps outpace the threat, but also doesn't bring down the show as part of the testing.

Speaker A: Yeah, definitely. The thing is with OT Good. OT testing isn't about breaking things. And I know a lot of red teamers and hackers like to, like to say, oh, I break things for a living. Uh, OT testing isn't about breaking things. It's about proving whether an attacker could, um, so we focus more on paths rather than payloads, um, and how far we can get, um, before someone notices or stops me or the team. Um, and then it's evidence in that two, um, clients or an organization that we've managed to pivot through a network or get to a certain place physically and then we stop. Here's the evidence that we got this far. We could have done this. You wouldn't go and test something and start throwing payloads and packets at, uh, OT because it can cause physical impact and even harm. Um, so there's correct ways to do things.

Speaker C: I come across people who say, no one's going to spend the time creating the perfect ransomware for a piece of operational technology. And I sometimes need to go, you might be missing the point because that's because you're targeting ransomware as such, has been targeting something that an operating system which is fine, robust, has updates and so on. But when you throw that kind of ransomware at an operational technology network, you never know really where it's going to land or what's going to happen. How do you guide them through that change of mindset that they need to go through?

Speaker A: That's a good question. It is a hard one.

Speaker B: Do you find that you have to rely on experience to provide assurance to clients interested in being tested? Or are you able to point to, I don't know, certifications or other things that don't give the guarantees. But again, go back to providing assurance that you're not about to bring down the conveyor belt that cleans the nation.

Speaker A: I think the one thing that, um, people in charge get worried about is that I would never say that we won't bring down anything because it's impossible to say that you won't. Um, that truthfulness, it alarms people.

Speaker B: It's interesting because I guess the, the opposite side of that equation is that if a client recognizes that there's so much risk with a unethically orchestrated attack against their platform, then they need to balance that against the genuine face risk.

Speaker A: Yeah, that.

Speaker B: Which is, gosh, if somebody, you know, does find a, uh, path through to pressing the big red button or making it do something outside of its normal operating procedures, then that risk is worth mitigating by taking perhaps a smaller risk with the engagement that you Bring.

Speaker A: Exactly. And that's that. Yeah, you've made that.

Speaker B: Um, let's say it's a less worry of two eBay.

Speaker A: Yeah, yeah, yeah. Those conversations are really hard. Um, because you know, when we're scoping a job or say well what about this? Oh no, no, don't touch that bit. But why, you know, oh, because it's operational, we can't afford any downtime. You know, there's sometimes where there's options where we can work at night when it's not being used as heavily and things like that. Uh, um, but most of the time it is like being gatekeeped and just because pure worry because their job could be on the line or you know, that type of thing.

Speaker B: Uh, and there's no, it's not like it where you typically have a pre production environment or test environment. Now OT environments are incredibly expensive and it's kind of one thing. So we've got the live environment getting

Speaker C: replacements and that's a huge supply chain issue as well. We're dealing into traditional cyber security resilience here rather than um, OT main well even for OT maintenance. That's why they're so cautious around their uh, kind of failure rates and so on because there's not many on the shelf that you can get should something go wrong.

Speaker B: So we've spent a great deal of time exploring what is OT and the current state of risk I guess that we see across both the very local OT environments that we probably find ourselves in day to day, but also the much broader ones at ah, national level. We'll be back after a short break.

Speaker D: No one sees the battles you fight. No headlines for the threats you erased before anyone even knew they existed. But the real danger isn't what you see, it's what you don't. Your attackers don't wait for test windows. They don't care about scopes or compliance. They'll do whatever it takes to break in. That's why the most successful security leaders don't test. They attack. They subscribe to Covert Swarm. With our constant cyber attack subscription, our swarm of elite ethical hackers targets your full brand across digital, physical and social vectors. You get a persistent adversary using real world methods, doing whatever it takes to find a way in. Uh, when we do, you'll know instantly so you can fix it fast. And if we can't, you'll know your defenses are working. Subscribe to Peace of Mind. Subscribe to Covert Swarm. Find out more@covertswarm.com.

Speaker B: So I'd like us to move now from looking at maybe the problem towards now pragmatic action and ask uh, how do organizations start addressing their OT security challenges without having to think that they have to shut down the entire operation or necessarily break these critical systems. So where do we start when you simply can't start over?

Speaker C: Well yeah, if you can't replace it, you can't patch or fix. What's the best thing you can do. There is internationally agreed guidance on how to take those measures. One of the things we've already touched on asset discovery is not just about where it is or what it does, it's how it's connected to something else. Is it via a physical cable or is it even via um, a wireless connection? Because that determines how discoverable it is and how well it fits into your risk appetite. We've talked about segmentation and isolating equipment dependent on your risk appetite because you've got to connect to it to find it but you don't have to stay connected to it and thinking about what's ah, pragmatic both for your industry and for its availability and for kind of going forward, how are you going to change and upgrade it just to uh,

Speaker A: just to echo that really. We're also seeing this reflected in recent NCSE guidance especially around the connectivity and realistic management of it. Um and from reading it, um, the message is consistent. It's all about that visibility, segmentation and understanding those real attack paths that I mentioned earlier which mattered more than checkbox security.

Speaker B: Mhm. I think that that's a very recent set of recommendations that have come out the NCSE I think in January of this year. Right?

Speaker A: Yeah, I believe it was the 14th of this month.

Speaker B: So well worth the read. For those of you that want to look at some practical takeaways that's definitely something that we'd recommend you looking at. Are there any other practical resilience strategies appreciating that we're never going to achieve perfect security that uh, you'd recommend to our listeners?

Speaker A: Monitoring instead of patching?

Speaker C: Mhm.

Speaker A: Um, most OT networks are unmonitored and whereas the most focus is on it, um, the IT side restricting who can access what wherever possible.

Speaker B: That sounds very, it sounds akin to IT technology again the privileged access ensuring that new joiners get the right level of access when they move departments accesses reviewed and made appropriate for their new roles. It's playing back a lot of the IT world's kind of um, security knowledge back in again. There's so many analogies or parallels here. Should I say I also imagine it's true that we've got to be thinking more about as we continue to, as you say, buy legacy, build that future. We think about the procurement of the technologies that we bring in. Again, in the IT world, we see security questionnaires brought in on the buying new hardware or software products to our businesses. I imagine that that really is something that procurement teams may not be thinking about when they think about building management system changing within their office environment.

Speaker C: No, we're already seeing it with some m of the Internet of Things legacy devices. So whoever installed one of the home heating systems that was then bought out by a very large competitor and then very quickly sidelined and disconnected to the Internet and their users were just not able to use their automation devices anymore. We're seeing open standards come on with home automation. If your device has the sensor, has an IP address and can run some of these protocols again, we can put a wrapper around it so that it remains interconnected. We're seeing some of these kind of mitigations even in home automation, home operational technology equipment. So the practices and principles are being adopted. I think it's just sad that we're having to backtrack and kind of fix old problems in a way that we can't move forward very easily with.

Speaker B: And what do you feel about cross functional collaboration? Again, we talk with many of our clients who've got well established IT teams but are uh, often unclear of who their OT team is. And they invariably have one. Maybe it's not formalized as a team, but I think as you said earlier, Emmy, there are people with knowledge that you really don't want leaving your organization who are responsible for the maintenance or at least understanding the architecture behind those things. What does good collaboration look like between IT OT and as I mentioned earlier, maybe procurement as well.

Speaker C: Well, even just an appreciation of each other's responsibilities. People are working against different principles and different criteria. One engineer is determined to make sure that the system never goes down. Another engineer is determined that the access port is defendable and yet one cannot turn off to run the patch and the other is frustrated because the only time they can run the patch is at 2am when the likelihood of use and availability means that that's the best opportunity. I've seen this with programs to encourage security champions within different sectors. So an operational technology specialist will have some exposure to cybersecurity to understand why they're concerned about this particular thing. Um, because it is easier to import cybersecurity principles into sectors rather than to get those sectors to comply with cybersecurity. Because at the moment operational technology is heavily regulated. It's a nice thing, but it's the threat that is driving the cybersecurity landscape, not regulators.

Speaker B: From uh, an offensive security perspective, thinking about the role of threat intelligence in testing and the realism that can bring. Any thoughts that you can share with our listeners from a kind of TI perspective and how that might influence testing?

Speaker A: Yeah, I think, um, I just wanted to touch on something that you'd just spoken about about that collaboration between teams first because some of the organizations that I've, I've managed to uh, perform engagements in the, the OT side was actually with the responsibility of the facilities management.

Speaker B: Right.

Speaker A: And nothing to do with technology or it. Whether that's right or wrong is a different collaboration, wasn't there because it was that lack of understanding of how each of works just, just as AMI mentioned. But I think going forward the, the role of threat intelligence is quite pivotal really to understand what other people are doing. The threats that are out there. Yeah, there's, there's various ABT groups that will um, attack different industries. So it's, it's imperative to keep up to date with you know, what um, threat actors would target your organization or industry. And that's where that, that red teaming and that continuous attack side of things is really valuable because it's emulating that real attacker uh, um, and not the attacks as I mentioned earlier. It's more about the behaviors and the paths that they would take because then you can, you can perform those um, in a, well as safe as possible simulation and to find those gaps. Um, and I think that's really important for ot.

Speaker B: I think one of the things that we always aim to do on this podcast is to try and avoid panic whilst acknowledging the reality of the risks that we are talking about. Do you have any thoughts about how we can achieve that with all that's been disclosed? Because it's all quite scary stuff but equally I am hearing that there are things that can be done and there is a pragmatic way forward. So thoughts from you both perhaps on that.

Speaker C: So there are two distinct horizons for me. The near horizon, we've got guidance, we have seen, um, the failure of others unfortunately to bring it closer to home. That time and effort is needed to support and manage our own infrastructure and to look at some of these things seriously. The next horizon I see is the next generation of operational technology. And kind of one thing that is being progressively developed is automated reasoning within operational technology. So using algorithms, AI, machine learning from all that historical data to actually Develop um, mathematical and guaranteed engineering behavior from our electronics, from our operational technology devices so that they are safe both, uh, in a way that it can be proven they're safe in a way that you can observe them as much as if it was a physical valve with enough certainty and using some of these mathematics and deterministic behavior to increase that security and safety aspect at the same time. And we're seeing that in new startups that are coming, but also the migration from aircraft, kind of those who have already been using that technology for many decades, making them more accessible to other forms of operational technology. And I find that's going to be kind of really beneficial to everyone in the next horizon.

Speaker B: I love the optimism and that is great to start the conclusion with an uh, optimistic tone. James, as we move to a conclusion from the offensive side, the red corner, what's the one thing organizations consistently underestimate about OT security?

Speaker A: So I think that's the impact that an attack on OT or IoT can have. It can have a physical impact and um, that safety, safety issue. And because sometimes it's not taken as serious as IT and data, that can be quite alarming. But I would like to say that with the clients I've spoken to recently, more and more people are getting more aware of their ot, um, and know that it's not an issue. There is an area that needs to be looked at. Whilst they are hesitant, they are open to having those discussions around how we can safely um, review those um, those pieces of hardware or networks, um, yeah, in a safe manner.

Speaker B: Well, thank you both. I think it's clear from the conversation that we've had that the OT security is no longer optional. And I think James, those words you just shared are reassuring that more and more people in charge of securing businesses, whether they're CISOs or facilities managers, uh, are thinking and raising the awareness of the OT exposure, the risk, exposure that they face. And whilst we can all see how the risk genuinely poses some significant threats at local, uh, and even national levels, it's clear there's a pragmatic path forward. I m would definitely point our listeners back to the recent NCSC guidance that has been published in the last few days. Lots of fantastic takeaways in there, some of which we've shared with you in this conversation. But it's also clear, I think through the conversation we've had, that, that as I introduced Amy from the blue side, the defense side, and James from the offense, the red team side, that really, it's both sides working together that helps reveal the full picture and the risk that organizations genuinely face it's clear that OT is really everyone's problem now. It's not just a critical national infrastructure matter. And I think what we've heard is that the machine in the building we now know where it is. We know the sorts of questions that we should be asking and the same is true probably of us as consumers with the IoT that we have in our homes and then more broadly thinking about the enterprises whether uh, it's an oil rig or a wind farm thinking about the technology impacts that an OT approach to testing will raise on the risk register I think is something of increasing importance. So I'd like to thank you both for your time today. Amy for traveling to us here in London and spending the morning together talking and James for you as well it's great always to catch up and I look forward to speaking to you all again on another episode very soon. Thank you.

Speaker C: Sam.