このサイトは企業・組織の情報セキュリティ担当者が、情報セキュリティ対策を推進していく上で、疑問に思っていること、困っていることに対して、種々の情報や解決策を提供することを目的としてします。
第１章 インシデント発生前に実施しておくべき技術的対策（1/2）
第１章 インデント発生前に実施しておくべき技術的対策
1.マルウェア侵入後の活動を防御遮断する技術的対策
2.インシデント調査を行うためのログの取得と保管
2.1保存しておくべきログの種類と対象事象
2.2各ログの保存期間
2.3ログの時刻の同期
2.4ログの保護及び保管の仕組み
3.ログ等を総合的に分析し、攻撃を早期に検知するための技術的対策
インシデントが発生した際にいかに適切に対応できるか否かは、インシデント発生前に対策をいかに整備しておくかにかかっています。インシデント対応手順等を作成して、想定されるインシデントのシナリオ毎にどのように対応すべきか、予め決めておくことも重要ですが、いざインシデントの被害状況や被害範囲、マルウェアの感染経路を調べようとしても、調査を行うためのログなどのデータが適切に取得・保存されていないのであれば、十分な調査ができず、何も解明できないということになりかねません。そこで、第１章ではインシデント発生前に実施しておくべき技術的対策について考えたいと思います。
まず、マルウェア侵入後の活動を防御遮断し、その活動を検知しやすくする仕組みについて考えます。マルウェアが侵入後に外部や他の端末、サーバと自由に通信を行えないよう遮断する仕組みを導入します。この通信ログ等を確認することにより攻撃の活動を早期に検知することが可能となります。
次に、インシデントの調査を行うため、どのようなログを取得し、どの程度の期間、どのような方法で保管しておくべきかについて考えます。
3つ目は、ログ等を総合的に分析し、攻撃を早期に検知できる仕組みについて考えます。攻撃の活動を検知するためには、一つのログを分析するだけでは見つからず、複数のサーバや通信機器のログを総合的に分析することが必要と言われています。このような解析作業を行うためにはどのような対策が必要かを考えます。
1. マルウェア侵入後の活動を防御遮断する仕組み
各企業、各組織では標的型攻撃の入口対策として、マルウェアが侵入する入口であるメール受信、ウェブサイトアクセス、USBメモリ接続などにおいてウイルス対策ソフトウェアなどを導入し、検知・防御対策を行っています。しかし、攻撃者も防御側の弱点などをついて、ウイルス対策ソフトウェアでは検知されない新種のマルウェアを添付し、巧妙な標的型攻撃メールを送りつけるなど、様々な攻撃を仕掛けてくるため、入口対策において100%マルウェアなどの侵入を防ぐことはできません。防御側としては、標的型攻撃によるマルウェアの侵入は避けられないものと考え、侵入後いかに早く攻撃者の活動を検知し、被害を最小限に抑えるかに対策の重点を置くことが必要と言えます。
マルウェア侵入後、いかに早くマルウェアや攻撃者の活動を検知するためには、マルウェアや攻撃者が活動しにくい環境を整備し、各通信機器のログを観察することが必要となります。具体的には、端末などがマルウェアに感染後、マルウェアがC&Cサーバと自由に通信を行うことができないよう、プロキシサーバ経由でない通信はファイアウォールでブロックするとともに、プロキシサーバで認証をされない通信についてもブロックする、感染端末を攻撃拠点として他の端末やサーバに攻撃を拡大できないよう、ネットワークのセグメントを細かく分割する、などのネットワーク設計を行い、ブロックされた通信のログなどを定期的に確認します。
詳しくは、内閣官房内閣サイバーセキュリティセンター（以下、「NISC」という。）『高度サイバー攻撃対処のためのリスク評価等のガイドライン付属書』（平成28年10月7日）の『付属書2.標的型攻撃への対処のための対策セット5.(1)侵入基盤構築段階』 に記載されている不正通信に対する監視及び防御対策等を参照して下さい。標的型攻撃の侵入基盤構築段階及び侵入範囲拡大段階における防御遮断対策、監視対策が詳しく記載されています。参考までに、上記付属書に記載されている表9及び表11の対策セット一覧を以下に掲載しておきます。
【侵入基盤構築段階における対策セット一覧】（上記付属書表9より抜粋）
防御遮断策
遮断1-1 ネットワーク通信経路設計により、ファイアウォールで不正通信を遮断する。
（筆者注：プロキシサーバを経由しない通信をファイアウォールで遮断）
遮断1-2 プロキシサーバにおけるアクセス制御により不正な通信を遮断する。
（筆者注：標準的に利用しない通信ポートを塞ぎ、遮断）
遮断1-3 プロキシサーバの認証機能により不正な通信を遮断する。
監視強化策
監視1-1 プロキシサーバ経由の通信を一度強制的に切断し、その時に発生するログ等により、
C&C サーバへの再接続を行う不正な通信を調査・発見する。（筆者注：正常な通信に
ついては再接続が発生しないため、不正通信の発見に役立つとのことであるが、業務
への影響を与えないよう注意する必要がある。）
監視1-2 プロキシサーバの認証失敗ログ等を 分析し、不正な通信を調査・発見する。
【侵入範囲拡大段階における対策セット一覧】（上記付属書表11より抜粋）
防御遮断策
遮断2-1 ユーザ端末とシステム管理端末を分離し、ユーザ端末からシステム管理端末へアクセ
スできないようにネットワークを分離する。。
遮断2-2 適切なセグメントの分離設計とネットワークセグメント間のアクセス制御を実施する。
遮断2-3 ユーザ端末間でのファイル共有や 管理共有を禁止(無効化又は遮断) し、ファイルサー
バとのみファイ ル共有を許可する。
遮断2-4 高い管理者権限(Domain Admins 等)のアカウントのキャッシュを 禁止する。
監視強化策
監視2-1 高い管理者権限アカウントに似せたトラップアカウントをユーザ端末に仕込み、当該
アカウントを用いた攻撃者のロクイン行為を検知する。
2.インシデント調査を行うためのログの取得と保管
全ての機器のログは取得し、保管しておくのが最良ですが、ログは大量に発生し、そのためのディスクの領域を十分に確保しないとシステム障害の原因になることもあります。そのため、運用上、ログの保管期間を短めに設定して一定期間経過後は自動的に消去している場合も多く、インシデントの調査を行おうとした場合に過去に遡って調査ができないという事象が発生するケースが多いようです。従って、ここではインシデント調査を行うためにどのようなログをどのくらいの期間、保管しておくべきかを考え、必要な期間、保管するための仕組みについて考えます。
インシデントが発生した場合の調査を行うため、どのようなログを調査し、各ログはどのくらい保管しておけばいいのかについては、一般社団法人JPCERTコーディネーションセンターの『高度サイバー攻撃（APT）への備えと対応ガイド』、『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』が参考となります。
2.1 保存しておくべきログの種類と対象事象
『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』の「3.2. 主な機器で採取できるログ」では、モデルネットワークに含まれる機器 (メールサーバ、Firewall、Web プロキシ、DNS サーバ、認証サーバ) のそれぞれについて、どのようなログが記録されるか、以下のとおり説明しています。機器によっては、デフォルトで設定されるログ以外の、より詳細なログを採取する設定や、ログの出力形式のカスタマイズが可能な場合もあるとしていますが、具体的な設定や出力の詳細は、各機器のマニュアルのログの設定と出力に関する事項を参照されたいとしています。モデルネットワークは単純なモデルなので、DHCPサーバのログなどが抜けており、それぞれの環境に適したログを採取する必要があります。
• メールサーバログについて
メールサーバでは、受信メールと送信メールの双方のログを採取できる。受信メールのログでは、組織外からのなりすましメールや、実行ファイル添付メールを検知できる可能性があり、送信メールのログでは、疑わしい宛先に送信されたメールを検知できる可能性がある。
メールサーバログ項目
ログ項目 ：ログ項目の内容
From ：メールクライアントで表示される表記名、送信者アドレス、実際のメール送信者アドレス
Content-Type, Content- Disposition ：添付ファイル名
• Firewall ログについて
Firewall は、ネットワークを内部と外部に隔てるために導入され、Firewall によって形成されたネットワーク境界の通過を許された、もしくは拒否した通信がFirewall のログに記録される。攻撃者が外部にいて、内部のシステムを遠隔から操作している場合には、そのための通信が Firewall を通過しており、その痕跡が Firewall のログとして記録されている可能性がある。
また、ネットワークの一部を他の部分から隔離してセキュリティを高めるために Firewall が利用される場合もある。例えば、重要なサーバ用ネットワークを従業員の PC を設置したネットワークから分離、あるいは、オフィスフロアや部署ごとにネットワークを分離するために Firewall を設置するのである。この場合には、マルウエアに感染した PC が、認証サーバや他の PC などにアクセスした痕跡をログ中に発見できる可能性がある。
以下の表に、本書で想定する検知方法において必要なログ項目を挙げる。Firewall のログは多量になるため、機器内に保存するのではなく、機器外の Syslog サーバやSIEM などに、ログを保存することが望ましい。
Firewall ログ項目
ログ項目 ： ログ項目の内容
Action ：Firewall ポリシーのアクション
dst zone ：送信先のゾーン設定
Src ：送信元アドレス
src_port ：送信元ポート
Dst ： 送信先アドレス
• Web プロキシサーバログについて
Web プロキシサーバは、組織内からインターネット上の Web サイト等へアクセスするためのパケットが通過するため、そのアクセス記録をログとして採取することができる。
Web プロキシサーバでは、PC からの Web サイトを閲覧するためのリクエストを全て記録することができる。HTTP や、HTTPS、FTP などの通信プロトコルを用いてC&C サーバと通信するマルウエアの活動の一端なども記録できる可能性がある。特に、マルウエアと C&C サーバとの通信については、Firewall のログよりもWeb プロキシサーバのログの方が、より多くの情報を得られる可能性がある。
以下の表に、本書で想定する検知方法において必要なログ項目を挙げる。Web プロキシサーバに残されるログには、マルウェアに関する通信だけでなく、正規の通信も含まれており、さらに、利用者が強く意識していない、ソフトウェアやプラグイン等のアップデートの際の通信も含まれる。Web プロキシサーバのログの調査では、正規の通信か否かを判断できるよう、使われている端末の OS やブラウザを調べて把握しておくことが望ましい。
Web プロキシサーバログ項目
ログ項目 ：ログ項目の内容
URL ： URL アドレス、送信先サイトのポート
method ：メソッド
UserAgent ： UserAgent
accesstime： アクセス時間
• DNS サーバログについて
DNS サーバでは、ホスト名の解決を行ったクエリ記録をログとして採取することができる。通常
DNS サーバは、権威サーバとキャッシュサーバの 2 つの役割があるが、痕跡の分析を行う場合は、組織内の PC やサーバからの要求に対して応答を行う、組織内部向けのキャッシュサーバのログを活用する。 キャッシュサーバのログには、マルウエアに感染した PC が、C&C サーバと通信する際の、ホスト名の解決を行ったクエリ記録が残る可能性がある。組織によっては、DNS サーバを複数稼働させたり、用途によりサーバや設定を分けたりすることもあるため、その構成の場合は、キャッシュサーバの役割を持つ DNS サーバのログを採取することが望ましい。
以下の表に、本書で想定する検知方法において必要なログ項目を挙げる。
キャッシュ DNS サーバログ項目
ログ項目 ： ログ項目の内容
clinet ：名前解決を行おうとしている PC 等の IP アドレス
query ：要求および応答したホストや IP アドレスの情報
• 認証サーバログについて
組織内の認証や権限の付与を集中管理する認証サーバが設置されることもある。認証サーバは、Active Directory やLDAP、RADIUS などが用いられ、利用者が誰であるかを識別し、ユーザやコンピュータの権利と権限などを一元管理する。組織内のユーザが、ネットワークコンピュータにログオンする際やサーバの利用権の確認などが行われる際に、ログとして記録される。ここでは、認証サーバとして用いられることが多い Active Directory を例にとって説明する。
マルウェアの中には、認証サーバや他のサーバにアクセスし、認証や権限昇格を行うものがある。マルウェアからのアクセスを含むユーザ認証のログや監査ログが認証サーバで記録される。ただし、そのログは、Windows イベントログとして記録されるため、他の機器やサーバのように検索を行うことはできない。そのため、Windows のイベントビューアーより、テキスト形式や、CSVファイル形式のファイルに保存した上で検索を行う。また、Windowsは、ログをエクスポートするためのインターフェースが他の機器とは異なるため、Syslogサーバなどでログを収集して保存する場合には、専用のソフトウエアの使用など工夫が必要となる。
上記ログの解説の出典：JPCERT『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』
『高度サイバー攻撃（APT）への備えと対応ガイド』の中では、「JPCERT/CC による過去の米国業界のベストプラクティスについての調査として、6 つのログ種別が分析において最も有用と判断された」として、以下のログを挙げています。おそらく、米国の資料を直訳していると思われるので、各ログの右側の説明部分は少しわかりにくい説明となっています。また、「こうした特定のログは、収集後長期間（1 年以上）保管することで、長期的な時間軸での攻撃者の活動の調査に有効利用できる。推奨されるログ保存ポリシーについて、ベストプラクティスや様々な機関からの情報やその他の要素をもとに検討するべきである。」とも説明しています。
• DNSログ –ネットワーク上のホストからの完全修飾ドメイン名についてのクエリ
• プロキシログ – LAN上のIPアドレスが要求したサイトやページ、ファイル21
• ファイアウォールログ– インターネット上のIPアドレスに対するアウトバウンド接続（IPアドレスおよびポート）
• NetFlow –アウトバウンド接続およびインバウンド接続（IPアドレスおよびポート）のトラフィック種別ごとの概要、およびネットワーク上で非常に頻繁に接続を行う者（トーカー）の概要（筆者注： NetFlow（ ネットフロー ）とは、ネットワーク上で流れるトラフィックフローを受動的にモニタできる機能のこと。ネットワーク・トラフィックを分析して、ネットワーク上の発信元、宛先、トラフィック量、およびパスを特定するために使用されます。）
• サーバログ – 各サーバ（数は少ないがより重要なシステム）のアクセスおよびログイン要求（成功または失敗）。
• ホストログ – 各端末（従業員が使う全てのコンピュータ）のアクセスおよびログイン要求（成功または失敗）。
上記ログの解説の出典：JPCERT『高度サイバー攻撃（APT）への備えと対応ガイド』
上記のログのうち、DNSログ、プロキシログ、ファイアウォールログについては、すでに『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』にて解説済みです。新たに挙げられたNetFlow、サーバログ、ホストログのうち、サーバログ、ホストログについては、JPCERT『インシデント調査のための攻撃ツール等の実行痕跡調査に関する報告書』に解説があります。それによれば、Windows の標準設定では調査のために十分なイベントログを取得できないため、監査ポリシーで各監査項目を有効にする必要があり、また、Sysmonをインストールすることを推奨しています。Sysmonとはマイクロソフトが提供するツールで、これをインストールすることにより、プロセスの起動、ネットワーク通信、ファイルの変更などをイベントログに記録することができ、イベントビューアーから記録されたログを確認することができるようになります。
これらのログは、分析において最も有用と判断されたログですので、『高度サイバー攻撃（APT）への備えと対応ガイド』付録文書『ログ保管に関する分析レポート サイバー攻撃への対応のためのログ管理に関する考察』では、前述のログ以外に役に立つ可能性のあるログ種別として、以下のログを挙げています。
• "VPN ログ：（途中略）攻撃者は正当なリモートアクセスと他の認証情報を獲得し、通常監視されていない正当な通信に紛れ込むことで、目的を達成する可能性を高めることができる。このため防御側では多くの場合、VPN ログの取得と定期的なレビューが必要となる。"
• "DHCP ログ：（途中略）DHCP ログは、ID、日付、時刻、説明、IP アドレス、ホスト名、MAC アドレスを記録する。リースされた IP アドレスがいつ更新されたか、または留置されたか、動的更新が成功したか否か、server authorization イベントがあったか否か、それがどのように進行したかを説明することができる。IP アドレスの追跡は特に DoS 攻撃元の追跡に役に立つ。DHCP ログは不正な侵入がいつどこで行われたかを大まかに特定するのに有用だが、ネットワークに数百台のコンピュータがある場合、その中の１台を特定するのは難しいかもしれない。それゆえ DHCP ログの利用は、ログをすべて検索して何かを見つけ出すのではなく、探すものが予めわかっている場合に最適である。"
• IDS アラートデータ：IDS はネットワークやシステム上での悪意のある活動やポリシー違反を監視し、レポートを生成する。攻撃者が標的ネットワークへの攻撃計画を立てるために試験的な侵入を試みる段階の動きをトレースすることにより、攻撃がおこなわれる前に攻撃元を追跡し、IP ネットワークのパケットログ収集とリアルタイムトラフィック分析を開始するために利用できる。プロトコル分析、コンテンツ検索、コンテンツ照合をおこない、探索や攻撃を検知する。IDS は主に３つのモードで動作する。スニファ（パケットを読む）、パケットロガー（パケットのログを取得する）、ネットワー ク侵入検知（ネットワークトラフィックを監視し定義されたルールセットに違反しているかどうかを 分析する）。しかしながら、完璧ではないし、誤検知や見当違いの警告も多い。IDS の警告は有用なソースだが、別方向から検証されるべきである。
• パケットキャプチャ（PCAP）：PCAP は実際の生のトラフィックを収集したものである。PCAP の保存における難しい問題は、それが短期間で膨大な量に膨らむということである。リアルタイム分析やインシデントレスポンスにおいては非常に有用だが、多くの組織ではこれを長期間にわたって収集することはできない。
• "Email ログ：Email は様々な攻撃者にとって一般的な攻撃ベクターである。フィッシング（足場を確保するための大量の試み）、スピアフィッシング（重要な機能エリアへアクセスするための中規模の試み）、whaling（特定の重要人物を狙ったメール）は多くの組織で経験されている。ログデータとEmail のオリジナルを管理することは侵入者の初期の行動を特定するのに使える。また、フィッシングメールの受信を報告する人がごくわずかでもいれば、ログをチェックして他の受信者を見つけ、彼らが悪意のあるコンテンツをダウンロードしていないかどうかを確認することができる。"
• アンチウィルスログ：いくつかの組織では、彼らが遭遇したのがどんなマルウェアかを特定するためにアンチウィルスログをチェックしている。これはシステム上の他の問題を浮かび上がらせ、組織が侵害される最も一般的な方法についてセキュリティチームが理解するのを助ける。組織内のすべてのシステムが最新の定義ファイルにアップデートしていないこともありうる。もし攻撃のキャンペーンを示す妥当なインディケータがあるなら、どのシステムがその侵入を止めたかという情報を得ることはインシデントレスポンスの観点からは重要なことである。
上記ログの解説の出典：JPCERT『高度サイバー攻撃（APT）への備えと対応ガイド』
以上から、インシデント調査を行うために必要なログは、メールサーバ、Firewall、Web プロキシ、DNS サーバ、認証サーバ、DHCPサーバのログ、NetFlow、各サーバ、端末のイベントログであり、その他に役に立つ可能性のあるログ種別として、VPNログ、IDSアラートデータ、パケットキャプチャ、アンチウイルスログが挙げられています。主なログについてはどのような項目を記録すべきかについては、上に記載されている通りですが、VPNログ、IDSアラートデータ、パケットキャプチャ、アンチウイルスログ等については、スタンダード的なものはなく、製品によって違うものと思われるため、具体的な設定や出力の詳細は、各機器のマニュアルのログの設定と出力に関する事項を参照する必要があると思います。
JPCERT『高度サイバー攻撃（APT）への備えと対応ガイド』では、ログの分析に当たっては、追加情報が有用となることが多いので、ストレージの制約が許す限りログはできるだけ詳細に取得するのが最善であると記載しています。もしストレージが問題であれば、一部のログはあらかじめ除外してもよく、例えば、アンチウイルスベンダとの通信、OS のアップデート、通常のビジネスパートナーの Web サイトとの通信など、ログのトラフィックの多くを占めるものがそれに該当するとしています。
2.2 各ログの保存期間
ログの保存期間については、内閣サイバーセキュリティセンター (NISC) は、平成 24 年にログ保存期間として 1 年以上を推奨しており、JPCERT/CC でも、インシデント対応支援や高度サイバー攻撃の調査等の結果から、ひとつの参考値として１年分のログを保存することを推奨しています。しかしながら、長期間にわたる高度サイバー攻撃や、採取したログを統計的に調査して初めて検知できるマルウェアもあるため、ログを調査すべき期間は長引く傾向にあります。JPCERT『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』では、Mandiant 社のレポートによれば、標的型攻撃は平均で 1 年程度、最長では 4 年 10ヶ月継続していたことのほか、IPAの報告として、標的型攻撃メールが 9 組織に対して 31 ヶ月間に渡り送られる攻撃を確認したことを紹介しています。
JPCERT『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』では、ログ保存期間は１年以上にすることが望ましいとしながら、もう一方でログを長期間保存する場合のコストがかかることから、直近 3ヶ月のログをオンライン保存し、3ヶ月を経過したらオフライン保存に変える方法も提案しています。
2.3 ログの時刻の同期
JPCERT『高度サイバー攻撃への対処におけるログの活用と分析方法1.1版』では、ログの分析においては、単発的な事象の有無の確認だけでなく、事象が発生した時刻を確定し、複数の事象が発生したタイムラインを明らかにすることも重要な旨、解説しています。特に、複数機器で採取されたログを分析してタイムラインを作成する際には、各機器のタイマが正しく設定されていなければ、Web プロキシサーバ、DNS サーバ、Firewall など複数のログを付き合わせて、時間軸での攻撃の流れを正確に把握することが難しくなります。
機器のタイマは、わずかな誤差であっても累積することにより、同期を行わないとずれが生じますので、正確なタイムラインを作成するため、正しい時刻でログが記録されることが望ましく、NTP を活用することが有効です。
2.4 ログの保護及び保管の仕組み
ログの時刻の同期と同様に重要なことは、記録されたログが攻撃者によって削除されたり改ざんされたりしないよう、ログを対象となる各種サーバ、監視機器等と別の場所に保管したり、ログのアクセス制御を適切に実施することです。
ログを採取できる機器の中には、記憶容量の余裕がわずかで、十分な量のログを保存できないものもあります。また、機器によっては、再起動するとログが消えてしまうものもありますので、各機器で採取したログを集約し、Syslog サーバなど長期保存に適したサーバに保存するとともに、それにより攻撃者からの改ざん・破壊行為から保護する仕組みを導入することができます。また、SIEM (Security Information and Event Management) を導入していれば、製品によってはログの分析だけでなく、長期のログ保存機能を備えている場合もあります。