セキュリティは掛け捨てコストではなく投資
釜山公徳(@masart_3) 氏：トップバッター釜山が発表いたします。『ログ分析勉強会 ログ分析の事前知識』。入門の入門という位置付けでお話ししようと思います。よろしくお願いします。
私以降の方々は技術的なところとか、すばらしい内容が待っていると思いますが、私の話に関しましては、技術もぜんぜんわかんないし、ログもぜんぜんわかんないという方向けに入門の入門についてお話できればなと思います。ですので、いろいろなマサカリを持っている方々がいらっしゃるかもしれませんが、お手柔らかにお願いいたします。
まず自己紹介をします。とある電気屋さんでエバンジェリストをやったり、金融のお客さん中心にいろいろな案件のコンサルをしています。
それ以外にはCompTIAという資格、人材育成を担っている団体がありまして、クラウドの試験、セキュリティの試験の日本語化開発なども行っています。そのほかクラウドセキュリティの団体である日本クラウドセキュリティアライアンス、JNSAなどいろいろなところで活動しています。
たまにコラムなども執筆していますので、興味がある方はご覧いただければと思います。
みなさんにお話ししたいところとして、これは私が講演する際には必ずお伝えしていることなのですが、まず初めに守りたいモノを定義しましょう。
本日はログ分析ですので、セキュリティと間接的に関わっているもののド直球なカテゴリーではありません。とは言うもののログ分析の世界においても、モノを定義をするというのは大事です。データドリブン思考ですね。非常に重要なところです。
あともう1点、セキュリティは掛け捨てコストではなく投資であるとよく言っています。ログ分析もそうなんですが、ものごとに対して単純にこれはお金がかかるから不要だねとすぐ削減することは多々あります。
このあとログ分析に必要な情報をいくつかお話ししますが、それらを欠くことによって結局のところモノとして運用が成り立たないなどいろいろなことがあります。ぜひそこを押さえていただければと思います。
ログとは何か？どんなものがあるのか？
冒頭でお話ししましたが、本日のポイントは入門の入門です。ログ分析を始める前の考え方をお伝えいたします。
まずログとは。（スライドを示し）いきなりウィキペディアからそのまま貼り付けているのかというお怒りをいただくかもしれないですが（笑）。別にここは重要なところではなく、どういうものなのかなというのをざっくりご理解いただくために引用しています。
ログは航海日誌……おぅおぅと。航海記録を取るというところから来ていると。あ、だから『ワンピース』で……あ、失礼しました。いらないことは言わないようにしておきます（笑）。
ログ、ログといろいろ言いますが、コンピュータのデータログ、ここが本日お話しする内容のド直球のところですね。ウィキペディアでは、ログファイルだけではなく揮発性メモリなどに記録するとあります。ファイルだけではなく例えばメモリダンプ、ありますよね。そういったものについても1つのログと言えます。いろいろなものがログとして存在するというということを押さえていただければと思います。
そしてログを分類してみました。これは私がマインドマップで簡単に作成したものですので、一切網羅性はありません。とくに責任も取りません。私の思考でざっくり分けると、こういうものがあるなぁという例を挙げます。
ログに関しましては、OS、ハイパーバイザー、ネットワーク、アプリケーション。OSI参照モデルベースで考えた場合にこういうふうに分けると分類しやすいです。いろいろな方法がありますので、これは1つの方法としてご参考にしていただければと思います。
いろいろな視点でいろいろなものがあって、例えばOSのログ1つとってもバージョンによって多少の出方はもちろんのことながら異なります。例えばWindowsであればイベントログですね。イベントログの中にシステムログ、アプリケーションログ、その他もろもろありますよね。ただバージョンが異なることによって多少の差分が発生します。
ログの分類においては、細かく分類すればするほど良いというわけではなく、適切な分類をすることによって分析が迅速かつ適切に行えますよということですね。
先ほどメモリダンプもログの1つだというお話をしましたが、データベース、RDBにおけるトランザクションログだって、これもログなんです。いろいろなログの観点があるので、1つのものに囚われすぎることは危険だということも併せて押さえてください。
ログの必要性とは
そもそもログなんていらねぇよみたいな方はいらっしゃらないとは思うんですが、必要性について、あんまりよくわかんないよねというところをお話しします。
ログって何に使うか？障害対応。ソフトウェア障害なのかハードウェア障害なのか。いろいろな障害対応に使いますよね。通常の障害対応だけではなく、セキュリティインシデントにおける対応でももちろん必要です。誰がいつどこでどういう不正な動きをしたのかというところを確認するためにログを確認しないことはあり得ません。
そしてプログラムデバッグ。インシデント対応という観点ではなく、開発者、デベロッパーの観点でものを作りました。プログラム作りました。なにか問題があります。それに関してデバッグする。これも1つのログと言えるでしょう。
あと先ほど申し上げたデータベースのトランザクション処理。あと復旧。REDOログといったものとかですね。いろいろありますが、そういった復旧のために使うようなものも1つのログです。分析のためのログだけではありません。
先ほど私のほうでログを分類しましたが、そんなもの必要なんですか？と。ログにおいては、環境によっては数億、数十億……私は100億件くらいのログの解析とかもしたこともあります。
これを分類なしでやると、マシンスペックやその他もろもろのいろいろなリソースの問題や、あと単純に時間がかかってなにもできなくなるといったところがあります。分類は非常に大事です。分類がないと現実的ではなくなってしまうんですね。
具体的にどうすればいいのか？
じゃあそのログ、具体的にどうすればよいのか、イメージを掴んでもらうために、Linuxベースにはなりますが、rsyslogの例で少し紹介します。rsyslogに限らず普通のsyslog、従来のLinuxのsyslogで同様です。
FacilityとPriorityにそれぞれ分かれています。Facilityの項目に関しまして、いくつもあります。（スライドを示し）ここに挙げているとおりですね。人によっては若干これが微妙だなと思われる方もいらっしゃると思います。微妙なのでlocalで設定するといったことは多々あると思いますが。
localで設定するにあたってどういう内容を設定するのか。これ大事ですね。そしてFacilityを押さえるだけではなくPriorityも重要です。Priorityといってもよく言われるinfo 1 errorですね。世の中にはいろいろなログフィルター、Priorityがあります。debugもそうですし、info、noticeとかですね。あとcrit、alert、emerg、いろいろなものがあります。
どういう問題が発生してどういうPriorityの場合にどういう動きをするのか。動きというのはオペレーションですね。どういうインシデントレスポンスをするのかなど、非常に重要なポイントになります。必ずこういったフィルターでどういうふうにログが成り立っているのかというのを押さえるとより迅速に対応が可能です。
もう1つ紹介します。さらに深掘りしますと、rsyslogのconfigの一部を引用しています。RULESのところですね。先ほどあげましたFacilityとPriorityの部分、どういったログがどこに保存されるのかっていうのが、ここで押さえられます。
例えばよくある/var/log/messagesですね。info、mail、いろいろなものがありますね。よく障害対応などで/var/log/messages、メッセージログをよく使われるのはこういったいろいろなFacilityが一気に突っ込まれているから/var/log/messagesを見るというのが慣例化されています。一番情報量が多いのでそうなるでしょう。
インシデント・レスポンスで押さえておくポイント
インシデントレスポンス中心の話でお伝えしていますが、さらに深掘りし、インシデントレスポンスを高速化、合理化させるためにどういうものがあるのかを紹介します。
（スライドを示し）これもLinuxの例ですが、いろいろなログがあります。こういうログがあるんですよというのを押さえると、なにか問題が発生したときにアクションが早くなりますよね。
それは当然の話なんですが、さらにもう1つ押さえておくべきところは、とくにLinuxですが、ファイルの形式ですね。あまりご存じじゃない方が障害対応中に陥るところといたしましては、バイナリログをPagerなどで閲覧してしまうケース。もちろんのことながらバイナリですので内容は見れません。それによってコンソールが固まってニッチもサッチもいかなくなり、なにもできなくなります。
それがTeratermなどでリモートでアクセスしているのであればいいのですが、データセンターでコンソールドロワー上でアクセスしてそれをやってしまうと、切り替えるにあたって単純にターミナルを切るだけでは済みません。若干の時間のロスが発生します。
迅速化するためには、とくにミッションクリティカルなシステムにおいてはテキスト形式なのかバイナリ形式なのかというのを正しく押さえる必要があります。バイナリ形式を見るにあたっては一般的にツールがあります。LastというコマンドであったりLastlogというコマンドがあります。そういったものを活用して情報を見ます。
メモリダンプの解析に至ってはそれ用のツールがあります。WindowsであればWinDbgが有名ですよね。そういった専用のツールが必要です。
次に、インシデントレスポンスの例をケースごとに紹介します。例えばケース1、OS起動後、ドライブがマウントされていない。そういった場合どうするのかというと、dmesgコマンドで起動時の状況を確認します。
失礼しました。（スライドの）ケース3のところがケース2とかぶっているのでケース2だけ紹介します。定期実行ジョブが動作しないといった話はよくあります。こういった場合は、cronのログを確認しましょうというのと、cronのログだけでは、例えばシェルスクリプトの中で呼び出し先自体がなにか問題が発生しているなど考えられます。cron自体の問題ではなくそれ以外の問題だという場合はmessagesログなども確認が必要です。
ポイントとしては、あらかじめユースケースはどういうものがあるのかというところを押さえておくと、実際になにかあった場合にアクションが高速化できるということです。これはエンジニアの方というよりも、プロジェクトマネージャーの方にとくに押さえていただきたいポイントです。
セキュリティインシデントにはトリアージが必要
そろそろ時間がきていますが、こちら、まとめの前の最後のスライドになります。
OpsとSecOps、最近よくこういう言葉使われますよね。じゃあOpsとSecOpsってログ分析においてなにか考え方が違うのかな？ というポイントを2つ紹介します。
まずセキュリティインシデントは通常のOps、もちろんOpsが軽いと言っているわけではなく状況によって異なるんですが、割合としてセキュリティインシデントのほうが訴訟リスクなども高いですので、緊急性が高い兆候があります。
ですので、優先順位付け、トリアージが通常のOpsよりも重要とされています。トリアージをするためにどうしたらいいのかというのは、ログ分類をあらかじめやっておいて、かつ体制がどういう体制があるのか。Opsの体制ですね。いつ、誰が、何が起こったときに、どのように対応するかという体制が正しく取られている必要があります。
そのうえでこういうケースにおいては、対応は不要であるとかですね。単純にPriorityで、例えば10段階で8以上、セベリティ、重大度が8、9、10といった重大度が高いものに関しましてはすぐに対応するとかですね。そういうローレベルのトリアージというのもあります。
内容に応じて、これはミドルくらいの重大度は5とかであっても、このシステムにおいてはミッションクリティカルでインパクトが大きいので優先順位を上げないといけないとか。いろいろな考え方があります。ビジネスインパクトをそこで抑えるといったところですね。BizSecOpsという言われ方もします。その環境に応じた、要件に応じたトリアージが重要です。
そして次の点、分析にあたっての視点の違いがあります。これもゼロイチの話ではなく、Opsであってもそういうケースはありますが、通常Opsにおいてはinfoのログはあまり見ないですよね。
セキュリティインシデントにおいてはinfoのログが非常に重要なケースがあります。例えば認証関連ですね。Kerberosのログ。ログがめっちゃ出るので、これを見ないという選択肢を取る方もかなりいます。別にそれが悪いとは言いません。
ただ普段Kerberos認証におけるログを見ないと、いざ何か進入された場合に一切気づきません。侵入したときに不正検知で引っかかればいいんですが、不正検知で引っかからない場合どういうふうに見るのか。
例えば平常時ログが毎日1万件出ていたとします。ただ不正にログイン試行をしている場合は10万件ある。そういったケースもあります。それを見極めるにはどうするか。ログのseverityを見るのではなくinfoレベルのログが平常時よりも多いか少ないかで判断する、といった視点の違いがあります。
まとめ。ログの分類を意識しましょう。目的によって必要なログが異なります。この2点を押さえていただければと思います。発表は以上です。ありがとうございました。
