PRODUCT

製品/サービス

CSIRT業務にLanScope Catを活用!

CSIRT業務にLanScope Catを活用!
ホワイトペーパー

本記事の関連資料をご紹介します!
「未知の脅威に対抗するエンドポイントセキュリティ対策」

目 次

・LanScope Catは、CSIRT業務に使えるのか?
・【1】MOTEX-CSIRTの体制
・【2】LanScope Cat Ver.9.0から追加された「アプリ通信ログ」をフル活用!
・CSIRT業務にLanScope Catを!

CSIRT(Computer Security Incident Response Team)とはCSIRTとは、会社や組織内のPCやネットワーク上で問題が起きていないかを監視すると共に、万が一問題が発生した場合にその原因解析や影響範囲の調査を行ったりする組織の総称です。MOTEXでも、2017年4月に「MOTEX-CSIRT」を発足。日々起こる様々なインシデント対応や社内のセキュリティ強化に奮闘しています。

LanScope Catは、CSIRT業務に使えるのか?

まず、結論を先に言います。「LanScope Catは、CSIRT業務に使えます!」
逆に「LanScopeなかったら、どうなるんだろう?」というぐらいです。今回は、私たちMOTEX-CSIRTが、どのようにCSIRT業務にLanScope Catを使っているのかをご紹介させていただきます。
CSIRTが設立された、あるいは設立準備中という会社も多いと聞いています。CSIRTの方もそうでない方も、LanScope Catの活用の可能性を感じていただければと思います。

【1】MOTEX-CSIRTの体制

さて、一般にCSIRTが取り扱うセキュリティインシデント対応については、以下のような流れで進むのではないでしょうか。

MOTEX-CSIRTの体制の図

MOTEXではこの流れを併記のサービス・ツールを使って行なっています。自分たちの情報収集、社外からの連絡以外にKCCS(京セラコミュニケーションシステム)の提供するSecureOWLサービスによる異常通信検知、プロテクトキャット(CylancePROTECT)による事前予防、LanScope Catでの原因追跡といった組み合わせです。

とくに、MOTEX-CSIRTは、設立から1年強と経験も浅く、兼務メンバーばかりで、まだまだCSIRT業務は勉強中という状況です。そのため、主体的能動的に動くというよりも、アラームや通報・連絡を受けて動き始めることが多いのが正直なところです。

そんなMOTEX-CSIRTが動き始めるトリガーとしては、KCCSのSecureOWLサービスからのアラーム連絡が、優先度・頻度の点で高くなっています。このサービスでは、AI型の異常通信検知システムであるDarkTraceによって、弊社社内からの不審な通信が検知され、SecureOWLサービスのノウハウで、フィルター・解析されたものが、弊社に通知されます。[図1]
Dark Traceからの通知

[図1]Dark Traceからの通知

この通知を受け、アラーム内容はどういった問題なのか、それとも問題はないのかを追うのに活躍するのが、LanScope Catになります。これは、警察などの外部からの連絡の場合も、次世代Firewallなどの場合も、同様ではないかと思います。CSIRTに渡される情報の典型的なものが、通信元通信先のIPアドレス、ポート番号ではないでしょうか。それらから、端末を特定したり、通信先を調べたり、その当時、端末使用者が何をしていたのかを調べたり、通信しているプログラムが何なのかを調べたり、ということをされると思います。

先の通知の例には、対象端末とその通信先IPアドレスが記載されています。ここから様々の状況を追跡・特定するのですが、これがなかなか簡単ではありません。例えば、端末特定ひとつとっても、かつての私たちのようにDHCPのログを残しておかないとお手上げです。

また、相手先通信ポートから「きっと、コインマイナーだ!」とわかっても、発信元のプログラムは特定できなかったり。

そして、最もお手上げなのが、端末使用者へのヒアリングです。「昨日の◯◯時ごろ、ご利用のPCで何かされてましたか?」と聞くと、十中八九「え?特にいつもと違うことはしてないです。」という答えが返ってくるのではないでしょうか。DHCPの例に限らず、私たちMOTEXもそうでした。

そう、LanScope CatがVer.9.0になるまでは・・・

【2】LanScope Cat Ver.9.0から追加された
 「アプリ通信ログ」をフル活用!

◆ 通信元の端末を特定から詳細把握まで

LanScope Catでは、Ver.9.0より「アプリ通信ログ」が追加されました。端末内のプロセスが行う通信を、相手先のIPアドレス/ポート番号、自身のIPアドレス/ポート番号とセットでログとして取得します。外部から連絡のあった不審な通信も容易に端末・プロセスが特定できるようになりました。

これらの特定には「アプリ:アプリ通信の正常ログ」と「操作:ウィンドウ切替の正常ログ」が有効です。[図2]

図2 クライアントログの検索画面

[図2]クライアントログ検索画面

ログを見ると、その時間帯に様々なプロセスが様々の通信を行なっていることがわかります。[図3]
図3 クライアントログ検索結果

[図3]クライアントログ検索結果画面

さらに、相手先のIP(40.76.XX.YY)で絞り込むと、mstsc.exe(RDPクライアント)によるRDP通信であることがわかります。[図4]
図4 クライアントログ検索結果

[図4]クライアントログ検索結果画面-IPアドレスで絞り込み

また、操作ログで絞り込むと、ユーザーがリモートデスクトップ接続クライアントを使用しMicrosoft Azureに意図して繋いでいたことがわかります。[図5]
図5 クライアントログ検索結果画面

[図5]クライアントログ検索結果画面-操作ログで絞り込み

ぜひCSIRT業務にLanScope Catを!

このように、LanScope Catでは、Windowsやプログラムの動作ばかりをログにするのではなく、人の操作にフォーカスしたログを取得しています。
なので、たとえ端末使用者から「特に変わったことはしていません。」というような返事が返ってきても安心です。プログラム動作という大量のログに埋もれることなく、その人がどんな操作をしていたのか、容易に判断できます。人の操作が特定できれば、不審な通信の発生原因や不審プログラムの流入経路が特定できます。これが特定できれば、同じことを他の社員がしないように、ブロックしたり注意喚起したりすることができます。つまり事後対策の延長で、再発防止ができます。

ぜひ、CSIRTのみなさんには、事後対策を事前予防に繋げるためのツールとして、LanScope Catをご活用いただければと思います。