更新履歴

(6/15更新)下記にてpiyologが更新されているので、そちらを見つつ足りてない情報を加え、情報を再整理d.hatena.ne.jp
(6/16更新)6/15午前から6/16 0時までに公表された情報を追加
(6/16 18:20更新)タイムラインを更新
(6/17 01:30更新)6/16から6/17 0時までに公表された情報を追加
(6/20 01:17更新)6/17から6/20 0時までに公表された情報を追加
(6/27 19:00更新)6/20から6/27 までに公表された情報を追加

イントロ

後でpiyologと答え合わせする用エントリ。
2016/6/14、JTBグループは株式会社i.JTBのサーバーに、外部からの不正アクセスがあったことを報告しました。

タイムライン1 2

ここではすべて2016年内での出来事とします

日時	出来事	備考
3/15	i.JTBの従業員がメール上の添付ファイルを開いたことでパソコンが感染	取引先を装ったメール。この時点で感染は認知されず。最終的にサーバー2台２台以上・PC6台に感染拡大*3
3/19	JTB情報システム（JSS）が内部Web*4サーバから外部への不審通信を最初に確認。遮断作業を開始。	当該サーバは本来個人情報を含まない。システム監視会社によって検知。継続的な不信通信をブラックリストに登録する作業をおこなっていた。遮断に関する報告はi.JTBからJTBにはなかった5 63連休
3/20	Webサーバーを社内ネットワークから物理的に切り離し。不審通信は別経路で継続	「当該日に不審通信を全遮断することは業務的にも技術的にも可能だった」7 3連休*
3/21	不正侵入者はデータベースにアクセスしCSVファイルを生成。制御サーバにCSVファイル設置し、その日の内に削除.*8	\| データファイルが作成された制御サーバと不審通信を発したサーバは別9。3連休*
3/24	内部サーバから外部への不審通信を最後に確認
3/25	遮断作業を終了。JSSがJTB IT企画部門に報告	*10
3/XX~3/YY	ネットワーク内の全サーバとパソコンを調査	3/19 ~ 3/30?
4/1	不正侵入者が作成・削除したデータファイルの存在を確認。CSIRT立ち上げ。	~~削除した日付については記述がない~~作成日に同時に削除。CSIRT自体は前々から準備していた。
X/XX~5/13	外部セキュリティ専門会社と共同で、ウイルスを駆除・データファイルの復元と不正アクセスの調査・分析・対応を実施	調査開始のタイミングの記述はない。復元対象のデータファイルは不正侵入者が作成・削除したデータファイルかと思われる
5/13	復元したデータファイルに個人情報が含まれることを確認。i.JTBよりJTBにエスカレーション*11 。個人情報流出の可能性を認定。事故対策本部を設置。	~~不審な通信とデータファイルの関係性が不明だったために”可能性"?~~ 不審通信によるファイル持ち出しは確認されていないが、可能性は否定できないとのこと
5/13~X/XX	直ちにデータを正規化し、~~約793~~693万件の個人情報があることを確認	*12
5/17	JTB　高橋社長が情報を認知
5/30	警察に相談	~~被害届か明言はされてない~~被害届はだしていない*13
5/31	観光庁に相談	*14
X/XX	問い合わせ窓口を設置
6/10	対象顧客が判明	*15
X/XX~	対象のユーザーへメールによる通知を開始	1ヶ月以内に連絡するとのこと*16
6/14	発表 && 調査継続。警察による操作開始	不正アクセス禁止法違反や不正指令電磁的記録供用の容疑にて操作中*17
6/15	個人情報流出の可能性があるユーザーへの注意喚起 *18	送信元メールアドレス、添付ファイル、ヒアリング内容に関して通達。観光庁が再発防止策の提出依頼*19
6/17	国交省、再発防止策を検討する有識者検討会の設置を発表	*20
6/24	観光庁への再発防止策の報告期限。該当する顧客への連絡は24日午前までに、ほぼすべて終了	「さまざまな企業や団体で個人情報が流出した事案の教訓が生かされておらず、大変遺憾だ」「全体的に遅すぎる」
7/1	末永安生専務をCISOに任命。社長直下のITセキュリティ専任統括部門を設置	*21

攻撃の概要

f:id:kengoscal:20160616023320p:plain *22

当時のJTBの体制

発覚以前

セキュリティを横断的に見る部門は存在せず *23
5.対策: (中略)ジェイティービー（グループ本社）内にITセキュリティ専任統括部門を設置いたします
CSIRTも存在せず *24
サイバー攻撃の緊急対応チームも当時は存在しなかった
一部ログを取得していなかった*25
すぐ情報を公開しなかったのは「不安と混乱を招くと考え、特定できた段階で公表する方針を取った」*26
対象データを暗号化していなかった。*27
実績データベースへアクセス可能な社員は1人だが、そのPCは乗っ取られていない*28
実績データベースのデータを使うBI（ビジネスインテリジェンス）ツールは25人の社員がアカウントを持っていたが、今事案との関連性は薄いと見られる*29

発覚後

問い合わせ窓口を設置
- スタッフ300名規模*30
- 6/14時点で数千件の問い合わせ
警察への相談済み(調査中)
7/1までにITセキュリティ専任統括部門を設置

「外部流出について可能性があるという表現にとどめたという。JTBは通信ログの一部を取っていなかった。」とあるので事実がないのではなく事実を確認する術がないというのが正しいかもしれませんね。 https://t.co/fkvewFVs7P
— nobuhiro tsuji (@ntsuji) 2016年6月14日

送信された標的型メール31 32 33 34 *35

件名: 航空券控え添付のご連絡
メアド: ごくごく普通のありがちな日本人の苗字@全日本空輸のドメイン *36
署名: 取引先の署名
添付ファイル名:
- 「北京行きのEチケット」パターン*37
- 「Ｅ－ＴＫＴ控え」パターン*38
  - 社内でもよく使われる
添付ファイル種別: PDF。
- 実態はELIRKS(の亜種?)とPluX(の亜種?)に当該PCを感染させる新種マルウェア
オペレータから返信。エラーメールがかえってくる
- 開封すると航空券のｅチケットが表示される
メールヘッダー: 海外のレンタルサーバー（香港を経由)*39
本文内容
- 本文無しパターン*40
- 「お世話になっております』などの通常の挨拶文のあとに、『ｅチケットを送付しますのでご確認下さい』と偽った内容パターン*41
添付ファイル開封者: オペレータ
- 標的型メールの訓練済み
  - JTB全体では定期的に訓練していたようだが、当該オペレータが複数回の訓練を受けていたかは不明

被害範囲

個人情報悪用の報告もない
~~流出は確定されていない~~
流出に関するログが確認できないため、わからない*42
- 尚、一部ログを取得していなかったとのこと
- 可能性は否定されていない*43
知らない宛先から不審なメールマガジンが届いた」といった指摘がおよそ１００件よせられた
- 詳細調査中*44

個人情報の項目

以下の一部か全て
- 氏名(漢字、カタカナ、ローマ字)
- 性別
- 生年月日
- メアド
- 住所
- 郵便番号
- 電話番号
- パスポート番号
- パスポート取得日
  - 現在で有効なものは~~約4300件~~4359件*45
訪日外国人の情報も含む*46
以下の情報は含まれない*47
- 予約した旅行の内容
- クレカ情報

対象となるユーザー

JTB関連のサービス

以下のサービスでオンライン予約したユーザー679万人
- JTBホームページ、るるぶトラベル、JAPANiCAN
- オンライン転売提携先でJTB商品を予約したユーザー
  - JTBグループ内外問わない
  - ただし以下の商品を予約したユーザーは対象にならない
  - JTB旅物語、高速バス、現地観光プラン、レジャーチケット、定期観光バス、レストラン、海外ダイナミックパッケージ、海外航空券、海外ホテル、海外現地オプショナルツアー、その他旅行関連商品
- また、以下の店舗で予約したユーザーは対象にならない
  - JTB店舗、提携販売点店舗、JTB旅物語販売センター
"ネットで予約後、店舗でご清算のお客様の情報は対象となります。" <- ??
- 予約 && オンライン清算が対象??
~~期間についての記述はない~~
- 2007/9/28 ~ 2016/3/21*48

別会社

NTTドコモのdトラベルユーザー49 50

対象ユーザー: 2014/2/27~2016/3/21に予約したユーザー
対象範囲: 33万人
窓口設置済み
ドコモの吉澤和弘新社長が謝罪と対策の強化を表明

auトラベル by DeNAトラベルを*51

対象ユーザー: 「auトラベル by DeNAトラベル」国内宿サービスを利用したことのあるユーザー
- 期間は不明
対象範囲: 4,462人
窓口設置済み

対策

不正アクセス対策

特定された外部への不審な通信の遮断
感染範囲の特定とウイルスの駆除
個人情報へのアクセス制御の強化

グループ全体の対策

JTBグループ本社にITセキュリティ千人統括部門を設置
実践的な教育演習でサイバー攻撃の察知力を高める (全グループ社員向け)

被害額試算

biz-journal.jp

不明な点

ウイルス感染からの流れ

最初に不審通信を確認してから何をしたのか*52
- 即時遮断しなかったのはなぜか？ => 継続的に通信していたから
- ブラックリストに随時追加していた
- ブラックリストへの追加はJTBへの連絡がなかった
- 技術的にも業務的にも不正アクセス者がDBにアクセスする前に遮断できた
感染したパソコンがどの様な用途で使われたか。
- 踏み台もしくは直接操作されたのか
- 内部パスワードを取得されたのか
  - 取得したパスワードで社内ツールを使ったのか
  - 取得したパスワードでサーバにログインしたのか
サーバ上でどうファイル作成・削除の操作する権限を得たか。
サーバ上に普段はないデータをどの様に取得したか。
- ディレクトリサーバ経由ではない*53
- 遠隔操作である可能性が高い*54
- データコピー元のサーバは１人しかアクセス権限のないサーバー*55
  - アクセス権限をもつ社員のPCは感染していない*56
不審通信はどの様な内容なのか => 不審なパケットデータだったか*57
- 宛先・通信種別は一定なのか
- ファイルを送信するような通信なのか
- 単純にいままでに観測されていない通信だったのか
- ~~普段の通信量とどれぐらい違うか(ちがわなそう)~~
何をもってして流出の可能性があると判断したか
- 不正アクセス者が作成・削除したファイルの存在で判断したか
- ファイルを外部に送信するような不審通信があったのか
- ウイルスの解析結果をもって判断したのか

業務推進がミッションの実務担当者に、標的型攻撃につながるメールを開いてしまったことに責任など負わせられない。「そこは訓練していたんです」なんてことは、記者会見で言い訳として言及することですらない。むしろ、その後の攻撃の連鎖への対応に何が欠けていたのかが、スタディには必要。
— riotaro okada (@okdt) 2016年6月14日

インパクト

パスポート情報漏洩（の可能性）がどれほどのインパクトがあるのか
- ~~直接的な賠償額(クレカとかだと500円の金券などをよく聞く)~~現時点では顧客への一律的な補償は考えていない*58
- その後の２次的な被害額
- 直接的なインパクトは余りなさそうだ*59 *ＪＴＢホームページ」で６月21日までの月間販売額が前年同期比１割減*60
「るるぶトラベル」では６月21日までの月間販売額が前年と同じぐらい
- いずれも通常なら１～２割増

事後対応

なぜ情報公開が認知後すぐでなかったか
- CSVデータを復元しても正規化が必要で、それだけではユーザーの特定ができず、余計な混乱をまねきたくなかったから
パスポート情報漏洩（の可能性）に対するエンドユーザーの対策
- 対策をJTBがしめすのか。外務省がしめすのか。
- 可能性であれば対応不要で終わらせるのか。

その他

ホームページのニュースリリース配下に「不正アクセスによる個人情報流出の可能性について」がないのはなぜ？
公表した日付と警察が捜査に着手した日付が同じ
一部のログが取得されてなかッタ理由
- 意図的ではなく様々なWebサイトを運営する中で統一できなかったとみられる*61

その他

後でpiyologと答え合わせする。
(2016/6/15追記) piyologと初期情報の量が異なるので、piyologが取得している情報ソースのリストを作る
- 見せ方に関しては、それをまとめてどう使うかは作成者によって違うので、これはこれでよし
(2016/6/20追記)２日置いてみたが特にめぼしい新情報がなかった(非営業日だからか？)。とりあえずここまでの振返りをする

振返り

まず最初に

今回はJTBがいちはやく整理された公式報告を公表していたので、概要が掴みやすかった。
恐らく、こういうタイプのインシデントはレアなのだと思うが、今後のインシデントを気にする（いや、起こらないのがベストなのだが）

情報ソースについて

Googleでの検索"JTB 情報流出　情報漏洩"
Feedlyでのニュース登録: Security NEXT, ITmedia, ITpro, Jpcert/CC, ZDNet, @IT, INTERNET Watch
piyologを見て利用したニュースサイト: 日経、毎日、朝日、産経、時事通信、読売
上記のサイトをウォチしてて思ったことは、大手ニュース(日経、毎日...)の情報提供は早く且つ頻繁だということ。
- ただし各ニュースが全てを完結しているのではなく、欠けていたり、定義が異なったりしていた
- 当たり前だけど複数の情報ソースを通じてフィルターするのは大事。仮に共通点がない場合は、確定していないということで、断定めいた文脈にしないよう本エントリでは意識した。
- 産経の記事がどの大手ニュースよりも初情報で踏み込んだ内容をリリースしていたイメージ
- 日経の記事が最速だったイメージ
- 日経と毎日の記事は更新頻度が高いイメージ
- まとめを作りたいなら、大手ニュースをくまなく見るのがヨイ
逆に、非大手ニュースはリリース時期も後ろで、内容はほぼ共通していた
- まとめだけをみたいなら、非大手ニュースを数個見ればヨサそう

情報整理について

まあまあ出来たのではないかと。できるだけpiyologを見ずに情報収集・整理したが（途中みてしまったが...)、取りこぼしたものはあまり無かったので。
勿論、取りこぼしたものもある。ので、更新頻度が高く、また情報密度も濃いpiyologはやっぱり凄かった

まとめの構成

GotSome \W+ech?

更新内容 -> イントロ -> タイムライン -> 攻撃の概要 -> JTBの体制(発覚前と後) -> 流出した可能性のある情報の項目 -> 対象となる可能性のあるユーザー ->対策 ->被害額 -> 不明点

piyolog

公式発表 -> タイムライン(提携先も含む) -> 被害状況 -> 発端 -> 原因 -> 対策…対応 -> ユーザーへの対応 -> 更新履歴
まず最初に更新内容を持ってくるのはやめる。更新が増えれば増える分だけ、リーダーが欲しい情報に到達するまでの距離と時間が長くなるから
タイムラインを直後に持ってきたのは良かった。提携先を別テーブルに切り出すことはまでは考えつかなかったけど....備考カラムを作ったのは良い
此処から先が明確にpiyologの構成と大きく異なってくる。piyologの場合は"被害状況"と軸をユーザーと現在の時間に置いてるが、本エントリの場合は「攻撃の概要」と環境に軸を置いている。これは本エントリが、この話を自分の担当する環境とのdiffをとり改善ポイントを洗い出せることを目的としているので、この書き方になっている。逆にpiyologは広範囲への情報共有が主目的である(気がする)から、軸が異なるのではないかと推測する。よって、どっちが良い悪いではないと思う。
それを踏まえた上でいうと、本エントリの流れと粒度は若干ぎこちない。攻撃内容ときたからには、攻撃結果(攻撃成否, 攻撃対象,..)が次にくるべきではないか。で、その後に対策がくるのがキモチイと思われる。よって、今後新しく書くとしたら...
- イントロ -> タイムライン -> 攻撃の概要 -> 攻撃の成否 -> 攻撃の影響(範囲、期間、被害額) -> 原因 -> 対策 -> 不明点 -> 更新内容
という訳で、次は構成にもうちょっと気をつかって書いてみる
ミニネタとして、はてなでは大見出しと中見出し２つで構成したほうがよさそう。少見出しと中見出しの見た目に違いがないように思える
- piyologの標的型メールのみやすさが圧倒的だった
- 問い合わせ窓口は想定リーダーが異なるから本ブログではいいかな...