The purpose of the Critical Logging Tiering Methodology is to support GitLab in categorizing logs based on their effect on GitLab's SaaS subscriptions and the achievement of GitLab's mission and goals. Ultimately, this provides GitLab with a mechanism to take a proactive approach to comprehensive risk management which considers risks, such as information security and privacy risks, impacting business operations across the organization. Additionally, by classifying logging into specific tiers, GitLab will be in a better position to appropriately prioritize risk mitigation activities and tailor internal controls based on a log's related tier.
The Critical Logging tiering methodology is applicable to all systems utilized across GitLab which are tracked within the Tech Stack to ensure that all systems are vetted completely and accurately using a consistent and standardized methodology.
| Role | Responsibility |
|---|---|
| Security Logging Team | Executes an annual review of Critical Logging tiers and makes adjustments as necessary. Owns the Critical Logging Tiering Methodology and supports the identification of and assignment of a Critical Logging tier as needed. |
| SIRT | Supports defining of Critical Logging tier in conjunction with the Security Logging Team when new systems are added to the tech stack. |
| AppSec | Supports defining of Critical Logging tier in conjunction with the Security Logging Team when new systems are added to the tech stack. |
| InfraSec | Supports defining of Critical Logging tier in conjunction with the Security Logging Team when new systems are added to the tech stack. |
| Technical System Owners | Provide complete and accurate data about the systems that they own so that an accurate tier is assigned. |
Defining what Critical Logging means at GitLab can be complex given the nature of our environment and the amount of integrations that exist across the many systems that are used to carry out business activities. As part of Gitlab's Business Impact Analysis (BIA) process, we obtain inputs that assist in the assignment of a critical system tier per system. These inputs used to determine system criticality tiers include, but are not limited to, the following:
Once the information is obtained, it is reviewed by the Security Risk and/or IT Compliance Team to determine which system tier should be assigned to the system.
Then the Security Logging Team with the support of SIRT/AppSec/InfraSec takes the output of the findings above and applies the guidelines described below in Determining Critical Logging Tiers to each log source.
Systems are assigned a Critical Logging tier based on the following matrix:
| Critical Logging Tier (CST) * | CST Description | Example | Previous CST Tier Mapping |
| Tier 1 Mission Critical** | Systems that have an immediate and significant impact to the security of GitLab and/or contains [red](https://about.gitlab.com/handbook/security/data-classification-standard.html#red) [customer data](https://about.gitlab.com/handbook/security/data-classification-standard.html#data-classification-definitions). | Cloudflare, GitLab.com, Teleport | Tier 1 Product |
| Tier 2 Business Critical*** | Systems that have an immediate and significant impact to critical business functions and customer service and/or contain [orange data](https://about.gitlab.com/handbook/security/data-classification-standard.html#orange). | customers.gitlab.com/subscription, Netsuite, Salesforce | Tier 1 Business and Tier 2 Core |
| Tier 3 Business Operational | Disruption affects operational business functions, negatively impacting efficiency/cost of operation across departments and/or systems contain [yellow data](https://about.gitlab.com/handbook/security/data-classification-standard.html#yellow) | Clearwater, PagerDuty, ZenGRC | Combination of Tier 2 Support and Tier 3 Non-critical and influenced by responses to BIA |
| Tier 4 Administrative | Affects GitLab team members only at an individual level (e.g., quality of life, individual productivity) | Donut, Jetbrains, LinkedIn Learning, Modern Health | Combination of Tier 2 Support and Tier 3 Non-critical and influenced by responses to BIA |
Notes
* As an extension of tiering methodology, the Data Classification Standard prescribes specific Security and Privacy control requirements for each data classification level. These requirements should be followed based on a system's data classification, regardless of the system's tier.
** By default, any system that contains RED Data per the Data Classification Standard OR is a Third Party Sub-Processor will be a Tier 1 Mission Critical system. This is due to the fact that this data is customer owned and uploaded and as such, has been deemed to be mission critical in nature.
*** By default, any system in-scope for SOX will be a Tier 2 Business Critical system, at minimum.
Tiering systems utilized across GitLab enables team members to make decisions on prioritizing work related to a specific system(s) based on the assigned tier. As an example, if multiple risks have been identified over a wide variety of systems and require remediation, impacted team members can leverage the assigned Critical Logging tiers to make a decision on how to prioritize remediation activities. This methodology will also provide GitLab with a mechanism to easily identify those systems which are most critical across the organization so that we can proactively protect, log and secure those systems.
A Critical Logging assessment is performed on an annual cadence in alignment with the StORM annual risk assessment process to validate existing systems in GitLab’s environment and make adjustments to assigned tiers accordingly. A system's assigned tier can be found in the tech_stack.yml file. A systems logging inventory can be found in the SecLogging Inventory Repository
Systems that are exempt from this methodology include any system which carries a data classification of Green. All remaining systems which store or process YELLOW, ORANGE, or RED data are required to have a Critical Logging tier assigned. Data classification will be validated to corroborate that the data stored or processed by the system is truly Green data, per the Data Classification Standard.
