10人のセキュリティエンジニアにAU-6が何を要求しているのか尋ねると、8人は答える代わりに PDF を開いて確認するでしょう。それはエンジニアたちを批判しているわけではありません。これは、ほとんどのチームがNIST SP 800-53をどのように扱っているかを示す兆候です。つまり、監査中に参照する文書として扱っており、本来はログアーキテクチャがすでに答えられるべき質問の集合としては扱っていないのです。
そのギャップこそが、監査がうまくいかなくなる原因です。管理策は満たされていても、それを証明する証拠を迅速に提示できる人が誰もいないのです。
800-53 はチェックリストではなく、一連の質問だと考えてください
管理番号を取り除いていくと、800-53 のうちログに関連するほとんどのファミリーは、監査人がいずれにせよ何らかの形で尋ねる、いくつかの平易な英語の質問に集約されます。
- 実際に重要なイベントを記録し、誰が何をしたのかを特定できるだけの詳細さで記録していますか？(AU-2、AU-3)
- 誰かがその活動をレビューし、単に保存するだけでなく、それに基づいて行動できていますか？(AU-6)
- 監査人やインシデント対応担当者が 6 か月後に記録を要求した際に、それらの記録はまだ存在しているでしょうか？(AU-11)
- 何かが起こった場合、それを検知し、対処し、報告するための実際のプロセスはありますか？(IR-4、IR-5、IR-6)
- 監視は継続的に行われていますか？それとも、誰かが確認することを思い出したときにだけ行われるのでしょうか？(CA-7、SI-4)
これらの質問はすべて、成熟したログおよび SIEM の運用において、すでに実施されているべき事項です。しかし、ほとんどの環境はこれらの要素の一部はうまくこなしているものの、その間をつなぐ部分で失敗しています。
ログプラットフォームがよくつまずくポイント
最も一般的な失敗は、データが欠落していることではありません。存在するデータではあるものの、実際の問いに答えることができないのです。コンプライアンスチェックリストにそう書いてあるからログを収集していても、10 種類もの異なるソースタイプにわたってアクターフィールドを正規化していなければ、「誰がこれをやったのか」という問いは、単なるクエリではなく調査プロジェクトになってしまいます。
保持期間が AU-11 の要件ではなくストレージコストによって設定されているため、最も重要なレコードが、すでに期限切れになっているレコードになってしまいます。また、検出（SI-4）とインシデント対応（IR-4）は多くの場合、連携する記録のない別々のツールで行われるため、監査証跡には、監査人が次に投げかける「それに対して何をしたのか？」という質問のまさにその箇所にギャップが生じます。
実際に具体的な制御と機能のマッピング
| 制御ファミリー | 要求事項 | 実際にそれを満たすもの |
|---|---|---|
| AU-2 / AU-3（イベントログ、記録内容） | セキュリティ関連のイベントを、行為者、行動、結果を特定できる十分な詳細さでキャプチャします | クラウド、オンプレミス、ID、SaaS ソース全体で一貫性のある構造化フィールドを用いた集中型取り込み — 単に「どこかにログが存在する」というだけではないこと |
| AU-6（監査レビュー、分析、報告） | 誰かが活動をレビューし、定められた頻度でそれに基づいて行動すること | 各 Insight がトリガーされた理由を説明するサマリーエージェントを備えた Cloud SIEM Insights により、レビューが生のイベントのスクロール作業にならないようにします |
| AU-11（監査記録の保持） | 監査と調査の両方にとって意味があるだけの期間、記録が保持されること | ストレージ予算ではなく、実際のコンプライアンス期間に合わせて設定可能な保持期間 |
| IR-4 / IR-5 / IR-6（インシデントの処理、監視、報告） | インシデントの検出、処理、報告のための、文書化され再現可能なプロセス | Cloud SIEM プレイブックがエンリッチメントと通知を自動化し、さらにSOC アナリストエージェントの証拠トレイルが、インシデントが実際にどのように処理されたかを示す組み込みの記録として機能します |
| CA-7 / SI-4（継続的監視、システム監視） | 誰かが決めたスケジュールに頼るのではなく、誰かが忘れてしまうことのないよう継続的に行われる監視 | 監査の 1 週間前に誰かが行う四半期ごとのログレビューではなく、リアルタイムのダッシュボードと検出機能 |
監査報告はデータの問題ではなく、ストーリーの問題です
監査担当者は生のログを求めているわけではありません。彼らが求めているのは、証拠を伴うストーリーです。何が起こったのか、どのように検知されたのか、誰がいつ行動したのか。それは、「これが私たちの SIEM です。あとはご自由に。」という成果物とは別物です。
ホワイトボックス AI の背後にあるのと同じ透明性の原則が、ここではコンプライアンスインフラストラクチャとしても機能します。SOC アナリストエージェントが Insight を調査する際には、何を、なぜ確認し、どのような結論に至ったのかを示す証拠トレイルを構築します。その証拠トレイルは、アナリストが信頼できる判断を下すための根拠となると同時に、IR-4 や IR-6 の監査所見で求められる形式にぴったり合致した、あらかじめ用意された説明として機能します。あなたは、5 つのツールから得られたタイムスタンプを基に、事後的にストーリーを再構築しているわけではありません。そのストーリーはすでに存在しているのです。
Sumo Logic の監査およびコンプライアンス機能は、この考え方を継続的な運用面にも拡張します。NIST、CMMC、ISO 27001 への対応準備のために構築されたすぐに使えるダッシュボードと継続的な監視が、FedRAMP Moderate、SOC 2 Type II、HIPAA、PCI DSS の認証をすでに取得しているプラットフォーム上で動作します。目的は、単にチェックリストにチェックを入れるための新しいダッシュボードを作ることではありません。そうすることで、誰かに自分たちがやっていることの証明を求められるたびに、あわてて説明を用意しなくて済むようにすることが目的です。
結び
コンプライアンスフレームワークは、アーキテクチャがどれほど洗練されているかには関心がありません。彼らが気にしているのは、2 週間の大騒ぎをすることなく、求められたときに監査人が実際に望む形式で成果物を提出できるかどうかです。最初からその前提で設計しておけば、NIST SP 800-53 は恐れていた PDF ではなくなり、本来あなたのログプログラムが行うべきことの説明になります。
スプレッドシートではなく、NIST 800-53 への継続的な対応状況が実際にどのようなものかを確認してみませんか？Sumo Logic の監査およびコンプライアンスソリューションのデモをご覧ください。
