## Background Groups are used in GitLab to manage one or more related projects at the same time. Although there are many different ways in which [a company can structure groups](https://docs.gitlab.com/ee/user/group/), for large enterprise companies in particular, a common group structure would be to have different groups or subgroups for different types of teams (e.g. having a different group for different application teams within a company). When this happens, there is usually another team that manages and administers the groups, such as a platform engineering or group administration team. As part of their responsibility in managing different groups, they are also responsible for the compliance and security posture of these different groups, including: - Ensuring that each group has the appropriate compliance policies and security standards applied and enforced; - Monitoring each group, on an individual or aggregate level, for any breaches of said compliance policies or security standards; and - Investigating the reasons for said breaches of compliance policies and security standards. ## Problem When managing, administering and assessing any impact to breaches in compliance or security posture, these platform engineering or group administration teams want to be able to see information aggregated at least 'one level up' (e.g. at an organisation wide level). However, there is currently no way in which we offer a single 'pane of glass' that provides a way to not only visualise, across all groups, what the associated compliance or security policy breaches are, but they are also unable to collate that information on a multi-group level to present as a report to upper management or other stakeholders that are interested on an organisation-wide posture, rather than on an individual group basis. :thumbsdown: The **pain points** that arise from being unable to view compliance and security concerns on a multi-group or organization level are as follows: | Pain Point | Hypothesized Use Case | |------------|-----------------------| | Increasing the amount of time required to perform compliance or security related tasks, as users need to go into each group/subgroup/project first and implement security policies, monitor compliance requirements, and report compliance issues. | The user wants to find certain violations or policies across different groups; they need to go to each individual group to perform the same search again and again | | Increasing the number of steps required in order to scope policies or compliance frameworks across multiple groups (e.g. large companies that have 100s or 1000s of groups), since the highest level of compliance and secure features are in groups, the user needs to go to individual groups to set up the potential same policy/compliance framework for each group. | The user has many groups in their organization. All of them need to comply with certain rules, and the user needs to set up policies to enforce them. The user needs to go to each group to set up the same compliance frameworks and policies. Imagine a user has 100+ groups; they need to do the same tasks 100 times. | | Increasing the amount of time it takes to have an overview of the whole organization's compliance and policy status, due to the lack of a 'single pane of glass' that provides this information at a multi-group aggregate level. | The user wants to have a glance at the current health status of the organization's compliance and security; they need to go to each group to check them. | | Increasing the amount of time it takes to understand and create a report of the whole organization's compliance and security posture across all the groups at an aggregate level. | The user needs to file an audit report of the organization's compliance status; they need to download reports from each group and manually put them together. | | Increased difficulty in managing permissions at a multi-group aggregate or organizational level | The user's organization has one security team; they need access to all the group's security and compliance features; the access now is open to all group owners; there is no way the user can separate security and compliance access from the group owner's roles and assign them to the security team only. | :thumbsup: Hence, the **benefits** of solving this issue include the following: | Benefit | Why this is important | |---------|-----------------------| | Decreasing the amount of time it takes to perform compliance or security related tasks, which aligns with the group direction goal | Aligns with our [group direction ](https://about.gitlab.com/direction/govern/compliance/)around making compliance feel easy and helping organizations move faster, not slower | | Decreasing the number of steps required in order to scope policies or compliance frameworks across multiple groups | Aligns with our [group direction ](https://about.gitlab.com/direction/govern/compliance/)around making compliance feel easy and helping organizations move faster, not slower. | | Decreasing the amount of time it takes to have an overview of the whole organization's compliance and policy status | Aligns with our [group direction ](https://about.gitlab.com/direction/govern/compliance/)around providing a "single pane of glass" to enable compliance teams to quickly identify non-compliant activities throughout the organization so they can take action. | | Decreasing the number of steps required in order to scope policies or compliance frameworks across multiple groups | Aligns with our [group direction](https://about.gitlab.com/direction/govern/compliance/) around enabling organizations to scope compliance requirements of their GitLab organization (groups,sub-groups, and projects) and manage high-level administration of policy enforcement (facilitated through Security Policy Management). | | Decreasing the difficulty in managing permissions at a multi-group aggregate or organizational level | Aligns with our [group direction ](https://about.gitlab.com/direction/govern/compliance/)around enabling organizations to scope compliance requirements of their GitLab organization (groups,sub-groups, and projects) and manage high-level administration of policy enforcement (facilitated through Security Policy Management). | # Solution There are 2 potential ways to look at solutions to this problem: * Design and develop an organization-wide scoping solution in line with the `Organization` object and wait for that to be available; or * Add a solution to the `instance` level initially and scope in any potential future changes based on how the `Organization` object will be implemented in GitLab. With respect to the second option, we could potentially develop a solution that takes into account 3 key principles from platform engineering ideas around IDPs: * Provide a way for a top-level group to create 'templates' of compliance frameworks and security policies (e.g. the IDP); * Allow the top-level group to allocate these templates across other groups in the same instance; and * Give the other group owners the ability to edit these templates for their own use cases but **not** the original templates that were created by the top-level group In this way, a top-level group acts as the 'IDP' (so to speak), and the other groups in the instance can pick and choose the templates they want to apply to their group and edit them as they see fit. ### Relevant Questions 1. What is the current high level, and what is the status of that 1. Organizations are probably the most relevant to manage cross-group; MVC will be ready to be tested by users soon 2. Design epic: https://gitlab.com/groups/gitlab-org/-/epics/10068 3. Organization blueprint: https://docs.gitlab.com/ee/architecture/blueprints/organization/ 2. Can git ability (version control) be available on the organization level 1. No. 1. This is most relevant for security policy; policy is stored as code, and users need to have the review process the same as merge codes. We need to have the project still as a storage for the policy.yml file, but we need to hide it (or wrap around it to make it not look like average project) 3. Do we need a customized user role and Permissions 1. Yes 1. We are currently preparing extra permissions for security policies; we probably need more permissions compliance as well 2. Based on the compliance and policy permissions, we can set up a customized role so that security permissions can be detached from the general owner role. 3. The admin of the organization should be the only one to assign security permissions to the customized role ## JTBD and Personas ### Personas * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) * [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Isaac (Infrastructure Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) ### JTBD **NOTE**: The below references [the recent research](https://gitlab.com/gitlab-org/ux-research/-/issues/2460#note_1525210690 "Use JTBD Survey to find unmet needs in Govern") conducted by @moliver28 around JTBDs for users in the Govern Stage * **Compliance auditor** audit the client or business unit’s records for any rule or regulation violations * **Policy creato**r create security policies for org’s assets, to increase the adoption of my organs assets to the compliance requirements; reduce the likelihood of a legal and financial threat to the organisation; increase awareness of the security standards among developers * **Policy ensurer** ensure security policy requirements across my org’s assets are compliant to reduce the likelihood of business-critical threats; maintain the reputation of the organisation in the industry; and increase the visibility of my organisation’s security capabilities and deficits among developers. * **Policy implementer** Implement security controls in my organisation’s assets to reduce the likelihood of a business-critical threat to the organisation’s assets and increase the adoption of my organs Asse to the compliance requirement. ## Next steps * [ ] Could you communicate the idea with both compliance and policy groups? * [ ] Problem validation for compliance * [ ] Problem validation for policies * [ ] Could you clarify the technical possibilities? * [ ] Design explorations for compliance * [ ] Design explorations for policy