Observation Remediation Procedure

Purpose

The Observation Management Program at GitLab is used to identify, track, remediate and provide a risk ratings of identified findings, exceptions or deficiencies for any Tier 3 information system risks that are identified as an output of compliance operations or other mechanisms by team members, such as self-identification of a system specific risk.

This procedure details the remediation process for observations.

Scope

Tier 3 risks identified at the information system or business process levels

Roles and Responsibilities

Procedure

Lifecycle Overview

graph TD;
  A[Identified] --> B[Assigned];
  B --> C[Remediation in progress];
  B --> D[Ignored or Invalid];
  C --> F[Resolved];

Observation Remediation

Once all remediation activities have been completed, the Remediation Owner is responsible for tagging the Observation Manager in the observation issue. If there is no Observation Manager assigned, tag @gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated in the observation issue.

It is the responsibility of the Observation Manager to track the milestones, work progress and validation of the remediation activity. The Observation Manager will then validate the remediation activity for completeness, re-test the observation (as applicable) and close the observation issue. If re-testing does not result in a fully effective conclusion, the observation description and remediation recommendations may be updated to reflect the new findings and required remediation tasks.

For detailed requiremented the observation manager follows during the remediation process, refer to the remediation and closeout runbook

Resolved

The observation is moved to Resolved after the observation remediation step is completed.

Ignored/Invalid

It is the responsibility of the Observation Manager to determine if an open observation is not valid or no longer applicable. This could be applicable for a variety of reasons including:

• stale observations
• legacy GCF controls
• process or application changes

If an observation is confirmed Ignored or Invalid, the associated risk rating of that observation can be changed. See the Observation Risk Rating Adjustment runbook for further details.

Root Cause Observation Epics

If multiple observation issues relate to the same root cause or are blocked by the same component of work, these issues will be connected together into an Epic in order to more clearly see how multiple observations issues are connected.

A list of observation Epics can be found here.

Non Remediation Owner Actions To Support Observation Closure

In cases where Internal Stakeholders (not the Remediation Owner) provide remediation documentation to support closure of the observation. Please tag the Observation Manager in the observation issue. This will trigger the validation of the remediation activity for completeness, re-test as appropriate and closure by the Observation Manager.

Remediation SLA

Observation remediation SLA’s are determined by the risk rating of the individual observation. The following table shows the SLA for each risk rating:

Opportunities for Improvement (OFI)

Throughout the course of testing or general monitoring of the GitLab ecosystem, Opportunities for Improvement (OFI) may be identified and documented so that the overall control environment and GitLab’s processes can be improved.

To capture an OFI, create an issue in the Observation Management project and add the RiskRating::OFI label.

OFI’s do not have defined remediation SLA’s as they are process improvements or suggestions only. The Remediation Goal to communicate the OFI to the appropriate stakeholder is 10 weeks.

What is the difference between an OFI and an Observation?

• Observations are tied to specific testing attributes, GCF controls and/or reflect areas where a third party compliance professional would be of the opinion that a relevant risk wouldn’t be or hasn’t been, mitigated.
• OFIs are not tied to specific testing attributes or GCF controls and are general areas of improvement that may streamline compliance or business activities.
• Observations will always impact control effectiveness ratings
• OFIs will never impact control effectiveness ratings

Criteria for Upgrading Observations (i.e. tier 3 information system level risks) to Security Operational Risks (tier 2)

The observation program is a key input to the StORM program, which manages tier 2 security operational risks. When the following criteria is met, it is an indicator that a larger risk exists and is upgraded to a tier 2 operational risk and therefore included in the StORM program. This criteria is as follows:

• An observation in an entity level control
• When multiple observations share root cause and are grouped in an observation epic. Observation epics are a group of observations spanning multiple systems that have shared root cause and remediation paths.

Security Compliance Workflow:

graph TD
    A[Observation Opened]
    A --> B{Observation meets<br>criteria for upgrading}
    B --> C{Yes}
    B --> |No| G(Follow Observation<br>Management Process)
    C --> |Observation Epic| E[Tag Risk, apply upgraded label]
    C --> |ELC| F[Tag Risk, apply upgraded label]
    F --> H[Risk is managed in <br> StORM program at tier 2 level]
    E --> I[Work with risk on collaborative remediation<br>for both Tier 2 and Tier 3 issues]

Security Risk Workflow:

flowchart TD
    A[Risk Team is tagged in a risk<br>meeting criteria for upgrading]
    A --> B{Type of<br>observation}
    B --> C[ELC]
    B --> D(Observation Epic)
    C --> E{Does a Risk<br>already exist?}
    E --> |Yes| F[Map related Risk in ZenGRC,<br>update into risk info if appropriate]
    E --> |No| H[Follow ZenGRC Risk<br>Runbook for new risks]
    H --> G(Risk is treated and<br>managed in StORM Program)
    F --> G
    D --> J{Does a Risk<br>already exist?}
    J --> |Yes| K[Map related Risk in ZenGRC,<br>update into risk info if appropriate]
    J --> |No| L[Follow ZenGRC Risk<br>Runbook for new risks]
    L --> M(Work with SecComp<br>on Remediation)
    K --> M

Detailed write up:

1. Open an observation following the Observation Intake runbook (internal only).
2. If the observation meets the criteria for being upgraded, tag the StORM DRI and apply label ~upgraded::storm-managed if an ELC or ~upgraded:storm-shared if added to an observation epic.
   1. Definitions of labels:
      1. Upgraded::StORM-Managed : StORM risk managers are solely responsible for tracking remediation activities
      2. Upgraded::StORM-Shared : Remediation of the observation and risk is shared by the StORM risk managers and the observation manager. The StORM risk manager may track remediation activities spanning multiple systems via a common initiative, while the observation manager would be responsible for remediation of the specific system. See the collaborative remediation section for more details.
3. When the Security Risk team is tagged, someone on that team will determine if there is a risk represented for the observation meeting the criteria.
   1. If there is an existing risk, they will map the observation to the risk and leave a comment in the GitLab issues for transparency.
   2. If there is not an existing risk, they will open a new risk following the StORM Risk Intake runbook (internal only).
4. An entity level control, the observation will be entirely managed by the StORM program at the tier 2 risk level, represented by the Upgraded::StORM-Managed label.
5. If the Observation is not an entity level control, Security Compliance will work with Security Risk for collaborative remediation with the remediation owner(s).

Collaborative Remediation

Security Compliance and Security Risk should look for opportunities to remediate via aggregated/common controls. In the event that observations can be remediated via a common control or implementation, activities can be tracked by the Security Risk team. For example, if we have systems that are not meeting password requirements and remediation across multiple systems involves integrating with Okta, this roll-out can be tracked by Security Risk. If remediation is system-specific, remediation activities can be tracked by Security Compliance. Remediation testing will be completed by which ever team is tracking remediation activities using the Security Compliance remediation runbook.

Status Labels

Defined below are status labels that will aide in the process of managing remediation of observations.

Exceptions

Exceptions will be created for observations that breach a mutually agreed upon remediation date, breach in SLA or if the Remediation Owner confirms the observation will not be remediated.

Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.

References

• Parent Policy: Information Security Policy
• GCF Control Lifecycle
• Sarbanes-Oxley (SOX) Compliance
• Observation Management Procedure
• Observation Management Project
• Insight Charts
• Control Health and Effectiveness Rating Procedure

Contact & Feedback

If you have any questions or feedback about the observation management process please contact the GitLab Security Assurance Team, or comment in this feedback issue.

View page source - Edit this page - please contribute.