 We're going to get started shortly. Give everybody a few more minutes to get logged in and update the attendance listing. As a reminder, when you put your name for attendance, if you have any updates or even no updates, please be sure that you put it in parentheses after your name. Huh, I'm actually able to connect this way. Amy. Can I see the buttons? Yeah, I had Amy toggle the settings because she's like, no, I'm not blocking anybody, but apparently that fixed it for some weird reason. Okay, so we're going to go ahead and get started. So as a reminder, please add yourself to the attendance list that is below on the meeting notes. If you have any updates or no updates, be sure to put that in parentheses after your name. If you have any special issues or ticket shoes you'd like to address, also put them next to your name. We don't have a robust agenda for today's meeting, so it will likely go pretty quickly. I'm looking at things. Push card, do you have any updates for us? No? Okay. Justin, what are your updates on the Sandbox project? Yeah, so we had the CNCF new Sandbox process review meeting on Tuesday and we accepted a whole lot of new Sandbox projects since the CNCF, three of them are security related projects. So Cloud, Custodian, Dex and Parsec were all accepted. I think two of those have presented security and Dex. I think it would be really nice. I think we had an issue around that but it would be nice to have them present now that they're a Sandbox project. So this is the new kind of lightweight process that Sandbox projects should be able to get in Sandbox if they're appropriate and fulfill the right requirements much more easily. So they could well be more coming up. I think Camus also applied but had some minor technicalities probably come up for reapplication soon but it's really good that we've got three more security projects in the CNCF because that's really great news. You said it was Parsec, Dex and what was the last one? Cloud Custodian. Cloud Custodian, okay. Is that it? Yeah, so officially they're just going through the onboarding process which is basically happened. Okay. Okay, issue 391. So this is a reminder for everybody that this Friday feedback on issue 391 is due back to Tim. There is more information there but before we jump to that, Pushkar is a new member and I'm gonna turn it over to him to introduce himself and why he is interested in joining. All right, thank you, Emily. Can everyone hear me fine? Hello? Yes, yes. Okay, all right, cool. So thank you for giving me the chance to introduce myself. I've talked to a few of the folks in different forums in the past. This is my first official meeting in the group. Some of you may remember if you attended our talk last QCon that I gave for the North America session. I'm mostly interested because I've had some level of experience working on different cloud native projects in the past three, four years now and have been wanting to see how I could contribute back to the community. And in the last six security meetup at QCon I was kind of very interested and intrigued on what things that Sarah and JJ had shared. So really looking forward to doing that. I'll be joining at least at the moment in my personal capacity but I work for a large payments organization in the security side of things. So yeah, looking forward to how I can help and maybe start working on some of the pending tickets. Cool, thank you and welcome. All right, Tim, what updates do you have on the DoDKate Stig? All right, hello everybody. Let's see here, let me just share my screen. There is a flurry of some activity and I'm trying to, like my computer has been having, can anyone hear me? I'm having major technical issues here. Let's see here if I can go here. All right, if everyone can hear me, I think we had some folks coming in here and I think I just wanna just like leave it open and as long as everybody is good with what it is here. I don't know what the right format is where they just go one-on-one and everyone says yay, nay, keep it but I think we wanna lock it down. So I think we gave some people had a chance to kind of work through it. We had a couple more people who were at a bunch of people asked requests they should all have access. So I think we already reviewed some stuff that was put in there and I'm assuming that everyone was good with what he had suggested. I think it was the first six and so then there was some, if everyone's good with that, we're just gonna say that's good. I don't know how I mark it here. Just say it's accepted. I think I just wanna make sure everyone here is kind of like good with it and then new things were done and then I had some dialogue with Torres kind of, no, no, no, sorry. Salvatore, things out your name? I can't remember now. Santiago, Santiago. Santiago. Yeah, sorry, I was finding the mute button. It's okay, yes. Yeah, so I think maybe let's do the first thing is whoever added stuff from the last time just walk it through because I'm gonna assume everyone was good with what happened last week and then we just walk through what's here and I think the question had been, well, you know, are there recommendations that can fit that don't fit within this and I'd rather you just have the discussion out in the open. So maybe we just start with the items who added these items here. I think we did, let me see here. So Santiago added and I just went through to try to tweak it a few minutes ago. Okay. So yeah, I'm happy to talk through any of this. Okay, great. I just wanna make sure through 150 we were good. Recommended mandatory categorization as well. I don't know if this is the right form for me to ask that question. Oh, what did you say again? I wanted to also ask about the categorization of recommended and mandatory because when I went to look at this I actually had an older version of this document somehow and I was looking through some of the things before that were listed as mandatory or recommended and I tried to use my intuition about what was meant by this in assigning those labels down below but my general intuition is that things that are important for security and not onerous would tend to receive the mandatory label and things that were either onerous or maybe one could see not using in certain circumstances would receive the recommended label. Is that my right way of thinking about it? You know, that's a good question. I think with all these things it's not a clear state machine. So I don't really know. I think what's your best, sorry, what's your best guess? I think everyone kind of has their thing. I think, unless there's a other way, I trust your judgment on this one I think. There isn't one. There wasn't a hardened definition. Okay. So I don't really know. Yeah, that was just what I had kind of done when I was going through and making these edits here. So I'm happy to talk about these. Shall we just take it in order? Yeah, let's go. You lead the show. I just want to confirm, everyone is good from 145 to 150. I think we discussed all of those last time, right? And they were, most of them were from, I think, PAN, Pollutant Networks, and I think one from Aqua. Yeah. It's all going to be under C and CF, but okay. Yeah, so these basic steps here, 151 and 152 basically deal with the process of getting like information about what has actually happened when you make your software. So the first one, 151, basically says, as you're going through the process of making your software, you should keep cryptographically signed record of this. In other words, it shouldn't be, and then golden plates fall from the sky that contain my software. There should be some actual meaningful provenance information, which I hope isn't too crazy of a thing to ask. And it's pretty easy to do, which is why I listed mandatory. And then 152 is that basically you should actually cryptographically verify this information that you've basically generated in 151 and to make sure that it hasn't been tampered, like that things have gone through the right steps or other things like that. And you should do that really prior to like the release of the software. So the idea here is that 151 kind of gives you the ability when something goes wrong to figure out what went wrong and to know that in a state where an attacker may have had access to some of your signing keys. And 152 is a process where you actually verify this automatically before you release your software, which I kind of hesitated. I don't know if others have thoughts on whether that should be a mandatory or recommended step. It's not a crazy hard step, but I also didn't want to kind of over... Yeah, I would love some concurrence. I've been pushing sort of on the side with the folks both here and then the finance groups of financial companies doing this, that this is a mandatory thing, but I think everyone here has to agree to it. Like this is the reason why I was very much advocating for Justin's and Santiago's involvement. This is an area I feel we really should lean into, but I think the group needs to get concurrence. Yeah, I'll say on my side, I was hesitant to put it as mandatory mostly because I wanted to be unbiased and somebody who works on this, to me it's easy to go and say, hey, you should really do this. Everybody should do it, but I don't know if somebody who's an outsider is in a different niche of the security space thinks differently. So I didn't feel that I was like right, making that call. I would say personally, I would put it on the mandatory category then again. Are we referencing in the supply chain here? Are we referencing the signing of container images in the supply chain in the CI process? What are we referring to? Actually, that's a great transition. Hold on, so I have, because we seem to get consensus, at least lose consensus, we can totally revisit this, but just for the moment, it's like the votes are tilting towards mandatory, so I'm gonna move it mandatory for a moment and we can come back and change that. That's actually 153. Yeah, 153 that we're talking about here, which is absolutely mandatory, that contents in the container registry need to be signed. And this is saying like at a minimum, you need to actually have signatures on the images and you need to protect the images and the delivery mechanism so that you're not just having unsigned content. Absolutely. Yeah, Justin, I feel like we've given a lot of latitude in this space over the past decade to like the general affordance for legacy IT systems and processes, and yeah, it's time to pull a band-aid off. This document will exist, five, 10, not 20 years. So if we're going to set it in the right direction, we should probably go ahead and go all the way to mandatory because it's such a foundational to actually being able to say anything about the quality of your stack. Okay, that's like really good guidance too. Now I feel like I should have probably labeled all of these mandatory, but we'll get to that later on. Yeah. Should I? I actually just had a quick comment. I actually liked the mandatory on this one as well because the analogy is RPMs, right? Or Debian packages, if you will. And we can download these from different repos, but then you have the option to omit the hash checks if you will, but with containers, it becomes even more important because arguably your developers could be pulling containers from so many different places and then there's absolutely no way to keep track of it. So I agree as well. Absolutely, yeah. So as somebody that's implemented STIGs in the past, when we're going through and reviewing a STIG to make a determination about what will or will not occur, obviously the mandatory items have to exist, but typically the recommendations never do. And even so, when we go through and have assessments, we have to provide reasonable justification for any mandatory items that cannot be configured due to a technical limitation of the environment or some other fancy reason and recommendations we typically don't have to provide a justification for. So as a general rule of thumb, thinking about it from the perspective of I'm a software developer or I'm a system operator and I'm really just trying to get this thing out the door, recommendations typically are not going to be implemented. There is a caveat with that where some specific data types or some particular functions and uses may turn those recommendations into mandatory items, like if we're talking about personal data or health information or sensitive financial information, those ones could become mandatory depending on what security controls exist for the system, but usually they're not implemented. Can I summarize that as mandatory means mandatory unless you specifically discuss that with compliance and recommendation means only happens if somebody asks for it specifically? Yep. Okay, that's good to know. So yeah, I feel very, very, very comfortable with mandatory on all the things marked mandatory and I'm kind of thinking these need to possibly change, but let me talk through these steps. All right, so we already talked about signing the container registry. So 154 is provide replay protection. Basically what you want to do is you want to make it so that a bad guy who breaks into your registry can't go and cause you to install valid but outdated images. The idea being if you have something like a tag and your tag point just says, give me a boon to latest. You don't want to be able to be given a two-year-old version of the boon to that was signed with the same key that was latest two years ago, but hasn't been and was in fact, quickly effectively removed from circulation because of security issues in it, which is the reason why they would likely want to replay that. Right, the library underneath were not updated. Right, right. So let me just go through the remainder and then we can talk about mandatory recommended. 155 is basically, if a registry is broken into, you want it to have a mechanism for getting back to a secure state. So that basically it's, you don't end up in the situation that I'm not gonna name individual Linux distributions or organizations because there's a lot of them I can name and I don't want to pick on anybody unfairly, but it's very common that after a compromise, the people say, oh, well, our key X got compromised that you trusted. So we're gonna give you a new key to trust and it's key Y and the way you know key Y is good is because it's signed with key X that was compromised. So the big problem there is obviously that the bad guys have key X as well. So they could sign and do whatever they wanted and give you any new key. So you have to hope you happen to randomly get it from the right party. And so having a mechanism to actually go and securely recover from a compromise is really, really, really important as well. And then the final step 156 is basically when a registry is broken into, the damage from such an attack should be limited. So even if I go and I break into a registry, I shouldn't be able to produce arbitrary images that are trusted by people coming to that registry. I shouldn't be able to just cause people coming to me to just install anything I say, which I think is super self-explanatory as why that's mandatory and why that's important, but it's something that surprisingly isn't always universal. So I would, does anybody have any questions about those before we talk about recommended mandatory, anything like that? I do, and I don't know if this, I brought this up last time and I don't know if it's getting too pedantic, but I am trying to structure it so that the language looks like it's testable and automatable. So the 155, I'm not really clear how someone like evaluates, yes, this passes and then what's the remediation? Like- I see. Just as I provide compromise resilience, but what is the test and imagine? I got it, yeah. I'll work on new text for that. But the other, is the text for the others okay? I thought 151 and 152, which were the ones that I'm most keen on, that seemed- Another observation when we state that it's mandatory, the items in which we have stated that are mandatory, these do not always fall into place for every Kubernetes distribution out there. So there are several that will fail because they don't have that functionality. Which one are you referring to again? Are you referring to the- You're taking a look at some of the items that are mandatory, like for example, checking in a container into a registry, making sure that it's signed. There are some distributions that don't dictate what type of registry that you should have. They don't dictate how you're signing your containers. So, I don't know how you can actually say from a STIG perspective, what that is supposed to look like when not every Kubernetes distribution actually has these features or functionalities. I think there's a limited view that do. And maybe that's where the STIG is signifying. I would wait here asking everybody to comply with something, otherwise it can't be mandatory. It's a very, very high bar now. Yeah, I get that. Yeah, and I understand the purpose of the STIG, but I think there would be a select few Kubernetes distributions that would fall into being able to actually run the STIG. I mean, these things don't all have to be supported out of the box by dollar distribution to be able to deploy it. If somebody wasn't running a distribution at all, but just downloading the binaries from upstream and building their own deployment tooling around it, for example, they would get nothing out of the box. They would have to build everything, but as long as they built it in line with all of the mandatory items on the STIG, then they would be in the clear. So that could be a differentiator for different distributions. If a distribution wants to make it very easy to achieve compliance with this STIG, then they could make sure that all the mandatory things work out of the box. Otherwise, users of a particular distribution could create documentation for how to deploy distribution foo in a compliant way. Yeah, yeah, that makes sense. Yeah, coming from one of those vendors' perspective, we certainly meet not a lot of these things. And we're sort of tackling it with the perspective of we should be meeting it, or it's sort of the type of thing where there's at least the ability to go in and configure these things just across the board. But ideally, we'll just have out-of-box support so you can just test it and we'll pass. For something like container registry, I don't know what the solution everyone will land on because Docker has their content trust thing, which I think is based on Tuff and is inside the CNCF somewhere. But do all of the Kubernetes runtime support that? I have no idea. So it's really hard without... Well, notary... What vendors will log in? Notary's there and notary's graduated. Tuff is graduated, notary's incubation. But I think, I mean, what's in the scope of a Kubernetes distribution is very variable. And like, lots of these things are outside. I mean, the Kubernetes per se doesn't have a registry. So I think a lot of these things, you're gonna have to be... I mean, you're gonna have the scope however you define it will be outside some people's products. Right. If you're going after, hey, I'm gonna be STIG certified and I'm gonna be published on DISA, then yeah, those things have to be part of your product. Those have to be included in order to pass that STIG certification, all those requirements. So yeah, it's a very careful selection here of what needs to be as far as mandatory in that particular list, as far as STIG certifications go. Yeah. He could add something. Sorry, go ahead. Yeah. Sorry. I hate him this might be too early to ask a question as a new member, but just wanted to check with, from your perspective, is there any kind of priority list from DoD where they care about a specific category of threats more compared to others? Because that could allow us to decide better from DoD's perspective, what could be mandatory for them versus recommended? No, they actually did not. So they had a list I shared in kind of the decks. I think there's links to those in the doc that you can find in the Slack channel, but they actually did not want to limit scope of suggestions that weren't on there. And a lot of those things are just sort of what you would expect to see. So I think their goal is not, because it becomes sort of a paradox if they say, well, these are things that we think are important and they miss something. So that's sort of like they end up, they're hardening their own blind spots versus they're saying we want the recommendation for a secure container and then it's sort of from dev ops to deploy. So they'll have the whole thing. And what is the recommendation? And so I think that's the spirit in which to take it is if they had to automate a checklist that's secure and then the use cases, this thing is securing nuclear weapons. So if you guys have your sort of disposal, you know that the recommendations here are things that people who are designing, deploying sort of software for that kind of thing. What would you want to say? Yeah, we made sure that we recommended this. I think that's kind of the spirit in which it is. Again, it's not mandated like Emily said, but it is all right. So I would like to revise my proposed rating for these two and we can argue if that's the wrong direction to go. But I do think you really do care. You don't want somebody to make arbitrary, you wanna be able to recover if someone is able to get in, recover in a secure way rather than just hope and rely, they get the right key somehow. I think you don't want them to replay old vulnerable versions of things. Both of those I think would be concerning. Although I'm, you know, I don't wanna, I just am very open to people that have pushed back or criticism or think that one of those is better recommended than mandatory. So perhaps this will help when we go through and we make a determination about whether or not we find a particular application, software product, whatever it is as acceptable for an operational or production deployment. The things that we look at are, we assign security controls to this thing because it needs to be secure. And then we make a determination about the security controls that were assigned, were they met? Are they operating as intended? And the ones that were not met that we said were mandatory is the fact that they're not met and the justification provided enough, like compensated for in a manner that it buys down the risk of this particular threat and this particular likelihood from bringing down everything. So like in the context of some of these things that we're talking about being mandatory, if somebody had a very good reason that they couldn't implement it, does this threat, the likelihood of that threat being able to execute the fact that this thing is not mandatory is that considered acceptable to us? So the concept of threat and risk all happen after the security controls and those mandatory or those recommended things are applied to an information system. So what we're trying to do is we're trying to create a baseline for like, this is what we want everyone to strive towards. And there are some things that realistically, they gotta happen no matter what, unless like you have this really crazy edge case where performance is a huge deal and you've got nanoseconds of response and implementing this mandatory thing means that we lose that time. And that's really where the difference is. We want stuff that's mandatory because we want the 80 to 90% of folks that aren't those edge cases to no kidding actually do it. And the ones where we really need to have that consideration about threat and risk, well, we're gonna look at them a little bit harder and see what compensating things that they have in place that offset the fact that they didn't do that one mandatory item. Yeah. Okay. Yeah, I agree. I think the other thing also is, we remove or we envision that it's not, even though we're not recommending a specific implementation, the spirit of this is much, if not all of this is an automated check. That's why I keep kind of pushing back. Like if it's automated and they say, this is a way to do it. This is how you attest. But then you kind of take that, oh, well, this is, you know, it's fuzzy or it's gonna take a long time to implement. And then we compromise, like Emily said, you know, speed for security. But the closer it looks like to, well, I can just check for this. And if it fails, here's the remediation. I think that helps. In related to that, that's so for example, again, not sure if it's nitpicking, but you know, if it's just because the metadata is signed, it alone doesn't check for replay. So it could be the mandatory is assigned and then recommended is it's checking against the manifest of the latest date or something like that. Like that's kind of where I see an example. Like that alone doesn't really technically stop or even check for a replay. It's just, like you said, you can have a signed outdated image and you're not checking for it. So there's a little nuance I would propose. I could add my perspective. If 151 to 153 are mandatory, 154 to 155 is actually fairly trivial due to implement because you've really done most of the work, the groundwork, that's just my opinion. Yeah, that's how I was seeing it too. Like one kind of is a derivative of the other, but I still think you can still be more prescript like how it actually checks. Like just because something is signed doesn't mean it still won't be replayed. They just, it's a side replay. I'll, any feedback like that or things like that, I'm really happy to go and work with you to tweak this. I feel like we may or may not need to wordsmith it in this meeting. I wanna make sure we're not just kind of monopolizing time with going through edits that I should have done like a week or two ago. Okay, so with that, since as Emily said, where it's locking Friday, nobody plans to add anything new. And at this point it's really just refinement and then lock. And then if things that don't fit, even though we had this, this was just a way to get us going. I knew it was kind of hard when it was vague. If you, when I mentioned this last time, and then Nicholas, he just said, what all the recommendation is just as they can't, nothing can be mandated. They're open to have language to ensure people understand the poll. And then this also extended later in the dialogue run. Hey, if somebody has a reference design architecture, and I know I think last I think Emily says she's working on an effort to do that. I think we should just include it. Like the worst they can do is say, they don't pull it into their final stick at this point, but at least it's in the repo. And they know this is a point of view of the CNCF SIG. And whether to take it or not, they don't, but I don't know if that's, if there's an existing artifact already around reference design, I don't see a downside of including it outside of this spreadsheet. So as an example, even though we want to be vendor agnostic, they're open to open source products. So if the items over here, we had a reference document. Again, it doesn't have to boil the ocean. It could just talk a little bit about how Intoto does that. And same with any other thing. Like I don't want us to be limited to this. I limited it because it helped us move faster. But if you're hitting up against the form factor isn't allowing you to communicate, we can certainly have a .md file that's we push into our thing and let them hash out they include or not. I don't want us to limit ourselves based on this form factor is what I'm trying to get it. If there's a best practice you feel, we should include it gets pushed in and then let them sort it out. Just in since we're kind of in progress with the re-envisioning of that, maybe what we could do is link to the high level, link to the repo and landscape and that way the artifact that we share is kind of the pointer to the future. Tim, I have one last little sort of request for you. As you land the plane with this, one of the things that I'd like to see, to security, serve in the capacity with the CNCF is how we participate in sustaining these relationships. We have a number of working groups and seek representation from folks like NIST and tried to maintain those relationships over time. So I'd love to, I don't know if we think up offline and discuss the final artifacts or in this sort of mark down just point. Here are the relevant working groups and what we're working on, please come and both share and request feedback. Yeah, no, I'm glad to do that. I think we should have a read me about the org reference implementation. Any other things, because this is their form factor that said the more that we sort of define it. And I have said, and they are open to it, just haven't had time to get organized around it to start doing briefings. So they have briefings with them and they said, he invited me to present in the briefings. What I would like to do is find a couple of projects. The only one that I'm that familiar with that, he's already familiar with that. He said that's a good candidate, for example, is the Intodo Tough and then that bring the team on and then the brief and that's to 100 or so folks within the DOD and anybody else has an open source project. I think that's also a good way to do that. So how about you and I sync offline about those? But as I said, that's kind of the spirit that we wanna do it. Here's this thing, let's expand the scope by briefing them so they're aware of what it is. And then that way they know about the project and then the working groups and it's just a beast as you probably know the number of people who are involved on their side. And I think the more surface area we can present for them to glom on to that. Perfect. Yeah, I'm confident that a Intodo Tough kind of overview is something that we could potentially land early. And then that would be a builder into probably the subsequent touch point would be when we feel comfortable to begin sharing the landscape work that Justin and Brandon are working on and actually going and doing some footwork and sharing that out. Yeah, I agree, yep, yep. Okay, so wanna get this wrapped up because we got two more items on the agenda. Justin and Tim, did you guys have anything else for this? I just wanna say one quick thing. So I had been thinking about going and trying to see like what we could do off the shelf to actually put together something that had all the mandatory requirements here. I'm also very likely to be teaching a class in the fall where I can potentially get a bunch of students to do that so we could get experience for people that don't have this to understand what the usability or other problems might be. I first wanted to mention, does that seem like something that is of interest overall to the group? Should I try to start a channel on the Slack or something like that and invite others who wanna participate or be part of this? Is that worth doing or should I just... Yes, yes, yes. Okay, and then just also... Sarevanan here, yeah, great idea I was planning to but as part of your curriculum, I believe you will have some kind of blueprint or reference architecture or some kind of references for the developers or people or organization who are trying to build something in the Kubernetes world. Maybe they can use our guide as for reference when it comes to sick security with controls and stuff. Yeah, I'll talk more about this. I don't wanna go too far down this rabbit hole because I know Emily is saying there's other people. So maybe that can be an action item for the next meeting and we can talk about how to do this. Definitely. Okay, and I just wanna say that when looking at this from this context, there's some items here that I also will have to discuss like just sort of like for instance, just row 35 says log everything, log everything in store outside of the cluster, including Kubernetes events. I don't know how to test something like that. You know what I mean? Or like, how do... There's a bunch of things like that. And I think that your comment on my thing helped me realize that we might have similar issues in a few other places and I don't know how we wanna address that given we're trying to finalize this Friday. It needs to be addressed. Agreed. So here was my thought. I think it came from last week was I think we do our thing to set the example. I've already seated with Nicholas and company. Hey, some of these things up at the top don't seem like they fit. And the suggestion was, okay, let's not bog down the suggestions and maybe it's another pass within the DOD to like make this truly like, this came back from some news, Nicholas sort of saying, we really need to make this look more automated to attest for its success and whether it's remediated. So I think we just focus on our stuff, like the CNCF stuff and say, this is what we've come up with and then use that to guide and then get them the rest. I think we can't take on the onus of how the whole thing is done at this point. Like the cat's out of the bag cart in a way. So I think we just do our best on ours and then we just try to encourage how it's done with the rest by setting a good example. So the last thing is, you know, Friday it's going to be locked and I'm going to push it. What's the approval process so I can say, this that I'm submitting has the blessing of the SIG. Like at this point, if there are just changes that Justin makes and or anybody else kind of does, can we, are we assuming that that's fine by whatever is there as Friday is approved or like what's the thing? Like everyone's kind of looked at it in its current state and I'm assuming everyone on the call since no one's raising anything that's marked CNCF they've approved if this were to go when they were fine and anything else is just going to be minor. That's what we discussed at the last meeting is that close a business on Friday and all components would be put in and then we gave it the blessing to move forward down the path because you've got to version it and we got to move forward and we can always come back and visit again later. I agree. Okay, great. So it's just going to be cut, it's closed but we've implied that this is blessed. Yep. Okay, great. Cool. All right. So click reminder. If you have comments on any part of the documents please comment on the ticket on the documents or in the DOD Doug SackOps channel. Make sure you call attention to Tim so you can see it. All right, next I got Mark Underwood added something last minute, a Metron. Mark, are you ready to talk about this? Yeah, I keep this really short. So NIST, a big data analytics initiative that we're looking at was going to use Metron and I'm wondering if anybody here is involved in the project. I can't even tell if it's alive from the activity in the GitHub but okay, I take that as a no. All right, that's it, done. Cool. All right, Tim, you had another item on the agenda. Yes. Single sign on SSO, is that what you meant for future meetings? Yep. Can you talk to us? Oh yeah, sure, absolutely. So we are beginning to roll out from the Linux foundation side a way to make the recurring meetings, the committees, the zooms, use a single sign on for security. And I wanted to kind of raise this if there are any objections. The date hasn't been set but we are gonna send out a notification next week, mid next week that these are gonna start being rolled out for certain types of access. So I guess this team doesn't use, for example, the mailing list but a lot of other programs, that's the one that's gonna go out first is groups.io. And then shortly after that, when you log in to Zoom, instead of just sort of the Zoom just pops up, it'll just say, hey, what's your SSO? And then you would log in at that point. And if there are any issues or questions around that. There's the, this is the doc. Tim, we've actually turned the authentication off on this particular meeting just for Justin Kappos this time and it seems to be working. So Justin, this is probably something that you'll wanna be interested in. Yeah. No, I don't know. We can see what happens with this if we turn it back on. But yeah, this is, it's been a pleasant to be able to look at documents and see people, which this meeting would have been nearly impossible for me to have the same input had I not been able to do that. So thank you. What was the limit again? What would you have been limited in doing if there was an SSO on the Zoom access? The single sign-in might be fine if I can actually sign in with Google GitHub, LinkedIn, I don't have LinkedIn or Facebook. But if the problem, there's some kind of technical issue that happens when I would follow the previous link where I would get a weird error message that no one else was getting. And I use Zoom for all sorts of other meetings, both that require sign-in and that don't and do all sorts of things. And this for some reason was the only meeting that had a problem. So whatever we have done now seems to have fixed it. Okay. I don't know whether- Whatever we have done is I have turned off the requirement that authenticated users needed to be able to use this to sign in. I am not certain if Tim's solution will have the same issue. Yeah. I'm wondering if I think about maybe we can test it with you trying to log on first before the next meeting. Well, let me take that as a note and then think about how we do this. If nobody else has a problem other than Justin, then you guys will probably be one of the first ones. Let me do it something offline with Justin then. Okay. One question. Does this imply everyone who sort of attends this meeting should have a Linux Foundation SSO login? It does. And you can create one. And you create it either with these IDPs or you can use your own credential. Okay. But it would go to an SSO maintained by the Linux Foundation. So I would want to ensure that we're so, security is trying to encourage the widest participation audience that we possibly can. That means lowering the barrier to entry for participation in any of our meetings. Yeah. And we need to ensure that all of the products that we're looking at using, whatever they are, are fully accessible to a diverse community. So, provided that it works for Justin, we need to make sure that we're meeting the accessibility requirements as well as making it very easy for anybody that goes to a conference or has a colleague that mentioned us to them that they can very easily get in and have conversations without jumping through a whole bunch of hoops, creating a bunch of different accounts. So that is my primary concern. How do we validate that we pass that? So I think that's the spirit in which we're doing it. And I'm not really sure what the acceptance test is on figuring that out. My recommendation would be look for members within the community of the Linux Foundation or some of the other SIGs to find out if you have potential test cases like Justin, for instance, that you can go through and work one-on-one on meeting and identifying what those requirements are. How would I identify a Justin from a corpus of users? What is the attributes that Justin had that we would then find it? I'm not really sure how we would figure out the use case from what Justin's described. I would recommend reaching out to a couple of other SIGs and letting them know that you're looking for individuals that have potential accessibility problems or think about it from the perspective of somebody that is brand new to open source software, has a security background and has never done development in their life. How would they participate or observe these kinds of activities? So that's the primary persona that we used. And we see that since logins are like a common access point, you put in the username, use a password, that feels like it meets that requirement. And we also are using standard IDPs. So I guess I'm not really sure where, I would need probably more granularity on what it is. The only thing I can, you know, we looked at what happens to have China access, but we are using standard SSO design patterns. So I think the only thing that I could think of is if there's something particular about the browser or something's happening on the DOM, something's in the, perhaps even the network level that happened with Justin. And those are the things that we're just, I think we're gonna, we can't a priori figure out all the unknown edge cases because you don't know what you don't know, but we will have a way for us to look at every user session. And I think we're gonna be monitoring it that way. Yeah, sounds good. Okay. Thank you everybody. Right. So that's everything we have on the agenda this week. Right now we do not have a facilitator for next week. So if you are interested in facilitating, go ahead and drop it in the channel. And one of the technical leads or chairs will reach out to you. And if you have any proposed agenda topics, you can still comment on them in the meeting notes for the next meetings. So thank you everybody for participating. We look forward to seeing you next time. Thank you. Thanks so much.