セキュリティインシデント重大度マトリクス
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.目的
本ドキュメントの目的は、セキュリティインシデントを重大度に基づいて分類するための標準化されたフレームワークを確立することです。この分類システムにより、セキュリティインシデントレスポンスチーム (SIRT) は適切に対応し、リソースを効果的に割り当て、組織全体でインシデントに関する一貫したコミュニケーションを確保できます。
スコープ
本ドキュメントは、GitLab のインフラストラクチャ、サービス、アプリケーション、データに影響を与えるすべてのセキュリティインシデントに適用されます。SIRT はインシデントの重大度を評価する際に本ドキュメントで定義された基準を使用し、エスカレーション手順については SIRT エスカレーションガイド を参照します。
役割と責任
| 役割 | 責任 |
|---|---|
| GitLab チームメンバー | 本手続きの要件に従う責任 |
| SIRT | 本手続きの実装および実行の責任 |
| SIRT 経営層 (Code Owners) | 本手続きの重要な変更および例外の承認の責任 |
手続き
重大度
severity ラベルは、セキュリティインシデントの実際または潜在的な影響を示すために使用されます。このラベルは、必要なレスポンスの緊急性、コミュニケーション計画、リソース割り当てを判断するための唯一の情報源です。重大度は初期トリアージ時に設定する必要があり、調整できません。
GitLab は重大度の判断のために以下の全社的なマトリクスを使用します。
| 重大度 | 影響 | GitLab のレスポンス | 例 |
|---|---|---|---|
| Severity:1 Critical | 顧客への影響: ユーザーへの非常に高い影響: 彼らの顧客またはビジネスアウトプットに影響が及ぶ または GitLab への影響: ビジネスへの確実なまたは深刻なダメージ | 即時の総力レスポンス | - 顧客向けサービスがダウンしている - 確認されたデータ侵害または red/orange データの露出 - 顧客データの損失 - GitLab のプラットフォームまたはサプライチェーンへの低複雑度で検証済みのエクスプロイトシナリオ - アクティブに悪用されている、または未パッチで到達可能、悪用テレメトリのない Critical RCE - 公的な露出 (報道、顧客、研究者による 0-day) のある Critical 脆弱性 - 外部のアクターが高権限の GitLab サービスアカウントを制御している |
| Severity:2 High | 顧客への影響: ユーザーへの大きな影響: 彼らの内部運用が混乱する または GitLab への影響: ビジネスへの可能性のあるまたは高まったダメージ | リソースの割り当て、クロスチームの調整、定期的なステークホルダー更新 | - 顧客向けサービスが一部の顧客に対して利用できない - コア機能性が大きく影響を受けている - アカウント侵害またはインサイダー脅威の動機と知識を必要とする権限昇格シナリオ - 悪用の証拠がある、または高い報道注目のある High 重大度脆弱性 - センシティブな GitLab システムへの不正アクセスの疑い - GitLab のクラウドインフラストラクチャでのマルウェア検知 |
| Severity:3 Medium | 顧客への影響: ユーザーへの中程度の影響: 彼らの内部運用が妨げられる可能性がある または GitLab への影響: ビジネスへの可能性が低いまたは軽度のダメージ | 通常の運用手順を超えて対処するためにリソースが転用される | - わずかなパフォーマンス低下 - 重要でない機能が最適に動作していない - 重要でないシステムでのコモディティマルウェア検知 |
| Severity:4 Low | 顧客への影響:: ユーザーへの低い影響: 彼らの内部運用が変更される可能性がある または GitLab への影響: ビジネスへの最小限のダメージ | 標準手順に従って Issue が解決される | - 顧客への不便、回避策がある - 使用可能なパフォーマンス低下 - red/orange データに影響を与えない GitLab セキュリティポリシー違反 |
重大度を判断する際の考慮事項
影響を判断するときに考慮する要因がいくつかあります。セキュリティインシデントに直面するたびに、リスクの範囲と露出、機密性レベル等を評価します。そうすることで、Issue を複数のより評価しやすいサブ Issue に分割します。以下にいくつかの例を示します。
CIA トライアドの以下のどの領域が該当しますか?
- 機密性 (Confidentiality)
- 完全性 (Integrity)
- 可用性 (Availability)
影響を受けたサーフェス - 影響を受けたサーフェスは何ですか?
- GitLab インフラストラクチャ
- 顧客データ
- クラウドアカウント
- 特定の 1 つのアプリケーション
- 顧客のインスタンス
- 自分のマシン
- GitLab Critical Security Control Systems (IDS/IPS、MDM、EDR、CDR、IAM、SIEM、ネットワークセキュリティシステム、変更検出メカニズム、監査ロギングメカニズム、自動化セキュリティテストツール、セグメンテーションコントロール)
悪用可能性 (Exploitability) - Issue を悪用するのはどのくらい簡単ですか?
- 非常に簡単 - 攻撃者は単にコマンドまたはスクリプトを実行するだけで Issue をトリガーできます。
- ある程度の労力を必要とする - 攻撃者は Issue を悪用するために、他の誰かがログインしているなどの特定の条件を必要とします。
- 困難 - 攻撃者は達成が困難な特定の条件を必要とします。
可視性 (Visibility) - 誰がこの Issue を見ることができますか?
- 全員
- 特定のアクセス権を持つ人
- 自分だけ
該当する CIA トライアドの領域が多いほど、また 影響を受けたサーフェス、悪用可能性、可視性 の重要性と組み合わせて、推定 重大度 を判断する必要があります。
例外
本手続きの例外は、情報セキュリティポリシー例外管理プロセス に従って追跡されます。
参考文献
bfd74782)