GitLab Secure and Protect UX, 1 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Security profiles - vision walkthrough

Description

A walkthrough of the high-level vision for Security Profiles. https://gitlab.com/gitlab-org/gitlab/-/issues/372190

A

Hey everyone, I'm michael fengman product designer for secure this video is to walk you through a high-level vision for security profiles. So security profiles are essentially taking a concept currently used by das, of having reusable configuration profiles and expanding amount to other security tools within gitlab.

A

So to explain this in a little bit more detail, I first would like to explain and walk through the current state of security configuration and the problem we're trying to solve here. So as it stands today, there are multiple ways you can.

A

You can configure and run security tests within a project in gitlab, so you can choose to add a job within a gitlab ci yaml file, so, for instance like this job, you can essentially define it here, and this will effectively run security scan whenever the ci pipeline runs and obviously the specifics of that will depend on the configuration options you choose.

A

We actually present users with a configuration page for this experience within the ui as well, but obviously or maybe not. Obviously, the configuration options and parameters and workflow varies a little bit based on the tool. You're configuring.

A

In addition to that, users can also choose to set up in, what's called an on-demand scan, and so this is essentially a point in time.

A

Security scan within git lab where users can come in and run one-off security tests at any point they choose, and so currently this is only available for dust, but eventually we'd like to expand it out to most of our security tools and then last, but certainly, not least, is users have the option to create, what's called a scan execution policy, and so this will essentially define a set of rules or conditions that, when matt will run a security test within a project um so think about these different workflows.

A

Obviously, there's a number of different aspects and facets to it to them and the options that we're presenting to users within the ui actually all differ quite a bit, depending on the method that you're choosing to configure so whether it be ci configuration, on-demand configuration or security policy configuration, the options available within those processes vary and then obviously the configuration specifics for each tool will vary depending on the specific tool. You're configuring as well.

A

But ultimately, this makes it difficult for teams to set up consistent, repeatable security practices for their projects.

A

So, for instance, let's take sas, for example, so thinking about sas within a project you can come in and configure it for your ci pipeline directly through this interface, where you have a number of different options for you, you choose your stage, your search depth.

A

You can exploit paths and you can even go as far as to define specific analyzers that you'd like to run for your tool here and then you can go through a merger crest process to add that to your gitlab yaml file and if you were to come in and set up sas for, say a scan execution policy. I think as it stands today, you pretty much are left within a yaml mode configuration where you can define sas of the scan and I think, there's some ways to add specific parameters within about how sas will run.

A

But it's obviously a bit different than the experience you went through for ci configuration and then, if you wanted to try to run a point in time like one-off sas scan using on-demand scans, you don't even have that option available to you right now.

A

So basically, I tried to summarize this whole problem into two key jobs to be done statements, and so the problem we're trying to solve is as an application security analyst. I want to store and manage custom security scanner profiles so that I can use them for ci pipelines on demand, scans and scan execution policies, and ultimately this is the key problem we're trying to solve here with this issue, but I included one other key problem to solve as well.

A

That I think, is important to keep in mind as we're working through the solution and that's as an application security analyst. I want to manage and administer custom security scanner profiles so that I can test projects consistently across my organization and so by solving this problem for users.

A

I see us providing a number of benefits to them, the first of which is that the same configuration parameters will now be available across all scan configuration workflows in gitlab, so anytime, you're setting up sas, whether it be for ci pipeline or an on-demand scan for a scan execution policy. All the same parameters and configuration options will be available to you within the ui, no matter. What the next benefit I see is that using security profiles to configure security scans will actually make it easier for teams to perform tests more consistently on their projects.

A

Another benefit is that it will make the tuning and configuration process a lot easier and more efficient, because changes made to profiles will apply to all places. Those profiles are used within the project or within scans, so you basically update the profile in one place and it will cascade to anywhere that profile is being used, and then last is that this will effectively create a single source of truth for security configuration within a project and it's a little bit of a workaround here.

A

But essentially you can come into your project and see what profiles are available for that project and then, where they're being used within that project. So this essentially lets you come in and see all the different areas and configurations that are used for security testing within a project.

A

I also outlined in this issue a couple of other future facing benefits and user experience goals. um I want to really make sure we get into the presentation of the high-level proposal here, so I'm just not going to mention those here. Please read them and ask questions about them in the issue. If you would like to like, I said the feature facing user benefits are important to keep in mind, but again not super entirely relevant to what we're talking about here.

A

So now, I'd like to just kind of give you a high level overview of the proposal and the concept that I'm thinking here. So, in short, as I mentioned at the start of this video, we're essentially looking to expand the concept of reusable configuration profiles from das to all of gitlab security tools, this will effectively make it easier to save and reuse customized configuration details, so uh digging into that a little bit more.

A

I was thinking that we could essentially build on the foundation that das has laid for us and leveraged two existing profile types that they've already outlined so having scanner profiles and target profiles, currently they're called site profiles within the application, but I know we're looking to change them to target profiles and so scanner profiles effectively define the configuration details around how a scanner should test its target, and so the different subtypes available would essentially align with the different security tools that gitlab offers.

A

So you could have a scanner profile for dast scanner profile for sas scanner profile for deskt api api fuzzing, and you can have multiple das profiles, multiple sas profiles for a project and so on. So these essentially are reusable configuration details around the tool itself and then, in addition to scanner profiles, there would also be a concept of target profiles.

A

So these effectively contain information around the target being scanned and so target profile. Subtypes would essentially align with the different object types that security scanning tools can analyze, so, whether it's source code, whether it's api, whether it's a website each of these different object types, would be subtypes for target profiles so to put in a use case, for instance, you could have a target profile of an api and you can target that profile or scan that profile with the dashed api scan or an api fuzzing scan, so profiles.

A

Target profiles effectively could be targeted by a number of different scanner profiles and there'd, be some overlap, obviously on what targets can scan based on the scanner profile.

A

So if that all makes sense, then I want to talk a little bit more around how this would change the architecture of our security configuration section. So as it stands today we have under a project.

A

We have a security configuration section and within that we have security, testing tab and to show that in reality here so we have the security configuration section and under that we have this main security testing tab and as it stands today, profiles are available only on desks within this tab, and so what I'm proposing here is to actually rip profiles out of this main security testing page and create its own dedicated tab for security profiles within the configuration section, and so this would allow us to basically rethink this main security testing page at some point down the road not included as part of this to iterate on it and make it a more valuable page for users, but then also create a dedicated area for users to create and manage profiles within a project, and so within the security profiles.

A

Tab you'd essentially have a you know, high level overview of that, and then each a link out to scanner, profile, library and the uh target profile library, and then I also included a how our architecture could change in a future phase two. So this isn't super, I'm not proposing this in this project. It's just more of a speculative thing. I think it's helpful to understand where we want to go with security profiles when we're making decisions on how to make the next step here and so effectively.

A

Looking at currently security profiles that only be available at the project level, but looking down the road to potentially make them available at a group level too, where you can create group level security profiles that would then trickle down to projects.

A

So now I just want to walk you through the key primary workflows around profiles themselves and so essentially identified two key workflows that you would encounter when interacting with security profiles in gitlab, and so the first workflow is creating and managing security profiles. And then the other workflow is to actually use profiles within gitlab.

A

So the first workflow I'll walk you through is creating the managing security profiles, and so I'm essentially thinking that there would be two main ways to create and manage security profiles within a project so the first of which is from the security configuration section. You would have a dedicated area for security profiles, like I mentioned before.

A

We'd have a dedicated tab for that and that tab would just contain a high level overview on what profiles are and then a brief description and a link out to the scanner profile, library and target profile library and clicking through to the profile libraries.

A

You definitely use essentially have a table page where you'd have tabs across the top of all the available subtypes for that so for scanner profiles, for instance, you'd have a tab for das, a temper sass tab for deskt api and so on, and that would essentially contain all the profiles for that specific scanner type.

A

And then, if a say, specific subtype didn't have any existing profiles, we could use that tab empty state as a way to educate users around what that specific tool is for and the benefits they would get from it.

A

And then, from this main security profile, page users could click on existing profiles to view the specific configuration details and make edits and changes so clicking on a profile.

A

Row within this table would then link to a full configuration page and that configuration page would essentially be the same for all profile types, so follow the same general design, format and standard. But the specific configuration options that are displayed on those pages would differ and be customized to the specific profile.

A

Subtypes, so we'd essentially be grouping configuration options into logical groupings down the page and all those pages would generally feel the same, but have different options depending on the subtype that you're configuring and then, in addition to just main configuration details on this configuration page. I also think it could be a good opportunity to provide a little bit of metadata around these profiles themselves too, so like when it was last updated where it's used within the project um where it was created and so on, um and the last thing to mention for this workflow.

A

So in addition to editing and viewing existing profiles, users would also be able to create new profiles from the profile library and so essentially, they'd have one main primary action to create a new scanner profile or create a target profile or whatever profile their library they're. In and that would initiate a two-step workflow, that's very, very similar to the workflow, that's already defined in security policies here, where you first come in and choose which type of profile you would like to create, and so this would effectively show a card for each of the profiles.

A

So users can learn a little bit more around, what's available to them and the difference between them, and then they would select whatever one they would like and then move through the configuration page for that.

A

So then, in addition to just this main configuration area for profiles, obviously it's helpful to be able to create managed security profiles within the context of a scan configuration process. So, ultimately, user's goal is never to create profiles. Their goal is to set up security scans, and so, when they're setting up a security scan, they should be able to access and manage and create profiles directly from that workflow.

A

So, in short, essentially, what that would look like is from a scan configuration page like, for instance, this is sort of a ci cd configuration page for das.

A

You just come in to find some of their details and then, depending on which scan type they're configuring, they can open up the profile library for that scan type and then look at the available profiles for that and select that or create new ones or edit them and so on, and then, if user wanted to create a new profile or edit it, while in the context of a scan configuration page, they can do that and it would all be done basically through a drawer. So this concept currently exists within dast today.

A

So, just to give you a quick overview of what that is like so like for on-demand scans, for instance, if you want to come up and run a desk scan you'd come in here, and you have your main profiles available to you, you could select them, you could edit them or you could come in and even create new profiles from this. So this makes it really easy to just contextually, add and select and use profiles within the main context of the main configuration workflows.

A

So that's the main first workflow of creating the managing security profiles.

A

Next is essentially using security profiles within configuration pages, and so, as I walk through at the start of this video, there are sort of three different ways you can set up security scans within a project, so the first of which is an on-demand scan, configuration page and so, in this context, to use profiles, this page wouldn't change much from its current state, except for the fact that we would essentially scale this out to other scanners down the road.

A

So you should come in select which scan type they'd like to run and then based on that the form would change and ask them to select profiles for that specific scan type.

A

So if they chose das, for instance, they would then be able to go in and choose their dash profile, their dash target profile and so on, and then those items would eventually be reflected and shown on the configuration page, and so uh the exact same sort of workflow would uh be mirrored for like say, cid cicc cicd scan configuration as well, where users would come in to find specific details for the ci cd scan, but then select profiles that already exist or create new ones when selecting them.

A

So we can come in, have their scan type select their profiles from the profile. Library, drawer, editor, create profiles, and then the chosen profiles would be reflected on that main configuration page and then last, but certainly not least, again. Is security policy, so scan execution policies. Users could come in create a scan execution policy get to that second page, and then they can define their conditions and then they can define which scans they want to run for that policy and then based on their scan type. They would then choose which profile they want to use.

A

So if they chose desk, for instance, they could then go in and select the available scanner profiles for das and select from the available target profiles for nest.

A

um So, in short or long, that's a high level overview of uh this general vision for profiles. um I did provide some specific page level wireframes if you're curious to get a little bit more of a sneak peek into how this would come together. It is linked in the issue.

A

I didn't specifically add them to the design section of this issue yet because I first would love to get feedback in buy-in and discussions and consensus on the high level vision and profiles, and then once we are aligned there I'll then like to look at the page level, details and start figuring out those specifics.

A

So um if you want to come in and provide feedback on just the general concept, um the approach of profile types and subtypes how this could fit into our configuration and then thinking about the key workflows and just let me know you know how do you think this works for your different scan groups and the different tools that we offer? Obviously, the whole goal of this is to create a cohesive, consistent experience that can scale out to all of our security scanners.

A

Obviously, comments in the issue feel free to ping. Me directly and obviously reach out. If you have any questions thanks a lot, I'm looking forward to hearing your feedback.