セキュリティ業務における「ログ」の基礎知識――なぜ分析基盤が必要なのか：セキュリティログ分析基盤活用入門（1）（1/2 ページ）

　リクルートテクノロジーズのサイバーセキュリティ部の日比野です。これまで筆者は、オープンソースの全文検索エンジンである「Elasticsearch」を活用し、ログ分析システムの導入を行ってきました。現在は、リクルートテクノロジーズで次期ログ分析基盤の全体構想検討や新技術検証などを進める傍ら、そこで得た技術ナレッジを広く公開することに情熱を注いでいます。

　「セキュリティ人材が約20万人不足している」と言われている中、特にセキュリティログ分析という領域は、フルスタックかつ高い技術力が要求されるにもかかわらずナレッジが少なく、ITエンジニアのキャリアパスとしても確立していません。「数年先に、どのようなセキュリティ脅威が発生する可能性があるのか」「脅威に対応するために学習すべき技術は何なのか」が手探りのため、多くの企業では本格的なチャレンジはなかなかできていないのが現状でしょう。

　そのような状況下において、少しでも先を見渡せるような道しるべとなり得る情報を伝えたい、そんな思いで本連載「セキュリティログ分析基盤入門」を執筆することになりました。

セキュリティ業務における「ログ」とは

　ログと深く関わるようになったきっかけは、2016年1月施行の「改正マイナンバー法」に準拠した、マイナンバー管理基盤のログ管理システムの導入案件でした。その案件での経験を機に、ログ分析基盤の構築やSIEM（System Information and Event Management）製品の導入など、幾つものログに関わるプロジェクトを担当してきました。本連載では、そうした経験の中から得られた知見を幾つか紹介します。

　まず、ログの定義です。ログとは「ある時点における事象の記録」であり、時系列データの一種です。時系列データとは、時間の経過とともに急速に増加するイベントデータのことです。データ内に必ず1つ以上の時刻情報を持っています。

　ITシステムに関わるエンジニアの皆さんは、日頃から何げなく「ログ」という言葉を使っていると思います。多くの方々は「作ったプログラムやシステムが正しく動作しない」「正常に稼働していたサービスが急に使えなくなる」などのトラブルシューティングが起きた際に、システムの出力するエラーログを見て認知されているのではないでしょうか。

　つまり、ログとは「人が見てもすぐに何が起きたのかよく分からない大量の英数字の羅列」という認識であり、何か困ったことが起きない限り、自ら積極的に見ていないのが多くのエンジニアの実情ではないでしょうか。

　しかし、セキュリティの領域では、そのような認識にとどまってはいられません。日本国内では、2014年の内部不正による個人情報流出事件や、2015年の公共機関を狙った標的型攻撃による国民の機密情報漏えい事件以降、ログによる監査や監視のニーズが急速に増加していったように思います。さらに、サイバー攻撃は日々巧妙になり、高度に進化しています。

　昨今のセキュリティ業務におけるログシステムと聞けば、SIEMを思い浮かべる人が多いように思います。しかし、それだけではありません。これまでの運用実績や検討状況なども交えながら、ログの活用方法について解説していきます。

セキュリティ業務におけるログの果たす役割

　セキュリティ業務において、ログは多くの役割を果たすようになってきました。分類方法はさまざまですが、ここではNIST（米国国立標準技術研究所）が公開している、重要インフラのためのサイバーセキュリティフレームワークをベースに、「1.検知目的」と「2.分析目的」の2つの観点でログを用いた業務を大きく分類しています。

NIST CSFで見るログ活用

セキュリティ業務において利用するログの種類

　次に、セキュリティ業務で利用するログにはどのようなものがあるかを見ていきます。セキュリティ対策は多層防御の概念に基づき、外部脅威から保護するために対策を講じるようになりました。つまり、多層化されたことで、多くの種類のセキュリティ製品が企業内の保護対象システムを囲い、脅威から隔離されるようになったのです。

　そのため、さまざまなベンダーの提供するセキュリティ機器や、保護対象システムのサーバ内にあるソフトウェアからログを取得し、単体のログでは見つけることが難しい外部攻撃や内部不正に対して、ログを組み合わせて利用することで見つけられるようにします。

セキュリティ業務で利用するログデータとは

　最近は、オンプレミスのデータセンター環境だけではなく、「Amazon Web Services」（AWS）、「Google Cloud Platform」（GCP）をはじめとするパブリッククラウド環境にシステムを構築するケースも多く存在します。このようにシステムを構築する場合、ハイブリッド環境に合わせたログ取得が必要になります。

　AWSであれば、「AWS CloudTrail」を中心に各サービスのログを「Amazon S3」「Amazon CloudWatch Logs」に格納して、監査や監視に利用できます。また、GCPでは「Cloud Audit Logging」という、各サービスで取得可能なデータアクセスログの一覧があります。こちらの表で取得したいサービスのログを確認し、有効化することにより「Stackdriver Logging」に蓄積することができます。

ログを利用するセキュリティ業務とは

　リクルートテクノロジーズのSOC（Security Operation Center）では、ログを利用するセキュリティ業務をさらに4つに分類しています。分類に際しては、「【1】非定型／定型」の縦軸と「【2】長期/短期」の横軸の2軸によるマトリックス上に業務をプロットしています。その他にもいろいろな軸で分類できると思いますが、選定するログ分析ツールの機能整理を行う上でこの分類としています。

　なお、この分類はこれまでの検討の中で、「アドホックなクエリに向いているかどうか」「サブクエリによる絞り込みが効率良く実施できるかどうか」「長期的な時系列データの保持に適しているかどうか」などを考慮してきた経験に基づいています。

　各業務の説明は以下の通りです。

セキュリティ運用における「ログ」とは

フォレンジック業務（分析目的）

　後述する監視業務と監査業務はどちらかといえば、プロアクティブな行為になります。一方、このフォレンジック業務はインシデント発生後の事故対応で実施するリアクティブな業務となり、法的に効力のある状態（改ざんされていない状態を保証できること）でログを適切に管理します。

　また、いつから事象が起きていたのか、もしくは過去のどの時点で発生したのかを正確に押さえる必要があるため、1〜5年という長期間にわたるログの保持が定められていることがあります。具体的には、不正を行ったユーザーの氏名もしくは漏えいしたファイル名などを頼りに絞り込んでいくことになります。

ハンティング業務（検知目的）

　このハンティング業務は、多くの方にはあまりなじみがないかもしれませんが、主にプロアクティブに未知の脅威を探索する活動になります。まだ世に出ていないような攻撃の予兆をログから一本釣りするようなもので、専門性の高いスキルが要求されます。検知のロジックが確立されていない状況で、攻撃者観点によるログ探索を行うため、高度で長いアドホックな検索クエリを書く業務特性があるともいえます。

　また、この業務で検出した脅威を深堀りして分析することで、問題が大きくなる前に対策を施すことが可能となり、影響を極小化できます。さらに汎用（はんよう）化できたロジックは、そのまま監視業務に利用されることもあり、監査業務のレポートに取り入れられるケースもあります。

監査業務（検知目的）

　SIEMなどの決まった監視ロジックを用いて、内部不正を検知させるのは非常に難しいことです。内部で不正行為を働く人間は、内部システムに対する理解があり、システムに対して適切な権限があります。そのため、正常な業務による操作との違いを見つけることが困難になるのです。

　よって、過去のトレンドやログの中身などにも踏み込んだ監査レポートを作成し、不正の予兆がないことを確認します。この監査レポートの元データがログになります。

監視業務（検知目的）

　いわゆるSIEMの領域です。監視システムにログを取り込み、自動的に脅威や不正を検知させ、検知をトリガーにインシデント対応を行います。検知対象は、主に悪意のあるハッカーからの外部攻撃です。

Copyright © ITmedia, Inc. All Rights Reserved.