Observation Management 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 creation process for observations.

Scope

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

Roles and Responsibilities

Procedure

Lifecycle Overview

graph TD;
  A[Identified] --> B[Validated];
  B --> C[In Progress];
  B --> D[Stalled];
  B --> G[Blocked];
  C --> E[Remediated];
  E --> F[Remediation Accepted];
  B --> H[Risk Accepted];

Observation Workflow Labels

These workflow labels indicate with the observation issue within the lifecycle.

Observation Category Labels

Labels in this set are used to categorize issues for metrics and reporting and cross-team collaboration.

Identifying Observations

Observations can be identified through the following channels:

1. Security control testing activities (CCM)
2. Business Impact Analysis (BIA) activities
3. External audit activities
4. Gap assessment activities
5. Ad-hoc issues

Assigning Observations

The observation identifier is responsible for opening an observation in the GitLab Observation Project. The observation identifier fills out all necessary observation information, remediation recommendations and submits the observation to the Remediation Owner for validation. The Observation Manager is responsible for managing the observation through the observation lifecycle. This includes linking the observation to the associated control in Hyperproof, validating the observation with the Remediation Owner, tracking all remediation progress and updating the GitLab issue with current information and status updates. Each observation has both a GitLab Issue (for Remediation Owners) and a Hyperproof Issue (for Observation Managers). Each observation will be assigned a risk rating, which should drive the priority of remediation.

Drafting Observation Description Guidance

The Observation description should include the who, what, when, where, why, and how related to the observation. As a review step, if you knew nothing about this observation could you understand the finding, how it was identified, and the effect it has on objectives? Consider leveraging the 4C’s model:

1. Condition - current state
2. Criteria - desired state based on policy, requirement, control, regulation, etc.
3. Cause - root cause of the observation
4. Consequence - actual or potential effect on objectives/assets

Risk Ratings

Tier 3 information system risk ratings are based off the formula below.

Risk Rating = Likelihood x Impact

Determine the likelihood of the observation recurring

At GitLab, observations will be rated based on the likelihood the observation has recurring and/or the frequency that the control has seen observations.

Determine the impact of the observation

Determining Risk Rating

Once the likelihood and impact scores are determined, the following table can be used to determine the risk rating for the observation:

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 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.

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 unless otherwise defined by the agreed upon remediation plan.

Criteria for Upgrading Observations To Tier 2 Risks

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]

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,<br>update into risk info if appropriate]
    E --> |No| H[Follow 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,<br>update into risk info if appropriate]
    J --> |No| L[Follow Risk<br>Runbook for new risks]
    L --> M(Work with SecComp<br>on Remediation)
    K --> M

Metrics and Reporting

Please refer to the observation management project’s issue boards for details for all observations by risk, status, and department. Please refer to our tableau dashboard for operational metrics for the observation program.

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

• GCF Control Lifecycle
• Observation Management Project

Contact & Feedback

If you have any questions or feedback about the observation management process please contact the GitLab Security Assurance Team.

View page source - Edit this page - please contribute.