その発表は突然に～JTBを襲った標的型攻撃～
友人や知人が被害にあった最近のインシデント（事故）の1つに「JTBに対する標的型攻撃」があります。筆者はJTBを利用したことがないので、幸い（？）被害にはあってないのですが、数百万人分の個人情報が流出した可能性ってのは、かなり迫力ある被害概要です。
- 不正アクセスによる個人情報流出の可能性について（JTB Webサイトより）
- http://www.jtbcorp.jp/jp/160614.html
上記Webページに記載されている内容からは、「約793万人分[1]の個人情報」流出の可能性がある、としています。
攻撃認識から報道発表に至るまでの時系列～まずは冷静に事態を把握する
以下は、Webページ「不正アクセスによる個人情報流出の可能性について」に掲載された内容ですが、この中に、インシデント発生から対応までを見た時の重要なポイントがいくつか含まれています。
- 1．経緯
- （1）3月15日（火）、取引先を装ったメールの添付ファイルを開いたことにより、i.JTBのパソコンがウイルスに感染しました。この時点ではウイルスに感染したことに気がつきませんでした。
- （2）3月19日（土）～24日（木）、i.JTB内の本来個人情報を保有していないサーバーにおいて、内部から外部への不審な通信が複数確認されました。
- （3）不審な通信を特定し遮断すると共に、ネットワーク内の全てのサーバー、パソコンの調査を行いました。その結果、サーバー内に「外部からの不正侵入者が3月21日（月・祝）に作成して削除したデータファイル」の存在を、4月1日（金）に確認しました。
- （4）外部のセキュリティ専門会社と共同で、ウイルスを駆除するとともに、データファイルの復元と不正なアクセスの調査・分析・対応を継続して行いました。
- （5）5月13日（金）、復元したデータファイルに個人情報が含まれることが確認され個人情報流出の可能性があることが判明いたしました。それを受け、ジェイティービー（グループ本社）内に「事故対策本部」を設置いたしました。
- （6）直ちに、データの正規化に着手し、今般、復元したデータファイルに約793万人分の個人情報が含まれていたことが判明いたしました。
- （7）本件については警察に相談をしております。
標的型攻撃は「やる気満々の攻撃者」による「攻撃対象に特化した仕掛け」を駆使する攻撃
標的型攻撃は、標的を定めて攻略する攻撃であることから、一般的な攻撃とは異なる特徴を備えています。標的の中でよく流通している用語を用いたり、よく情報をやり取りする相手の癖をメールにちりばめるなどして、攻撃対象を信用させ、メール内に記載されたURLや添付ファイルを開かせようとします。
対照的なやり口に「ばらまき型メール攻撃」などがありますが、このような攻撃の例は、最近「複合機などからの通知や企業からの文書を装ったマルウェア」を添付したメールが届くという形でよく見られます。このようなメールは（開かずに）少し放っておけば、勝手にウイルススキャナが発見・駆除してくれる一方、標的型攻撃に使われるマルウェアは、ウイルススキャナに検知されないことも多いです。
標的型攻撃はいわば、「やる気満々の攻撃者」による「攻撃対象に特化した仕掛け」を駆使する攻撃ともいえます。このような攻撃者が求めるものはさまざまですが、今回の場合は攻撃対象が保有する（大量の）個人情報を求めたように見えます。
第一報の遅れと対応体制構築の遅れ～適切な対処をすべて帳消しにして、余りある不適切な対処の代表格～
筆者が対応の経緯を読んで「すごい」と感じたのは、不審通信の特定と通信遮断を早期に実現しているところでした。
一方で、経緯中の（4）のタイミングまでウイルスの駆除などの局所的な対処にとどまって、「事故対策本部の設置」が5月13日まで行われなかったことは、かなり大きなミスといえます。
攻撃されていることを認識してからエスカレーションまでの時間がかかりすぎたとも取れますが、「まずしかるべき責任者に一報を入れ、対応を促す」ことが、不測の事態に対応するための基本動作であることは言うまでもありません。
専任部署／担当者の不在～さすがにちょっと驚いた内容
インターネット経由でのサービス提供を行っているJTB内に、セキュリティ専任統括部門が存在していなかったのは、ちょっと驚く内容でした。この内容は、JTB Webサイト中に掲載された「不正アクセスによる個人情報流出の可能性について」の「5．対策」中に以下のように記載されたことを判断根拠としています。
「ジェイティービー（グループ本社）内にITセキュリティ専任統括部門を設置いたします。」
むしろ専任部署がない状態で、検知から対応までをやっていたというのは「よく対処していた」ともとれるでしょう。しかし、情報を抜かれてしまった「可能性がある」となっては、不用意の誹りを免れません。
適切な対処内容だけではどうしようもない「攻撃者に有利な状況」
ほかの内容を見ると、「サーバから外向けの通信」などの文言もあり、攻撃者に圧倒的に有利な状況だったと考えられます。
本来ならばどうすべきだったか？①～マネジメント上の対策の一案～
インシデントの内容を把握して、しかるべき部署にエスカレーションの上、対応体制を整える（「経緯」中、（2）の検知を契機にして、（5）で示した「事故対策本部」の設置を行い、対応体制を整えたうえで、より組織的に動く必要があったと感じています。「事故対策本部」を設置しないまでも、「中から外に対して不審な通信が行われている」という検知を受けた時点で、何らかの対応体制を整えるべきであったともいえます。
早期に対応して、結果として大した被害もなく対応が終わればよかったのですが、ここの対応の遅れが、大きな被害を招いた要因の1つともいえます。
本来ならばどうすべきだったか？②～システム上の対策の一案～
JTBのWebページには、「漏れてしまった可能性がある」とありますが、これは「漏えいした／してない」ということを客観的に示す証跡がないことを示唆しています。
また、最初に届いた添付ファイルは、文書ファイルの体裁を装った実行ファイル[2]であるとも言われており、添付ファイルの種類に応じてフィルタするなどの対処を取れていなかったことも示唆されています。
局所的な対策ばかりを打ち出すと、「あっちを立てればこっちが立たず」となる可能性があるため、本来は冷静にシステム構成やシステム検査などをはじめとして、全体を見渡し、その上でシステムや業務が持つリスクの把握と対応が必要だったといえます。
本来ならばどうすべきだったか？③～全体の見直しと改善を統括する部署
「本来ならばどうすべきだったか？①」で書いたことと一部重複しますが、社内のワークフローやシステム構成などから、リスク分析の実施および、結果に基づいた対策強化などを従前から実施すべきであったろうと考えます。
そのために必要な対応は、本稿では述べませんが、IPAなどから有用な文書を入手可能です[3]。最近は「何らかのサイバー攻撃で被害→CSIRT設置」という動きが目立ちますが、本来必要なことをせずにCSIRTだけ設置しても、集められた側が困るだけです。必要なのは、被害最小化と再発防止（未然防止）をはじめとする総合的な対応であり、その中で必要な事項の1つとしてCSIRTの設置があるべきと筆者は考えます。
おわりに
本稿では、非常にアバウトな感じで不足する部分や対応すべき部分を述べましたが、詳細に詰めることで「より具体的」な対応を考えることが可能であると考えます。あと、本稿を書いていて「もし筆者がその現場にいたら…」ということを考えましたが、少なくとも一人だけで対応しきる自信は全くなく、どう考えても、組織的な対応を取れるように働きかけるパターンしか思いつきません。
下記は、組織的な対応を取れるようになるために必要な事項の一部です。組織的な対応を考えれば、本稿で述べた「エスカレーション」などは、このような事項を考えていくと出てくるアクションの1つであることを理解いただけると思います。
- セキュリティリスクを経営リスクの1つととらえる（経営層の役割）
- マネジメントと技術（システム）の両面から対応を考える（マネジメントと現場の役割）
- インシデントが起こる前に、「インシデントが起こったら」ということを想定した対応を検討する（訓練はその一環）
まだ被害に遭っていない企業／団体の方々も、こういう類のインシデントは起きうるものとして、備えるべきと述べて、本稿の結びとさせていただきます。
