DBSC（DataBase Security Consortium）というデータベースのセキュリティを扱っている団体のホームページで「統合ログ管理サービスガイドライン 第0.9版」が公開され、内容についてパブリックコメントを9月6日まで募集をしています。これは、「統合ログWG」というDBSC内のワーキンググループのリーダーを私が務めさせていただいており、そこで取りまとめたものです。

　このガイドラインを作ろうとした背景として、複数の機器が出力するログを統合するシステムの普及が始まったということがあります。なぜ統合ログシステムが普及し始めているかと言うと、内部統制の浸透と関係があります。

　内部統制を推進する上でログは不可欠なものとされています。そこで、統合ログシステムがあれば容易にログが収集管理できるとあって、統合ログシステムが普及してきているのです。

　ところが、ログがあればいいという具合に、「取得することが目的」になって導入が急速に進んだせいもあって、今になって、「これは役に立つのだろうか？」「膨大なログをこのまま集め続けることに意味があるのだろうか？」「もっと役に立つ使い方がないのだろうか？」という声が聞こえ始めました。

　一般の方からすると「ログが取られている」というと「後で何でも分かるはず」と思われるかもしれませんが、残念ながらそうではありません。取得することが目的のログというものは後で役に立つ可能性は低いのです。なぜなら、きちんと考えてログを取得しないために、分析に必要な項目が抜けていたり、複数のログに関連性がなかったりする可能性が高いからです。ましてや、ログに記録されている時間が機器ごとにずれていたりすると絶望的です。

　ログは「何かあったときに後で調査に使う」という使い方以外に「平常時に異変を察知する」使い方があります。これは監視や継続的なモニタリングを意味します。それぞれの目的で取得すべきログの種類と項目の設定は違うのです。

　ログを用いて何を検出したいのか、調査したいのか、という「要件定義」がとても重要な工程になるのですが、この工程は必要性すら一般に認識されていません。さらに、日々の運用についても設計されていなければいけません。そうでないと、統合ログシステムが「ただのごみ箱」になってしまいます。

　また、集められたログは関連性を持たせることで意味を持ちますが、同時にログそのものが機密情報になってしまうのです。この機密情報の取り扱いにも十分に注意しなければいけません。その企業や団体の活動そのものが、そこから分かってしまうからです。

　こうした統合ログの設計などの目安として参考となるべくガイドラインを作成しました。骨子にしかなっていない部分もあり、すべてを網羅できていないかもしれませんので、ぜひ、ご意見をいただければと思います。

　また、今後、データベースという枠にとらわれずに、広く統合ログシステムの管理サービスのガイドラインとして他の団体との連携も進めて行きたいと考えています。