Tom Hofmann - Effective Countermeasures For Securing Critical Infrastructure – A View On The Human Aspect

I'm Tom Hoffman from Ernest and young Switzerland. And I will have a little bit of a different view this time. It's about a topic I've been pursuing for the last couple of years. My background is about 18 years in cybersecurity from setting up networks in China to developing high secure infrastructures for the finished military at the polar circle and with a strong technical background, I still try to figure out why we are not any further in the terms of cybersecurity. And there's actually one quote I wanna share with you in the beginning from actually someone quite famous, Bruce Schneider. And he said, if you think technology can solve your security problems, then you don't understand the problems and you don't understand technology. And this is actually what we see in a lot of cases. And just as the colleague from KPMG's at, we still have a lot of fishing malware.
So we put all this effort, all this money into technology and still, this is the major risk. And this is the part where I have been working on professionally, but also from an academic side for the last couple of years, when we try to figure out and understand what that really is. So I think most of you heard about the try to attack on Saudi Aramco last year. I want to have a little different view on that instead of just going through all the malware again and all the technology again, let's have a look what actually happened. So for those of you who don't know the Triton incident, this was a safety system, specialized malware, and this malware attacked the Schneider electrics system during the initial, like response and investigations. They found out that a lot of people in these plants actually leave the switch of the, of the box in programming mode.
This is actually a safety switch. So it's supposed only to be in program when you set up and install a new program and then turn it into run. So you cannot alter the software while it's running. And yeah, they actually found out simply no one just put it back into the program, into run mode and kept it in programming. And the idea is, so why did that happen? If you look at triune in the end, we even found out that the virus actually leveraged a flaw in the software itself. So no matter what the key position was by bad programming or in some incidents, they still were able to infect all the safety in systems, but it gives a pretty good insight. So what we can really see there, even though there is this key switch is a physical switch that is there to secure the system.
And even though these people never attended to do something bad for their company, actually it had a massive impact. And if you looked at further with all the new IOT stuff, that's just getting worse. And this also where the health information trust Alliance made a good statement about that. We don't actually address non-malicious well-meaning beings within our organizations. So we had a lot of people that yeah, set up an SAP system. As we heard facing the internet, they didn't do that on purpose to harm the organization. None of that, even if I go to clients, if I do an audit with a company, almost none of the flaws we can find are there on purpose, they're just happening by misguided employees. And what we currently do, if we address these employees, it's only passively, which means I'm pretty sure you all know these standard web based training everyone has to go through and they have to click through that and talk about, yeah, please don't open that attachment.
We have that for years. And we have been doing that for years and still it doesn't work. And if we do a penetration testing of social engineering, I mean, just still gate detailing, like following someone with a batch still works. So what is actually the reason for that? And we can just break it down to say, okay, more technology and more controls won't necessarily result in better security. And we see that with every breach coming up again and again and again, and therefore I was interested, okay, how can I help my clients to address the root cause of the problem instead of focusing on the technology part. And so this is not gonna be a sales presentation. It's actually going to be a little academia because the root cause can be found here in the year of 1949 in British coal mines. It was the time shortly after world war II.
When the UK was rebuilding the country and recovering from the war and coal was the main source of power and energy. So it was vital to the country to have a very high productivity in these coal mines. And they thought, oh, we just introduce a bunch of new tools, new mechanics, and now we're gonna be more productive. What actually happened? The productivity of the, of the minds decline people were leaving the minds. People actually did the job less good than before. And because this was so crucial for the country, the UK government send out a bunch of researchers around Eric tri and cam Bamford from the Tavistock Institute to actually have a look into that. Why so many cool new tools and still productivity is declining. And this is similar to what we see today with security technology. And what they found out is something that's called social technical systems, which means they found out that if we look at an organization as a whole, we definitely have the technology subsystem.
So we have technology. We have tasks that we address with these technologies. We have processes. And this is where we currently are. A lot of us talk about network segmentation, patching, et cetera. But what we really forget is the interesting part they found out back then, it's the social part. All of this relates to the humans and the roles within the organization. And that's the interesting thing. If we apply this to the Triton incident, this key switch for security position was built by an engineer. This guy's role was to an engineer, but the people who had to operate the software, the safety system, they're not there to just turn the key. They job is something completely different. And that's why the solution from an engineer is not necessarily the most effective one. And if we take it a little bit further into whole IOT, it OT convergence.
We now see a lot of people. Like when I consult my clients in the, in the energy sector, we now have people in trading desks, actually controlling power plants when they trade on a stock market. If you look at this and you're an IOT manufacturer and you have a heating system, the human and the role is for example, the client, the customer. So if you sell heating systems that are smart to your clients, you should consider their needs and their jobs. Because if it's Christmas Eve and you have an security incident and thousands of people just sit at home without any heating system, that's gonna be a real issue. And then they need a solution that is not designed for your role as a security specialist or as an it specialist, but they actually need something that works for them.
So in general, they found out the joint optimization within organizations only works. If we have a look at the social and the technical part, we really have to take both sides into consideration to come up with something that really works. And this is the same as we heard before. I mean, a lot of the, the malware incidents, this is still because yeah, technically people know, okay, don't click there, but they're like, oh, I'm in an HR department. I have to open this word dog. I need to enable macro whatever. I mean, these basic stuff that we've seen in the aftermath of want cry, this is just because we don't, or we shouldn't focus on the technical system so much.
So right now we are facing problems that are difficult or impossible to solve. We have this new coming up, IOT solve. We have more technology than ever before. We're gonna end up with like 20 billion devices in the next couple of years, all connected to the internet and more and more people use this it. And because of the incomplete, because we don't know where it's going to. And, and sometimes we even have contradictionary indications like, oh, you have to spend less money on it, but you have to be more effective. Yeah. Business still not know where we are really going with this whole IOT stuff, but yeah, make sure it's secure. So we have to bring this all together and we actually have to recognize them. And this is also something that is not new. This definition of a so-called wicked problem is about 30 years old. And this is something that comes again from the mechanical engineering part. There's a bunch we can learn from these guys because they have been tackling all these problems 50, 60, 70 years ago. And it's quite interesting if we apply these findings from times of mechanization to times of digitalization.
So how can we actually tackle these wicked problems? We should definitely bring together design and security. And obviously we already have security by design. It's also coming up more and more in the whole IOT world. We say, okay, we have to build that with zero trust. And we have to change the approach, which is completely true on the technology part. But as we've seen, it's not all that counts. And interesting just recently, the GCHQ and the UK national cybersecurity center released a bunch of guidelines on security by design. Not sure if you heard about that. So they're like one of the first international first national security centers that published such guidelines and what they say that we should have security built into the product. It can't be at a later, which is quite true. If you look at all the IOT devices, a smart meter, if you have millions of smart meters in Germany, how can you patch them?
How can you like remotely access 'em et cetera. So if you make these mistakes in the early beginning, you really have some issues afterwards and you don't wanna deal with that. The second thing is you should treat the root cause and other symptoms. That's quite interesting because this comes back to like, okay, don't just put something together, receive it works. And then it's all done. Now we should really take security to its root cause and say, okay, what is the problem that is causing security flaws? And the third one, it's a process. And it must continue. So these principles as good as they are. And as good as the intentions are by the British government, they are actually only focusing on hardware and software development. And we know that this simply doesn't work because the humans who gotta use that hard and software, they might use it completely differently.
And I, I see that with my clients almost every day that, oh yeah, the, the source code repository. Oh, it wasn't supposed to be out there, but we had to like quickly interact with someone. Yeah. We, we outsourced and yeah. I mean, theory is all gray. So let's have a quick reality check. And this was quite a nice one. It's just been recently released. This was a check from the Swiss government. So I really like that. It's it's publicly available so I can talk about that. And they actually had an internal audit of the Swiss military, one of the largest training facilities in Switzerland. And the funny thing is, so they actually stated like, oh, we have to acknowledge our people. They had proper training. It was all good, all fine. They had like the standard fishing stuff, et cetera, but further on, they found wifi access points all over the place.
And they had no idea where it came from. There were no any repository. There were no listed nothing. They had no idea where they had connected to. They had no idea. Was it an internal network? Was it completely isolated to which part of the network? And the funny thing is on top of that, they even started to develop their own private mail and web servers. So former military guys just went out and being very capitalist. They actually developed their own services that they've been now used by the Swiss military personal again, there was no control over the systems that have been deployed there. And this is a massive issue. And we see, again, it acknowledge and states. Yeah. We have proper training for these guys and still because they don't get the job done. That's why they had to start and set up their own infrastructure, their own services, and even develop their own major service, which is completely, yeah. Problematic. If you look at this as the Swiss military, and this is quite a lot, what's going on in the industry right now. So we see it doesn't work. We've seen it since 90, 49, that it doesn't work, that we have to change the approach. And this is why I'm looking very much into the human aspect of cybersecurity. And this is also what I do within Ernest and young. And we actually take this human center, this human center design to cybersecurity.
So what is actually human centered design? It's not about having these trainings and yet just check mark. He went through the standard fishing and then we are all good. This actually adapts what we have security by design to bring the human aspect into the game. So quite famous guy, Tim brown from ideal, it's a design company, one of the most famous ones in the world, he actually just combined it and says, okay, we use the toolkit of designers to come up with solutions that really address and integrate the needs of the people and the possibility of technology with business requirements. And that's the interesting part because this really takes into account the people that have to use these systems or that you build your software for. So what I am doing with my clients, actually, I am going there way before any technology decisions. And we together develop something that is technologically feasible, which we can all agree on as it and cyber experts here. We all know the business viability. I mean, we all have a limited budget. We don't have enough people here. So we all know these restrictions, but first and foremost, what we do in our workshops,
We go to the root cause we try to build something that is human desirable. So we take the people together and work on their needs and what they actually need to do in the end. And this is why we start actually with the human. And only if three aspects come together, then we can have a proper working and sophisticated system. The problem is sometimes it looks like this. So this is like awesome creativity. Yeah, it was super cool. We just go there. You know, we have, yeah, we get some insights. We do some research and it's some ups and downs and everyone who's been in academia probably knows they're from the master's thesis or something. It's like, yay. But yeah, we, we cannot really use that in a business context. We really have to see, okay, from research to concept, to even clarity and, and later to the final design and design here doesn't mean we have a fixed final product. This is more like the design phase actually means something like a minimum viable product. Based on this, we will start to develop further. And this is the main key point. How can we actually address that with our cybersecurity people and innovation aspects with all this background we've heard, how can we actually bring that into a process and address it to the cybersecurity?
And this is also something that we know from mechanical engineering standpoint, actually. So we start by asking the user, what is your problem? We go there and we really, we don't start with a standard axle word, document requirement, sheet, whatever. We've really gonna start with finding out who's the persona. Who's the user. Because if I address, for example, the worker in Saudi Aramco, Orry, it's gonna be completely different than what my mom would need with our smart meter and smart heating system. But in the end, these are the people we designed these solutions for, or internally. If I look at an power company, if we design cybersecurity for people trading on a stock market and operating these machines in the OT environment, I have to develop a solution that works for them because they don't want to find any shortcuts. If it works, it works.
And this is also a lot of the problems I see with shadow it shadow. It has been around for many years and cloud services that made it easier because what has been developed internally was not necessarily was needed by the user. And while a lot of people shy away from this, because this means more effort and more work in the beginning of the project, it really pays off because in the end, we do understand what we're gonna do. So in the first phase, when we do these kind of workshops, we actually start to discover research the information. This means in these workshops, I'm not only inviting the cyber department. I actually ask them to bring, Hey, can you bring a typical client, bring it all on site. It doesn't make sense that we design something within our closed community and closed group that we understand. We literally have in this design process, we have to bring in the people that are affected by it. And this is something that you might have heard of is, is the approach of design thinking. So we really come in and bring the users all together. And we have a very heterogeneous mixed group of various types of people.
And as soon as we have all this information, we have all this research, we then try to bring it together in a converging factor to trying to really understand what is the problem, what is the issue we try to address because only then I can design the right thing. And I, I really have to understand that. And this goes far beyond the typical requirements engineering we, we are currently doing in the second phase. We actually go from the problem. And again, we encourage people to come up and explore new ideas. So this means it's completely crazy. We have pretty funny things happening at these workshops, just developing something that, that is completely unusual and that most of the it people never thought about. But yeah, the guy from the welcome desk actually did because he was like, yeah, I'm using that. I'm having that issue.
And so based on these ideas, we then finally start to come together to a prototype. And this actually really means prototype. I have built VR glasses for argumented maintenance. What we actually did. We just cut it out of cardboard because it's also really completely different having a requirements, word document, or really emerge immerse people into this whole experience of prototyping saying, okay, just fix it together, glue something together. We have marshmallows, we have Lego, we have all this kind of stuff and people really get a tangible. And this is without going in too much of the scientific background. This is also quite a valid point because it engages people completely different than just sitting in front of a computer. We actually take away the computers for three days, which is quite unusual. So a lot of people are scared by that in the beginning. Like, whoa, there's no PowerPoint.
There is no word. Yes, exactly. Just get it off. And this is actually the, the interesting stuff that we are doing, because then we can really see where are we going? What is the new IOT security solution gonna look like? Who should it work for? Are these people integrated into the process? Because right now too many times we start and say, okay, I know the problem. I know the problem. Of course, especially in consulting, a lot of consultants are like that. They just go in and say, okay, no need to explain anything. I know what you need. This is gonna be the solution. And as we see with all these attacks, that's just not gonna work. And it's, we shouldn't keep continue doing this.
So just as a quick look, how, how does actually look like? So this is really, these workshops are really iterative. So we really embrace people to discover and come up with new idea. Like I told you, we completely remove all the it stuff. We get people posted. We actually get them to define their own persona. So they really empathize with the user. They develop the solution for, we come up with yeah, a lot of posters. It's very colorful and funny thing. These, these couple days we do this workshop with the clients, but it's really creative when they come up with something new, out of their usual box, out of their music, usual cubicle with the laptop.
And yeah, we actually have a bunch of tests. I mean, this was one of the events I did in a hotel. And we were like redesigning the hotel experience. And we just grabbed a bunch of people from the floor. And we said, Hey, we're just doing a prototype test session. Can you come upstairs? And it was incredible. What type of insights and, and bias has been discovered by, by doing so, not just by sitting there, especially very in Germany, we are very engineering. Like we sit in the basement for five years. We develop something. We come out with like, Hey, it's all shiny new, but yeah, it's not what we actually need or want. So, and this is something that we can try to avoid here by actively integrating these people by tackling their needs and by understanding their needs.
Yeah. And in the end we actually have the, the delivery phase and this is something people quite often get wrong. If we are in the requirements process, if we are in the process of designing something new, it's not about, yeah, this is it. It's all fixed. It's all done. It's all nice and shiny and polished. This is actually just the beginning of where we can then start to integrate really, okay, this is now what we're gonna develop. This is gonna be the system we're gonna implement. But after that, you can be much more ensured that the thing you build, you spent the resources on the money on which we all don't have. I mean, there is not enough security guys out there. So it really makes sense to spend a lot of time before technology comes in, spending the time on finding out what needs to be done. So the limited resources we have can actually be used to build what actually is needed.
So, and I'm thinking I'm close to the time. So the last slide actually is, oh, is a little bit slipped. We, we can't solve the problems by using the same kind of thinking we used when we created them. So this was quite a famous quote or similar from Einstein, depending on which citation side you look at. But it's quite true. I mean, if we just keep continuing this and we're just like, oh, there's another malware, there's another fishing attack we had to us military storing 1.8 billion records of surveillance data without any password on Amazon cloud, we had the us security central command, storing backup data with highly critical and sensitive information that was even labeled no foreign, which is no foreigner allowed. They just stored it on Amazon bucket without any password at all, revealing a highly secure military intelligence tool to the world. So we see it with the Swiss military.
We really have to rethink the way we approach our problems and to find new ways. And they might not only be purely technical. We just really have to take this human factor into account. Yeah. And by saying this, I just quit my talk. You can always reach out to me through LinkedIn or via email if you want to. And thanks for that. I'm sticking around, gonna be later on the panel for the discussion. And if you have any questions, whether it's academia, whether it's how to implemented stuff in an, in a project or in an organization, please let me know. Thank you.