The Art Of Saying NEIN (In Security)

So, welcome Pes. Thanks for having me today. It's an honor for me to be here in front of this nice audience. Um, as already said, I've been working for a couple of uh companies and institutions. Um, today this is a private talk. So, here is my disclaimer. everything that I say uh is my private thing because some of them may say nine to the things I will be saying. Um so when I got the uh first uh ask to potentially do this keynote here at Bites 9th edition obviously I could not say nine. Uh and saying no in general is hard. And why is that? Uh it's because everyone know how it feels to get a no. Um

as already said in the introduction, we all know if we hear a no already from being a child, there is this one word only two letters in German 4 yet very powerful which is the word no. And we know this from being a child that asks for something. I mean I I remember it well from myself, right? Can I have more candy? No. Can I stay out with my friends late night playing in the dirt? No. Can I go to school and wear my new heavy metal t-shirt with skulls and bones on it and my sted letter jacket? No. Can I then at least dress up like my favorite action heroes, Arnold Schwarzenegger in military look when I

go to school? No. I mean some of these examples were a little bit special but you got the point. Um so we all grow grew up with the word no being attributed to denial and rejection. Um and thus it's easier for us to say yes over no sometimes because who wants to reject a colleague or a friend? And so many of us uh tend to say rather yes to things. But there may be good reasons um for giving a no. When you're a child, you don't know. Uh you are not able in most cases to take informed decisions. That's why your parents do it for you. They are decision makers hopefully. Uh so you know, eating more candy, no,

not a good idea. It's unhealthy. Staying out with your friends late night, no, you have to do your homework first. Dressing up with your heavy metal t-shirt and your stud letter jacket. No, you're a sevenyear-old and not Ellis Cooper. Secretly, I did it anyways, but please don't tell my mom. And no, dressing up like action heroes like Arnold Schwarzenegger at school is not an option because being an action hero is a very dangerous job and it's a full-time job. So, here's the thing, though. As already said, no is the opposite of yes. So if you say no to something um you're also saying not yes which means you're deciding to do to not do something. So for today imagine the yes

as being the attacker side because you're actually tackling something and being the no the defensive side of things because you're trying to prevent things because in the end if you're saying no to something um it protects you also from effects of potentially having said yes. And as I grown up, I can overcome this. Of course, I can now, you know, eat up as much candy as I want. I can wear whatever I want. I can stay laid out as long as I want. But sometimes it needs hard lessons. Realizing that having said no would have been actually the better option. So to this end, I advocate today towards leveraging the power of no and make informed decisions.

Okay. Yes. Blah blah blah. What does this now have to do with security and how can it apply to security? So looking in security there is so many facets of nos. You can say no to so many different things. I'm sure you have seen experienced or even suffered from at least one of those things here and there is an endless listing that would not fit on this slide. So you can say to to many no to many things. You can also say more generally no to things like getting more budget uh to added workload for your teams. Uh you can also say no to your users like in the sense of don't do this or that. And you can also say no to

attackers by raising up your shields. And moreover, there can't be even no more nodes, no more vulnerabilities, no more errors, no more additional security rules, whatever. And lastly, my famous my my most famous one or my personal personal favorite uh failed assumptions. Nobody would ever do this and nobody can ever access this and nobody would ever try this and of course nobody can ever hack this. So why is there no at all now in security and where do nos come from? So first of all there must be someone or something that says no, right? And someone or something you can't possibly say no to. And secondly in security it's mainly about trust. So whom can I

trust? And uh trust requires humans in the end to some extent because of course machines can also establish trust amongst each other. But in the end it's humans who are looking for whom they can trust. And my personal experience with trust goes like this. Like would you trust that guy? So when I was young long time ago, I'm a very old man. I was already excited about computers when we had our first Intel 286 PC at home or something. And with that passion, I said, "Okay, I wanted to go and study computer science at uh a college. Luckily in my hometown, there was a college. So I went there uh applying and I uh was going to the

secretary there and she she looked at me and she said no. And I was like why no? And she said we don't need people like you here. And now you would likely need maybe some more context. Uh because that guy was actually me back then. Um, and that's, you know, that's already the compromise, right? Because it was even more colorful and way more extreme than you can see on this picture. So, when I had to renew my passport and go went to the authorities to renew it, you guessed it already, they said, "No, we don't issue a passport for this, right?" So, we made a compromise that at least we do it in grayscale, so it's

like, you know, not as as dramatic. Um yeah, but back to the uh to the college. So what did I do? I knew I had to change something. So I eventually went home. I cut my hair, uh dressed up nicely and shiny. And sometimes later again, I was there applying for the college, handed in all my records. I only had Agrades by the way and this time it was an entirely different talk. So she didn't even recognize it was me again. So I was accepted. I did my studies there, graduated and years later uh after the graduation ceremony I told her this story and she in the first place didn't believe it. But in the end she said you know uh you

have found your way and it's good the way it is and if I have a le learned a lesson in life then if you trust yourself uh and trust in what you're doing performance and your ambitions are more important than you look and that's actually a lesson I have learned multiple times in my life um but not this time that did not happen. I just want to enjoy this particular moment when you potentially trust me well enough to believe that this story that I just told you was true. What really happened was the following. When she said to me, "No, we don't people like you here." I was like, I mean, I showed her one of my fingers and

said, "I don't know people like you either." and I left because no matter whatever I would do, how good my grades would be, it wouldn't change her mind. It wouldn't change her trust in me. Um, yeah. But at that time, of course, I didn't notice. I was just an angry teenager. So, in the end, I applied for another college in another town, which was even more hard, they said. And since it was remote, I could first apply via email. So, they accepted me. And then the surprise was big when they saw me for the first time. But it was already too late for a no. So that way I changed the game by being first accepted and later on

rejected because then they said to me like you know people like you they will have a hard time here and I did but not mainly not due to my look but more to my performance. That's another story. So in the end the lesson I learned a lesson that money can never buy is trusting in myself as I really said in the first part in the story and trusting in my performance and my ambitions is more important than the look and this is actually what I try to do also to others how you want to be treated and conceived uh because this is one important part of establishing trust amongst humans. Now as we know about uh trust between humans

we can also recognize that computers or IT systems or cyber how we call it nowadays are sort of sociote techchnical systems. So there is always an interaction with humans to some extent and interactions with humans are sometimes unpredictable that what raises the fun in security right and uh so this may be the reason why we can assume at this point there may be different perspectives potentially for why someone is saying yes or no and uh in security we have attackers uh we have defenders who are in a constant arms race right thank you captain obvious everyone knows that uh there is also of course a victim who is to somehow extent impacted by this by this. So the the the affected

one, the one who has the damage and they have different roles. The attacker is abusing, the defender is acting as a savior, the victim is crying helpless uh and so on and they have different behaviors which also could like change over time. they have their very own perspective and to some extent this can relate to the well-known drama triangle um where you have the persecutor, the rescuer and the victim with these different roles and people very often step into this drama triangle in in many ways often even without noticing and the roles also can circle uh without noticing probably. And the point is that being in this triangle potentially even without knowing everything is blocked

right. Uh because then the blame game starts and we also can see this in security right. So the security department can say to the users you are so stupid you are never obeying our rules. The security department can say to management you never give us the budget that we would actually need. Or also the other way around, the user can say to the security department, "It's such a hassle and such slow thing to work with your shitty systems because they're so secure, but I cannot use them anymore." Or a client that always points to his customer saying, "He does not understand the need for security." Or your team that does not want to accept even more

workload. So there's plenty of examples for all these roles ending up in a blocking situation. And in this case, there's no further progress made uh especially when it comes to security. So what if a no now could be turned into a yes? There's two things uh in the first place. The first is escape the the triangle. Step out of the drama triangle and the drama. And the second one is um the answer is always 42. who know today it's 49 or in Bside's words is fear 9. So the answer to this is ah it's a bad one. [clears throat] I needed to do it. [laughter] [applause] The message is don't fear the no. Instead try to change the game. Find

game changers that can can help you turning nos into yes. And for today I brought four examples uh of generic examples but four things I found that helped turning nos into yes. First thing is technical disruption. We are on the edge of AI and quantum computers and you name it there's many things moving. The second is customer requirements and market requirements. So what do they actually expect? The third one is standards and regulation. Yeah, boring one. And the fourth one is an experiencable added value of security. Now for the first one, um, does anyone remind still this? Okay, that's great. You know, back then in the 1990s, there was the computer and in most cases it was really one computer

and the internet and in order to be in the internet, you just clicked on this and uh it would access it. >> Yeah, [laughter] exactly. And you were in the internet just connected to your mode and there was nothing in between literally. So if you remember there was not a firewall. firewall was introduced with service pack 2 and the tougher guys later on they had their own firewall dedicated firewall uh which had mainly the purpose to prevent the bad evil outside from the good inside uh so can see it here red outside bad good inside so that was the security paradigm at that time so it was not so complex right and this has changed little so actually much has

changed since then. So because as of today the internet did not get just more colored, it is also more moving, more interactive. It is ubiquitishes. It's social sort of. And lastly, it also changes things in the physical world. And while we have seen many technological advancements which also changed some of previous assumptions and paradigms, we have to deal with a couple of new things. So just think of um bandwidth internet connectivity. So if you think of the speed of 5G even you have coverage, it can be so fast that it's not really worth loading some some data from a local system. It can be as fast or even faster if you get it from the network. So the former inside

outside thingies may be blurred and then we see a lot of other things uh that have been introduced and that we have fun with today. Attacks can come from the inside. We have bring your own device uh things. Uh we have an ongoing interconnection of it and OT uh and so on and so on. And with this a lot of former paradigms have also changed. So the Windows 95 inside outside parameter is one example. Another example could be introduced by the arrays of AI agents. So they may add probably an entirely new parameter across um systems and functions. And the point of all this is that things that have been okay in the past, so where you would say yes,

it's a good idea to connect my Windows 95 PC with a without any firewall or something directly to the internet are nowadays clearly a no. And likewise, things which may be nowadays a yes [snorts] may turn into a no in future due to such things that are happening in many places. Just think of a simple example then I stop about this one uh otherwise the talk will get like forever. Uh one thing that is really added back since then is back in the times the internet was also designed out of this assumption right uh that is somehow a closed world because the internet was never designed with security in mind and that's because of two things. First, back then it was not

important for anything and second there were only a few trusted ones who had access to the internet. So the assumption was everyone who is in internet is good and trusted. Nowadays this changed little and nowadays the internet is also moving physical things. So back then when you had a crash at your system you may have lost your data and today when your car crashes you may lose your life. And one thing that also emerged from this is that the yes, remember the attack and defense, the yes side, the attackers have way more advantage over the no side for many different reasons being complexity, being insecure, software being whatever, there is a ton of reasons why it is as it is.

And in a world where the internet is moving physical things and [snorts] potentially causing real harm, there should be more no over the years actually. So the second point is customer expectations. You know, customers will expect certain things that they're used to. For example, if they buy something, it's reasonably secured and tested. I take this car example here. If you buy an expensive car, you simply expect it works and it doesn't crash all the time. And when you plug in your latest smartphone, uh it will work and it will be secured. And this comes particularly true when security became some sort of commodity. So one example in the IT world, everyone is used to buying money,

buying things for getting more security, right? We're buying firewalls, EDRs, and all this stuff in a domain like a car or a plane or a medical device. Probably people do not pay extra for security. They simply assume it's there. Like safety is assumed to be simply there. No one is buying extra money for his car that the air opens up faster. You simply expect that it's secure, right? The third one as I mentioned the probably boring one is all the legislation topic on standards and regulation. So actually maybe I have to say sadly that's the most impactful driver in my experience in so many discussions. So especially when it's sector specific uh because if there's a standard that

you have to obey and that is required there is no discussion anymore if you need security blah blah blah. It's just a discussion how can we meet the requirements of this standard and meanwhile and luckily probably we have plenty of standards uh in security and uh one thing that makes them very powerful to some extent is they add tangible metrics to the security discussion which means you can argue with cost with penalties if we don't meet the standard we cannot sell our products anymore we will lose probably shareholder values we will lose our market reputation, the management could be liable uh if it turns out that we did not meet these requirements and so on.

Yeah. And lastly and I have also say to say again sadly that's probably the weakest one of the four is the experiencable added value. So what I mean with that demonstrate the value of security and this is a hard thing to do a hard thing to market a hard thing to advocate. So that's why security is mostly being demonstrated by its absence and the consequences of its absence. So yeah, how can we turn now all this into yes, I mean we cannot go out and do technological disruptions or change the market requirements or drive new standards on [snorts] a daily basis at least. So here is a simple story of an example that has the unexpected factor

in it. Uh it's it's redacted and oversimplified because actually it's based on real world examples. Um but it incorporates a couple of the lessons and things uh mentioned earlier. So picture this. There is a product system which is intensively complex highlyworked. Um it's work it's built on a closed world assumption and it's highly engineered. So yeah during security review and the design phase there were plenty of discussions what could be the right level of security and so on. And since it's also let's say an accessible system to the outside not something that is inside a data center. There was also the discussion of hey we should you know make sure all components and all these

distributed systems which are interconnected there should be authentic and trusted which would imply we would need some sort of network access control hardware rooted security measures and many more such things but you know no because there's no security budget >> [clears throat] >> uh for this and also technically it's infeasible because we had to replace many things and redesign many new things. So yeah, it was done without such things. Then at the testing phase later on it turned out indeed okay it's very hard to access very hard to find a way tried out many things nothing worked but then there was this camera I mean not a camera like this but you get the point

there was something accessible from the outside where they said and you guessed it already it's my favorite no one will ever access this and you cannot you know detach it and whatever and Yeah, it turned out you can even without tooling uh with a little bit of practicing you were able to detach the lens uh of this device [snorts] and surprise surprise the unexpected thing happened. There is a network cable sides. So, let's connect to it. See what it happens. And yeah, there were security measures, but pretty basic ones actually. So, nothing like as it would originally have been suggested. Um, so it was easy to evade. Next surprise, next unexpected factor. And then being in this network, turns

out this device and its network cable was directly connected to the main central control system of this entire thing. You remember the Windows 95 example earlier like yeah that was even more unexpected. So what did we do? We made it experiencable. So by demonstrating to do something that everyone was saying no that's impossible inaccessible blah blah blah whatever we could open up the front doors uh in this case and this was something that is you know understandable to everyone that you know doors open that's a problem doors closed all good but even then when reporting this they couldn't believe it and so what did we do we gathered all them and we made a real world practical

demonstration. The reaction was sort of off like this kind of um even though uh because it's a closed world assumption and no one will ever connect to this you blah blah blah you know it there were a couple of other things that made it fun because you could not really remediate for example firewall rules were rooted in hardware because they said you know we will make it unchangeable no one ever can change it again not even if an attacker gets access rules anymore. So yeah, in this case it was yeah, they had to resign the whole thing and in the end it even made their security budget being revised the formally no turn into a yes and uh yeah

we showing let's say the or demonstrating the the experiencable value of security in this case helped turning a no into yes. Certainly we cannot turn every no uh into any yes like in the previous example and at the same time of no at the same time we cannot always be in security the department of no right and uh while as I mentioned initially saying yes feels good saying yes to everything and anyone is also not uh the ideal solution. So what can we do? Think of my initial picture uh with attack being the yes, defense being the no. Instead of saying always the department of no, always being the department of yes, we can carefully consider our yeses

and nos in security which means if we have to make a decision, do it carefully. Do it well balanced. Be consistent in your decisions. Be open open alternatives if you have to say no. And if you have to say no, say it early. Align with the business goals when you say yes or no. And most importantly, foster with your stakeholders openness, empathy, and trust because that's at the end what keeps the thing going. So balance well your yes and nos, your attack, and defense. Say yes to no more often, even if it's harder. Turn a no into yes where it's feasible. may not be in every case but in sometimes. And lastly and most importantly say yes to all the awesome

talks that will be ahead today at this Pak 25. Thank you. [applause]

[applause]

the microphone >> maybe on turn on. >> Yeah. >> Hey, pardon. So maybe a Sorry. Sorry. [laughter] Maybe a followup. I really liked your story about uh the university. Um so maybe a meta point I'd like to make to everybody who's here. Besides Munich is for everyone, security, enthusiasm or experience or not. Um we actually are very happy to see people who are from all different fields be it in IT or outside IT who are here your perspective is welcome and I think the most important thing that you can do is participate in the discussions and bring your stories and the small meta point I have um if you have a driver's license in Germany you probably have one that

doesn't expire so you must have a picture from the time when they didn't let you in. I'm Austria. Sorry. Okay. But I have also a driver license that doesn't expire. So >> I wonder how that is with image recognition these days when you need to rent a car. [laughter] >> I didn't face into any problems actually because in many cases they take this paper thing and make a paper copy of it. >> I don't know what you did but yeah. >> Yes. Welcome. Uh excellent. Um good. So maybe do I have a first question for Martin? [snorts] I do not see a raised question here. Okay. call. >> So, I think I'm supposed to speak into

this thing. Thank you, Martin. This was awesome. Uh, and my my my question is, so you mentioned becoming the department of enablement, do you have any kind of secret recipes? Any thoughts on that one? Like how instead of being the department of yes or the department of no, how to be how to have security as an enabler? >> Yeah, good question. So I think from from the first from the four examples I brought I think actually that really or unfortunately the standard exploring thing is the most powerful one. But you can also use the weakest one which is showing security to demonstrate that uh there is a value and that it is a good idea to have a healthy relationship

between the cost that you spend on security and the damage you can potentially have if you don't right so and for this I think secret ingredients in my experience is one I try [clears throat] to bring out a little bit is trust trust among your stakeholders you're dealing with you have to say yes or no. Carefully decide if you have to say yes or no and then give yourself certain like guidelines if you have to give or when you give a yes and a no. I I gave a few very high level examples at the end. But I think trying to be transparent and um consistent uh is a good thing. Um, and in the end I

would rather I would not say always no, but I would be rather cautious to not say yes too often than rather saying too no too often. Yes, exactly. >> Thank you. Do we have another question? Maybe anybody in the back. >> Um, >> doesn't appear to be a case. Then I will not stop people from heading to the coffee break. Please be back here at 10:00 I believe. Um a little bit before. Yeah. And uh thank you and enjoy the rest of besides. Thank you. [applause]