 Magna, are you facilitating today? Sure, I can start. Okay, second. Yeah, hello everyone. Thank you all for joining. This security meeting, per, as this meeting is being recorded, right? And since this is a CNCF meeting as well, just make sure that you are following the code of conduct from CNCF and anything else, Andres, before we start? Sounds so good. Okay. Welcome again. Thanks, Magna. Thank you. Yeah, so yeah, today we're going to have a presentation by Jen Burns from MITRE. She's going to speak about the MITRE attack for containers, the first draft, which was released last month, and provide us with some information and guidance on how we could help improve this initiative. Jen, if you're free, take it away. Yeah, for sure. Let me put this together like a short slide deck, so I'll see if I can share my screen here real quick. Okay. You able to see that okay? Yes. Okay, perfect. Yeah, so I guess first off, thanks for having me today. Jen Burns, I work at MITRE right now in the lead of Attack for Cloud. And a few months ago at this point, we kind of kicked off this project with MITRE ingenuity's Center for Threat and Form Defense to research adversarial behavior in containers and really determine if there's a possibility of including container techniques into attack. So at this point, like Magna said, we've released first draft of the matrix for feedback from the community. We've already received lots of really great feedback. Just wanna talk to you folks about really attack itself, kind of that first draft that we released and how we could use your help and how we could potentially collaborate on this. So figured I'd just give a short background on attack. I know some folks may be familiar, some may not. So kind of start off with that and then just kind of hope to kick off a discussion on that contribution process and collaboration process. Really feel free to interrupt me or ask questions at any point, definitely happy to answer whatever I can. But to start off attack itself, it's a knowledge base of adversary behavior. It was born out of a series of red team and blue team operations at MITRE's Maryland site around 2013. I originally have focused exclusively on the Windows platform, but since then it's kind of expanded into like Mac OS, Linux, mobile, even network devices, ICS, and then also the cloud, which is my area of focus. And then this containers piece is kind of tangential to that. Key point about attack, it's based on real world observations of adversaries. So what adversaries have done in the past and what they're likely doing now based on those previous observations, it's not really meant to include kind of more of the theoretical proof of concept attacks. It really focuses more on what real adversaries have done because we believe that there's definitely value in prioritizing those types of behaviors based on threat intel. Another key point about attack, it's free, it's open, it's globally accessible. Anybody can use attack and because it's free and open, it kind of provides a common language that different teams and organizations can use to make sure they're on the same page. And then last, but certainly not least, attack is driven by the community. A large portion of attack has been contributed from outside of MITRE. We shape many of our decisions based on the needs and requests from the security community. For this containers work specifically, at this point, the vast majority of the techniques have been driven by contributions from the community, which is pretty awesome. You folks are the ones out there with boots on the ground really seeing what adversaries are doing and defending enterprises. So having those contributions is pretty invaluable to us and it really leads most of the work that we do. Just to kind of take it a step further and really explaining what attack is, this model from David Bianco is pretty helpful. If you're not familiar, this is called the Pyramid of Pain. It describes how some indicators that adversaries leave behind are more painful for them to change than others. So for example, if you think of something like a hash value, if an adversary changes a single bit in a file, that hash value is going to change. It's almost painless for them. Then on the defender side, carrying out actions based on something like hash values as limited utility since the adversary can easily change them. Similarly, adversaries can do things like register new domains, IP addresses per campaign. So if you're just monitoring for those, you might miss some activity. And then moving of the pyramid to what is most painful for the adversaries to change, we see that tactics, techniques, and procedures, and that's really where attack lies. Adversaries are humans too, just like us. They are creatures of habits, painful to change behaviors. So as a defender, if you can detect those behaviors or TTPs, you have a better chance at thwarting those adversaries. If you're familiar with attack, you're probably most familiar with the enterprise attack matrix. As a heads up, you can also find all of this on our website at attack.minor.org. Across the top are tactics, or what we consider to be the technical goals of adversaries. And then within each column are the techniques or how those particular goals may be achieved, such as gaining persistence via the technique of account manipulation. More recently, we added sub-techniques to the matrix. And you'll see this with containers as well. So for example here, the technique fishing has three sub-techniques. And these are just more specific techniques that fall under that technique of fishing. And then within techniques and sub-techniques, we have a set of procedures. And these are adversary implementations of specific techniques. So for example here, we see a specific implementation of the spear fishing attachment technique carried out by APT-12. And that's mapped to a couple of open source threat reports for references. To dive just a bit more into techniques before we dig into containers, here's an example of a technique on our website, which is process injection. You'll see we lead off each technique with a description. And really that description explains what the behavior or technique is from the perspective of the adversary. And then we have these little cards on the right side of each page that calls out things like the tactics that a technique belongs to, what systems may be affected, such as Linux, Windows, and macOS. When we get containers into attack, there would be a platform here, most likely just called containers. We also have different cloud platforms that may be included here as well. And then currently, we also have data sources here. And data sources kind of explain what sensors, so to speak, may be used for detection of this particular technique. So I kind of get more into the containers bit. Why are we investigating the container space for attack? First off, we've had the community ask for it. Like I mentioned, attack is largely driven by the community and the needs of the community. Before we started researching adversary behavior in this space, it was probably one of the questions I received the most from folks when talking about attack for cloud. It's kind of like the what about containers piece. You may also be familiar with Microsoft's release of their Kubernetes Threat Matrix. We've seen folks start to adopt this as their threat model, which is great. I think this just gives more weight to the fact that folks are looking for something to kind of utilize in this threat-based space for containers. Also, we're finding threat intel and reports that mentioned behaviors in the container space often tied to Linux and cloud as well. We want to be able to kind of represent those container-specific behaviors within attack, even though the behaviors might kind of bounce across cloud containers in Linux. And then also one of the reasons we're able to take up this work is it's actually a project through MITRE Ingenuity Center for Threat and Form Defense. This really just kind of gave us that opportunity to take off and run, so to speak, with this new space for attack. All right. So kind of when it comes to what we did first, really came down to researching that adversary behavior in the container space. And so we kind of started by searching for open-source intelligence in the area. There was some good content from folks like Palo Alto, Magno sent us some great content from Trend Micro. Aqua had put some stuff out too. We also have ties to folks in the community who have visibility into what adversaries are doing this space. So we definitely leveraged those and received contributions from them as well as we kind of started developing that draft matrix. We've actually been in touch throughout this process with Microsoft, kind of regarding that Kubernetes threat matrix, since that was kind of one of our final pushes to, hey, we need to do something with this in attack. They gave us a really great starting point with the work that they had done. One of the things that kind of sets their threat matrix separate from what we're working on though, is that in the wild element of attack. Mentioned this in the blog we released with that first draft of the containers matrix, but one of the first steps that we did as a team was actually work with Microsoft to determine, out of what they have, which behaviors in their matrix had been carried out in the wild by adversaries. And we also published an initial blog kind of during this kickoff of the project asking for intel on what adversaries are doing in containers in the wild. So then we basically organized that content, those contributions into kind of these distinct behaviors or buckets, so techniques based on tactics. And then for each of those techniques or behaviors we determined is this something that's already covered in attack. So if so, for those behaviors, we would consider maybe simply just adding a new platform tag to that technique, like that containers platform tag. So we would maybe add that tag, maybe a line or two to the technique on how that current technique applies to the container space. Maybe add more content to the detection as well to how that kind of applies to containers. If that behavior though wasn't already covered in attack, that means we need to add a new technique or sub-technique and attack to kind of cover that behavior. So building out those new portions of attack and kind of carving out what that might look like, that's actually been a really large chunk of this work. At this point, we're still going through feedback we received from folks and really refining our matrix. We're also building out those detections, data sources, mitigations, other pieces of attack, particularly for the techniques that will be considered new to attack and due to this addition of containers. Timeline-wise, we're hoping that containers will be added in the April release of attack, which is in the next month or so. There are some dependencies that we have there that may or may not be met. So we haven't officially confirmed that release yet, but that is what we're targeting at this point. And so this is what we released with our blog post is that first draft of a containers matrix. I can come back to this and talk to you folks more about this and answer questions you might have about it, just want to go through kind of the next slide real quick first. So how can you help? We've already received lots of feedback from the community. This has been a huge community effort. There's gonna be a lot of contributors added to attack with this effort to add containers, but we do still have some thoughts and questions where we could use some help. One is, do we have any gaps in the matrix? Have you seen or heard of in the wild adversary behaviors that are currently not represented with what we have for our draft? And this is really focused on the in the wild piece, so not that kind of theoretical what could happen or what our red team's doing. It's really focused on the real adversaries. What are they doing? And also, do you have intel on adversaries using containers for other traditional purposes, such as for something like exfiltration or collection? What we've been finding is that most of what's out there, really the end goal or the objective of the adversary is coin mining, crypto mining. So is there, are adversaries out there doing like all of these behaviors to ultimately do something other than that crypto mining piece? We really want to understand if that's really the main objective of adversaries in this space right now. Next, kind of besides deploying new containers, do you have intel on lateral movement behaviors that would fit into containers? Something like moving from container to container or pod to pod, et cetera. Kind of what we've been saying is there's a lot of gaining access to the environment and then deploying new containers versus like getting access to a container and then moving laterally to another. So we're trying to kind of suss out is there like this idea of lateral movement in containers that adversaries are actually taking advantage of or is it more of like a theoretical concept of you can move laterally? Kind of fourth here, did we get something wrong? Is there something completely inaccurate or did we name something weirdly? We've gotten actually a lot of great feedback on this already. We know the technique we're calling container service, that's not a great name. It's kind of vague. So we're currently working on trying to suss out. You know, what else could we call this? Should we split this into multiple techniques or add sub techniques to it? But any thoughts that folks might have there would be super helpful for us. And then finally, we're kind of at this point where we're building out detection logic to add to attack for these specific techniques. And a lot of it on our end has been kind of reading through what recommendations are in this space. We don't have like this lab where we're seeing adversary activity and trying to detect it ourselves. So we're kind of hoping that folks in the community who are doing detections in this space would be able to really help us kind of build those out. And so with that, that's kind of all I have here. I think that I saw some folks are posting questions and things so I can kind of see what's going on there. Let's see. But also if folks have any questions, super happy to dig into some of this. The one thing I noted, by the way, Jen, awesome presentation. My attack framework is not only heard from like government sources and I'm seeing like investment banks using it as the overall framework of like here's how like to use this to be able to kind of have this framework for attack and all of that fun stuff. But I just noted that like a lot of the mappings that are happened from the various vendors that are out there, there's some amazing stuff going on. And I think there's a place for like every, a lot of different solutions to be able to be able to like fit into that framework because you can easily map these two, these specific quadrants that you have. So I wanted to tell you, you all did an amazing job and I appreciate you coming out and doing this for us. Awesome, yeah. Thanks, Dan. Appreciate it. Jen, regarding Intel around lateral moves, what kind of information do you seek? You talk about this is not theoretical. How evidence-based does that need to be? Are you seeking forensics? Is it anecdotical? Yeah, so I don't know if we need like like kind of the low level details of what's going on. It's more so like really just proof or I say proof but attestation from somebody who has a visibility saying, yeah, I see, I've seen an adversary move from container to container using X or like using this procedure. It doesn't have to be like the actual logs or anything like that. Just kind of an example of what that looks like in the space. And that's kind of where people are saying, hey, this is possible these different ways but our adversary is actually doing that. That's kind of the piece that we're looking for. Okay, perfect. And at the same time, proposed mitigations, I presume. Yeah, yeah, those are always good for sure. We're kind of like the same thing we're doing with detections or we're doing with mitigations. You know, there's a lot of, there's some open source Intel out there about what's going on, but there's not as much on how to defend against it. And so, you know, we're trying to figure out like what are the best ways to build your defenses. So mitigations are definitely super helpful since we kind of don't have that kind of lab setup to be able to totally suss it out on our own, you know. One week. This is a great presentation, Jen. This is Vinay Venkatragan here. I'm actually part of Palo Alto Networks and they contributed some information there. I'm just wondering, you know, recently we've had a lot of initiatives within the SIG Security Group to, you know, talk about cloud native security and the right posture across the entire application life cycle, if you will, right? The build, deploy, distribute, run aspects. I'm wondering, do you think it'll be useful if we were able to see from a defense perspective to your point, how do you protect against these types of attacks to take all these, this collection that we built up and see how do we map it and then call out, like here are the specific types of attack patterns and here, if you adopted this kind of defense and protection techniques, you could potentially have avoided or protected against that particular attack pattern. Do you think that kind of, how do you say, story would be useful for people who are embarking and trying to protect against these types of attacks? Yeah, yeah, absolutely, I think so. And this is kind of, you know, I've been doing this with cloud too. It's always kind of a gray area, especially like with these matrices. It's like, where do you transfer from cloud to containers to Linux, et cetera? And so having examples kind of going across all these different platforms I think helps kind of tie things together for folks. And to give, I guess, some clarity onto how we are scoping containers at this point. So we're kind of thinking of cloud, like AWS, Azure, GCP, et cetera, which were actually as a heads up there if you're using those matrices in this next release in April, we're combining all of those into a single infrastructure as a service matrix in attack because if you actually look through each one, AWS, GCP, Azure, the techniques are the same. So like at a high level, the behaviors are the same. It's just at the procedural level, it's slightly different between the different cloud service providers. So that's kind of a tangent. But for cloud itself, like IaaS, we're thinking of it as more like of the cloud versus in the cloud. So for example, what you find at the cloud control plane or the management plane, what you can get from like cloud trail logs, logging at that level. And then once it kind of pivots onto the host like an EC2 instance, that's covered by the Linux matrix. So if you wanna have coverage kind of across both you would layer something like this new IaaS or AWS now matrix onto Linux to kind of explain, okay, here's my coverage across my kind of fleet of instances within cloud and the cloud management plane for containers. It's kind of in that area between cloud and like Linux or the host. So we're thinking of it as more kind of in a similar fashion to cloud. Like it's things you would get from like logging and Docker or Kubernetes, things of that nature. So once it pivots onto the host, like an example here would be deploying like gaining access to like a Kubernetes environment, deploying a container, that's all here in containers. As soon as the adversary gets a shell on the host and does something like deploying like coin mining malware, et cetera, that's where the pivot to Linux would be for containers. So I think having, in something that we need we're considering putting out ourselves like some sort of blog on here's how you pivot between each of these. But the more that the community is able to put out that type of those type of details I think that's just gonna help everybody understand like how do we use this across like our entire cloud something of that nature. So that was probably more words than I needed to put in there but hopefully that helps. Yeah, I mean, so from an input standpoint, for example, mapping host mount points is a great way of let's say you run a container, let's say there's a malware and you can exploit this persistent host mount, move and get some kind of access onto the host and then do those lateral movements. So there are these very, very, I think kind of reasonably well-established attack patterns from a container standpoint and then how they move from a container to the host and then they move. So just amplifying that message and then hopefully and how can we help MITRE and bring back that kind of telemetry. Yeah, I think just putting out probably just putting out your own like blogs et cetera on it is super helpful. Finding things that are novel to that kind of that cycle that would be helpful. I think what we have now in the containers matrix is based on like a lot of open source Intel. It's interesting for containers, there's actually significantly more open source Intel than for cloud itself. So that was actually our job a lot easier with containers versus cloud but basically finding anything novel in that process would be helpful for us too. And then when you like put things out about it like a blog or something of that nature mapping it back to attack so people can understand how the techniques and attack apply there. Yeah, makes sense. Thanks a lot, Jen. Yeah, absolutely. I kind of want to echo what Vinay said as well and basically like whatever help that we, any of us in security, like I'm not going to talk for everybody here but like in terms of like us's help to help you kind of map or things that you're kind of unclear on, we're seeing this on a day-to-day basis and for us to be able to like help with some of the mitigations that you talked about so many attestations, all of those types of things where whatever you need from us, like now you have all of our, you know where to get us now, right? Yeah, yeah, that's awesome. And even as we're before we do a release for this and like I said, we're hoping for the April but we'll kind of see how it all goes even before doing that release or right after the release, the detections we release, making sure that those make sense. I think we could certainly use a lot of help there with folks with kind of the boots on the ground. So I can kind of maybe coordinate with Magno a bit on this too, but if I can get some of that stuff potentially publicly released a little bit early, might be able to get some feedback on that as well from you folks, which would be really great if you're willing. Hey, Jen, do you have any more information about any contributions for the infrastructure as a service attack matrix? Yeah, yeah, definitely. Pretty much what really helps us. So you can send to attackadmider.org. We have like a set of here's a, there's a contribute section on our website that kind of gives you an idea of how to write up a contribution, et cetera. But mainly when we get those contributions and what I personally look for is the first off kind of that in the wild piece. So either like a mapping of that behavior to something that's open source or an attestation that yes, we did see this, an adversary do this in the wild. So it's like, it's helpful to have it all written up the way it says on the website, but really we take contributions and we kind of fit it into how we process attack, so to speak. But yeah, if you have stuff that's not in the IaaS matrix that you've seen adversaries do, just send a message to attackadmider.org and that just pretty much instantly gets it into my inbox and then we can kind of go back and forth on it. Awesome, great, thank you. Yeah. We often know that's exactly how it happened. We didn't get to see it firsthand. Right. But yeah, all of it certainly resonates. Awesome. I don't know if any of you folks have gotten a chance to look at the draft matrix. I know Magno has, he sent me some really awesome feedback already. But do you guys have any questions like on how any of these, we got to the conclusion of any of these techniques or what any of the main or anything of that nature? And if not, that's totally okay. Yeah. Hey, Jan, just one more thing for me. Yeah, thank you for the presentation. It was really great. Yeah, I think that one thing that sometimes it confuses me is in regards to that fine line between what fits in the containers and what fits in the Linux matrix, right? So I'm not sure like something else like Vinay mentioned, like deploying a privileged container that maps into the host and then you have access to the host environment. How can we, how do you process that and what is the thought process if that would fit into the container matrix or into the Linux one? Yeah, I think from what you just said, it kind of goes across both. So doing the deployment of the container and even the mapping. So like if you do like a file system mount or something like that to escape to the host, once that escape occurs and the follow-on behaviors are on the host, that would be Linux, but also just deploying that container once it starts, you know, once the adversary starts doing things like pulling down malicious content via curl, things like that, that would be Linux. So if it's stuff that is like the container piece, like to an extent, it doesn't matter, quote-on-quote. So if it's something that you could just do on a Linux host itself, that would generally be kind of that pivot into Linux. We've kind of been, our catchphrase so to speak has just been if it's Linux, it's Linux. So that's kind of what we're trying to go with with this, but there is that like kind of pivot point. So it's almost, I think some of the pivot points we've seen, it's kind of like that deploy container piece after the deployment, like those follow-on activities tend to be just Linux, so we would map those to Linux. You kind of the same escape to host once you have that privilege escalation from the container to the host, everything that happens on that host, if it's not just deploying other containers or something of that nature, that's Linux. Okay, awesome, yeah, sounds good, thank you. Sure. I had one other comment, if I may really quickly, and Jen, this goes back to your comment about the AWS Azure, GCP, the IAS. Is it the matrix or the recommendations? So this is shared responsibility, right? So we've all been so conditioned in the cloud to use it off the cloud and in the cloud, right? So off the cloud, so is there some recommendation you also provide where, a lot of us, we really don't care off the cloud, right? Because that is exactly why the CSPs are there. They are, that's their responsibility. And in the cloud portion is what we as either, let's just say, cloud customers and container customers, whatever are responsible for. So how do you, do you have any recommendations on how you help people sift through the separation of responsibility and concern there? Yeah, so I think that of the cloud piece we could probably just split that into a couple sections and it's like the, of the cloud that, the cloud service providers are responsible for and then the part that we're kind of responsible for like, you know what you could find, like I mentioned, like in something like cloud trail logs. So if you can like get visibility into those areas, that's more of where we're focused on. We're not as focused with attack on just things that the cloud service providers would be responsible for. There might be like some, like small nuances to that. But in general, we're more focused on, hey, I have like cloud trail, cloud watch, et cetera, Azure activity logs, what can I, what am I responsible for in those, in those logs, if that makes sense? Yeah, and I think it's also generally speaking, also it's very confusing, right? Because everybody just says, just like I did, off the cloud, in the cloud. But where exactly does that responsibility to your point about having access to that information? That also makes sense. Thank you, Eugen. Yeah, absolutely. Hi, my name is Bhavan. I work at Trend Micro. I manage the cloud and container threat research team here. Thanks for the session, Chan, amazing. On Vanessa's comment there, I think you brought up a good point there. Like, I just wanted to add my thoughts that from a minor point of view, from an attack matrix point of view, I think it doesn't matter whether it's a CSP responsibility versus the customer responsibility. I think a technique is a technique. If you can figure out a way to break into an AWS system, it's still a technique that an adversary could potentially use. Yep. Yeah, we can be pretty much transparent to that from a micro point of view. Yeah, that definitely makes sense to me. I think the, maybe the differentiation is we, so this is another spot, especially with cloud, there's not a lot of open source intel. So when they first were putting the cloud matrix together, it was highly dependent once again on contributions. So we might not have the details of what is going on from that cloud service provider perspective, like what they might have visibility into. So I guess that's probably the difference and probably why, like I definitely agree with you. Like if it's a technique, it's definitely a technique. We might just not have that visibility to be able to add that into attack, if that makes sense. Yeah, exactly. Cool. Yeah. Hi, Jen. I had a question. Sure. Have you, so mostly we assume that when it's a container or Kubernetes, I think we assume it is Linux, but I've seen some people run Windows containers too. And so have you ever thought about those things, like it could also run on Windows and have you ever thought about that mapping? Can it be like Linux plus containers and those plus containers in your mapping? Or have you ever thought about those things? Yeah, that's a good point. And I think most of the, almost all of the intel that we've received has been ultimately like behaviors that were carried out and the containers moving to Linux. I think if we find or are given intel in the Windows space, I absolutely think that we would kind of pivot from containers to Linux also to Windows. And we also kind of our philosophy with adding platform tags to like existing techniques is that if a technique or a behavior can happen on Windows, for example, or has happened on Windows, for example, but could also happen on Linux or Mac, we would still add that platform tag to Linux or Mac, even though we don't have necessarily the intel that it has been carried out on Linux or Mac. So that's kind of a different way we process things as well. So there may be some cases here where, perhaps escaping to host is somehow escaping to the Windows host. I think escape to host ultimately will be like containers, Linux and possibly Windows as well. If we can, we haven't done a lot of research in that area yet, but if we find that there are ways to escape the container to go like into the Windows environment, then we would certainly add the platform tag there, but we haven't received any in the wild yet really about adversaries kind of moving into Windows. Any other questions from folks? So I'll just go back to the point of we were discussing about how like it's all evidence-based as you mentioned, but if we can really demonstrate in a lab that this is how we can break out or move from a part to a part, how open are we about including, because we cannot just wait for adversaries. The way it works is like they're also catching up on technology learning as we all learn and they're trying to get there, learning more about containers and cloud and we are seeing techniques that we wouldn't have imagined four years ago. The adversaries are using them now. So we could demonstrate something in our lab. Yeah, this is how you would carry out an attack. It's very, very plausible. It's just that we're just short of evidence on that. How open are we about including such stuff? So this has been definitely been a kind of a philosophical conversation back and forth with attack for a long time. Attack itself is kind of rooted in CTI, cyber threat intel, what adversaries are doing. There are other models like KPEC, for example, that are kind of more of the theoretical this is what adversaries could do or what we can do in a research lab, et cetera. I know with cloud and containers, you know, the space has been, we're kind of more at the, I guess the infancy levels of those, those platforms in attack. So there's definitely an argument for, you know, where as research comes out, you know, the adversaries are going to be doing those things, but it's still ultimately attack is rooted in like what adversaries are doing versus what can be done. So there's an ongoing conversation about that, but as of right now, we're focused on the in the wild adversary behavior. But if there is an existing like technique for so escape to host, that's another, brought this example before. If we're seeing adversaries do that in Linux, but there are ways to do that in Windows, like through research, we found that that can happen on Windows as well. We would add Windows to like that existing technique. So to create a brand new technique, we would need some sort of in the wild for it, to add a platform to an existing technique that could be more research-based. Cool, thanks. Yeah, awesome. Awesome. Thank you. Thank you again, Jen. I think it was a really great presentation. And yeah, we were hoping to even contribute more to this matrix. So we can have the final version, believe so. Yeah, absolutely. Thank you guys for listening. And we can talk, Magno, more about it, about maybe seeing if I can get some feedback from you folks on our detections and things like that. But we'll definitely stay in touch. Okay, yeah, great, sounds good. Awesome. Andre, do you have any other discussions for today? Let's go over the meeting notes and the attendancy if anyone has any updates they'd like to share. Okay, does it look like it? Or yeah, if anyone has any updates, feel free to speak up. Or if anyone is new to the group, this is the first security meeting you're attending. If you want to introduce yourself, let us know what brings you here, what you're hoping to learn or share. I heard a, yeah. Yeah, I'm new. Hi guys, I'm Marina. I work at SISDIC with Dan. Happy to be here. I'm part of a lot of other working groups around regulatory compliance and CS benchmarks. And I thought it's a good time to join this meeting as well to see how I can contribute. I have a lot of compliance and risk management knowledge and I also have a lot of understanding of cloud and containers. So hopefully I can help with this effort. Marina's the super smart one. I'm the funny guy. That's just, you know, that's our dynamic. I'm glad you think you're funny, Pop. Someone should. All right, there you go. Just not the only thing I think I can do. That's all good. Welcome, Marina. Thanks. Hi, hi everyone. I'm Edan. I'm from Aqua Security. Also first time in this call. We actually even talked with Jen a little bit about the Mitre framework for containers. My team, the team now still did a lot of work around the malicious attack that we see in the cloud, specifically things that are more related to containers. And that's it. Awesome. Welcome. Going through the list here, see who we have. Yeah, I do not know that there are any other updates. Well worth mentioning the schedule for cloud native security day collocated with KubeCon Europe 2021 is now posted. Some of you might have seen that in the chat. A big shout out to the program community who helped review all CFP submissions. It was a very artist task. There was really high quality submissions. It was a hard job having to make choices. There is a number of submissions that were made that we think would be a great fit to present on regular weekly calls. We're going to be sorting through some of those. That said, well, schedule is now posted. It would be great if you can help promote and advertise the event so we can make that a very participative, well attended, engaging event. And we can have good discussion. CTF is also happening. Planning for that is still ongoing. We're going to be sharing six different scenarios. Some of you might have done the capture of the flag next year. Expect new things and changes to be made to that. But yeah, that's that. I don't know if anyone else, like I see Richard Julian on the call. Richard, you've been joining Friday's calls on the secure supply chain working group and participating and writing that. Not sure if you want to talk a little bit about that to others. Sorry to put you on the spot. No, no, no, it's totally okay. I'm actually here as a proxy for John Meadows for the most part. Yeah, I mean, the progress that we've been documenting in the chat is pretty up to date. It's pretty much at this point, we're going through the document. I personally am reading it out of order in various sections to make sure they work on their own. Anybody who is willing and wants to read a rougher draft of that document. Honestly, we've gotten a summary of all the major recommendations. If anything, I'd love for the feedback on just that part. If you really have 30 minutes and you want to go through our document and just read the bullet point part. If there's anything major that you see missing there, let us know. There might be some contextual pieces that would help. But yeah, that's where we are today with the actual white paper. I see Magnus sharing the link to it. Richard, what do you suggest for the feedback is it best left in comments? Do you want to direct folks to the Slack channel for it? I think I would say go ahead and leave it in comments inside the doc. That's where we've been all keeping our feedback. If you are particularly good at writing or have want to play editor, we'd be happy for any sort of recommendations on that side too. And I know, I see Alex is on the call. There's a lot of folks going and working in that capacity. But the more the merrier, I think. Fantastic. Suggestions and comments are welcome then. And Andreas, I do think, is there going to be just breaking outside of that working group? Is there going to be a greater sharing maybe with SIG Security first of that document of maybe just a summary of it and vetting a lot of the concepts? Will there be something formal for that? That is very much the plan. And in addition to that, we also managed to secure a CUBE concession to present the white paper. So there's right now some discussion around of like, well, SIG Security has only allowed one talk and we already had one talk to promote membership and promote the group. CNCF has some language around sanctioned working groups also being given a maintainer track. And that's how we managed to slot that in. But there was some confusion on the back end. So while it's on the schedule, it's not 100% confirmed. So like I said, we managed to secure, like we managed to put in there, it's subject to change. We're advocating keeping it on as it's very relevant. There are some other supply chain talks, but they really don't shed as much light or like elicit or extrapolate as much as the white paper has done. So we really want to make sure that gets represented. John Meadows is the primary speaker. Emily Fox and I are there as secondary speakers. But yeah, we might even shuffle the like those seats given, well, a lot of folks that put in a lot more work into the paper than I have personally. I participated initially, but I'd be willing to concede my seat depending on, well, merit of what's gone into the paper. So yeah, stay tuned for updates on that. I don't expect it to change at this point, but yeah, ongoing discussion. Last, sorry for the shifting thought process. I did see Magno at the links for the schedule for Cloud Narrative Security Day. And also last year CTF arrived up on the CTF for last year. I forgot to mention Magno is going to be doing a live stream of the CTF. Magno, you want to talk a little bit about that and piece that up a little bit? Sure, no problem. Yeah, so what we're working on is having at least some time on the Cloud Native Twitch team to do a live commentator session with some people in the community that are very famous and understand a lot about Kubernetes security. So we're going to present to them some of the challenges from the CTF and ask them, okay, how would you go about solving it? So how would you start? Where would you look for this information? Which tools did you use? So me, Diego, and I think Ron. So we're going to be talking with these people. We're still selecting a few guest speakers there. And we're going to have, I think, one to two hours. And we're going to do the small sessions. So after we release one of the challenges, then we invite some of the guest speakers to talk about it and understand their thought process. So just to have that attacker's mindset of how would they go about solving that problem and looking for the flag or how would they compromise that specific cluster or look for the logs or information about it. So that's what we're going to do on the Twitch stream during the Cloud Native security day. Awesome. Yeah. Any questions? Okay. Question away. Yeah, if nothing else, you have time for anyone to raise their hand and share. If not, we can adjourn the meeting. See you all next week. Thank you. Parting thoughts? I love you all. You're doing great work. Let's keep the internet secure. Let's do it. Thanks again, Jen. Thanks, Magna. Thank you. Thank you, everyone. Bye. Thank you, Jen. Yeah, thank you. See you.