 small group. Do you want to start? This is really unofficial, right? So we're gonna try that. My hope was that we're gonna do that interactively and talk about zero trust. That's my hope. So I actually meant to start by asking you what is zero trust for you before we leverage where we stand on that. Yes, okay. So my name is David Adidas. I'm with IBM Research. I'm also security work group lead together with Evan of Knative. Also the owner of the security guard code, which is a Knative extension that can be also used by Vanilla Kubernetes. I will mention it later on in this session. And a member of the TOC in Knative. One of the activities that I was working on recently was on a white paper for tech security, which relates to zero trust. And that led to this unconference proposal. So again, I can introduce what zero trust is, but I know that different people have different views or understanding of zero trust. So I was hoping that someone would raise their hand and say, my understanding of zero trust is that. If there are no volunteers, I'll do the work. Go ahead. Go ahead. Or just speak up. I feel like marketing is ruined zero trust. Okay. So that's what it means, like different people. But I think in general, like the way I think I would look at it is it's like flipping the network or the internet, like everything has been opened by default, like from the very beginning. And so what we're really saying is let's not allow anything from the beginning like just by default, everything is closed off. And then when we have the right parameters for the user, the device, they're on the context, or then we'll make sure that point in time that they're actually entitled to access something. Right. That's like the general concept. That's okay. I would look at it. Yeah. Okay. We are just four of us, five of us. It's okay not to be ashamed here. It's a very small group. Okay. So yeah. So I am one of the organizers for security hub. I'm also security coach here for the attack within CNCF. The main goal for an conference is sometimes the speaker's talks for 25 minutes. And then we hardly have five minutes for questions. And then it overflows and then, oh, I need to run for this and then that. And then we never really get to have real conversations. So that's really the main motive of these kind of sessions. There is, I'm sure David has a lot of content to share that he can share. But if you want to like learn about a specific thing related to zero trash or any topic somewhat related to that, this is also a good opportunity. If you have experiences doing any of these things, and that is something you can share, I think we would all benefit from it as well. So I think we can, the more interactivity is, I think, the more successful on conference sessions can be. So we can try that. Otherwise, I know David has a lot of content. So really up to us how we make the session. Okay. So, so maybe I'll start by describing what zero trust is for me. What I, my understanding of zero trust is. And through the process that we did on this white paper, I also got to engage with other people and see that there are different, there are variants to what I'm describing. So I think everyone would agree, everyone that would dive into zero trust would agree that first of all, zero trust is the contrast of perimeter defense. So in perimeter defense is where you say, I have a firewall, I have a guard in the in the entrance, and he will make sure that no bad guys will come in. And zero trust says, no, the bad guys are already in. You have bad guys in your environment, which could be your own, your own team could be some node in your system that got hacked. It could be someone who was able to penetrate through your firewall and now is traveling inside your network. It could be malware that was installed by one of your, your IT guys without even knowing that he's installing a malware. It could be anything. And you can't assume that all the bad guys are outside and everyone inside is good. So this is really, if you want to understand that, think of a terminal in the airport. You can go into the terminal. You are not normally, when you go into the terminal, you are not being checked that you are not going to do anything fishy there, but everyone in the terminal is a suspect. And I think we all feel it. Right? We all feel it. We are being monitored every step of the way. All the time in multiple, multiple layers and layers of defenses to make sure that although we could be hostile, in many ways, the security of the terminal will be kept. And zero trust is in the same mindset. If you are originating a request from within the network, you are as suspicious as someone who is originating from outside of the network in zero trust. That's one of the things that people quickly learn to understand about zero trust. But it also means, and now I'm bringing my own thoughts into that, it also means that even if I know who you are, even if PJ would address me and send me a request and he would prove that this is PJ, and I know PJ, he always sends good requests, no exploits. I still need to assume that PJ's machine may be hacked. And therefore, he may send good, good, good, good, good exploits. So I'm always in that sense of suspecting everything. I need to be monitoring everything. All my services could be hacked. All my requests coming in, all the requests coming in could be bad. It's really a case where everyone is a suspect and everything will go wrong. Okay, that's a mindset. That's the mindset of zero trust. And now you need to ask the question, and that's really the hard part. So what do I do about it? We start in this mindset. We say, okay, we know that everything is a suspect. This means that if I give someone permission to do something, I will not give it based on the fact that he is one of my crew members. No, I would give him that permission because I know he needs that permission. And I would only give him permission for that minimal thing. Because I know he may be a suspect still, although I know him. And it also means that I need to continuously monitor him. And everything will go wrong. Meaning I have a service which is running for 364 days. And it could be that in the last day of the year, it will become malicious suddenly and start doing something fishy against my database. Start accentuating data. I need to monitor all my services. So that mindset and how we translate it to a technical architecture that we can now build and now maintain in our system, that's the hard part. That's where different people have different views of what should be done. By the way, many efforts related today to zero trust go and try to improve the identity management. For me, improving the identity management is only slightly helpful. Because as I said before, even if I know really who you are, I'm not sure that you are not hacked. So let's look at Cloud Native. And in Cloud Native, we in principle have services. We have clients approaching those services. And we have the actual service requests sent out. So between those, a service can get hacked. A service request could be malicious. And a client may be hacked and maybe malicious. Maybe sending us a malicious service request. So this is where we start. And again, it's my understanding is that the first thing we need to do to do zero trust is introduce what we call what is called in zero trust an active observer. That's not my invention. That's something that already appears in previous zero trust documentation and startups and so on. And it actually means that we have an automated observer, not the human that would look at what happened three days ago, but an automated observer that will evaluate the risk and the potential of harm from everything. From everything that we own. So we need to evaluate whether a client is now became malicious, started sending malicious requests. And we need to look at every request and ask the question, should I just process that request or hand it over to the service? Yes or no? If it's an exploit, maybe I shouldn't. And I need to look at every service and say, okay, now it's okay, and now it's okay, and now it's okay, and now it's okay, and now it started doing something really fishy. Maybe I need to restart it. Maybe I need to raise alerts for someone to quarantine it. Maybe I need to quarantine it. Maybe I need to raise it to someone to look at the code and see if there is malware inside. Why would restarting a service help, by the way? Why do I say restarting a service? Well, how can that help me? Yes, I'll go back to the known state. I don't know if that known state is okay. It could be there are two possibilities. One possibility is that it already includes the malware. That restarting it will not help. But then there is another possibility, which is very common, that it's vulnerable. I have a service. It's vulnerable in some way. And someone found a way to exploit it. So now it is in a state where it is starting to do something bad. If I would restart it, that offender would now need to redo his work. If I would restart it quickly enough, it would make his life impossible, and he would go away and attack someone else, which is good for me. So the most important stuff is that I need to be in that position, that I'm actually monitoring everything that is taking place in my cloud-native environment. This is a conference. I'm going to interrupt, unlike other sessions, as a moderator. I know David shared some very interesting thoughts in the last couple of slides. What questions do you have? Anything that stands out? Anything we could go deeper than usual? You can shout out your thoughts also. I'll try to repeat it for the recording as well. Anything you want. This answering Pidge's request is an open time-open question. So you can do that in five minutes as well. Yeah. And I mean, if the discussion goes well, we can skip all the slides also. So it's really up to us how we want to make it. I can start with one question maybe. I think the active observer feels like I am in some place where there are a lot of CCTVs and somebody is in a dark room looking at all the activities of people, but only for software and cloud systems and everything. So in reality, would there be like a person like an incident response or operation center who is looking at all the systems that are running who is trying to understand if the services are behaving normally or not? And if that is not the case, what are the realistic options? Because I think human interaction and monitoring probably won't scale for the scale of services we all work on. So I would like to claim that it is not feasible to assume that we're going to have that monitoring based on the SOC or some human looking at the incidents and trying to figure out what should be done. Because if we are to monitor each and every request, because it's a potential exploit, we should be able to block that request instantly. We can also report that to the SOC later on, but we need to do something at runtime, at that moment in time. Same goes for a service that got hacked. If we see a service that suddenly starts spilling out all the information from the database or attacking another service, we need to stop it right now. We can't put a human in that loop. So my sense is that we shouldn't include human in the loop. We should start building the security systems to offer the runtime security in a way that would give us at least that first level of security across the system. And we can have then the human later on coming in and modifying the policy, changing the behavior of the system, maybe something got blocked and shouldn't get blocked and saying, well, don't block it in the future. We can have the human in the loop later on tuning the system to the right place. Okay. So in here, this is a slide actually from the white paper that was not yet published. It's still under review. So what it shows is that when we're looking at the clients, some of the clients are outside of our scope. They may be external clients reaching out to services in our cloud native environment. So we can't really monitor the clients. We only monitor the clients by observing the request that those clients are sending. So first control release is to have some technology. And here it is suggested it's going to be a specific type of technology. But some technology that needs to be observing each and every request and identifying whether that request is hostile or not. And it's okay to be suspicious of a request without saying it's an exploit. It's okay to say, well, it doesn't look right. I'm somewhat suspicious. And then access control will decide what to do in it. So in fact, this is also coming out from historical zero trust papers that we're expected to define a confidence level. We're expected to say, how confident I am that request is okay. And access control should have the say, what do we do in each situation? So if I'm not suspicious, I would allow the request to do everything from that client to that service. It needs to be very specific according to zero trust. So that client when approaching that service, if it is not suspicious at all, let him do anything. But if the request is somewhat suspicious, maybe allowing only to read and not write, I don't know, make a decision in the access control. So the human would define the access control. But then the X control would rules would include also the indication of the confidence level. And then we also have a confidence level that needs to be done also question. Yeah. Maybe for everyone also in the audience, what is SBA, SR, SBA, SI? I'll answer that in a second. I didn't want to start with that because I want to be more generalized. In the same way, we need to evaluate a service and have a confidence level in the service. And there needs to be some rules somewhere, maybe in the service lifetime management that would say, okay, if that service becomes somewhat suspicious, start the instance, or only when you really are sure that it is... It's not really defined. All of that is not really defined. We are only somewhat in the beginning of understanding how to do that and what exactly we need to do there. Now, basically, the normal way how we do... I don't know if I have a slide on that. The normal way how we do identify that a request is suspicious is through signatures because what I'm looking for is an exploit. And how do I identify an exploit? I look for a signature that matches that exploit. Of course, if someone changes the exploit enough, I will not be able to identify it. So it's really up to how much coverage I have with my long list of signatures. And SBA, Security Behavior Analytics, is trying to be the alternative to that approach, saying, okay, we shouldn't be relying on signatures. We should be looking for something else that will tell us this is an exploit. And I'll explain SBA in a second how that is done. But conceptually, from the name, it is Security Behavior Analytics, so we analyze the behavior in some way. And from that we identify if that's an exploit or not. And in a similar way, you can think of service. If a service behaves in a very certain way, we may have rules that would say if it would do that, then be suspicious of it. Or you may have Security Behavior Analytics. You may look at the behavior and say, okay, this is a normal behavior of the service. And there are all kinds of things he may do which have security implications. This is what he normally does, which have security implications. But then he suddenly does that. And that also has security implications, but he never did that before. So now I get suspicious of him. Okay. So I now step back and I'll explain what Security Behavior Analytics from the ground up. So Security Behavior Analytics, if you want to know more about that, I did a talk on that yesterday at 2.30. So you can see that in the videos when they come up. Security Behavior Analytics is taking the stance that we can learn microservices and 12-factor apps, serverless functions, everything which is so minor in the behavior that it does, because it has a very specific pattern. And also the requests coming into that service. I don't know if I have this slide. I don't know if I prepared that. Also if we look at the requests coming to each service, these are on the left side here. Then all the requests to each service are very well defined, because the service is doing something very specific. We already took the big workload and divided it to small chunks. And each such small chunk does something very specific and serve a very specific request. So we have a very good pattern of the request, and we have a very good pattern of the service. And we need to be able to utilize that for security purposes. So Security Behavior Analytics says, let's learn let's learn exactly how it behaves, how the requests look like. And of course we don't care if it does something out of what was learned if it doesn't have security implications. So we need to know what we are looking for in a second. And if it does something off from what was learned, then we can raise suspicion. We can decrease our confidence level in that request, in that service. So the secret source of this technology is actually taking the ingredients from which I'm talking about analyzing a request. Okay? So to know if your requests include an exploit, we would be taking the ingredients of an exploit and would try to look them up in the request. And I will explain how you do that. We take each and every value, for example a header and it has a value and a query string has a value inside, or JSON body has some keys and some values. Each and every value we take that and we look if that value includes semicolon, curly brackets, dollar sign, quotes, comma, unreadable characters. There are plenty of those which people use to build exploits because they have special meanings in certain languages, for example. So we know how people build exploits, therefore we know what are the ingredients that our people are using. Now these will be our security indicators. We will monitor them. Now dollar sign can be used perfectly, um, um, naively in some field. That's okay. We will learn that in this field, in this specific field, a dollar sign is normally used. So it will not be an alert for us. It will not, it will not make us suspicious. But even if another value doesn't, does never include a dollar sign, then maybe we would use a dollar sign as an indicator. Now if you think of what that means, if you think of what that means is that is, um, we don't need signatures to do that. And I can show you a demonstration. Not now. If you see the, the, um, the, the session that was yesterday, you would see an example where we took a regular, um, vulnerable, um, application. It was vulnerable for log4j. And we sent the exploit for log4j. And it got stopped. Now that technology doesn't know log4j. And that's the important part. It's not familiar with specific vulnerability and the specific exploits that are used in log4j. And log4j could have many variants in the exploits. But it is looking for those ingredients. And it has identified those ingredients and therefore stopped the exploit. And I would say that the same thing can be done for services when we are monitoring services. We are monitoring services. And I give you a small example. If a server, if a service normally only approaches his database and suddenly also approaches a whole bunch of IPs outside, we get suspicious. If another service never approaches everyone, anyone, and he suddenly approaches someone, then we get suspicious. If another, if a third service approaches everyone on the internet occasionally, we, we don't use that as an indicator anymore. It doesn't help us. And that's just one indicator. Now let's go for other indicators. And over time, we build our understanding of what, what is suspicious and what is not. I'll stop here. So yeah, David, this is great. Like I'm very intrigued in terms of like, okay, how this is going to actually work. But we only have roughly five minutes remaining. So if anyone has questions, now is the time we can discuss it or we can let David continue with whatever is left. Is this making sense though? Like whatever David is sharing, thumbs up, thumbs down. Okay, cool. All right. So yeah, if, if no more questions, like keep going. And when the time is done, we can continue offline after that. So let me see what else. Yeah. So I'll, I'll, I do want to say that this is another, let's assume we can find some good security indicators. For example, to examine requests and identify exploits. That would stop many exploits, right? If we find an indicator that, that it would, that our ingredients in exploits, it would cause a certain percentage of the exploit community out there to be stopped by our tool. That is really good. Why? Because suddenly we are in a completely opposite chase than the one we are used to. Instead of them coming after us, we are coming after them. We suddenly start taking away their tool set, the offenders tool set. So now they can't use semicolon in their attack or they can't use, okay, let's say that we, we didn't make the work good enough and they can still find an exploit, go through our system and we cannot identify between normal and exploit. Okay. So think of that like a multi-dimensional space and all these indicators are dimensions in that space. So now we have only two indicators. We have two dimensions and this is what we see. We see that they are the same, the normal and the exploit. So we cannot detect that something is, is off here. This means we need another indicator. So let's say we found one, we analyzed the problem, we identified that exploit that got through and how it's, it's, it on that value looked exactly like the norm. So we couldn't identify and so on. So we added now another dimension. So it's like rotating. It's a bit theoretical, but it's like rotating the picture. We now see another dimension of the problem. So I have one question actually. You mentioned exploit will be different from normal, but would it be fair to say that there will be some events and some behavior that wouldn't be not normal, but also not be an exploit? So is there a chance where something is not normal, but it's not an exploit and something is not normal and it's an exploit. How do we kind of figure out what is what? So, so bear with me on that just a minute. I'm not sure I have the time to answer that, but second, I now added another dimension. So I now see the difference between them. But that dimension didn't help me only to see that specific exploit that came in. It helped me eliminate a new and another capability that the attackers has. So actually what I did is eliminate a subspace of the exploit that are out there that I didn't block before. So you can imagine that through such process by adding out additional indicators, by finding out the set of indicators that we need, we can get to that point where we are making exploiting cloud-native services because they are so well-defined and have good buttons and so on, impractical for the attackers. So there is a good prospect here to get to the point where the attackers would say, okay, I don't want to try to handle cloud-native because they have good protection against my long list of exploits that I have in my disposal, but I can still use those exploits against other systems and I can still try to hack into cloud-native in other ways but not through the API. And to try to answer your question about you, you are actually asking about false positives, right? So first of all, we learn the normal behavior. What you just described is a situation when there is a normal behavior which we didn't learn. So this is an operational problem. This is an operational problem. How do you get to that point where you build your normal behavior for that service, for those requests of that service, well enough and generalized enough so that it will include all the traffic that you are expecting? There is a process that we can run, for example, start in a test bed, do all the tests that we can to try and build up what is a normal behavior, then go to the field. In the field, we then try to identify between... We continue learning for a while, continue learning, but then we monitor what we have learned in the field to make sure we are not learning any exploits. And at some point in time, we stop the learning, we say, okay, we don't see any more false positives. Now it's a policy issue. Do I want to stop the exploits? Do I want to not stop the exploit? Just get alert on. Continue learning, not continue learning. Maybe that's all that before we go to zero trust, when we go to zero trust, then we also need to ask the question, what kind of access control are we going to have there? How do we influence the cloud confidence level and so on? So there is huge room here for handling false positives and trying to get it right. Yeah, I think that makes a lot of sense. I know we are almost out of time. So thank you so much, David. Please continue discussions afterwards. Or here we have another session at 3.25. We'll do kind of very informal way, just like we did now. Bring your friends, come back if you want to, and we'll keep learning. Thank you. Thank you.