Cloud Commute
Automatically secure your application with your personal Application Firewall
It started out as a research project into containerized environments. For many people, these kind of low-level security mechanisms have been hidden or underutilized. It's a different kind of beast than your average Node.js application, no offense to Node.js develop. You basically have the auditing phase when you have a testing phase. You see that if you keep it running for a little bit longer, does something happen which we didn't record? At some point, you put it into production, and you hope that you just caught all the edge cases. If they have been used at all, they have been used probably most as denials, setting a few boundaries for where your containerized workload can't go. You really want to secure the services further down the stack, because if somebody can inject some malicious call, your service behaves weird and probably returns something you would not expect. And as you said, reach some security passwords or whatever. You're listening to Simpleblocks Cloud Commute Podcast, your weekly 20-minute podcast about cloud technologies, Kubernetes, security, sustainability, and more. Hello, everyone. Welcome back to this week's episode of Simpleblocks Cloud Commute Podcast. With me and yet another guest, Hannes, welcome. I'm very, very glad to have you and maybe just introduce yourself very quick. Who are you, where you from, and what do you do? Well, thank you. Hi, Chris. Nice to be here. My name is Hannes Ulman. I'm born and raised in Sweden right now, currently living in Stockholm. And yeah, I'm a techie from way back. It used to be the guy, all the friends, family called when they had computer issues, when we were in little school. And I mean, I probably fixed as many computers that I have broken them as well. But it was a, yeah, I learned early days. But yeah, I'm one of the co-founders of Bifrost at this stage, and I have a background working in tech for the last 15 years in different areas. Cool. Yeah. So you're joining us from Bifrost security, right? So tell us a little bit about Bifrost maybe. Yeah. Bifrost is a runtime security company. We focus on helping organizations and companies in securing their applications at the runtime part. So we want to help them analyze and understand the behavior of their software to understand the better behavior from and differentiate that from the bad behavior that can cause exploits and vulnerabilities to be exploited into their co-vases and gain access into things that others shouldn't get access to. And yeah, we want to help companies limit the tech surface and contain their security, contain their applications at runtime. Right, right. And as far as I know, I mean, we've talked a little bit beforehand, as far as I remember, it all started as a university project at Lumben University. I don't remember the name. Sorry. No, it's pretty close. It's Loon University in Southern Sweden, which is actually my alma mater. So it's pretty fun to be working with something that comes from the same university as you as myself studied. But yeah, it started out as a research project into containerized environments and security around containers and new ways of running software. And that run from, I think, 2018 to 2022. And part of the findings that they had, they thought had potential to be used in a more commercial setting. And these days, universities across Sweden, or I think across Europe in general, have a separate arm that looks to what type of research is being made at our university, and what could be actually derived from that, and what should be turned into successful products, or could be turned into successful products. I think this is a longer lifespan in the life science area, where you have a lot of universities doing science within medicine and things like that, that then at some point ends up with one of the big pharma companies as well. But over the years, there has been a lot of more shift towards the tech side of it. So there's been both software, but also hardware companies getting founded on successful research coming out of universities. Which I think is much more interesting for the students as well, because you're working towards, which is eventually actually being used. I mean, sure, for for medicine, hopefully it is being used. But for other things, there's a lot of like this theoretical research that is probably never going to get anywhere. But because of, I guess a lot of the people in the audience probably are not aware of what the process would be. How does that look like? I mean, is the project or the research actually started with the idea of potentially going into a full-blown product in the end, or how do I have to think about that? Well, in this case, I would say that the research was done at the EU funded program that was running across multiple universities and industries in the Europe zone, but had contributors from all over the place. But we had this professor in Lund that was focusing more on the cyber security part and the runtime part. And they work within the group. And when they think that they have something that they would like to, that should probably get funded to become something, they can apply to a certain project or a certain program within the university. That's LO innovation, it's called, you know, an innovation program. And they get help assessing whether their idea or their research has potential to become something. And from that, they, if they are not fully permitted themselves to help you, to venture out from the university and get started and start a company and do all the things that that entails, they have a program to get connected with other entrepreneurs that can help you as operators of the startup and help together bring the commercial project to life. So that was actually how I got into this project. Right. Okay. Got it. Got it. Interesting. I've never, never spoken to anyone who had that kind of background coming from a university and the project being spun off into a company. That's, I mean, you always hear about those things, but as I said, I've never had the chance to talk to anyone. That's really interesting. So let's get back to Bifrost then. Bifrost, as he said, it's a security solution. I'm not sure if it's 100% specific to Kubernetes, but at least it is Kubernetes related. And as far as I know, it uses App Armor to automatically spin up profiles for App Armor, right? Is that correct? Yeah, that's correct. An App Armor is one of a few different Linux security modules that has been wrong for, along for quite some time. And the idea behind it is that you can set a few, or as many as you want, rules around what a given application is allowed to do. And when containers came along, these LSM were then converted into to also be able to contain your containerized workloads. And of course, you don't have to run this in Kubernetes. We have started with Kubernetes because we believe that it's a very strong foundation and a way of running containerized workloads that has gained traction over the over the 10 years that it has been. And but it's not solely contained by Kubernetes. And there are a few others as well. We have Acetenux. It's a computing one. There's a lot of work being done now in eBPF, which is also something that you can help and do these kinds of things with as well. So we're investigating those as well as we build this out. But yeah, App Armor is the one we've started with. Right. I think App Armor is the one that was initially started by Google for Android, or was that Acetenux? I'm just messing that up. That's an origin story I haven't heard. App Armor came out of Novel and was later acquired by Canonical. And the majority parts of the Ubuntu has been using App Armor for a long time. I think almost up to 10 to 15 years now to contain applications. Maybe I'm completely messing that up. But I think it's the one that the Android environment also or the Android. Google for sure is using it because they have also based their cloud optimized OS that runs on their default Kubernetes engine that supports App Armor out of the box. They come shipped with it on by default. Okay. Maybe the audience will lynch me for that. And he got it completely wrong. I mean, perfect. I'll help you shield you from a little bit of help. Right. Just generate an App Armor profile for me. But to be honest, I think it probably comes from the fact that Android is maybe the biggest App Armor user, and that's probably why I thought it came out of Google. Fair enough. So how do I have to think about that? How does it know how to generate those profiles? How does it know what the application needs or doesn't need? No, that's a good question. I think that for many people, these kind of low level security mechanisms have been hidden or underutilized. And there's been a couple of reasons for that. One, they are close to the kernel. So it's a different kind of beast than your average node JS application. No offense to node JS developers or anything like that. But it is. And it's also tricky to use in the manual sense. They come with a way to run them both as allow or deny whatever it is. And if they have been used at all, they have been used probably most as deny rules, setting a few boundaries for where your containerized workload can't go. And they have up until now mostly been manual labor. So line by line, you manually describe what your application is allowed to do or not allowed to do. And you have wild cars and everything like that. But it's tricky and a manual process. And with everything else in the dev tool chain, these days being automated for speed and velocity of development, the ones focusing on these low level mechanisms, they have hard to keep up. So they go unutilized. But that's one of the main thing about pyforces. We try to change that and we try to help you automate this process as well as most as possible, so that we can build the profiles automatically for you for every new build that gets deployed to your Kubernetes cluster so that we can continuously audit during the development phase of your application or the development sprints or wherever. So that we always get the latest developments of what your application is doing. And then we can automatically create the security profiles that evolves with the builds that you produce so that you can kind of contain the application as it grows on behavior. Right. A few weeks ago, we had Anders Ecknerd on the show, and he's working for blanking out with the company right now, or yeah, I listened to that podcast for a while back, and we know each other a little bit, and we meet each other on the Stockholm tech scene as well a few times. Yeah, okay, yeah, that makes sense, that makes sense. So he was talking about OTA, like the OPPA, the OP policy. And I think the idea is kind of similar, just from the understanding, Epamor is obviously deeper in the stack, because it shields the application from using certain operating system or other applications, whereas OPPA was more on the service level, basically between different services, but it sounds like those two things would be like a perfect match to be combined and used in tandem, right? Yeah, no, they are, I think that they combine each other or complement each other a lot, but they are working on different levels. And what we are trying to do with the Epamor and Bifrost is that we want to move. Zero trust is a very used term today, but I mean, kind of a zero trust on a Cisco level, so that you only want your software to do the Cisco's and all the IOs that you wanted to do, and nothing else should be allowed based on that. So that's the idea with us, that we help you contain the application by looking at its behavior, and then crafting profiles that allow for that certain behavior, and then can block behavior that lies outside of that boundary. Right, so in this case, it's probably closer to something like a web application firewall, where you monitor this behavior of the application or of the traffic for a while, and then you say, okay, these seem to be like the things or that is the traffic pattern, we expect from the application and everything else, we just got a block, basically like the, what is it, WAF from AIM? Yeah, that's very close, that's very close. And I mean, there's a lot of other monitoring tools that use like Falco and Tracy and things like that, that looks to see and tries to monitor for bad behavior, and we think that we can take that one step further by doing that in the, by basically setting up the good behavior rules based on the audit part, and then relying on protecting that in runtime in production with the security profiles that we can produce. So you mentioned eBPF early on, I guess a lot of the automatic auditing is done via eBPF integrations or eBPF, whatever you call them when they're in this in the kernel. Yeah, so right now we're mostly using app armor for the audit parts as well, because app armor has an audit mode that helps you understand and get the logs out of the given system, but we could use app armor, we could use eBPF for that as well. And, but we, we, we get audit data from a given workload based on, on the app armor audit mode. And then you have two different modes that you run the actual security profiles when you get them from our, from our service that you can either run them in a complaint mode, which is a non-destructive mode where it's basically just complaining when you step outside of the boundary that, that the profile is drawing up for your work. But then you can also get to a more strict stage where it's an enforced mode, where you actually enforce the profile. Right, so you basically have like the auditing phase when you have like the testing phase, you see that if you keep it running for a little bit longer, does something happen which we didn't record? And then at some point you put it into production and you hope that you just caught all the edge cases. Yeah, no, I think, yeah, exactly. No, I think from the ones that we have started working with on so far, they are running a few, few profiles in complaint mode in production as well, just to make sure that they don't trash anything and catch all those edge cases. And we help them analyze the few complaints that we have seen so far. And then once you get to a state where you're kind of boxed in, you rather want to be on the enforced mode where you proactively would block a bad behavior if that occurs or anomaly that anything that we haven't seen before. Right, okay, okay. So from, from a user's perspective, what would be like the biggest benefit? I mean, I could, I could claim why do I need that, right? I guess one obvious thing would be like a CV or somebody manages to get root permission or root permission on the container. But apart from that, if I don't have any malicious traffic, why would I care? Well, that's a good thing. I mean, I think that the whole shift, left mentality that has tried to focus on making sure that we get that to the vulnerabilities in the at the root cause, we still see a lot of applications that goes out to production with a number of vulnerabilities in them. Right. That's just fact, you need to ship features as well. And there's sometimes there aren't the fix that you can bump and there's work on breaking changes in the fix or things like that that makes it so that we have vulnerabilities. And research behind and why we, that this become became a venture out of the university was that when you look to a given software stack based on open source components that has vulnerabilities in them that can be used to to break into the container. And then in some cases also break in through the, to the, to the node and things like that. If you look to the behavior of what that's actually doing when it's supposed to be doing what it's built to do, you only allow that behavior. And then a majority of those vulnerabilities become mute because they can't do the step two or the step three and the exploit chain that they, that they, that they have. And being able to contain your application while you still have a lot of velocity in building new features and building and updating your product, still having something that can automatically contain it and understand it as it evolves is one thing that we think is an added benefit. And also as a platform team, you might be working with multiple dev teams across your companies that is doing a lot of different type of development that is building different types of service in the containers. And this is a way to, to raise the level of security between those team without actually having to, to work with every developer to have them understand how you actually can use the service like Bifrost or security profiles in general. I think you mentioned something very important. I just want to make sure it doesn't get lost because you talked about the, the attack chains. So these days, an attack or trying to take over a system is normally not a single thing, but it is a chain or a connection of either in multiple CVs, multiple vulnerabilities, whatever you want to call them, or even jumping through multiple systems or multiple microservices, trying to figure out how stuff happens. Yeah, no, that's, yeah, that's true. And I mean, there could be misconfigurations running at some point where if you had not given a security profile that would just tailor to the specific workloads behavior, that you would be able to, to use that misconfiguration to get secrets out or something that can help you move laterally quicker across, across the network and across the cluster. Right, right. That makes, that makes a lot of sense because now it, it also means you really want to secure the services further down the stack because if somebody can inject, you said multiple developments, if somebody can inject some malicious call that you wouldn't expect and now your service behaves completely weird, we all know, happy while testing. Right, so now your service behaves weird and probably return something you would not expect. And as you said, maybe breach some security passwords or whatever. Yeah, that makes sense. Unfortunately, we're already out of time. I would have so many more questions. But one, one, one, one final question, the one, basically, I ask everything, what is, what is on the horizon? What do you think is like the next important thing, the next big thing? What is, what is, what is like the interesting thing you see in terms of specifically, I guess, security? You're hard pressed not to have to have me say AI, but which I think it's, it's hard to avoid. But I think the, if you get it closer to application development, I think AI is a tool like many others and that will bring productivity and with productivity comes higher velocity and with higher velocity comes many more changes. And I think that in and of itself, that will give attack vectors will be, there will be more attack vectors in the future just by, by having this sheer speed on the velocity of software development being increased by AI. And that will bring for more interesting areas, both from, of course, how, how that can be utilized against us in terms of, of, of all the ways you can attack software and humans in terms to get access because still, of course, ransomware also have a large portion of them happening because people are socially engineered to give up the secrets that they shouldn't. But I think it will work in tandem. So I think it will, we will see an increased velocity in everything happening from good things to bad things. And that I think is, it's going to be an interesting decade to say the least for, for, for the digital area. I think that is a perfect way of ending the episode. There is good and bad things on the horizon. All right. Thank you for being here. It was a pleasure having you. I wish you all the best with Bifrost. I think it's a really interesting product. Thank you. Thank you for having me. No, my, my pleasure. Um, and for the audience, uh, next week, same time, same place. Uh, I hope you're listening again. And thank you very much as well. The cloud commute podcast is sponsored by simply block your own elastic block storage engine for the cloud. Get higher IOPS and low predictable latency while bringing down your total cost of ownership. WWW, simply block IO.