AWSは、AWSネットワークファイアウォールにルールヒット数を導入し、セキュリティチームがステートフルなファイアウォールルールがトラフィックにマッチしているかどうかを測定できるようにしました。
この新機能は、ある問題への対処を狙ったものです。ポリシーが拡大するにつれ、組織はどの制御が有用で、どれがトリガーされないまま容量を消費しているだけなのかを判断するために、手作業によるログ分析に頼ることが多くなります。
しかし、この作業は時間がかかるうえに結果にばらつきが出やすく、監査の場で正当性を説明するのも困難です。ルールごとのマッチ状況を可視化することで、AWSは管理者に対し、古くなったエントリーを特定し、ポリシーを調整し、導入済みの防御策が本番環境で実際に機能しているかを検証するための根拠を提供します。
この機能はSuricata互換ルールを基盤としています。ヒットカウンターは、マッチしたルールがアラートログのエントリーを生成した場合にのみ増加します。そのため、alert、drop、rejectといったアクションはアラートレコードを作成するため、このメトリクスに反映されます。
一方、passルールはデフォルトではアラートログを作成せずにトラフィックを許可するため、カウント数には表示されません。許可されたトラフィックの可視性が必要な組織は、passルール内にalertキーワードを追加できます。
これにより許可の判定は維持したままマッチを記録できるため、アナリストはアプリケーションやアウトバウンド接続を許可しているルールを検証できるようになります。
各アラートログには、リソースARNを識別するAWSのメタデータが含まれ、Suricataシグネチャ IDによってルールが識別されます。AWSネットワークファイアウォールはこの組み合わせを使い、Top Rule Hitsダッシュボードでルールヒット数を算出します。
このビューは、あるファイアウォールについてAWSリージョン内のアベイラビリティーゾーンをまたいで結果を集計し、ヒット数、全マッチに占める割合、リソースARN、シグネチャID、ルールの説明、直近の発生タイムスタンプを表示します。
アナリストは、ログがCloudWatchに配信されている場合はCloudWatch Logs Insightsを通じて、Amazon S3に保存されている場合はAmazon Athenaを通じて、レコードを直接調べることも可能です。これにより、テレメトリデータへのアクセスが容易になります。
ルールの健全性を保つ観点では、このダッシュボードが出発点となります。あるシグネチャが選択したルックバック期間中に表示されない場合、そのルールはその期間中トラフィックにマッチしていなかったことになります。
セキュリティチームは、そのルールが陳腐化しているのか、順序が誤っているのか、あるいはまれにしか発生しないワークフロー用に確保されているものなのかを調査する必要があります。自動的に削除するのではなく、ヒットデータを資産の所有者情報、アプリケーション要件、変更管理レビューと組み合わせたうえで、削除するかどうかを判断すべきです。
AWSによると、調査の際にアナリストは活動を疑わしい期間に絞り込み、不審な接続を検知したルールを迅速に特定できるとしています。これにより、関連する痕跡が明らかになる可能性があります。
これには、外部のテストインフラとの通信の試み、想定外のアウトバウンド経路、ブロックされた地理的な接続先などが含まれます。同様の可視性は、新たに導入した制御の検証にも役立ちます。
導入後にヒットの記録が始まったルールは、そのルールが意図したトラフィックを捕捉し、ポリシーのアクションを実行しているという証拠になります。AWSによれば、ルールヒット数機能はデフォルトで有効になっており、ネットワークファイアウォールの追加料金は発生しないとしていますが、通常のロギング、ストレージ、クエリにかかる費用は引き続き発生します。
ネイティブのダッシュボードで可視化するには、アラートログの配信と詳細モニタリングが必要ですが、カスタムダッシュボードでは付属のメタデータをそのまま利用できます。この機能はステートフルなルールのみに対応しており、チームによるファイアウォールのガバナンス判断を支援します。
セキュリティチームに、不審な活動をより迅速に調査し、ビジネスへの影響が拡大する前に脅威を封じ込めるための可視性とコンテキストを。ANY.RUNで調査を強化する
翻訳元: https://cyberpress.org/aws-network-firewall-adds-rule-hit-counts/
