 Hi Anka. Hello. So just the two of us here. It looks like Robert, who was the other person interested in Oscar, he had a schedule conflict. So I think he is not able to attend. So I'm not sure whether Jim is coming. Let me see here. So we may have to move this discussion to. I'm sure the fortress team will not wait for another two weeks. Let's see here. Is someone recording this? It looks like it automatically records it. Okay, so let's let's give a few minutes if nobody else is joining, then we may have to come back in two weeks and present. I think that's what we need to do. I'll put I'm adding some notes into the document. Okay. That we both joined and let me let me add that you can see what I'm adding. Do you think it makes sense just to present because since this is recorded, I think people can watch that and use maybe next week to get more feedback or maybe you can get feedback from. Is there any, what are the means of communication with the, with the team is via mail threads or. It's mainly with the, in the, in this call and in that meeting notes. In the meeting notes. Okay. Yeah. Why don't you do that? That's a great idea. So let's go ahead and have you present it that way it's recorded and people can review it. Yeah. And then we can ask, you know, what, what is the feedback? I hope the PR would be maybe. So the sample would be available for everybody. Let me. I need to share. Okay. Can you see my screen? Yep. Okay. So I have here a tool. Jason structures. Left and right. They are both related to the result from the compliance operator and the OpenScap and those originated X, X, the F results are structured here around the. Uh, a scale assessment result. Uh, subset of. Of, uh, I think you presented Oscar in the prior sessions. So the team members are aware of the Oscar as a compliance framework, as well as a, uh, uh, the, uh, schema, the data models for that framework and as well as the documentation, uh, uh, standardization. So here we are leveraging the Oscar schemas, the data models. Uh, the data models. Uh, and the data models. Uh, and in particular the assessment result. Uh, schema. Um, the, the framework is complex as well as the, uh, schema that are associated with that at the various level of the flows in the, uh, of the data flowing through the. Framework. Um, the, uh, which brings right into, into the schemas dependencies on the different, you know, prior steps. Um, on the, on the, on the, on the, on the different findings, we are able to, um, extract a set of, um, objects that can be leveraged to describe the results in a way that we do not need all the other, uh, dependent, um, artifacts, um, on the prior steps in, in Oscar. So, um, we, I present here left and right, uh, this, um, uh, Jason form on based on the Oscar. Findings. The difference between them is whether the, um, the assessment tool in this case, the compliance operator is regulation aware or not. So if we are looking strictly X at the XECDF, uh, result, right? At the, uh, open scape, uh, uh, results. There is no mention of, of, um, regulation or the controls we've seen a regulation. What you'll see are the, um, CS benchmark banks rules, um, with the timestamps and, and the results. And this is what we have on the left. Um, we have, uh, a bunch of properties that, that, uh, we can find in, in that file, right? What is the run of the test? Um, right? What are the, um, some, uh, remarks that are in there? So all the, all the, I would say, uh, items that are not strictly related to the result and to the rules are mapped here under the, uh, properties, the observation properties. And, uh, part of that we get also the rules that are associated. And I'm looking here at two particular rules. Right. So I'm looking at item nine and item 10. And they, um, uh, describe the rule that, uh, particularly the idea of the rule. XECDF, um, the one is finger service and the other one exact time out. Requesting some time out. So these are, these are the, the rules. Let's say that I have a, you know, an XECDF as config map. And these are the rules that I find in that, uh, let me close the properties. I have here all the details and that. And now we are looking at the, uh, evidence. So I have two rules. So I expect to have at least two, uh, uh, uh, evidence items in here. Um, in the case of compliance operator, I have, um, uh, uh, a result per, uh, worker node. So if I have two rules and three worker nodes, I'll have six evidence items here. Here we have just, you know, for the sake of this example, two rules on one worker node. Um, and I'll have those two rules. So I have the, um, properties in the one being, okay, what is my rule? What is the timestamp? And what is the, the, uh, status? Uh, it is a pass. And in the other one, we will find the, um, um, rule, the timestamp, uh, and the fail that, that second one failed. Um, um, and the second one comes with, uh, additional, uh, properties and they are, they are described in here. Um, so we are talking about the scope in this case. It was an, uh, cluster with one worker node. So subject references, um, is the object under which I put the subjects of my assessment and the, the, the references to that those subjects. So in the case of VMs would be the, um, you know, IPs associated to that and so on. In this case, I'll have the, um, um, the, uh, details associated with that, uh, with that, uh, worker node that we could find in that, um, uh, result from the compliance, uh, operator. And there is one last item observation methods where I can describe details in the cases and automated, uh, automated test. The reason why I find this relevant is that, uh, if we have certain, uh, uh, tests that are, uh, done, um, uh, manual and, and this is the case, for instance, in the, um, uh, CS benchmarks that are not implemented. They do not have a script within the, um, um, OpenScap, uh, logic, right. They will be marked as info or not checked. Um, and the, um, the, the meaning behind that this is a, uh, check that is done, is done manually. So we can capture that aspect as well here, uh, knowing that the result will be passed in a, in a manual way. So, so this is mapping, uh, what we have in terms of the XECDF, uh, from the, um, compliance operator, uh, on top of the, uh, the OSCAL, uh, assessment result observation object. Now, if we are looking at the, um, uh, code that is available, the data that is available for the compliance operator, uh, particularly the, um, uh, compliance as a code, uh, project, we find, uh, as part of the data available, the mapping of the rules of the CS benchmarks to various, um, regulations. So, um, in particular, the open-scap for, um, uh, OCP, uh, for Linux, right? They are both covered by, um, by a compliance operator. Uh, we see the definitions of the profiles and the, uh, the, um, a SIG has a profile for NIS, the profile for CIS, profile for HIPAA, and, you know, other, other regulations. And we find as part of the documentation in compliance as a code that mapping between the CIS benchmarks for R-HEL 7 and the, uh, NIST, uh, 853 controls, um, that are relevant for that. Uh, in the case of the, uh, OCP, uh, we are looking at OCP 4, um, the, um, so this is OpenShift Cloud Platform, uh, version 4. We have only two that are mapped, but through, um, uh, other artifacts that are available in the compliance as a code, we are able to infer that mapping as well. So now, depending on where the logic of associating those results on the left, right, just the observations with the, uh, corresponded regulation that is of interest to the consumer, right? The consumer may be, uh, looking at NIST level or CIS level or HIPAA level. The, um, result that we send back to, um, to the tool that is providing the display of the, uh, or creating the document for that regulation, uh, may contain also the association with the controls and OpenScap and, uh, sorry, OSCAL allows that mapping as well. So, um, I present here on the right, um, an addition to what we have on the left in order to include the regulation. So the left one is regulation agnostic. The right one is regulation aware. And you see here under observations, right? I'm marking here, right? This, what we have here are basically the, um, uh, details that I have on the left, right? So we have the properties, the evidence group, the observation methods and so on for, for multiple items. And what I have above is the delta that I'll, I'll show how OSCAL handles in order to, um, to provide the mapping to the controls. So, uh, we are talking now about results group and findings. A finding includes multiple, uh, observation, but the finding, uh, maps one to one to a control in the regulation of interest. So here I'm looking at the NIST 853. So one finding, right? I'm looking at item zero. I have, we have two items in here, item zero and item one. So item zero is interested in the, um, control AC three. So the objective and objective status, uh, object in here contains the control AC AC three. Um, and the result, um, with the value fail, um, this is the aggregated result across all the, uh, constituent rules that are associated with that AC three. Those can be rules in OCP, um, uh, for ICIC, um, um, CIS benchmarks, uh, for Kubernetes, those can be in our health seven. These are the, uh, Linux, uh, benchmarks, right? That are associated with AC three. So all those will be, uh, will contain observations with their individual status. And what we have here in the objective status is at the regulation level, AC three, the NIST control with the aggregated status across that, um, uh, in the properties here, we defined all the rules that are associated with, uh, AC three. And we have rules that come from the, uh, Kubernetes CIS benchmarks on Kubernetes as well as, uh, rules that come from the, um, our health seven, the Linux. Um, so we did, we have here all the rules. And now we expect that the observations will provide at least one observation for each rule. If, if one of those rule is, is missing the status that we have here, it would be error or missing or. So now that we know what are the rules that are associated with AC three set. And because here we are in the context of the compliance operator, we are looking at CIS benchmarks. But if we are looking for other contexts, right, you may have other, um, rules in there. Um, when we are looking at the observations and I said, okay, the first observation is for the rule in our limit user access. And as we've seen before, I will have here the properties associated with that. We'll have the evidence, uh, where I present the, uh, what is the, what is the rule and what is the status. So in this particular case, um, this is not checked. Let's see what, what, what was the, um, target, the, the subject, the resource on which that was, um, it is, uh, it is a VM. Okay. And the details of the VM will be provided here. Okay. I'm talking about, um, that worker node in that cluster in, in that region. So whatever it is provided by, uh, the compliance operator, uh, result, right, will be, will be here. So we'll have the details of the, um, uh, target resource in this case, it was this, uh, worker node. We'll have the evidence that will tell the rule associated with the, uh, with the, with the status. And in the, uh, uh, properties above, we'll have additional details related to, uh, uh, to that, like the, uh, result or the timestamp associated with that. So this is, this is one item. We can look at another one. Uh, and this comes from another, uh, another, uh, VM. In this case we had, um, uh, cluster with three worker nodes. So we will have the results, um, uh, in the observation, right? Three observation, one status for each of the, each rule for each, uh, VM. And if we are looking at the others, we will see also results from the, um, the Kubernetes CS benchmarks, because in the dependencies for this AC three for this needs controls, I have both CS Kubernetes rules as well as, uh, Linux, um, CS benchmarks. So the, um, subject reference here, I think would be, uh, a worker node and those will be the details of the worker node in here, the location, the cluster associated with that and so on. And if we are looking at the, um, um, evidence, okay, what would be the evidence, right? We will see the rule that is associated with that and the, uh, result, right? The failure. So the, the, the logic, um, here, actually we have this implemented and the logic that we use that if we have any failure, it's a failure. If we have, um, any, um, error, it's an error. If we have any warning, we are looking also at, um, uh, trends, right? For, for some of the rules. So, uh, if we have a warning, right? I get close to a limit of a value of a parameter. I have a warning, um, um, else if everything passes, I have a pass. Um, so let me close the observations here and go back for a second to the, um, objective. So in this control AC three, we, um, Oscar provides also, um, uh, an object which is implementation status that allows me, uh, allows the, the, um, uh, user of the system to tell whether this, uh, um, control is implemented completely or partially. Right. So, uh, this means that the interpretation of missed AC three, uh, from the point of view of the, uh, rules, the CS benchmarks that I, that, that are associated with that in the, in the properties completely cover, right? AC three, uh, control. So then I'll have a complete and a complete and, uh, and, uh, uh, pass, right? Will give me a pass for this control. However, if this control is partially implemented, meaning that the, the benchmarks that are associated with that do not fully cover all the items that the control, um, requires, I will have here the implementation status as being partial. And then the, um, uh, the result in, instead of being a pass, if everything passes, it will be a partial pass because it's not completely implemented. Um, and, uh, one last, um, item here, um, we, we discussed that under the observations, right? In, in the, uh, observation, we also give this observation method, whether it's automated or not. If we are dealing with a mix of automated, um, tests assessments, as well as manual assessments, um, until we have the manual, uh, items as well in the system, that will also be a partial pass. So if I have, uh, um, all the results from my automated tests, right? Everything that I get from the, uh, openscap that is, um, has a script, right? To, to check a rule. Um, if everything passes, but I do not have the results for the, uh, the test bench, that are manual, it will be also a partial pass. So all this, all this, um, um, let's say levels of granularity and levels of, uh, detailed to inform the user on the actual posture of, uh, of a control are supported in this rich, uh, schema, uh, uh, that comes from, from Moscow. So now, uh, depending on the level of, uh, leverage right in, in this, uh, uh, project, this working group, right? We can, we can select a subset of that or, you know, go with, go with the full blown, um, a set of, set of items. So I know it's a mouthful and we have many items covered, but I would say in, in a, uh, summary here that, um, what we, um, uh, and by the way, as a, uh, uh, pull request, uh, that I, um, created for the, um, sample, right? That I submitted, um, is for the complete one here on the, on the right. If we need, I can submit it also the, the simpler one, but since this one includes the observation of the other one, I submitted only this one. So in, in, in conclusion, right? We are able to, um, map the, uh, current, uh, you know, uh, XECDF result part. XECDF is very rich, right? So it has items related to remediation. It has items related to, uh, violations and so on. This wasn't the scope of this exercise. So in this exercise, we only focused on the, uh, results, um, uh, that are presented in XECDF. By the way, Oscar also supports the, uh, the, um, um, description of the, uh, uh, remediations and, and, and threats and risks and so on in other aspects, other objects associated with the assessment results. Again, they are not subject of this, uh, um, uh, presentation and the, um, um, modeling that we have done between XECDF and, and, uh, Oscar Jason here. But if we are interested, right? I can bring, uh, samples related to that as well. So we only looked at the, uh, results. We've seen that the Oscar observations object, uh, can encapsulate the aspects related to, uh, scope, right? What is my target, um, uh, subject, uh, that I've done the assessment one, uh, covers the evidence. Um, uh, it, um, covers the, uh, observation method and properties that, uh, can be associated with that. Beyond this, we've seen also that we can go a level above and associate this with a regulation, uh, and be able to describe how this individual observations contribute to an aggregated result for a control in a regulation. And now, for example, it was NIST 853. Um, so, um, I'll stop here, uh, uh, uh, Jaya and let me know if there are any things that you've seen this presentation before, if I missed anything, or if you think there are obvious questions that we need to answer. No, this is great. Um, thank you, Alka and I think, um, I see Jim has joined, which is great. Hey folks, yeah, apologies. I was running late today. Oh, how, uh, how far did you see into the presentation? So I joined in, you know, quite a few minutes back. So I caught most of it. Uh, Oh, excellent. Yeah. So Anka, just so you know, is, uh, is, uh, is at IBM research and, um, she's working actively with IBM cloud. Um, and, um, so this, so since they are also looking at, um, feeding, you know, information about results from for various controls assessment. And so I kind of pulled her in into this work group, right? So that's great. Yeah. And, uh, she's also, uh, has dug deeply into Oskal. And, um, and so I think this work she has done is a very good example. I think of how we can bring, bring in Oskal into the policy report, uh, standard, right? That we are trying to stand. Yeah. And that, that's a good question. And Anka, I did see your pull request as well. And thank you for, you know, providing that, uh, the detailed report there. Um, I think the question we need to think through and, you know, discusses is the expectation that the policy report, uh, like a policy report would contain all of the Oskal report details or what is the mapping and how will the two live together, right? So I'm not sure. Like today in your system, when you're producing this Oskal report, I'm sure there's other systems consuming that directly and that will continue. So what is the expectation from the policy report? So if we want to put some of this data in a Kubernetes CR, or maybe all of the data in the Kubernetes CR, how do we do that? And then how is it consumed and used? Yeah, this is, this is a, you know, it's a, you know, a very good question. And we, um, since, since Oskal again has these many layers and, you know, it's a, it's a full blown framework, right? We've done baby steps. So the way that we adopted, um, uh, Oskal was in phases. So, um, we have created our own, uh, schema validation. And initially we had more items being, um, optional than in the, um, validation that you have, uh, on the official, uh, Oskal project. So that, that's how we adopted. So one way of moving forward is having, um, uh, mandatory only those, uh, objects that are necessary, right? In the context, right? Um, of the working group. And, and then as you move forward, additionally can be enabled as, as mandatory and the schema validator, uh, updated. That, that's how we worked out into, into the complexity of Oskal. Okay. Um, so, but which would it be that Oskal, the Oskal report and that schema that remains like a superset of what we want to put in the policy report or would the, do we want to see if all of this somehow fits even if it's a generic untyped data? Um, it, somehow we want the policy report to contain this information when I'm not, yeah, not too clear about how or what would be the goals over there? Yeah, I think, uh, Anka, did, did you say that, uh, if you want to kind of break up, you know, what Oskal is providing into buckets, right? So there is the result and then there is the remediation and then you were talking about, uh, evidence, right? Uh, so the, yeah, the result and the evidence, um, evidence reference, right? So if we go here into the observation, right, we have the evidence, uh, uh, reference, right? And, and, um, reference at the policy and, and the status, right? Um, then we can have a separate, there is a separate, uh, sub item here on the remediation. Um, what are the issues associated with that or the tickets or, uh, actions that are recommended and so on. Then there is another item related to, um, risk. Um, and, uh, and I think the reason for leveraging, right, those is if this result is sent to a system that deals with enforcement or, um, uh, right, automatic remediation, whether it's sent to a GRC system, sorry, where risk is needed in order to fit into the processes that they have there to associate risk with that. So, um, I think as Jim, you know, pointed out, I think it's, you know, fair, uh, very fair that depending on what is the goal, right, of, of this, uh, policy result and, and, uh, framework that is used within, right, more or less of those items will be leveraged. Okay. Yeah, I think the way I read this, uh, at a very high level is, looks like, you know, a lot of thought has gone into the definition of the Oskar standard. Oh, definitely. Yeah. Right. And, uh, and it comes obviously disorganized in this and there are other parties contributing to it. Um, and it seems to me that, uh, the policy report is essentially, uh, representing that in the context of Kubernetes, right, for Kubernetes, uh, CRs or Kubernetes resources, right, controls to protect a Kubernetes environment. So then Oskar obviously can apply to all layers of the stack, right, not just Kubernetes, but also VMs, et cetera. Yeah, that's, that's the beauty of that, that at the end of the day, we are able to put together a report where those different items can be aligned. Because if I'm looking for AC3, right, or the other one was AU3, I, I picked up those on purpose because these are controls that, um, gather their, um, aggregated result across the stack. So in order to meaningfully be able to aggregate that, we need those different layers in the stack to produce a result that, that, you know, we compare and are able to aggregate. Yeah. And I think, uh, from my point of view, right, um, given, you know, the focus, uh, that I'm working on is, uh, security and governance, um, on the, I would, I think, as everybody knows that needs to be applied across the stack, right, for all the controls. And, and you want to be able to represent the results in the context of a standard that the customer is interested in, you know, whether it is in the state, number 53 or PCI or HIPAA or whatever, right? So I think this, um, this kind of brings that to the table. Um, so, so I really like this approach of bringing the Oscar concepts into the policy report definition so that we can start, uh, have a more consistent way of dealing with all layers of the stack in what I mean, Jim. Yeah, I think that makes sense. Um, so I think the question then becomes, so are we expecting, so for the Kubernetes layers, when we are reporting, and one option is, okay, we could say, well, let's just adopt the Oscar definition and somehow see if we can, you know, if there's, uh, if we can take that definition and represent it as a Kubernetes CR, right? That would be one approach. Um, the other approach would be to say, okay, we still want to provide some generic top level information like we have in the policy report, uh, which is something that we're inventing, but then somehow we can, you know, we can keep all of the Oscar, I don't know which layer it would cleanly map to, like, so I see there's findings and there's a results group of findings and observations, so somewhere in there if we map one of those layers to a policy result, um, then we could put all of the other data in, in just like the generic kind of an object, right, which is untyped or unstructured in the policy report. But yeah, it is tempting to kind of at least take a deeper look if this work has been done, if it's used and if it's comprehensive, um, can we represent this Oscar report or the entire structure in Kubernetes, right, for the Kubernetes layers? Um, so, right, and I think every time we are looking at something like, you know, standardization and so on, the first thought is, am I locking, you know, uh, my, my, uh, myself into a, you know, a rigid schema or structure and so on. And you can share the experience that, um, we, um, had items as part of that, uh, that through the experience of, you know, in the field found out that, you know, things have to be handled in a different way or it makes sense, more efficient. And, um, the, uh, Oscar team was open and flexible to take these feedbacks, um, and, and, um, make changes in order to be more efficient. So if we find out that the exercise that you may, uh, mentioned Jim, let's take, have a deeper look and you see that some things are needed or missing or need to be done in a separate role, although the schema is pretty flexible and generic. Um, the team is, is open to, to listen to those feedbacks. So this is, this was a positive experience for us. Okay. Well, that's good to know. Um, so are there systems, you know, which within, like, uh, you know, for, like your management tools, are there examples of how these reports have been used, like to, whether it's for user interfaces, like reports, um, like, you know, more, I guess, user consumable reports, right, that are produced. So it'll be interesting to see that, can this data, are there actual, uh, real world examples of this data being taken and translated, uh, into something consumable by administrators and, uh, people concerned with security of these systems. Um, because that would be a good data point to see that, yeah, then this makes sense that we also supported for Kubernetes. So Jaya, you have more experience with this working group. How much can we disclose from, you know, what we, how we use this for SCC and the plans and so on. I, um, yeah, I think, um, we are just starting to, you use on the call, he's in, uh, my team, uh, leading the, our GRC squad and we are just starting to look at this, right, in terms of putting it into the product. So we haven't done that yet, but that said, you already have submitted an example of our config policy controller within Rackam, how it would use this standard to represent the results. So, and, um, so what I'm saying is that we have mapped our, um, our existing controls, um, to this standard, the existing policy standard, right, policy report standard. And, but now that, uh, Anka has done the work of bringing the scale in, um, we can do a, we have to kind of redo that mapping, I think, because I think, uh, some of the fields that you have filled out, uh, was not done as part of use work, but that said, our control today already has standards control categories and controls in it. So we already have those pieces of information for our policies. So, so we should be able to fill those in, um, based on the example that you have here. Um, and I think I would like to proceed in this direction because eventually, like I said, we take the Rackam product today, it already has, um, if you look at our dashboard, it already summarizes the controls in the context of their standards. Right. Um, I think, um, by making sure that when third party contribute to our open cluster management, uh, policy collection repo, right, where they start contributing policies and so on. If they also return results for the standard, uh, I think this will make sure that they are also including the, the, um, control categories and controls and standards in terms of the results so that when, when we roll it up in our, in our UI, we can have everything contributing to that overall picture. Right. Because, um, that's really what customers are looking for. Right. When they operate a cloud, they're saying, you know, I have to operate it to a standard and, and when I'm using governance, I want to know what am I actually governing? What are the gaps? Right. Um, and so for that view, we do need this information. Um, otherwise it's going to be just islands. Right. We'll just no policies, but we wouldn't know, you know, where, where do those fit? Right. And right. I think this is that, that's, that's, um, an important path that, that is needed for, uh, and where this can help to, um, write, uh, standardize and, um, organize the, uh, across the stack and other direction that, uh, I have seen the, uh, compliance, um, right institutions, uh, going towards is automatic generation of the documentation. So we are talking about those, you know, hundreds of pages of, um, of the reports for the audit. And, um, our, our initial thought and, and they start started producing a particularly coal fire, which is the first one that we've seen interested in Oscar, uh, uh, templates for those documentation that can then be automatically, uh, filled out from the, from the assessment results in, in Oscar. So that's another direction. We are not yet there, but for us, that's, that's the ultimate ultimate goal, right? To, to help the automatic generation of the audits. Yep. Yep. That's a second. That's another goal. Yes. Right. So I think the, the other question that comes to mind is, and I don't have an opinion on this, just kind of wondering out loud as, you know, so part of the, the driver or the motivation for the policy report was to have something that the cluster admin could see and that we have all of these different, uh, you know, the growing set of policy tools, uh, for Kubernetes, right? Whether it's, uh, image governance or runtime policies or configuration scanning, things like that. So the question is like this report, it, it seems extremely comprehensive and well thought out. So definitely seems worth the closer look, but how, how would the, if somebody is looking at this as a custom resource or like as a, um, you know, set of YAMLs and Kubernetes, will this be, is it consumable as is? So do we need a simpler format that the admin can see and understand to say, okay, what's going on, uh, in their particular system at a given time, right? Um, so if we are looking strictly at the language, uh, Oskal, uh, provides the same thing in YAML and XML and, you know, so we can get the YAML. Uh, so that's one aspect of your question. Uh, the other one, um, I think the, um, uh, it depends. Uh, and, and we've, we've, we've got exactly into, into the, uh, core of, of this, uh, uh, concern, right? Um, if we are looking at the compliance, uh, operator, I think we have about 600 rules, right? So, um, is it, is it, uh, the expectation there that an admin will be able to go through those 600 in one document. And of course that, that's not, you know, feasible. So we are looking at organizing those, um, uh, Oskal files and objects within, in a, in a way that it is, uh, easily, um, uh, handled, um, by, uh, by the person that is looking to make changes to the profile or the policies and so on. Um, and, uh, and this is done by structuring all this, you know, uh, results and the policies, um, in, uh, in, uh, github in a way that is, that is easy to, to navigate. Um, the other approach that we have is via the, is via the UI. Uh, where I think it's very similar to what Jaya has today in, in Rakam where we are able to, uh, search or we are able to display, right? Through navigation, what are the policies and then display the content that is relevant just for that particular, uh, so you see here, uh, an observation is kind of self-contained. It has the evidence, the scope and, uh, the properties. So those would be the two means by which that can be, uh, done. Um, if I can make the comparison, first one is more like the Linux approach. The second one is more like the Windows approach. So depending on the, you know, the, the type of users that we are dealing with may, we may have people that work directly with the files or we can people that would work with the UI like, uh, Jaya has today in the ACM. Yeah, I, I have to drop, but, um, I think, I think this is, I know Jim, uh, I'm sure you have to think out, think through this. Um, and I'm, I know Robert couldn't join. Um, so I'm hoping that he will listen to this recording and, um, I think we should, uh, come back and regroup, right? Yeah, absolutely. Yeah. Let's, let's have another discussion on it and maybe, you know, like I'll, I'll do some more research and read up on this too. This is super interesting and I mean, I agree. It makes complete sense. I'm just, you know, we need to kind of make sure that the, some of the initial intent of the policy report are still, um, met, right? Like in terms of having something simple for the user to see and understand what's going on. But yeah, at some point this data becomes overwhelming, right? Cause if you have thousands of rules, it's no longer going to be easy to read anyways. So yeah, those are some interesting tradeoffs to discuss and decide how we want to proceed. Yeah, I think one interesting, um, uh, aspect for us would be, are the users interested in, um, uh, configuring those policies at the, uh, CIS benchmark level? Is this, what are they rather interested in having, uh, blueprints? The, the same way that the, um, CIS benchmarks creates those or the openscap actually those profiles. So I'm taking my 400, uh, missed rules and I'm taking my 300, uh, you know, CIS benchmarks and I, I know that they are targeted to HIPAA or to NIST or to, to the right level. And I try or do I really have to go and edit within each rule of those, you know, 400 or if you have any, any usability at this, at this point, I would be very interested because that would drive the user experience in a different way. Right. Yeah, makes sense. I think that's something we need to think through. And I, I don't know. Like again, it will the mapping be done externally. Will it be done on a poor rule basis? And which, you know, who represents that, right? But at a high level, what we, at least with the policy results, uh, the policy report. Like just if you do run a CIS benchmark, the idea would be to at least we get to be able to see some summary status and under, you know, kind of be able to represent that in Kubernetes as a native object, uh, of what the benchmark results were. Now details, we have to decide, are those separate CRs, are they part of the same report? Uh, or, you know, are they managed in external tools, right? And all of those are possible options. Uh, but the more flexible we can make this, I think the wider adoption and usage we'll see. And the schema allows for that, right? Right, right. So is there any, I didn't see any, um, so Jay, I know you, you have to drop. So please feel free. Maybe if, if Anka has some time, we can continue chatting. Um, I have. I have 10 more minutes. Yes. Yeah. Please go ahead and we can catch up. Okay. Thanks. Yeah. Okay. Thank you for joining today. Thank you. Bye. Bye. So is there like in this, um, and I, you know, are there provisions for even providing things like summary counts, et cetera? Cause, um, that was one of the things we wanted to do in the report is have some inability to say how many total pass failed, or is that just something, I mean, obviously you can process that by scanning through the data. So is that also available? That would be as part of the, uh, properties. So it's not, it's not, um, uh, uh, singled out as, uh, as, as such. Um, and the reason for that is that this is part of a. A larger hierarchical structure. So you have those individual observations, then you group them and aggregate at the controls level. Then you group them at, uh, regulation level. Then you group them at the profiles that, you know, may include multiple. So when I have my counts, right, it may be you given, given this hierarchy, um, it's very difficult to, to, to have a count because you will need to associate it, which, which level I am in, in, in that. Right. So all counts are rather, um, by product that, uh, that, uh, can be, um, generated rather than have it as part of the schema. Right. I see. Okay. Um, and then it's so like just going back to the hierarchy, you know, so there is the result group, the findings, the observation. So how, where does it say, if I'm running like a CIS benchmark, and you had some example of this. Um, is the CIS benchmark map to the, like, so let's say I'm running CIS benchmarks for Kubernetes. Does that map to the top level result group? I have, you know, one result group for CIS benchmarks for Kubernetes. And then I have findings underneath for each rule or how, what is the mapping? Uh, correct. So, um, we pick a regulation. Right. So in your case, uh, in our case, we had missed, you say, well, I'm looking for CIS benchmarks. This means that my findings here, my, my control, right. It is, it is the CIS benchmark itself. So then that's what I'm declaring there and the, um, that's my 12 o'clock. And, um, the, um, the rule, the observations that are associated with them would be at the, uh, would be mapped one by one. So if you are looking here at this item, so let's say that I'm looking for a CIS benchmark. I'm not looking for AC three. This means that that will be mapped to mapped one to one to an observation. Right. Because, uh, although I have seen in, um, uh, in, uh, the CIS benchmark is implemented by two rules. Right. So, um, so this is the finding, right? Is that the regulation level? And then what I have on the left, these observations, right? Are the individual results. So what, what the finding allows you to do is that level of, of, of mapping to say, well, what are the, my, um, my individual results out of which I create my, uh, in this case, the CIS benchmark. But I would say 99% of the cases I will have here a CIS benchmark and I have one to one, one observation associated with that. You change the finding to NIST. Right. I have, uh, this, you know, for properties for rules, uh, for CIS benchmark that are associated with that. So you, you can use it across any, any type of, um, uh, regulation or benchmark that you, that you need. Okay. So then what does the result group map to, if, um, Is that. Okay. Uh, the result group, it is part of the, um, uh, an object above, uh, those, those observations and findings, which is called assessment result. So as part of the assessment result peers to result group would be, um, the, uh, uh, SSP would to be the inventory on top of each. I apply, uh, my, um, objectives. So let's say it gives you, it gives you flexibility as an auditor to, uh, fine tune your audit. Right. So if I'm, if I'm doing openscap and I'm doing all the compliance operator and I put it in there, format, right? It is all or nothing. What the other levels, um, peers to result group allows me to do is to say, uh, I'm looking only at this set of inventory. I'm looking only at this, uh, particular clusters or this particular VMs. And my SSP will, will give only those items. So then when I go here in the observations, I will not have a hundred percent of my inventory. I will have a subset of that. Um, another. Sorry. Okay. No. Just. Yeah, I see. So, so this seems like this report then is generated based on what you're trying to. What information you're trying to gather, right? So if I say, okay, I want to look at maybe, um, some subset of my clusters or maybe some subset of nodes in a cluster, then the report will, the result group will be for that particular, did I understand that correctly? It's for that inventory that I will create the result group. And then the finding will map to each one of the benchmarks or each one of the regulations. And then the result group will be for that particular, um, the results that I want to apply. And then within those, I will have multiple rules. Um, yeah. So let me see if I have, um, This is the right. No. I try to find, because I think the, uh, what I try to say is that the more layers you add to this, the more functionality you get out of the Oskar framework. So right now we looked only at the core results, right? If you add to that the SSP, you get flexibility on handling the scope. Uh, another aspect that you have here, it's called, um, assessment methods. And it allows you to describe, let's say that I have, uh, 10 tools to do assessments, right? I have compliance operator. I get caveonics. I have Prisma. I have, right, different tools. So it can be that an auditor says, you know what, I, I want that tool, the results from that tool. So it allows you to describe how the, uh, what are the methods. So, um, again, Oskar is very rich, right? Another aspect it's called, um, a peer to result group is called, uh, objectives. So the objectives is derived from the object of profile. So where you say, I'm not interested in full mean state 153. I'm interested only in the, um, uh, access control part, or I'm an auditor that I'm only familiar with the network, uh, aspects. So I want only the, um, boundaries, uh, related controls, right? So the, the more levels you, you add here, right? The, the, the richer starts to be the, the way that you can tune your result. Right now is what we have. It's right all, all or nothing, or we have other means by which we trim that. Okay. All right. Yeah, this will be interesting to think through and discuss and see how we want to, like, because if we have certain policy frameworks running in a Kubernetes cluster, how should they. Store their information and then seems like maybe we do need a little bit of, um, um, something which can allow queries to pull this together and, and pass back a particular report in Kubernetes, right? Or if you, if you want to support. Add all these other layers is because they are dependencies as you say. Right. So this means now I have, I need a discovery. See provided inventory in the Oscar SSP format. So I'm able now to build this into, into this report. So, uh, I removed on purpose everything so that the people are not that we need all these other tools, but now if we have that discovery and we are able to produce, uh, uh, Oscar in other aspects of Kubernetes, like inventory as code in the Oscar SSP format. And so then we, we are able to put those together and, and leverage them here as, as, as, uh, uh, um, um, item. All right. Yeah. I'll do some research and thank you for this again. And, um, I know we're coming up on the hour and we both have other meetings coming up. So we'll maybe continue the conversation offline and we can meet again next time. Yeah. So I'm really looking forward for the, the, the people. Hello. Good evening. Good afternoon. Who is listening to that? Yeah. And please join next time to, to provide the feedback on, on, uh, on this, uh, Proposal of, uh, uh, policy result standardization. Yeah. Looking for it. All right. Thanks uncle. Thank you. Thank you. Bye bye. Bye bye.