GitLab Threat Management Community Office Hours, 15 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Threat Management Team: Office Hours

Description

Open office hours for topics related to Threat Management groups - Secure:Threat Insights & Protect:Container Security

A

Welcome to the threat management office hours, uh we're gonna quickly summarize what the original question was alexander. Can you restate your question for the video.

B

uh Matt actually did a better job of summarizing.

A

Alexander's question.

B

A

Alexander for the video.

C

Sure so alexander was asking about having vulnerabilities created from like potentially from alerts and then also how that could fit in with some of the policy management stuff and from I think, I'm a little less clear about alerts. I think sam and I've kind of talked about this, but that's more stuff, that's happening in production. On the infrastructure side, it may make sense to convert some alerts into a vulnerability if it's something for like an internal team to address or patch something.

C

I see a more a stronger use case for the policy piece which I think sam is about to give us a demo of and it'll make a little bit more sense when you see it, but because it's sort of a generalized rules builder, I think it would be great for setting up things like, for example, today we've got the vulnerability check rule or the security approval gate. Whatever you want to call it, it's kind of just a one or a zero. It's on or it's off.

C

If it's on it enforces any critical, high or unknown vulnerabilities are blocked from being merged without an approval. That's great, but it's not really flexible right like what. If for a particular project, I only care about criticals what, if I don't care about hives from a particular scanner that I know is noisy right so using something like what sam's got with a policy builder, you could construct those very specific kind of, I guess logic rules and use those to enforce different things for like the vulnerability management workflows.

C

And ideally we could do it at a group level. So you wouldn't have to go into each individual project. You could just set a policy for something like that top down and then overwrite at the project.

C

Level, oh sam you're, on mute.

C

Sam you're, a mute.

D

There we go is that better, so um we don't have everything that matt talked about in this prototype, but we do have some things. uh So we created this new vulnerability management policy type and that lets you write some rules around some of the actions that users can take. So if you want to actually prevent users from ever dismissing vulnerabilities, you can do that. You could potentially extend this out to add some additional criteria or have this say you know, allow the action but require a comment.

D

You could also write some rules around when vulnerabilities change severity so that you could either allow or prevent users from changing that severity or provide a comment if they decided to upgrade or downgrade the severity of vulnerability. So we don't have like. I said we don't have everything that matt talked about. I think some of that other stuff would probably come in your scan results policy where you say you know, if uh you know dependency scanning finds one or more critical vulnerabilities.

D

You might have an action down here that says you know, ignore that. Don't generate the vulnerability. Just you know we, don't we don't really care about. You know whatever this may be so this. If this, then that logic is definitely highly extensible, so we can um have that flexibility to adjust this as needed, depending on our users needs in the future.

B

That's super cool.

C

That's it so alexander. When are you going to have that done since you work on that now.

B

Yeah that that's next, that's just I'm like just finishing up some things and then uh you know next year.

C

Which isn't like 16 days.

B

Yeah yeah, you know q2 q and q3 or something.

C

With a q, so one thing I I do want to make sure to call attention to is when sam was kind of showing this to me, he basically said and sam tell me- this is incorrect.

C

The behaviors so like that was just a prototype and sam has graciously added things to his prototype for vulnerability management specifically, but you can almost think of everything from that top level.

C

Drop-Down setting like the scanners and the vulnerability management is like a module, so we would have the ability to do kind of whatever we would need in terms of our rule sets we're just leveraging that awesome, ui and the kind of if-then-else logic on that a lot of stuff to figure out like how do we store that, obviously doing that in a yaml-based, config probably doesn't make any sense, especially not for a group, top-down kind of a policy piece and especially for things that aren't going to necessarily rely on a pipeline like if I want to make a rule.

C

For instance, that says dismissals require an approval before I do that, if that's on a vulnerability report like project level thing, why would I put that at a yaml file right? I should be able to turn that on and off without triggering a pipeline, so quite a ways out, but I think that's a really really good direction to sort of point at so that comes up in the future.

E

I have a minor remark or question uh that would be super useful to me personally in the sec, auto team, and is that and also as former part of the security operations team, we sometimes had issues that were high crit that were critical or high priority that would be cycled between faces or the severity would be changed and it nests. It wasn't necessarily appropriate, um probably someone that was a bit tired, changed.

E

It sculpt it down whatever, but is this also intended to work with labels so that you sort of build your own home brewed version of the artifact that you are having, so you have vulnerabilities, you have scanned results from those vulnerabilities from those countries or results, but is there also a plan to use the normal labels defined per project or um labels that are scoped can't be changed? If, then else?

E

um What are your thoughts because for me it would have been useful to say if a issue type label or incident type label is high or critical. It cannot be marked done unless you whatever or you cannot be scope or change the priority of an incident label issue once it has been set. If then blah things like that, but sort of more like oriented to label.

C

I don't know sam if you had any plans on the label side I'll say at least from the vulnerability object side right now. We've purposely avoided adding labels just because we want to make sure that vulnerabilities are really for just sort of the triage and understanding what the specific problem is. And then you create issues in mrs from that and attach it to do the actual sort of like workflow and follow-up pieces, so I'll say no, not in the near future for the vulnerability side but yeah. I don't know about sam labels.

C

If you'd consider the policy piece.

D

Yeah, I mean all of the vulnerability stuff management. Stuff is really far out on our roadmap, so matt you would get to that way before we did at this point because we're just I mean our category is brand new and we're just starting with project level.

D

Das scheduled scan policies so we're starting with like a super, narrow slice and like we have a long ways to go before we even start approaching vulnerability management type policies, so it the the editor is definitely flexible enough to allow what you're describing it's just not any time on the near term. Right now,.

C

And jason, I have a question about that, so you mentioned using some of those labels to sort of enforce what you can and can't do.

C

Is there a way that you can actually put a label on something and excuse me not like I couldn't come and remove one of your scope- labels, for example, to get around the policy. I guess I thought labels were a lot more discerning anybody could add them or remove them.

E

Yeah so um at least the way we use them in the team and as far as I've seen in the security team is pretty much only we set the label. So there are no external team members like yeah from other teams, other departments that touch our labels, but sadly, due to the way the gitlab org git labcom hierarchy is structured.

E

Many could because the the maintainer permissions sort of trickle down- and there are people outside of the security team and the security department and the sec auto team that have maintainer permissions in our groups and projects, so they could change. They could make an issue that is a critical make it a low and if you're not paying attention, it's now a low, and we don't work on that. So um we aren't as big so that as to make it possible that does so.

E

That sort of thing gets lost in the noise, but abstracting away a bit. It could happen um yeah. So that's that's why I mentioned because one of one of the concerns I remember I was I used to discuss with people was okay. How can we guarantee that the priorities of issues is not changed, that there's a paper trail that we can react to it so yeah? It's it's been in our minds. It's not a high priority thing, but it's been on our minds.

C

Yeah, no, that's an interesting point. I think that sort of starts falling outside of the direct purview of this team. When you start talking about issue workflows and enforcing permissions and things you can and can't change about them, I will say that that's probably a better place to look at the vulnerability object, so our severities are a. We have a set. You know severity level for everything.

C

We definitely have it in the plans to be able to override that. That would make a a perfect rule right there to basically say either. You can't or requires an approval to change a severity so that you would at least have the tracking on the vulnerability piece itself and you you know.

C

I think there was actually I don't remember who opened it, but there was the idea of trying to map some of our labels to the severities. When you create an issue like if it's critical map that automatically to a severity, one, for instance, there's nothing to prevent people from changing that, but I suppose you could kind of use that as another trigger to say, hey these two things are out of sync get a little a little funky, but I think that's part of the problem is just get lab.

C

You can do kind of almost anything, and anybody can access too much stuff. It's hard to lock down things that are really flexible, like the labels.

D

Yeah and another note on that- I mean matt gonzalez in the compliance team, is working to create immutable labels that basically are locked down.

D

So again, I think we'll get there in the long run, it's just pretty far ways out, but we're slowly working towards that.

E

C

Sam, that's a good point about his labels. I kind of forgot about where, where are those scoped to is that are the labels on the project level, or can they actually be on the issue level? I.

D

Think they're on the project level, so yeah you would have to work with the most.

C

Constraints gotcha interesting.

A

Awesome unless somebody wants to hang out and puzzle, we have any other questions for today, I'm more than willing to hang out and puzzle.

A

And jason you're more than welcome to join us at any time. If you ever want a puzzle, he'll put the link there in the zoom chat for you. It's constantly got a puzzle going. You can look in the threat management social channel if it changes and thank you for joining us on our office hours. So we did update this to have an apac and a maya friendly schedule.

A

So in two weeks I think we still have this in two weeks because of the holiday yes it'll, be later in the day to accommodate for our apac team members.

B

A

All right, thank you. Everyone.