情報畑でつかまえてロゴ
本サイトは NTTテクノクロスが旬の IT をキーワードに
IT 部門が今知っておきたい最新テクノロジーに関する情報をお届けするサイトです

3.業界内/間の連携によるセキュリティ対策が強化される(その2)

今回は、コンピュータセキュリティに関するインシデント対応をする組織であるCSIRTについて紹介します。

3.業界内/間の連携によるセキュリティ対策が強化される(その2)

はじめに

 前回は業界内/間の連携によるセキュリティ対策の強化の一例として、日本国内の情報連携組織の一例を紹介させていただきました。

 今回は、コンピュータセキュリティに関するインシデント対応をする組織であるCSIRTについて紹介します。CSIRTを配置するとどのようなメリットがあるか、どうやってCSIRTで連携するのか、どのような課題があるかの紹介をしたいと思います。

CSIRTとは

 CSIRTとは「Computer Security Incident Response Team」の略で、年々増加するサイバー攻撃やそれに伴うインシデントを対処するために構築される組織です。CSIRTはインシデントが発生することが前提の組織で、発生前の事前対応を行い未然に防止できる体制を構築し、発生した後でも被害が極小化されることを目的とした組織です。

 CSIRTは実際の業務によって以下に分類されます。

  • 組織内CSIRT
  • 国際連携CSIRT
  • コーディネーションセンター
  • 分析センター
  • ベンダチーム
  • インシデントレスポンスプロバイダ

※JPCERT/CC CSIRT ガイドより抜粋、詳細は以下をご覧ください。
https://www.jpcert.or.jp/csirt_material/operation_phase.html

NCAを通じての業界内/間での連携

 セキュリティのリスクに1つの企業のみで立ち向かうためには限界があります。日本では、日本シーサート協議会(NCA)という組織がありこれを通じて情報共有が行われています。2016年7月1日現在、161チームが加入しています。

 NCAでは新規にCSIRTを構築する組織に対しての支援や、ワーキンググループを開催しています。ワーキンググループとは、会員企業が抱える課題を会員企業同士で協力して解決していく取り組みのことで、現在は13のワーキンググループが開催されています。

参考:日本シーサート協議会ホームページ 
http://www.nca.gr.jp/

NTTグループのCSIRT

 NTTグループでも各社でCSIRTを配置しています。日本電信電話株式会社のNTTセキュアプラットフォーム研究所が中心となって運営している組織であるNTT-CERTをはじめとして、株式会社 NTTドコモ、NTT データ先端技術株式会社、NTTコミュニケーションズ株式会社、株式会社 NTT データ、東日本電信電話株式会社、西日本電信電話株式会社(NCAに記載順)がNCAに加入しています。

 NTT-CERTは、NTT グループ全体に対してセキュリティ関連情報の受付、提供、調査、分析、再発防止策の検討等のサービスを提供しています。脆弱性が発見された場合には、NTT-CERTから情報が共有されます。当社でも2016年7月1日にCSIRT組織を設立してNTT-CERTからの情報をもとに対応を行っています。

CSIRTでの情報共有の例

 CSIRTの活動としては大まかに「未然にインシデントを防止する」と「発生してしまったインシデントの事後対応をする」の2つがありますが、今回のブログのテーマとして「未然にインシデントを防止する」の部分の例を紹介します。

 1つ目は最近発生した脆弱性の例で、2016年4月19日にApache Struts2の脆弱性(CVE-2016-3081、S2-032)の件です。これは、ある条件で任意のOGNLコード(≒Javaコード)の実行が可能となる脆弱性なのですが、攻撃コードの存在や攻撃を受けるサーバ側の設定・攻撃条件などが情報共有されました。

 実際に攻撃を受ける状況になっているかどうかや、今後攻撃を受けないためにはどのような対策を採用すればよいかなどの情報を共有してもらうことによって、インシデントを事前に回避できた例となります。

参考:Apache Struts2公式
https://struts.apache.org/docs/s2-032.html

参考:IPA Apache Struts2 の脆弱性対策について(CVE-2016-3081)(S2-032)
https://www.ipa.go.jp/security/ciadr/vul/20160427-struts.html

 もう1つの例としては、同一の脆弱性でも新たな攻撃手法が見つかり情報が複数回更新されて共有された件があります。こちらもApache Struts2の脆弱性でCVE-2014-0094関連、S2-020関連の少し古い例ですが、以下のような表で示すような経緯となっています。これも任意のOGNLコード(≒Javaコード)の実行が可能となる脆弱性でした。

日付

内容

対処策

CVE

2014年3月5日

CVE-2014-0094 の脆弱性の対策をした Apache Struts 2.3.16.1 が公開された

・Struts 2.3.16.1にアップデート

・WAF等でリクエストを遮断

CVE-2014-0094

2014年4月17日

Apache Struts 2.3.16.1に対策漏れがあるという情報が共有された

WAF等でリクエストを遮断

CVE-2014-0112

CVE-2014-0113

2014年4月24日

Struts 1にも類似の脆弱性が発見されたとの情報が共有された

Struts 1がEOLのため、WAF等でリクエストを遮断

CVE-2014-0114

2014年4年25日

CVE-2014-0112とCVE-2014-0113が対策されたStruts 2.3.16.2がリリースされた

-

-

※IPA Apache Struts2 の脆弱性対策について(CVE-2014-0094)(CVE-2014-0112)(CVE-2014-0113)より抜粋
https://struts.apache.org/docs/s2-020.html

 ここ数年で脆弱性を悪用された情報漏えいやデータの改ざんというインシデントはどんどん増加しており、後を絶ちません。また、今後も脆弱性が完全になくなるとことはないでしょう。そのような時に、CSIRTでの連携を通じていち早く脆弱性の情報を入手し、自社のどのシステムで利用しているソフトウェアなのかということ事前に把握しておくことで、インシデントの発生を未然に防ぐことや発生してしまった場合には影響を受ける箇所や範囲を特定でき、被害を最小限に食い止めることができるでしょう。

 ただし、課題も残っていると思います。セキュリティ担当からは「危険な脆弱性なので、すぐに対応してくれ」という情報が出たが、運用担当からは「現在稼動中のシステムを試験もなしにソフトウェアのバージョンをアップデートするとサービスが停止してしまう可能性もある」といったような声をよく耳にします。企業としても、サービス停止中の損害を被るかサイバー攻撃が発生してしまうかの判断を行わないとならない状況が発生してしまいます。そのような場合の一例としては、ファイアウォールやIDS/IPS、WAF等で一時対処を実施し、並行してバージョンアップデートの試験を行いサービスが続行できることを確認します。試験を充分に行った後に、実際に稼働中のシステムのアップデートを行うといった方法があるかと思います。

 これは対処の一例となりますが、どのような判断を行うかも含めてCSIRTの構築を行う必要があるかもしれません。

おわりに

 今回は、日々高度化するサイバー攻撃に対応するために、企業内にCSIRTと呼ばれる組織を構築し、CSIRT間での情報共有についてご紹介しました。

 次回は、OSSや多様化するAPの脆弱性とそれを狙うマルウェアの拡大をテーマにお伝えします。

「サイバーセキュリティトレンド2016」無料配布中!
著者プロフィール
大森 章充
大森 章充

NTTソフトウェア株式会社
クラウド&セキュリティ事業部
第一事業ユニット