Merge branch 'acarella-master-patch-26689' into 'master'

Update VM handbook links and exception process

See merge request !42451

source/handbook/engineering/security/vulnerability_management/index.html.md

@@ -53,8 +53,8 @@ Vulnerability scan data is exported and analyzed to provide consolidated vulnera
 Tenable also provides reporting functionality that is used by our Compliance team to run reports for audits.
 
 Currently, we export vulnerabilities as CSV files. These exports are filtered to be specific to the project/account (for example, gitlab-production in GCP gets its own report). Once exported, we analyze
-and consolidate the data into different `views`, including; unique vulnerabilities, vulnerability count, vulnerability count by asset, and vulnerability by severity. Once completed, we group vulnerabilities by solution and open a corresponding [issue](https://gitlab.com/gitlab-com/gl-security/secops/operations/blob/master/.gitlab/issue_templates/vulnerability.md)
-in the [Security Operations issue tracker](https://gitlab.com/groups/gitlab-com/gl-security/secops/-/issues). These issue are where all discussion and documentation for the vulnerability will occur. We also open a linked issue in [Infrastructure issue tracker](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues)
+and consolidate the data into different `views`, including; unique vulnerabilities, vulnerability count, vulnerability count by asset, and vulnerability by severity. Once completed, we group vulnerabilities by solution and open a corresponding [issue](https://gitlab.com/gitlab-com/gl-security/secops/vulnerability-management/-/blob/master/.gitlab/issue_templates/remediation.md)
+in the [Vulnerability Management issue tracker](https://gitlab.com/gitlab-com/gl-security/secops/vulnerability-management/issues). These issue are where all discussion and documentation for the vulnerability will occur. We also open a linked issue in [Infrastructure issue tracker](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues)
 which is where the vulnerabilities get scheduled for review and remediation.
 
 The vulnerability issue template is shown below:
@@ -63,7 +63,7 @@ The vulnerability issue template is shown below:
 
 ### 3. Ingestion
 
-Once the data is prepared in a format that we can pull out the most important information, we can ingest into GitLab.com. Issues are opened in the [Security Operations tracker](https://gitlab.com/gitlab-com/gl-security/secops/operations/issues) to track the remediation process of the vulnerability. Another issue is opened in the [Infrastructure issue tracker](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues) linking to the Security Operations issue; these are so that the work can properly get prioritized and scheduled according to Infrastructure team’s workflow. 
+Once the data is prepared in a format that we can pull out the most important information, we can ingest into GitLab.com. Issues are opened in the [Vulnerability Management tracker](https://gitlab.com/gitlab-com/gl-security/secops/vulnerability-management/issues) to track the remediation process of the vulnerability. Another issue is opened in the [Infrastructure issue tracker](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues) linking to the Security Operations issue; these are so that the work can properly get prioritized and scheduled according to Infrastructure team’s workflow. 
 
 Currently, we group vulnerabilities on a number of factors, such as severity and solution, as to consolidate the work required to remediate. If there are 10 unique vulnerabilities, but all require the same solution, it makes more sense to open a single issue to work through remediation.
 
@@ -75,11 +75,13 @@ Vulnerability issues should be tagged with the `vulnerability` type label. The f
 
 * `~vulnerability::falsepositive`: This label identifies that the vulnerability has been validated as a false positive and is no longer impactful to our environments. With this label a vulnerability issue can be closed.
 
+* `~vulnerability::exception`: This label identifies that the vulnerability has been validated as legitimate and has an approved exception issue to account for a business need. In extreme circumstances, a vulnerability issue can be closed with an exception.
+
 * `~vulnerability::mitigated`: This label identifies that the vulnerability has been validated and triaged. The impact has been reduced through compensating controls, but not remediated (it is still actively identified on vulnerability scans). With this label a vulnerability issue should not be closed.
 
 * `~vulnerability::remediated`: This label identifies that the vulnerability has been remediated and the remediation has been validated. With this label a vulnerability issue can be closed.
 
-We also add the `VM` label to all Vulnerability issues to scope the issues in the [Vulnerability Management issue board](https://gitlab.com/gitlab-com/gl-security/secops/operations/-/boards/1341809).
+We also add the `VM` label to all Vulnerability issues to scope the issues in the [Vulnerability Management issue board](https://gitlab.com/gitlab-com/gl-security/secops/vulnerability-management/-/boards/1573615).
 
 ### 4. Validation
 
@@ -89,7 +91,7 @@ Vulnerabilities can sometimes be identified during a scan, but are not actually
 
 ### 5. Remediation
 
-Remediation is the part of the process in which a validated vulnerability is fixed. The remediation process would be tracked in the corresponding vulnerability issue in the [Security Operations issue tracker](https://gitlab.com/gitlab-com/gl-security/secops/operations/issues). SLAs are in place to help prioritize vulnerability based on severity. Once a vulnerability is remediated, we will run followup scans on the impacted systems to validate that the vulnerability is indeed remediated.
+Remediation is the part of the process in which a validated vulnerability is fixed. The remediation process would be tracked in the corresponding vulnerability issue in the [Vulnerability Management issue tracker](https://gitlab.com/gitlab-com/gl-security/secops/vulnerability-management/issues). SLAs are in place to help prioritize vulnerability based on severity. Once a vulnerability is remediated, we will run followup scans on the impacted systems to validate that the vulnerability is indeed remediated.
 
 #### Vulnerability Issue Workflows
 
@@ -205,7 +207,40 @@ S1/P1 vulnerabilities discovered in scans would be worked on immediately through
 We understand that it is not always technologically feasible to keep all packages up-to-date due to application conflicts, or that a business decision may be made to not remediate a vulnerability because remediation would impact performance too greatly.
 Low risk vulnerabilities that may not get prioritized within the remediation SLAs should have an exception approved for them, documenting the low likelihood of exploit due to layered security, other compensating controls, mean of exploitation, etc.
 
-With this in mind we have an exception process; currently, we are working to create an exception process specific to our vulnerability management process. In the interim, we are leveraging our [information security policy exception process](https://about.gitlab.com/handbook/engineering/security/#information-security-policy-exception-management-process). 
+With this in mind we have an exception process; If you've identified a vulnerability that is a candidate for an exception, please open an [exception issue] in the [vulnerability management issue tracker](https://gitlab.com/gitlab-com/gl-security/secops/vulnerability-management/issues).
+
+Please fill all out the pertinent information requested in the template. For reference, the information required is as follows:
+
+* Vulnerability title
+* Tenable plugin-ID
+* Original remediation issue due date
+* Length of requested exception
+* List of applicable hosts
+
+You will also need to describe the business need for the exception and document any existing/implemented compensating controls.
+
+##### Exception length restrictions
+
+We currently allow exception lengths based on priority/severity as follows:
+
+| P/S  | 30-days | 60-days | 90-days | 365-days |
+|------|---------|---------|---------|----------|
+| P1/S1| `Yes`   | `No`    | `No`    | `No`     |
+| P2/S2| `Yes`   | `Yes`   | `Yes`   | `No`     |
+| P3/S3| `Yes`   | `Yes`   | `Yes`   | `Yes`    |
+| P4/S4| `Yes`   | `Yes`   | `Yes`   | `Yes`    |
+
+
+##### Exception approval matrix
+
+After the issue is open, the requestor should assign the due date to match that of the associated remediation issue and assign to the proper approver. The severity and priority of the vulnerability will dictate the approval process. This is documented below:
+
+| P/S  | Approver                        | 
+|------|---------------------------------|
+| P1/S1| Vice President of Security      |
+| P2/S2| Vice President of Security      |
+| P3/S3| Director of Security, Operations|
+| P4/S4| Security Manager, Operations    |
 
 ## Host Validation