2018年2月21日（水） 

「たかがログ、されどログ」

 株式会社STNet
 プラットフォーム技術部 セキュリティ技術第1課　　菊澤　弘

 
　うどん県で、日々かまたまうどんをすすりながら、「セキュリティ診断」や「セキュリティインシデント対応」といったセキュリティに関する業務を行っています。
　業務外の活動としては、「セキュリティうどん(かまたま) (※1)」というセキュリティ勉強会の開催にも携わっています。
 
　本コラムでは、私自身が実際のセキュリティインシデント対応の現場で感じたことについて、書きたいと思います。
　なお、対象者については、企業で働く情報システム/セキュリティ担当者向けになろうかと思います。
 
 
　みなさんが、日頃運用しているシステムで障害が発生した場合、まず何から取り掛かるでしょうか？
　おそらく、何らかの「ログ」の内容を確認していると思います。
 
　「インターネット公開サーバへの不正侵入」、「不審メールの添付ファイルを開いてウイルスに感染した」といったセキュリティインシデントが発生した場合についても同様です。
　セキュリティインシデントの原因・被害状況・影響範囲を特定するためには、「ログ」が必須となります。
　ログが存在しない、もしくは断片的なログしか残っていない場合、調査は難航することになります。また、状況によっては調査が手詰まりになる可能性もあります。
 
　ログが取得されている場合であっても、
 
　① 欲しい時期のログが存在していない (保存期間の不足)
　② 内容が簡易すぎて、欲しい情報がない (情報量の不足)
　③ 内容が細かすぎて、人手で確認するのは困難 (可読性の不足)
 
といったこともありますので、「ログの保存期間、取得内容」は非常に重要なポイントとなります。
　特に、③の「人間が見てわかりやすいログ」については、あるとないとでは調査の進捗に大きな差が出ます。
　とあるWebアプリケーションシステムのアカウント不正利用事件について調査した時のことですが、ログがミドルウェア(Webサーバ、DBサーバ)のものしか存在していませんでした。Webアプリケーション上で「ユーザが行った操作」を調査する必要がありましたが、存在しているログだけで調査するのは困難を極めました。その事件の後、Webアプリケーション上で「ユーザ操作のログ」を取得するようにシステム改修が行われたため、現在はセキュリティインシデントが発生しても、迅速かつ「楽に」調査を行うことが可能となりました。
　このような事例から、ログを取得する際には、「セキュリティインシデント対応時の調査」や「不正アクセスの監視」といったログを取得する目的を明確にしておくことが重要だと感じました。
 
　サイバー攻撃が日々増加、巧妙化している今、「セキュリティインシデントが発生することを前提」に、各システムにおいて適切にログを取得する必要があると考えられます。
　セキュリティを意識した情報システムを構築する際に、一般的に取得を検討すると思われるログは、以下のようなものがあります。
 
　(1) ファイアウォールの通信(許可/不許可)ログ
　(2) Webプロキシサーバのアクセスログ
　(3) メールの送受信ログ
　(4) ウイルス対策ソフトの動作ログ
　(5) 認証サーバ(ディレクトリサーバなど)の認証ログ
　(6) ファイルサーバへのアクセスログ
　(7) データベースサーバへのアクセスログ
　(8) DNSサーバのクエリーログ
　(9) DHCPサーバのIPアドレス割り当てログ
　(10) アプリケーションの動作ログ
 
　もう一歩踏み込んだ(お金をかけた)システムでは、以下のようなログも取得可能となります。
 
　(11) 侵入検知/防止システムの検知ログ
　(12) WAF(Web Application Firewall)の検知ログ
　(13) HTTPS(暗号化通信)に対応したWebプロキシサーバのアクセスログ
　(14) 送受信されたメール本文、添付ファイルの内容
　(15) クライアントパソコンの操作ログ
　(16) 通信パケットキャプチャ (インターネット～公開サーバ、内部ネットワーク～インターネット)
 
　様々なセキュリティインシデント対応を実施してきた経験上、個人的には「(15) クライアントパソコンの操作ログ」、「(16) 通信パケットキャプチャ」については非常に重要だと感じています。
 
　不審メールの添付ファイルを開いてウイルスに感染してしまった場合、クライアントパソコンの操作ログ(プロセス起動、ファイル操作など)が調査に必要となります。
　クライアントパソコンの操作ログを取得するには、高価な情報漏洩対策ソフトウェアなどが別途必要だと思われがちですが、Microsoft社から提供されている「Sysmon (※2)」をインストールすることにより、調査をする上で十分なログ(いつ不審なファイルが開かれて、それによって実行されたプログラムが何であるか、インターネットへの通信先、通信を行っているプログラム名など)が取得可能となります。
　Sysmonのログを集中管理したい場合は、SIEM(Security Information and Event Management)をいった大規模なログ管理ソリューションが必要となりますが、ユーザが不審なファイルを実行したことを調査するくらいであれば、Sysmonがクライアントパソコンにインストールされているだけでも十分だと考えられます。なお、標準設定でSysmonを稼働させると、大量のログが出力されるため、ログの保存期間・調査時のコストに影響があります。事前にどこまでのログを取得するか検討して、ログのフィルタリング設定を適宜行うようにしてください。
 
　クライアントパソコンのログ取得について補足となりますが、最近の不審メールに添付されているMS Office文書のマクロウイルスは、最終的に「Windows PowerShell」が実行されて、インターネット上の外部サーバから別のウイルスをダウンロードして実行するケースが多くなっています。あわせて、PowerShellの実行ログについても取得しておくと、調査の際に役に立つ可能性がありますのでおすすめします。
 
　通信パケットキャプチャについては、Webサイト経由でのウイルス感染時の調査に非常に役に立った経験(※3)があります。
　ドライブバイダウンロード攻撃によってウイルスに感染した場合、発見が早ければ感染元サイトに実際にアクセスして、どのような攻撃を受けるのか確認することが可能ですが、感染元サイトは「生もの」なので、ある程度時間が経過すると、「攻撃用コードが何も埋め込まれていない」とか「サイト自体がなくなっている」ことが多々あります。そういった場合、実際にどのようなデータがやり取りされたのか特定することが出来なくなります。ここで活躍するのが、通信パケットキャプチャです。攻撃を受けた時点での通信内容を確認出来るため、どのような脆弱性が悪用されたか詳細な調査が可能となります。
 
　ここまで、ログに関することを長々と書きましたが、セキュリティインシデント対応の現場での経験をもとに、お伝えしたかったことは
 
　① セキュリティインシデントが発生することを前提として、適切にログを取得！
　② クライアントパソコンに「Sysmon」をインストールしておくことをおすすめ！
　③ 費用と手間はかかりますが、通信パケットキャプチャは非常に有用！
 
ということです。
 
　情報システム/セキュリティ担当者の方々が、今後システムを構築・運用していう上で、何らかの気づきを得るきっかけになれば幸いです。
 
---------------------------------------------------------------------------
※1 セキュリティうどん(かまたま)
　　　http://sec-udon.jpn.org/
 ※2 Sysmon - Windows Sysinternals 
　　　https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
 ※3 ITpro「いきなり襲ってきた「mstmp」ウィルスに大わらわ」
　　　http://itpro.nikkeibp.co.jp/article/COLUMN/20101027/353496/
 

※記載内容は執筆者の知見を披露されているものであり、著作権は本人に帰属します。