Logging ワーキンググループ

属性

ビジネス目標

1. GitLab セキュリティがイベントの監視・管理・検出・アラート・対応・監査に使用する、可用性の高いシンプルなロギング構造を整備することで効率性を向上させます。
2. GitLab セキュリティがイベントを共有・連携できるシンプルなロギングシステムを構築することでコラボレーションを向上させます。
3. GitLab Security が GitLab への脅威についてより正確かつ情報に基づいた判断を下せるよう、関連性があり実行可能なデータを提供することで成果を向上させます。

終了基準

1. 2022年8月時点の既存インフラ、既知のギャップ、現在のセキュリティロギングの取り組みを特定します。
2. 既存・新規・廃止されたセキュリティロギングインフラを追跡するプロセスを定義します。
3. データ要件、ストレージ、保持期間、コンプライアンス・法的要件を含むロギングプロファイルを定義します。
4. ワーキンググループの範囲を超えて作業を継続するための次のステップ、共有 OKR、その他のイニシアチブを特定します。

成果

その他の調査

こちらに移動

役割と責任

要件と考慮事項

関係者

• セキュリティオペレーション
• インフラセキュリティ
• プロダクトセキュリティ
• IT エンジニアリング
• インフラストラクチャ
• 開発
• プロダクト
• 法務
• 品質

一般

• GitLab チームメンバーとして、GitLab でログに記録されているすべての事項について相談できる単一のチームがあることを把握しています。
• GitLab チームメンバーとして、単一のハンドブックページを参照することでロギングチームの担当者を確認できます。
• GitLab チームメンバーとして、専用の Slack チャンネルを通じてロギングチームに連絡できます。
• GitLab チームメンバーとして、ロギングチーム向けに GitLab の Issue にラベルを付けることができます。
• ロギングチームメンバーとして、管理・保守が必要なロギングサービス・インフラは1組だけです。

セキュリティアシュアランス

• セキュリティアシュアランスチームメンバーとして、最大12か月前のログを容易に検索・閲覧・分析できます。

SIRT エンジニア

• SIRT エンジニアとして、最大1年分のログを容易に検索・閲覧・分析できます。
• SIRT エンジニアとして、1年以上前のアーカイブ済みログソースを取得し、それらのログを容易に検索・閲覧・分析できます。
• SIRT エンジニアとして、インシデント対応のためのルール・アラート・ダッシュボードを容易に作成できます。
• SIRT エンジニアとして、以下を含むログソースに関する情報をハンドブック内で確認できます:
  • 各ログソースの責任を持つ DRI
  • 各ログソースのフォーマット
  • 各ログソースに記録されるフィールド
• SIRT エンジニアとして、迅速・正確・信頼性の高いインシデント対応のために、ロギングデータを他の SIRT ツールに容易に統合できます。

インフラセキュリティ

• 収集
  • インフラセキュリティエンジニアとして、インフラや第三者ツールからの監査ログを中央拠点に設定・送信することを誰でも容易に行えるようにする必要があります。
  • インフラセキュリティエンジニアとして、IDS ツールからの検出結果を容易にエクスポートできる必要があります。
• 配信
  • インフラセキュリティエンジニアとして、ログがスケーラブルで一貫性があり信頼性が高いことが必要です（タイムスタンプの破損やデータ損失がないこと）。
• 保持
  • インフラセキュリティエンジニアとして、ログが保持・廃棄要件および社内ポリシー、標準、規制要件に準拠している必要があります。
• 監視とアラート
  • インフラセキュリティエンジニアとして、1つ以上のインフラリソースのログと脅威検出結果を容易に分析できる必要があります。
  • インフラセキュリティエンジニアとして、ログのルールや異常に基づいてアラートを作成できる必要があります。
• 変更管理
  • インフラセキュリティエンジニアとして、すべてのインフラと設定がコードとして管理され（terraform、python、bash）、変更管理がマージリクエストレビュープロセスに従う必要があります。

IT エンジニアリングとインフラストラクチャ

• IT エンジニアとして、今日 Sentry でバグ報告を行うのと同じくらい簡単に、テックスタックアプリケーションやベンダーの SaaS サービスをロギングサービスに追加してログの送信を開始できます。
• IT エンジニアとして、異なる通知サービス（メール、Slack、GitLab Issue など）に送信する基本的なダウンタイムや高アクティビティ閾値のアラートを設定できます。
• （オプション）IT エンジニアとして、ドロップダウンメニューからデータソースを変更するだけで（検索条件（アクター、IP、日付範囲など）を保持または容易に再現しながら）エンドツーエンドのシステムログを参照し、インシデント中に影響を受けたすべての関連システムを調査できます。
• IT エンジニアとして、相互に関連するテクノロジーをサポートするサービスの階層的な組織構造を作成し、相互接続したサービスグループのアラートとダッシュボードを作成できます。
• IT エンジニアとして、同じ製品/サービスの複数インスタンスをサポートしたいと考えており、各インスタンスとすべてのポリシーを手動で再作成する必要はありません。
• IT エンジニアとして、新技術の統合や、何か月もしくは何年後にベンダーが統合サポートを追加すること、またはプロフェッショナルサービスが必要になることへの懸念があります。製品・サービスプロバイダーがロギング・監視プロバイダーとの統合を構築することを促進するオープン API エコシステムアプローチを好みます。
• IT エンジニアとして、API コール、構成管理、IaC（Terraform/Ansible）を使用して設定とプロビジョニングを標準化できることを望みます。
• IT エンジニアとして、チームメンバーからのすべてのリクエストに対してダッシュボードやアラートを作成する必要はありません。プラットフォームはクエリとレポートの構築という観点から使いやすく、Excel でのピボットテーブルの作成や Tableau/SiSense でのレポート作成と同程度に使いやすいもので、フィールドが容易に識別できる必要があります。複雑な SQL クエリ言語はバックグラウンドで有用ですが、プロアクティブなアラートの普及を妨げ、インシデントトリアージ中の特定のクエリにのみ役立ちます。
• IT エンジニアとして、このプログラムが各チームが担当するより広範なテックスタックアプリケーションとサービスのための組織全体の NOC ダッシュボードへと発展することを望みます。

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