GitLab Govern: Security Policies, 15 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Protect UX ideation: schedule a scan (policy creation MVC)

Description

https://gitlab.com/groups/gitlab-org/-/epics/4598
context: 0:00 - 1:40
ideation: 1:40 -10:30

A

Hi, this is just some early ideation, uh the the product management and product design team for um the new forms protect and um the on-demand das team is collaborating on creating a new mvc policy, so policies are currently in threat, monitoring the current ux's in security and compliance and threat monitoring, and these only relate to container network um security.

A

So these are actual policies for container network security, and if you want to edit them, you can um or see more details about them. You can open up a side drawer here and then you can create a new policy from here. It's a sort of conditional statement, but also the ability to direct directly do it in the ml mode. So this is the current ux. What this is this epic is about is actually the mvc to add a another policy, and that policy would be a recurring dashed, on-demand scan.

A

What makes it a policy is the recurring aspect of it. If it's just a one-time scan, that's not considered a policy even if it's a one-time scheduled scan, that's not a policy, but since it's recurring, that's what in this nbc we're considering it as a policy in future mbcs, there may be um same sched the ability to schedule uh other scanners, but for this one it's just focusing on desk and making a recurring one.

A

Okay, so thinking through um some of the changes that this would be some of the questions around it across the teams that I have for the task team, anna bell and derek just to think about. um This is again just focused on some ideation and and some changes that would result in in this nbc one would be information, architecture, here's the current one that we see today. I just want to point out a related one in issue, two one, five, six three: five, which actually merges the dependency list and license compliance list.

A

So it just sort of tightens up that area. There's a discussion, that's ongoing with that somewhat related. Only also because license compliance also has a policy section. So there may be that aspect that eventually merges into um the protect policies: uh future npcs, okay, let's say that doesn't happen or it happens later or what not just looking at the current information architecture.

A

This would some of the changes we're making here would result in a new policy section here under security and compliance, and that would look like this very similar to what we saw in the prototype, and this was just showing these type of policies that relate to network policy.

A

If we were to add dast, it act adds a new type section here. Some of the things that we'll have to think about is: what's the name for these recurring policies. What is the current inputs that users have um what would be the most appropriate one?

A

Some of the columns may not work like environment may not uh be relevant for that or there may be another relevant data point there for that, like uh what the pro, what um url the the profile is targeting, I'm not sure if it would go under that and then how status is so as we grow these policies and as we merge different um like network policies and then adding the ability to schedule scans, we'll just have to think about how these columns, like the data that we're showing to identify these policies, how it scales, because, as we add new things, there may be areas like this environment, one where maybe it doesn't scale so well or it's relevant for one rule and not relevant for another.

A

um So the questions I have here as for death stream is what might be most appropriate for the naming convention for the task policies and I'm sorry this shouldn't be showing overview here. That's that's just a state quickly, building this out, but some other questions too, is that the as we saw in the prototype there was um when you look at policies, there's a fly-out drawer. That gives you some summary details if we were to follow that same pattern.

A

Here is what are the key details that we would need for the profile of the recurring views, um so it's just taking a look at what the current edit page looks like on on demand and bring that into to this, and um it may may require linking to a dedicated page, but um just listing out some of those details would be helpful for that to know what's next in terms of the actual creation.

A

So just going back here, it's like the user, creating new policy like they do today, except in this case they'll, have the ability to select from runtime container policy or scan schedule policy. That's the one that we're focusing on for this mvc.

A

If they chose that one, then we just need to identify what are the key inputs that they need. There's two different directions here there may be an already existing profile so somewhere we can identify that and then create the rule um and but, but I think the other, the other scenario would be if um they need to create a new profile.

A

Is that something that we could handle right here in this screen by those inputs by kind of leveraging the same creation process that is seen in on demand to create that profile? Or do we need to bring in uh another modal overlay to make that creation?

A

I'm not sure I I want to just go back and focus on what those uh required inputs are, and then we can come back to the ui elements, but just wanted to point these out as kind of some ideation around it and then also with the creation process. I think that the main thing to focus on now is just the actual conditional statement so um going back to the prototype here for a second is we have the conditional statement for uh runtime container policies and it it goes like this.

A

If this, then this um so looking at scheduled scans- and this is just the prototype- it's not um uh the suggested one, but just to get an idea for how it works. It's like schedule, the br uh branch environment to be scheduled, then, and then um down here. You can select yes well, that that doesn't really it's. It won't work so well because each scanner may require different um sort of conditional rules. So just looking at it like this in in this way, I I think can help us identify that first sentence.

A

We have so I grade out the parts that are not part of this mvc and- um and these could be, this could be the first selection, and so the only selections here since this would be the only new rule. That's there for the scheduled scan is schedule das and then profile name. This could be the area where we get that input from the user. Now we'll have to think of once we get to the user interface, we'll have to think about the flow to create a new one.

A

If a profile doesn't exist, that's going back to maybe that modal or whatnot, I'm not sure, if that's the right one, but just just kind of focus on um the conditional rules so schedule, das profile, name to be scanned and then weekly daily hourly.

A

um The questions here is maybe for the mvc is: what is our introduction mvc, um which one makes most sense? Do we need to cut this down?

A

Do should we just have scheduled das, then the only input is profile name to be scanned weekly or where are we on capabilities for um the scheduling and recurring of it um could be a question for the das team, but also a question for for sam or kind of a question for all of us and on how we want to do that and what's within the scope here like, I said, these ones that are grayed out kind of just show later iteration so license scanning could have a similar pattern, but the inputs may be different.

A

For example, one that comes to mind is container scanning the inputs and not wouldn't be profile name, but maybe it could be what emit what um container image that it's to target? Maybe all of them there could be cases, multiple uh images just to show. So I would say that this would be the key focus, and then we can go back to the ui and um take a closer look at that.

A

Okay, then, the fifth aspect uh of focusing on is- and maybe we can adopt the pattern. That's in existence for on-demand scans is how are we displaying the results when they're when they're, um when the scheduled scan has done so since there's a recurring one? Let's say it's weekly, you know we'd want to show log of those weekly recurring ones and what is sort of the audit trail or what? Where can the results be seen? I understand that I, I think that it goes view results now and then they can go to the pipeline page.

A

So it's just adopting that pattern and then I'm just showing the details page here again. Maybe this is where we're showing the log, because if it's recurring what if they want to go to the one that was three weeks ago, if it was weekly, for example, so just some thoughts around uh that in the ui, um and we can probably just uh you know, adopt what and where those results are being shown currently for the on-demand desk hands.

A

Okay, so that um that is the rundown, that's where the ideation is so far, and uh this is just the head of any uh synced meetings. Okay, thanks.