セキュリティチームは多くの場合、ルールの作成から業務を開始します。しかし、ルールは時間が経つにつれ、数が増え、変化し、一貫性を失っていくものです。たった数件の検出が、すぐにロジックの重複や名前における一貫性の欠如、変更者についての可視性の限定など、運用上の課題をもたらします。
検出エンジニアリングでは、これを変えることができます。検出結果をコードとして管理することで、企業チームはソフトウェアを出荷するのと同じ方法で、SIEMコンテンツのバージョン管理やレビュー、テスト、そしてデプロイメントを行うことができます。
このガイドでは、次のことを行う方法を説明します。
- Sumo Logic Cloud SIEMのルールをGitHubリポジトリに保存する
- 一貫したデプロイメントのためにTerraformを使用する
- 検証と自動化のためにGitHub Actionsを適用する
- OIDCを使用してTerraformの状態をAWS S3に安全に保存する
目標：DevOpsの厳密さをSOCに導入する。これにより、すべての検出はバージョン管理され、テスト可能かつ繰り返し可能になります。
コード検出が重要となる理由
| 課題 | コード検出によって可能になること |
| ルールにおける逸脱と矛盾の解決 | バージョンの集中管理による一貫性の強化 |
| 手動デプロイメントとヒューマンエラーの解決 | 自動化されたCI/CDパイプラインによる予測可能なロールアウトの実現 |
| 限定的なコラボレーションの解決 | プルリクエストの適用による全ルールの監査およびレビューの実現 |
| 困難なロールバックやテストの解決 | バージョン履歴による安全なプロモーションおよび即時のロールバックの実現 |
コード検出は、SIEMを静的な構成から、エンジニアリングの規律に基づいて設計、テスト、およびデプロイされた生きたシステムへと変えます。
構築するもの
次のことを可能にするGitHubリポジトリを作成します。
- Cloud SIEMの検出をコード（YAMLまたはJSON形式）として保存する。
- Terraformを使用してSumo Logic環境に変更を適用する。
- GitHub Actionsを通じてデプロイメントを自動化する。
- OIDC（静的認証情報なし）を使用してTerraformの状態をAWS S3バケットに保持する。
このアーキテクチャにより、手作業によるエラーが排除され、反復が加速されるほか、すべての環境にわたる完全な監査可能性がSOCに対し提供されます。
セットアップ手順
ルール管理用のGithubリポジトリは、組織のアカウントで設定することをおすすめします。また、ルール管理リポジトリは他の機能や製品と共有しないことをおすすめします。
前提条件
- 状態管理用のS3バケットを備えたAWSアカウント
- Githubアカウントとリポジトリ – 新規リポジトリの作成 – GitHub Docs
- Sumo Logicアカウント
資格情報
AWSおよびSumo Logicの資格情報はGitHub Secretsに保存されています。Terraformは、これらの資格情報を使用してAWSおよびSumo Logicとの認証を行います。
Sumo APIの資格情報
Sumo Logicの資格情報を取得する手順はこちらをご覧ください
AWSのセットアップ
AWSのバケット作成および資格情報は、以下の手順により取得可能です。
- AWSコンソールで、S3ページに移動し（検索バーで「S3」と検索）、「Create bucket」をクリックします。
- バケットに希望する名前を入力し、残りのオプションはデフォルトのままでバケットを作成します。
- 「IAM」>「Policies」ページに移動し、「Create Policy」をクリックします。
- ポリシーエディターをJSONビューに切り替え、「Statement」フィールドを以下のものに置き換えることで「bucket-name」をステップ2で作成したバケットの名前に置き換えた後、「next」をクリックします。
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::bucket-name",
"Condition": {
"StringEquals": {
"s3:prefix": "terraform-state"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state.tflock"
}
]
- 次のページで、ポリシーに任意の名前を入力し、「Create Policy」をクリックします。
- こちらの手順に従って、AWSにIDプロバイダを追加します：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-console
- プロバイダのURLには次を使用します：https://token.actions.githubusercontent.com
- 「Audience」には次を使用します：sts.amazonaws.com
- 「IAM」>「Roles」ページに移動し、「Create Role」をクリックします。
- 「Trusted entity type」で、「Web Identity」をクリックし、IDプロバイダとして「token.actions.githubusercontent.com」、オーディエンスとして「sts.amazonaws.com」を選択します。このリポジトリが分岐されるGitHub組織の名前を入力し、「next」をクリックします。
- 「Add Permissions」ページで、ステップ5で作成したポリシーを選択します。
- 適切なロール名を入力し、「Create Role」をクリックします。
- GitHubリポジトリの「Settings」>「Secrets and variables – Actions」>「Variables」で、
「AWS_ROLE_ARN」、「BUCKET_NAME」、「BUCKET_REGION」の変数を、先ほど作成したバケットのロールのARN、バケット名、およびリージョンと置き換える、または追加します。 - GitHub Actionsにおけるシークレット
- Sumo Logicの資格情報（Personal Access Keys）は、リポジトリシークレットに保存され、Terraform GitHub Actionによりアクセスされます。同様に、S3バックエンドへのアクセスに使用されるAWS Roleは、バケット名およびバケットリージョンとともに、リポジトリ変数セクションに保存されます。これらのシークレットおよび変数は、リポジトリ設定の「Secrets and variables」>「Actions」から更新できます。
SUMOLOGIC_ACCESSID
SUMOLOGIC_ACCESSKEY
AWS_ROLE_ARN
BUCKET_NAME
BUCKET_REGION
ローカルでの実行
ローカルから実行する場合、上記のAWSセットアップは機能しないため、次の手順によりAWSアクセス資格情報を作成し、使用する必要があります（これらの手順では、S3バケットおよびポリシーの作成が前提となるため、未作成の場合はAWSセットアップのステップ1～5に従ってください）。
- 「IAM」>「Users」ページに移動し、「Create User」をクリックします。
- 適切なユーザー名を入力し、「next」をクリックします。
- 「Set Permissions」ページで「Attach Policies Directly」をクリックし、先ほど作成したポリシーを選択します。次のページで、「Create User」をクリックします。
- 「IAM」>「Users」ページに戻り、新しく作成したユーザーをクリックします。
- 「Security Credentials」タブの「Access Keys」セクションで、「Create Access Key」をクリックします
- ユースケースとして「CLI」を選択し、チェックボックスにチェックを入れて「next」をクリックします
- 必要に応じてタグを設定し、「Next」をクリックします。このステップでは、AWSアクセスキーとシークレットアクセスキーを作成します。
それぞれを「AWS_ACCESS_KEY_ID」と「AWS_SECRET_ACCESS_KEY」という名前の環境変数としてエクスポートします。
検出の促進とテスト
次のように分岐と環境分離を使用してルールの昇格を管理します。
- 機能ブランチ→開発と検証
- プルリクエスト→ピアレビューと計画承認
- メインブランチ→開発ブランチへの自動デプロイメント
- 手動ワークフロートリガー→テストまたは本番環境に昇格
品質を維持するため、YAMLリンティング、ポリシーテスト、またはメタデータ検証を追加します。
このDevSecOpsスタイルのワークフローでは、誤検知の減少、反復の高速化、および検出に対する組織の信頼構築が実現します。
運用規律
成熟した検出プログラムは、どれも運用上の一貫性に依存します。
次のような規則を採用しましょう。
所有者、ユースケース、およびランブックURLなどのメタデータフィールドを含める。- 一時的に無効になっているルールに
enabled: falseを使用する。 - 命名基準とメンテナンスウィンドウを適用する。
Terraformプランを使用して夜間のドリフトチェックを実行する。
強力なプロセス規律により、検出管理は事後対応型のルール調整アプローチから、継続的な検出改善プロセスへと変化します。
トラブルシューティングと回復
一般的な問題：
- 予期せぬ削除：状態のバックエンド設定を確認します。
- 認証エラー：OIDCおよびAPIシークレットを確認します。
ドリフト警告：Sumo Logic UIで手動編集が行われていないことを確認します。
ロールバック：コミットを元に戻して再適用します。Terraformの状態により完全な回復が保証されます。
価値：これらの安全対策により、検出エンジニアリングの回復力が高まり、操作ミスは危機となるどころか、学習の機会となります。
重要となる注意事項
Sumo Logicは、Cloud SIEMサービス、API、そしてCloud SIEMサービス内のルールやその他の設定に関連するTerraformの公開リソースのサポートとメンテナンスに対してのみ、責任を負うものとします。独自のGitHubリポジトリと、当該リポジトリ内におけるセキュリティおよびプロセスのサポートとメンテナンスに対する責任は、お客様ご自身が負担するものとします。また、このガイドは無保証で提供されており、リポジトリのセットアップとサポートによりすべての関連組織要件が満たされていることを確認する責任は、お客様ご自身が負担するものとします。
プロセスから実践へ
GitHubにおけるCloud SIEMルールの管理は、手動調整から測定可能な進歩への移行という、きわめて重要な転換点となります。バージョン管理、自動化、およびCI/CDにより、すべての検出は学習、適応、および改善を行う生きたシステムの一部となります。
Sumo Logic Cloud SIEMを搭載したこのシステムは、検出をコンテキストに、コンテキストをアクションに、そしてアクションを結果に結び付けるインテリジェントセキュリティオペレーションへと進化します。
録画デモにより、SIEMの実際の動作をご覧ください。
