セキュリティ第三者リスク管理

GitLab の統合 Third-Party Risk Management プログラム

GitLab は、自動化、継続的なモニタリング、およびビジネス機能全体にわたる深い統合を活用して、外部関係者と共有される GitLab データのセキュリティを検証する、業界をリードする Third Party Risk Management (TPRM) Program を維持しています。

ベンダー調達フロー内に GitLab の TPRM プログラムを統合することで、Privacy、Legal、IT、People Operations 間の機能横断的な コラボレーション を可能にし、透明性のある リスクベースの意思決定、ビジネスおよびステークホルダーに焦点を当てた Results、そして GitLab の規制および Compliance Obligations の遵守を促進します。このプログラムを通じて維持されるベンダー関係は、組織全体で効率を生み出すために活用されます。

範囲

この手順は、GitLab データにアクセス、保管、処理、または送信するすべてのサードパーティプロバイダーに適用されます。

目的

GitLab の Security Third Party Risk Management (TPRM) プログラムは、GitLab またはお客様のデータにアクセスできるサードパーティから引き起こされるセキュリティ脅威に対する保護を支援します。これらのリスクには、データ侵害、不正使用または開示、データの破損または喪失が含まれる可能性があります。適切な TPRM は、セキュリティの懸念を軽減 し、GitLab が契約上の義務を満たすことを可能にするベストプラクティスです。TPRM はまた、GitLab が ISO、SOX、GDPR、およびベンダー監視を必要とするその他の州法および連邦法に関連する規制要件と標準を満たすことを可能にします。

GitLab の Security TPRM プログラムは、Procurement プロセスに統合された 3 つのコンポーネントを含んでいます。

1. サードパーティがデータプライバシーとセキュリティを実施する保護策を実装することを保証するためのデューデリジェンスの実施
   • この活動は、私たちの Security Assessment Process を通じて実行されます。私たちの TPRM Assessment Report テンプレートのオープンソース版は、Open Source Security Hub で見つけることができます。
2. これらの保護策を実装することをサードパーティに 契約上 義務付ける
3. サードパーティの保護策と契約された規定の遵守をモニタリングする
   • 高リスクの特定のサードパーティは年次でレビューされ、低リスクのものはこの文書内でさらに定義された間隔でレビューされます。

役割と責任

オンコールローテーション

TPRM エンジニアは、ベンダーの取り込みと TPRM の問い合わせを管理するために週単位でオンコール業務に割り当てられます。チームメンバーは、緊急の問い合わせのために Slack または GitLab Issue 内でオンコールエンジニアをタグ付けすることをお勧めします。オンコールカレンダーは こちら で見つけることができます。

サポート

即時対応が必要な緊急の要求や TPRM の懸念事項については、Slack の #security_help チャンネルに連絡してください。

よくある質問

何が TPRM Assessment をトリガーしますか?

Security Risk は、コンプライアンスを維持し、適切な監視を確保するために、さまざまなインプットをモニタリングしています。TPRM アセスメントは、特に指定されない限り通常 12 か月間有効で、次のシナリオでトリガーされます。

• 新規ベンダーエンゲージメント: Orange または Red データ にアクセスする新しいベンダーまたはシステムは、承認前に TPRM レビューを必要とします。
• ベンダーの更新: 最新のアセスメントが期限切れの場合、ベンダーの更新は承認前に TPRM アセスメントを必要とする場合があります。
• サービスの変更: 既存ベンダーからの新しいサービスや機能は、以前のアセスメントでカバーされていないリスクを導入する可能性があります。
• セキュリティインシデント: ベンダーが GitLab データに影響する可能性のあるセキュリティインシデントを被った場合、Technical Security Validation と共にアセスメントがトリガーされる可能性があります。
• システムの統合: 新規または既存システム間の統合、特に高機密性データを処理するものは、アセスメントを必要とする場合があります。詳細については システムの統合 を参照してください。
• 年次の高リスクレビュー: コンプライアンステスト（SOC 2、SOX など）の対象範囲のベンダー、GitLab Sub-Processors、その他 Red データを処理するベンダーは、コンプライアンス義務を満たすために年次でレビューされます。

ベンダー選定のためのセキュリティ考慮事項

セキュリティは GitLab のベンダー選定プロセスにおける最優先事項であり、GitLab は機密データの保護を優先し、堅牢なセキュリティ対策を維持するベンダーとパートナーシップを結ぶことに尽力しています。そのため、Security Risk は、業界標準への遵守、関連規制へのコンプライアンス、Bitsight セキュリティレーティングの健全性を含む、各ベンダーのセキュリティ慣行を徹底的に評価します。GitLab の目的は、GitLab のデータを保護し、ステークホルダーの信頼を維持するために、セキュリティの最高基準を維持することへのコミットメントを共有するベンダーとパートナーシップを確立することです。以下は、Security Risk がさまざまなタイプのベンダーをどのように評価するかの例と、購買決定を行う際にベンダーを審査するための推奨事項です。

TPRM Assessment Requirements

次の表は、異なる GitLab データの分類 にアクセスまたは送信されるベンダーに対して TPRM エンジニアが従う手順を定義しています。以下の手順は、Procurement プロセス中に開始され、該当するベンダーが以下に定義された承認ウィンドウ内でレビューされていない場合のすべてのインスタンスで従われます。TPRM の Minimum Security Standards との不整合は、ベンダー要求の拒否や Security Notice の発行につながる可能性があります。 前回のアセスメント時に Security Notice が文書化された場合、要求承認の前に、特定された不備の現在のステータスを判定するために問い合わせが行われます。不備の性質に応じて、新しい TPRM アセスメントが必要になる場合があります。更新は Security Notice Issue 内に文書化されます。

GitLab の機密性の高いデータを収集および保管するために Web 対応のアプリケーションを利用するプロフェッショナルサービスベンダーは、一般的に Orange SaaS システムとして扱われます。

手順

GitLab がデータを管理、所有、その他の責任を負う場合、以下の図は、サードパーティと共有されるデータの Data Classification に基づく TPRM 手順を示しています。

graph TB
    %% Procurement Intake
        ProcIntake[Purchase Request Created]

    %% Data Classification
        zgClass{Data Classification}
            zgLow[Low Risk<br>Green / Yellow]:::Green
            zgElevated[Elevated Risk<br>Orange / Red]:::Orange

    %% Elevated Risk Path
        zgAssess[Security Assessment Completed]
        %% Note: assessment repeats internally until GitLab standards are met before proceeding
        zgMeets{Meets GitLab Standards?}
        zgOwnerDecision{Security Notice Issued <br> to Business Owner}
            zgStop[Requisition Denied]

    %% Approvals
        zgApproveLow[Security Approves]:::Green
        zgApproveElevated[Security Approves]:::Green

    %% PIC - Elevated Risk, New Systems Only
        zgPIC[Post-Implementation Checklist Initiated]:::PIC

    %% Linking nodes together
        ProcIntake --> zgClass
        zgClass --> zgLow
        zgClass --> zgElevated

        zgLow --> zgApproveLow

        zgElevated --> zgAssess --> zgMeets
        zgMeets -->|Yes| zgApproveElevated
        zgMeets -->|No| zgOwnerDecision
            zgOwnerDecision -->|Accepts risk| zgApproveElevated
            zgOwnerDecision -->|Declines| zgStop

        zgApproveElevated -->|New system| zgPIC

    %% Clickable Nodes
        click ProcIntake "https://handbook.gitlab.com/handbook/business-technology/enterprise-applications/guides/zip-guide/#how-to-initiate-a-new-request" _blank
        click zgPIC "https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/third-party-vendor-security-management/-/blob/6e728f5d0ee7f6f6f6e2d8c13fa7bdca6b67e3b3/.gitlab/issue_templates/Post-Implementation%20Checklist.md" _blank

    %% Dedicated styling
        classDef Green fill:#A3CC6C,stroke:#A3CC6C,color:#000000;
        classDef Orange fill:#FFA500,stroke:#FFA500,color:#000000;
        classDef PIC fill:#D65DB1,stroke:#D65DB1,color:#FFFFFF;

ベンダーの固有および残留リスクの判定

TPRM 手順は、提供されるサービスと共有されるデータの性質に基づいて判定されるベンダーの固有および残留リスクレベルによって導かれます。これらのリスクの理解は、ベンダーを活用するための情報に基づくビジネス意思決定を行う上で重要です。

固有リスク (Inherent Risk) は、GitLab の Third Party Risk Management Program で要求される軽減コントロールを考慮する前のベンダーのベースラインリスクレベルです。GitLab は ベンダーと交換されるデータの機密性 を使用してベースラインリスクレベルを確立し、これにより TPRM アセスメント要件 を決定します。

1. クラウドサービス（SaaS 提供など）を提供するベンダーエンゲージメントに関連するリスクの増加により、これらのタイプのサービスに関連する新たな脅威と脆弱性を考慮するために固有リスクレベルが引き上げられています。
2. Orange Individual-Use Software は、これらのタイプのリクエストに関連するリスクの低減により、削減された範囲の下で中程度の固有リスクとしてアセスメントされます。詳細なガイダンスについては こちら を参照してください。

残留リスク (Residual Risk) は、GitLab の Third Party Risk Management Program で要求される軽減コントロールを考慮した後に残るリスクのレベルです。ベンダーの残留リスクを効果的に管理するには、ベンダーのサービスや製品の重要性、関与するデータの機密性、そして GitLab のリスク許容度を考慮するバランスのとれたアプローチが必要です。

GitLab のセキュリティ要件を満たすベンダーは、以下のような残留リスクレベルを持ちます。

GitLab の Third Party Risk Assessment 要件を満たさないベンダーには、Security Notice が必要になります。

Third Party Minimum Security Standards

TPRM は、サードパーティをアセスメントする際にリスクベースのアプローチを利用しています。異なるベンダータイプ/リスクプロファイルをアセスメントするために使用される特定の手順は、上記の TPRM Assessment Requirements セクションで確認できます。

Security Risk Team は、ベンダーと協力し、私たちのレビューを完了するために必要なドキュメンテーションを取得するために合理的なステップを踏みます。提供されるサービスと送信されるデータに応じて、これにはサードパーティセキュリティ証明とペネトレーションテストの概要などの他の関連ドキュメンテーションのリクエストが含まれる場合があります。ベンダーがこのドキュメンテーションを維持していない、または提供を拒否した場合、Security Risk チームはリクエストを拒否したり、承認前に TPRM Security Notice の完了を必要としたりする場合があります。

私たちの TPRM 手順中に一般的に特定される不備を以下にリストします。

1. ISO 27001、SOC 2 Type 2 などのサードパーティセキュリティ証明の欠如
2. 従業員と請負業者のバックグラウンドチェックの欠如
3. Okta との統合不可*（GitLab の Password Standard との整合）
   • Okta 統合が整備されていない、または不可能な場合、ネイティブの多要素認証 (MFA) 機能が軽減コントロールになり得ます。これは、関連する要求を承認する前に、サインオフのために CorpSec にエスカレーションすべきです。
4. 最近のペネトレーションテストの証拠を欠いているシステム
5. 明らかな是正計画または予想される是正日のない、解決されていない High および/または Critical のペネトレーションテストの所見
   • ペネトレーションテストの所見は、不備の性質と GitLab への影響を理解するためにエンジニアによってレビューされます。GitLab への影響が無視できる、または既存の GitLab コントロールによって十分に軽減されている不備は、不利な結論にならない場合があります。

特定された不備は、ベンダーの広範なセキュリティ環境と送信されるデータの文脈の中でレビューされます。GitLab データに対する重大なリスクが特定された場合、これは TPRM Security Notice Process を通じて Business Owner に報告されます。

受け入れ可能なサードパーティ証明

GitLab は、サービスプロバイダーの内部統制環境の設計および運用上の有効性に対する保証を提供するために、サードパーティ証明を取得およびレビューします。これらの証明には、ISO 27001 認証や SOC (Service Organization Control) 2 Type 2 レポートが一般的に含まれますが、これらに限定されません。これらのより一般的なドキュメントがない場合、代替形式の証明を活用できますが、その証明がコントロール環境を十分にカバーしており、私たちのアセスメント基準と整合しているかどうかを判定する際にアセッサーによってデューデリジェンスが行われるべきです。

ISO 27001: ISO 27001 認証と、付随する Information Security Management System (ISMS) の範囲、および Statement of Applicability (SoA) は、業界標準のセキュリティベストプラクティスへのコンプライアンスの証拠として活用できます。ISMS の範囲は、ベンダーから GitLab に提供されるサービスが ISO 監査によってカバーされていることを保証するのに役立ち、SoA は組織によって適用されているポリシーとコントロールへの可視性を提供します。該当するサービスをカバーする有効な ISO 27001 認証は、外部の認証機関が、経営チームの以下の継続的な実行に関連するコントロールの設計と運用上の有効性を検証するためにテストを実行したことを示します。

• 脅威、脆弱性、影響を考慮した、組織の情報セキュリティリスクの体系的な検査；
• 受け入れ不可能とみなされるリスクに対処するための、首尾一貫した包括的な情報セキュリティコントロールおよび/またはその他の形式のリスク治療（リスク回避やリスク移転など）の設計と実装；そして、
• 情報セキュリティコントロールが組織の情報セキュリティニーズを継続的に満たし続けることを保証するための、包括的な管理プロセスの採用。(Source)

ベンダーが有効な ISO 27001 認証を提供しているが、SoA を提供できない場合、私たちのアセスメント基準を満たし、彼らのセキュリティ環境のより良い理解を得るために、SIG や CAIQ などの自己証明の完成を要求します。

ISO 27001 認証には有効期限が含まれていることに注意してください。この日付を過ぎると、認証はもはや有効ではなく、私たちのアセスメントで活用すべきではありません。

SOC 2 Type 2: SOC 2 Type 2 レポートは、サードパーティリスクをアセスメントする際に好まれる証明です。なぜなら、このレポートは組織の情報システムの設計と、さまざまな形式のリスクがどのように対処されているかを詳述するためです。このレポートは、組織内の整備されたコントロールを詳述するだけでなく、それらのコントロールのそれぞれが監査期間中に効果的に機能したかどうかの独立した検証も含まれています。このレポートは、以下を検証するためにレビューされるべきです。

• レポートが、GitLab に提供されているサービスをカバーしている；
• レポートが過去 12 か月以内に発行されている；
  • 最新のレポートが 12 か月以上古い場合、ブリッジレターを取得して、レポートの発行以来ベンダーのコントロール環境に重大な変更が発生していないことを保証する必要があります。
• レポートが、GitLab データのセキュリティに影響する条件付き意見や例外なしに発行されている。
  • 「条件付き」と指定されたレポートは、評価された 1 つ以上のコントロールが監査期間中に不十分に設計または実装されていることが判明したことを示します。条件付きの性質は、コントロールの失敗が GitLab データのセキュリティに影響を与える可能性があるかどうかを判定するためにレビューおよび理解されるべきであり、影響を与える場合は TPRM Security Notice を通じて Business Owner に報告されるべきです。
  • レポート内で、条件付き意見の発行につながらない例外が特定される場合がありますが、それらが GitLab データにリスクを呈する可能性があるかどうかを判定するために、いずれの例外も以下についてレビューされるべきです。
    • 例外の性質: 関連するコントロールと例外自体は、GitLab がそのコントロールに依存して私たちのデータを保護しているかどうかを判定するためにレビューされるべきです。
    • 経営の対応: 例外の理由とそれに対処および是正するためにとられたステップを扱うために、経営の対応がしばしば含まれます。これは、是正が成功したことを検証するために外部監査人によって実施される再テストを伴う場合があります。
  • これらの項目は、存在する場合、TPRM Assessment Report 内に記録されるべきです。条件付きまたは例外の性質が GitLab のセキュリティに影響することが判明し、経営の対応が是正ステップがとられたという十分な保証を提供しない場合、これは TPRM Security Notice Process を通じて Business Owner に報告されるべきです。

SOC 2 Type 1: SOC 2 Type 1 レポートは、SOC 2 Type 2「準備状況」プロセス中の予備的なアセスメントの一環としてしばしば公開されます。これは、サービスプロバイダーの環境内で整備されているコントロールの設計の限定的なスコープ、ある時点でのアセスメントであり、コントロール運用上の有効性の検証は含まれません。そのため、Type 1 レポートは、Orange SaaS / Red システムに対する私たちのサードパーティ証明要件を扱うために単独で活用すべきではありません。ただし、サービスプロバイダーの環境に対する保証を提供するために、ISO 27001 認証または同等の証明に追加して活用できます。

PCI Attestation of Compliance: PCI Attestation of Compliance (AoC) は、サービスプロバイダーの PCI DSS フレームワークへのコンプライアンスを検証するために、Security Compliance Team によって活用されます。この証明は、付随する Responsibility Matrix と共に、GitLab インフラストラクチャをホスティングするベンダーに対して一般的に必要とされます。Security Risk チームは、Security Compliance のリクエストにより必要に応じてこのドキュメンテーションを収集します。PCI AoC は、Security Risk が TPRM Assessment Requirements を満たすために 活用されません。

Complementary User Entity Controls (CUECs)

一部のベンダーのコントロール目的は、GitLab によるサポートコントロールの適切な設計と実装なしには達成できず、これらはベンダーの SOC 2 レポート内で Complementary User Entity Controls (CUEC) の形で指定されます。CUEC は、データセキュリティとサービスコミットメントをサポートするためにベンダーによって一般的に活用されており、データセキュリティをサポートし、不正なデータ開示を防止するためにこれらのコントロールに対処するのは GitLab の責任です。

Security Risk チームは、私たちのレビュー中にベンダーの SOC 2 レポートを取得し、CUEC が定義され、ベンダーによって依存されているかどうかを判定します。CUEC が定義されている場合、Business Owner は Zip 要求の承認時に通知され、CUEC をレビューし、それらに対処するためのコントロールが整備されていることを確認するように指示されます。コントロールがまだ整備されていない場合、Business Owner はこれらのコントロールの実装を調整する責任があります。これは Security Assurance チームと協力して完了することができます。私たちはあなたの主要な GitLab プロジェクトで Application/Service Name CUEC Mapping というタイトルの Epic を作成することを推奨します。アクションが必要な各 CUEC に対して Issue を作成すべきです。Issue は、必要に応じてコントロールが定期的に行われることを保証するメカニズムを含む、文書化された計画またはプロセスが整備されたら、理想的にはハンドブック内でクローズされるべきです。一般的な CUEC と各々のガイダンスは以下の表で確認できます。ベンダーの SOC レポートで定義された具体的な言語は以下の言語と異なる場合があり、修正された行動方針が必要になる場合があることに注意してください。

CUEC に関する質問は、Slack の #security_help チャンネルに直接送ることができます。

Standard Information Gathering (SIG) Questionnaire for Vendor Self Attestation

SIG questionnaire や CAIQ などの同等のドキュメントなどの自己証明は、個別利用ソフトウェアベンダーが有効な SOC 2 Type 2 レポートまたは ISO 27001 認証および Statement of Applicability を提供できない場合に必要です。Red ベンダーまたは Orange SaaS ベンダーは、上記で定義された Third-Party Attestation を提供する必要があります。SIG questionnaire は、サービス組織のセキュリティ環境の成熟度をアセスメントする際に、私たちの Security Questionnaire への回答と並行してレビューされます。

Security Risk は、評価される製品やサービスに応じて使用するための SIG questionnaire の複数のテンプレート版を維持しています。一部のベンダーは提供する SIG questionnaire や同等のものを持っていない場合があります。SIG テンプレートには、メインアンケートタブの列 D と E 内の Inquiry 回答のみが必要であるという指示が含まれており、SIG 内の追加の情報やドキュメンテーションのリクエストは一般的に必要ありません。専門的な裁量により、ベンダーの回答を補完するために追加のドキュメンテーションリクエストの必要性が指示される可能性のある潜在的なフリンジケースが存在する 可能性があります。さらに、どのバージョンの SIG questionnaire が送信されるべきかを決定する際には、専門的な裁量を適用すべきです。レビューに必要なレベルが不明な場合、エンジニアは #Sec-Assurance-Team チャンネル内の @Security-Risk チームと相談し、提供されるサービス、交換されるデータ、以前のアセスメントの結果などの要因を考慮した上で意思決定を行うことが奨励されています。

Bitsight の活用

Bitsight の使用は、Security Risk チームに GitLab のベンダーエコシステムの外部セキュリティポスチャーの包括的かつ継続的なビューを提供します。Bitsight は、Security Risk が私たちのベンダー全体にわたる潜在的なセキュリティリスクをリアルタイムで特定およびアセスメントすることを可能にし、私たちのリソースを優先順位付けし、GitLab に影響を与える可能性のある重大な脆弱性に対処することに焦点を当てることができます。GitLab は 2 つのサービスを活用しています。

• Bitsight Total Risk Monitoring

Bitsight の Total Risk Monitoring は、公開スキャンとピアベンチマーキングの使用により、ベンダーの外部からアクセス可能な環境のセキュリティに対する追加の保証を取得するために活用されます。ベンダーをアセスメントする際、彼らの Bitsight レポートはダウンロードされ、彼らのスコアリングが「Advanced」セキュリティレーティングによって証明されるように適切であるかどうかを判定するためにレビューされます。「Basic」または「Intermediate」の Bitsight レーティングは、低いレーティングの背後にある根拠と特定された不備が GitLab に対するリスクを示す可能性があるかどうかを理解するためにさらに詳細にレビューされます。Bitsight のスキャンの広い範囲のため、一部の不備は GitLab のベンダーサービスの使用に影響しない領域内に存在する可能性があり、したがってベンダーの残留リスクに寄与しません。GitLab に重大なリスクを呈する可能性のある不備が特定された場合、それらが解決されたかどうかを判定するためにベンダーとさらなる問い合わせが行われる可能性があります。解決されていない重大な不備は、TPRM Assessment Report 内に文書化され、以下に定義されている TPRM Security Notice Process を通じて Business Owner に報告されるべきです。

ベンダーがレビュー時に BitSight 内に存在しない場合、アセッサーは Company Request を提出 すべきです。

• Bitsight Daily Alerting

Bitsight の Daily Alerting は、潜在的なリスクと脆弱性を迅速に特定および対応するために、GitLab の最高重要性のベンダーのセキュリティポスチャーを継続的にモニタリングするシステムを確立するために活用されます。このサービスの使用は、Security Risk が GitLab の機密性の高いデータとインフラストラクチャを効果的に保護するのに役立つ 24 時間 365 日体制で運営される、サードパーティセキュリティ管理に対するプロアクティブなアプローチを維持することを可能にします。GitLab の Tier 1 ベンダーの環境内の変化は、深刻度と GitLab への影響に応じて、さらなるセキュリティ問い合わせと調査、新しいセキュリティレビュー、または TPRM Security Notice につながる可能性があります。

TPRM 承認ウィンドウ

Security Risk チームは、私たちの TPRM アセスメントのライフサイクルと要求の承認における依存関係を決定する承認ウィンドウを確立しており、その後、GitLab の規制およびデューデリジェンス要件への継続的な遵守を確保するために、後続の要求の承認の前に新しいアセスメントを完了する必要があります。これらのウィンドウは、要求の性質、共有されるデータの機密性、Critical System Tier との整合で定義されています。

プロフェッショナルサービスプロバイダー、または Red データにアクセスするベンダーは、私たちの Tier 1 ミッションクリティカル要件と整合してアセスメントされます。Orange データへのアクセスを持つプロバイダーは、私たちの Tier 3 ビジネスオペレーショナル要件と整合してアセスメントされます。

要求は、ベンダーに送信されるデータに重大な変更を示す可能性のあるスコープ変更が以前のアセスメント以来発生したかどうかを判定するためにレビューされる必要があります。ガイダンスについては Material Changes セクションを参照してください。

重大な変更

GitLab に提供されるサービスやベンダーのセキュリティ環境への重大な変更は、以前のレビュー時には存在しなかったリスクの増加を呈する可能性があります。そのため、以前のアセスメントの 承認ウィンドウ 内のベンダーに対する要求は、提供されるサービスに重大な変更が発生したかどうかを判定するために TPRM Engineer によってレビューされる必要があります。これらの変更の例には次のものが含まれます。

1. データ分類の変更、たとえば Yellow から Orange のデータ分類に変わる。
2. 以前のレビューの範囲にない新しいシステムの追加。 たとえば、ベンダー XYZ は Billing システムの調達のためにレビューされましたが、彼らの Revenue システムの購入のための新しいリクエストが入った。
3. データが保管または送信される場所の変更、たとえば GitLab がホストする環境からベンダーの SaaS ソリューションへのデータ移行。
4. ベンダーのセキュリティコントロールの対象ではない新しい請負業者の追加。
5. 新しい sub-processor の追加につながるシステム内の新しい AI 機能の導入。

以前のレビューが新しいサービスやシステムに対する保証を提供しているかどうかを判定するために、以前に活用されたドキュメンテーションをカバレッジについてレビューするか、ベンダーに直接質問してください。十分な保証が存在しない場合、または変更が GitLab に追加リスクを導入すると考えられる場合、Security Risk チームは要求を承認する前に新しい TPRM レビューを完了する必要がある場合があります。

ベンダーは、新しい AI 機能や subservice provider の導入など、契約サイクル間に以前に特定されていなかったリスクを導入する可能性のある変更を実装することがあります。チームメンバーは、これらの変更が発生したときに Security Risk チームに通知すべきです。必要に応じて、新しいアセスメントが完了するまで、そのような機能を許可、利用、または有効にしないように指示される場合があります。そのような変更の通知時に、Security Risk チームは上記の手順に従って新しいレビューが必要かどうかを判定します。

注: 上記で定義されている以外の状況が、さらなるレビューを必要とする可能性があります。TPRM Engineer は、これらの状況を特定する際に専門的な裁量を使用し、必要に応じて追加のレビューや検証を実行すべきです。変更の重要性や適切な承認ウィンドウに関する質問や懸念事項は、#Sec-Assurance-Team チャンネル内の Security Risk チームにエスカレーションすべきです。

TPRM Security Notice Process

TPRM レビュー中に特定された不備は、GitLab 内の TPRM Security Notice を通じて Business Owner に報告されます。この Issue には、(1) ベンダーまたは要求に関連する背景情報、(2) Security Risk チームによって実行された検証の説明、(3) ベンダーと共有される GitLab データに存在する可能性のあるセキュリティ不備と結果として生じるリスクの説明が含まれています。リスクから結果として生じるセキュリティインシデントの潜在的な実世界の影響を表現するために、「最悪の場合」のシナリオが含まれています。可能な場合、TPRM は特定されたリスクを軽減または回避するための推奨事項も含めます。システムのセキュリティコントロールの設計または運用上の有効性の失敗から生じる不備については、Security Notice 内でより大きな文脈を提供するために、ステークホルダーへの配信前に Technical Security Validation が要求される場合があります。これらの項目は、Business Owner と他の関連関係者による情報に基づく意思決定をサポートするために文書化されます。

要求の拒否

TPRM は、ベンダーのセキュリティ環境に対する十分な保証を取得できない場合、または GitLab データやサービス提供に対する活発なリスクを呈する不備がある場合に、要求を拒否する場合があります。

私たちの最低セキュリティ要件を満たさない新しいベンダーは、Security によって拒否される可能性があります。見込みベンダーが私たちの要件を満たさない可能性があるという懸念がある場合は、Slack で @securityrisk に連絡してください。

私たちの最低セキュリティ標準を満たさない既存のベンダーは、要求の承認の前にオフボーディング計画またはベンダーと合意された是正計画の文書化を必要とする場合があります。Security Notice は以下に文書化されているように承認のためにルーティングされます。

TPRM は、彼らの環境が変化する可能性があり、私たちの要件を満たすように成熟する可能性があるため、拒否されたサードパーティのリストを維持していません。以前のアセスメント結果は文書化されており、リクエストに応じて利用可能です。

リスクの受け入れ

ビジネス要件によりベンダーと進む必要があるという状況が発生する場合があります。これらのシナリオでは、Business Owner と他の関連ステークホルダーは、ビジネス運営に悪影響を与えないように、文書化されたリスクを受け入れることを選択する場合があります。 Security Risk は、利用可能な情報に基づいてこれが正当化されるかどうかについての意見を提供します。Business Owner が報告された不備に照らしてベンダーと進むことを決定した場合、彼らは以下の項目の完了に責任を負います。

1. StORM ハンドブックページの Accept the Risk セクションの 承認 とその内容の理解。
2. 特定された不備に照らしてベンダーと進む 正当化。
3. 特定された不備に対処するための 是正計画。これは時間制約付きで、セキュリティ所見を解決するために必要なすべてのステップを含む必要があります。次回の更新前に所見を是正できない場合、E-Group エスカレーションになる可能性があります。
4. リスクが是正されていない場合の 年次再認証。これは、関連ステークホルダーからの関連承認とともに、ベンダーまたはシステムの新しいアセスメントをトリガーします。
5. Security Notice の 承認。組織全体での透明性を促進するために、不備の認識される深刻度に基づいて Security Risk チームによって必要と判断された場合、Business Owner、彼らの VP、IT、適切な E-Group メンバーによる承認が必要となります。

一部の状況では、ビジネスはセキュリティレビューの完了前に要求の迅速な承認を必要とする場合があります。これらのシナリオでは、TPRM Security Notice が文書化され、Business Owner と彼らの VP に提示されます。承認後の合理的なタイムライン内に必要な資料を取得できない場合、E-Group へのリスクのエスカレーションになる可能性があります。

Technical Security Validations

TPRM は GitLab の Security Research チーム と提携して、セキュリティコントロールの設計や運用に不備がある高リスクシステムなど、より高リスクのシステムの Technical Security Validations (TSVs) を促進しています。これらの検証は、私たちの Security Notice プロセス中にトリガーされ、システムのセキュリティ構成と GitLab への影響をより深く調査することを含みます。TSV の必要性は、特定された不備の性質、送信されるデータの性質、システムの重要性に基づいて判定されます。TSV プロセス中に特定された懸念領域は、TSV Issue 内に文書化され、関連する Security Notice に統合されて、GitLab により大きな保証を提供し、ステークホルダーによる情報に基づく意思決定をサポートします。

TSV の完了は、特定された不備の深刻度、送信されるデータの機密性、システムの重要性などの要因に応じて、関連する要求の承認の前に TPRM の裁量で必要となる場合があります。このアプローチは、潜在的に安全でない環境内へのデータの導入や継続的な存在の前に、より情報に基づくビジネス意思決定を促進するために取られます。Business Owner はこのことを通知され、ビジネスの中断やベンダーへの支払いの遅延を引き起こす可能性がある場合は、遅延を控訴することができます。

新システムのオンボーディングと Post-Implementation Controls (PIC)

私たちの TPRM アセスメントのアウトプットとして、Security Risk チームは Information Technology と提携して、さまざまな GitLab 機能をサポートする新しいアプリケーションの使用、管理、統合をインベントリ化しています。このインベントリは Tech Stack、つまりビジネスをサポートするテクノロジーに関する GitLab の信頼できる唯一の情報源（SSOT）内に存在します。要件は、各システムの Critical System Tier に合わせて定義されます。GitLab が Critical System Tiering (CST) をどのように活用しているかについての詳細は、CST ハンドブックページで確認できます。

Post-Implementation Controls (PIC)

Post-Implementation Controls (PIC) プロセスは、go-live 後に新しいシステムが GitLab 環境内で効果的かつ安全に構成およびデプロイされていることを検証します。Security Risk は PIC Issue を開始し、Business Owner に割り当てます。Business Owner は、以下のコントロールドメインを完了し、証明する責任を負います。

• CUECs — ベンダーの SOC 2 レポートに含まれる Complementary User Entity Controls について、Security Risk が提供する GitLab 固有の翻訳を使用して確認する。
• Access Security — ローカル認証が無効化されていること、サービスアカウントがインベントリ化されていること、ユーザーアクセスが Okta SSO を通じてプロビジョニングされ、デプロビジョニングプロセスが整備されていることを確認する。
• Infrastructure Security — CST 1 および CST 2 システムについて、ベンダーログが SIEM に取り込まれ、モニタリングが実施されていることを確認する。
• Business Continuity — システムの RTO/RPO 要件が理解され、該当する場合はベンダーがインシデント対応ワークフローに組み込まれていることを確認する。
• Application Integrations — go-live 時に確立された API 接続を文書化し、API キーが GitLab ポリシーに従って管理されていることを確認する。
• Compliance Scope — システムに関連するコンプライアンス義務を確認する。

完了した PIC Issue は、ベンダーの Tech Stack レコードにリンクされます。質問は #security_help チャンネルの @security-risk に問い合わせることができます。

その他のタイプのサードパーティアセスメント

年次の高リスクベンダーアセスメント

GitLab は、Red データへのアクセスを持つか、コンプライアンス活動の対象範囲であるベンダーのサブセットに特に依存を置いています。これを念頭に置いて、Security Risk は、これらのベンダーに対する年次のアセスメントケイデンスに従って、継続的なカバレッジと潜在的なセキュリティリスクの特定を確保しています。これらのアセスメントは、各会計年度の Q4 中に行われます。

この活動のスコーピングは、以下の集団に基づいており、私たちのスコーピングの正確性を確保するために GitLab 内のさまざまなチームと連携して最終決定されます。

1. GitLab の Third Party Sub-Processors
2. Red Professional Services Sub-Processors
3. SOC 2 対象範囲のアプリケーション
4. Red アプリケーション

上記の集団内のベンダーは、私たちの Red ベンダーアセスメント基準と整合してアセスメントされます。特定された不備は、私たちの TPRM Security Notice プロセスと整合して Business Owner に報告されます。

年次のアセスメント手順に含めたいベンダーがありますか? #Sec-Assurance チャンネル内の @Security-Risk に連絡してください。

サードパーティアプリケーション統合

GitLab の環境内のシステム間の統合は、各システム間で送信されるデータのセキュリティに対する保証を取得するために、上記で定義された TPRM アセスメント手順の対象となります。Security Risk チームは、リクエストをレビューして、共有されているデータの理解を取得します。アプリケーション統合リクエストは、こちら にある App Integrations Issue テンプレートを使用してオープンできます。

アプリケーション統合リクエストプロセスは、GitLab をサポートするために相互に対話するシステムの可視性と監視を可能にする機能を持っています。このプロセスは、標準の Zip 調達プロセスの対象とならない既存のシステムを Security Risk チームが特定およびアセスメントするための「ソフトゲート」としても機能します。統合リクエスト内の各システムは、提案された統合の結果として送信されるデータの機密性に対処するためにアセスメントが以前に完了しているかどうかを判定するためにレビューされます。新しいシステム、または送信されるデータの機密性が増加する統合は、リクエストの承認の前に TPRM レビューが完了する必要があります。リクエスト内に記載されている各システムが新しい統合で共有されるデータと整合して任意の時点で以前にアセスメントされている場合、リクエストは追加のレビューの前に承認できます。

App Integration Requests は、TPRM レビューと契約更新との整合をサポートするために、24 か月の延長された承認ウィンドウの対象です。問題のいずれかのシステムのレビューが承認ウィンドウから期限切れになっている場合、いずれかのシステムの新しいレビューがその後に開始および完了される状態でリクエストを承認できます。これは、より低リスクと考えられる統合を遅らせないことにより、GitLab のイテレーションと結果の価値観をサポートすることを目的としています。私たちのレビュー基準が満たされているが、それ以外の懸念領域が特定されている場合、アセッサーは項目が解決されるか新しいアセスメントが完了するまで承認を遅らせる際に専門的な判断を使用することが奨励されています。アプリケーション統合リクエストの結果として特定された不備は、関連するシステムの Business Owner に報告されます。これは統合リクエストをオープンした個人と同じであるかどうかは関係ありません。

個別利用ソフトウェアのリクエスト

個別利用ソフトウェアのリクエスト手順は こちら で確認できます。これらのツールは、しばしば「4」の Critical System Tier としてカテゴライズされており、集中化されたオーナーシップの欠如により、Tech Stack で表現される必要はありません。

Orange Individual-Use Software は、ベンダーリソースと GitLab 内での使用範囲の限定を考慮して、削減された範囲の下でアセスメントされます。これらのベンダーの要件の詳細については、上記の TPRM Assessment Requirements セクションを参照してください。アセッサーは、フルスコープのアセスメントが正当化されると感じる場合、それを実行することが奨励されています。Security Risk は、私たちのセキュリティ要件を満たさない個別利用ソフトウェアを許可しないか、承認を保留する権利を留保します。このプロセスへの例外はケースバイケースで検討され、TPRM Security Notice プロセスを通じて関連ステークホルダーに報告されます。詳細については、GitLab の Internal Acceptable Use Policy を参照してください。

ドキュメンテーションリクエスト

アクティブな GitLab ベンダーのコンプライアンスレポートをお探しですか? TPRM ワークスペース内で「Vendor Documentation Request」テンプレートを使用して 新しい Issue をオープン してください。喜んで追跡します。

人工知能 (AI) の使用

GitLab チームメンバーによる人工知能 (AI) サービスの使用は、独自のセキュリティ、プライバシー、法的影響を伴っており、GitLab の Acceptable Use Policy によって統治されています。TPRM は AI 機能のセキュリティに対する保証を取得するための手順を統合していますが、私たちは一部のシナリオで、これらのサービスの使用が GitLab の AI Acceptable Use Policy と整合しているかどうかを判定できない場合があります。そのため、TPRM は、この機能の使用が追加のリスクをもたらす可能性があるかどうかを理解するために、要求の承認の前に Legal および CorpSec チームと連携する場合があります。これらのチームによる不利な発見は、TPRM Engineer による要求の拒否につながる可能性があります。

TPRM プロセスへの例外

特定の状況で、TPRM レビューのパフォーマンスや内容の要件は、上記で定義された標準プロセスから異なる場合があります。

1. プライバシー駆動の TPRM レビューについては、GitLab がサードパーティから Controller-to-Controller 転送で個人データを 受信する インスタンスは TPRM レビューを必要としません。Privacy チームは、調達プロセス中の Privacy アセスメントの一環として、関係の性質を分類します。
2. Law Firms、Accountants、Auditors は、Controller-to-Controller relationship で Red データを含むデータを受信する場合があります。これは、これらのタイプのエンティティが法律の下でデータを処理するための直接的な義務と標準を持っていることを意味します。そのため、これらのエンティティは Orange ベンダーとして扱われる可能性があります。
3. GitLab チームメンバーが第三者 Data Controller に自分のデータを提供するインスタンス（チームメンバーが個人的に第三者の利用規約を承認する）は、TPRM アセスメントを必要としない場合があります。例には、GitLab がサービスのみを資金提供しているがチームメンバーの代わりにデータを送受信せず、チームメンバーが自発的にプログラムに参加することを決定する、健康、コーチング、カウンセリングの福利厚生にサインアップすることが含まれる可能性があります。
4. Field Marketing イベントは、GL チームメンバーや見込み客の連絡先情報の収集が Field Marketing チームの通常の業務過程で標準と見なされるため、Security レビューの完了を必要としません。Field Marketing チームがその運営を促進するためにソフトウェアの使用を依頼している場合や、GitLab の代わりにデータを収集するためにベンダーを雇った場合、これらのベンダーは Data Processor（詳細については上記 1. を参照）と見なされる可能性があるため、TPRM レビューの対象となる場合があります。GitLab が他の主催者からイベントデータを受信したり、GitLab が他の独立した組織やスポンサーとイベントデータを共有したりすることは、TPRM アセスメントを必要としません。

参考文献

• GCF Compliance Controls
• Data Classification Standard
• Current listing of controlled documents
• App Integrations (Team Member Enablement)
• Observation Management Procedure
• STORM
• Procurement Process

ページのソースコードを見る - ページの編集 - please contribute.