はじめに
前回の記事では、AWS Security Hubを使った運用体制再構築の概要について触れました。
実はこの中で紹介している 「4.リスク優先度に基づいた対応」 が安定して運用できるようになるまでは、弊社では一定の時間を要しました。
理由としては「思った以上に大量のログが出て、対応優先度が即座に付けられなかったから」なのですが、同様のお悩みを抱えている方もいらっしゃるのでは？と思い、弊社での対応内容を簡単にまとめました。
1. 想定を大きく上回る「膨大な量のログ」に直面
運用を始めて最初にぶつかった壁は、 「同一重要度の大量のログでダッシュボードが埋め尽くされる」 ことでした。
当初は「”重大”や”高”と表示されたものから順番に対応すればいい」と考えていましたが、
実際に運用を開始すると、大量のログが同じ重要度で並び、その中での優先度が全く付けられないという状況に陥りました。
これでは何をどうすべきか判断できず、適切な運用はできません。
このログたちをどうにか整理しないと…でもどうやって...？しばらくこの問題で悩むことになりました。
2. 優先事項を整理し直す「ログの仕分け」作業
弊社では、AWS Security Hub を監視ダッシュボードとして、
AWS GuardDuty、Amazon Inspector、Amazon Macie などから情報を集約しています。
「これらの情報から何を得たかったのか？」という本来の目的に立ち戻り、以下の2つの視点でログの整理を行いました。
1. 重大度「重大」または「高」でフィルタリング
2. 運用中の他のサービス群と組み合わせたときの「実質的な重大度の変化」を評価
これはAWSが提供する 「セキュリティサービス単体で見たときのリスク」と、弊社の運用状況を鑑みての「実際のリスク」をかけ合わせる作業です。
セキュリティサービス単体で見ると高リスクであっても、別の方法でリスクヘッジできているケースもあると思います。
Webセキュリティの運用を行っていく上では、これらの要素を「総合的に評価して優先度を定める」ことが重要だと考え、このような整理の仕方をしました。
以下に、その具体的な仕分けパターンをいくつかご紹介します。
-
パターンA：「AWS WAFを活用している環境下で、AWS GuardDuty のアラートが上がる」ケース
- AWS WAFをすり抜け、ネットワーク内で不正な振る舞いが行われている可能性を示唆。
- 早期の確認が必要と考えられます。
-
パターンB：「AWS WAFを活用している環境下で、Amazon Inspector のアラートが上がる」ケース
- コンテナイメージに含まれるライブラリに脆弱性があるが、AWS WAFで一定のリスク低減が図れている。
- 対応は必要だが、一定の対応猶予があるものと考えられます。
-
パターンC：「Amazon Macie のアラートが上がる」ケース
- 個人情報や機密情報の取り扱いが、想定通りではない可能性がある（オペレーションミス、システム不具合など）
- 早期の確認が必要と考えられます。
幸いほとんどのアラートがこういったパターンに分類できたため、思ったよりも短時間でログの整理を完了することができました。
3. ログ仕分け後の変化
この「ログの仕分け」作業の結果、弊社の場合はこれだけで適切な運用が可能なログ出力量になりました。
AWS GuardDutyからのアラートをはじめとする優先的に確認・対処が必要なケースが明確になったことで、リアルタイムでの対処が可能になり、Webのセキュリティを担保しつつも、比較的低コストで効率的な運用が実現できています。
まとめ
いかがでしたか。
この記事では、弊社が直面した「大量のログによる優先度付けの困難さ」と、それを解決するために行った「リスクに応じたログの仕分け」について解説しました。
ログの仕分け方法についてはあくまでも弊社での事例となりますが、
こういった考え方自体は、この記事をご覧のみなさまも活用できるのではないでしょうか。
セキュリティサービス単体で見ると高リスクであっても、別の方法でリスクヘッジできているケースもあると思います。
Webセキュリティの運用を行っていく上では、これらの要素を「総合的に評価して優先度を定める」ことが重要だと考え、このような整理の仕方をしました。
最後まで読んでいただきありがとうございました。
もし現在、大量のログの中で「次に何をすべきか」を見失っている方がいらっしゃいましたら、この記事が解決の一助になれば幸いです。