どもどもにゃんたくです。
さて、今回はこちらに行ってきました！
第3回情報セキュリティ事故対応アワード
当日はTwitterと連動しながらすすめる場面もありました。
その時のハッシュタグは「#事故対応アワード」
このハッシュタグをtogetterでまとめてみましたのでこちらも参考にしてみてください。
=================================================
<2018/03/26>
第3回セキュリティ事故対応アワードの開催レポートが公開されたので追加
==================================================
僕は、第1回、第2回と参加しており、幸運にも今回も参加することができました。
第1回と第2回の受賞一覧はコチラです。
なお、昨年の「第2回」の僕の感想ブログはこちら
まず、「情報セキュリティ事故対応アワード」とはなんなのでしょうか。
※一部前回の内容と同じ部分あり
▼情報セキュリティ事故対応アワードとは
セキュリティ事故後の対応（インシデント・レスポンス）が素晴らしかった企業をセキュリティ分野の有識者が選ぶ表彰制度。
ただし、セキュリティ事故後のシステム運用/改修の詳細に踏み込むのは難しいため、主に説明責任/情報開示にスポットライトが当てられる。
→今後の模範となる、説明/情報開示パターンを国内のセキュリティ担当者に知ってもらいたい
▼部門賞一覧
最優秀賞、優秀賞、特別賞、報道賞
※報道賞は第2回から新設。有識者が「良かったと感じた記事」を讃える賞
▼評価軸
・事故発覚から、第一報までの時間（事故報告するまでの期間、頻度）
・発表内容（原因、事象、被害範囲、対応内容、CVE情報やなんの脆弱性を突かれたか等）
・自主的にプレスリリースを出したか（報道だけではなく、自社発信）
▼集計期間
・昨年1年間
※第3回の場合2017年1月から2017年12月まで。
▼ 審査員
・北河 拓士 氏 （Twitter : @kitagawa_takuji）
・根岸 征史 氏（Twitter : @MasafumiNegishi）
・piyokango 氏（Twitter : @piyokango）
･･･セキュリティのBIG 5の皆様です。ちなみにアワード委員長は、辻さんです。
さてなんとなくですが、どんなアワードかわかっていただけたかと思います。
そして、このアワードで勘違いしてほしくないのは、このアワードは決してインシデントを起こした企業を「煽ってる」わけではなく、インシデントを起こした企業のインシデント・レスポンスを「本気で褒める」というアワードであるという点です。
この認識を持っていない限りは、情報セキュリティ事故対応アワードの開催意図を1ミリも理解できないと言っても過言ではないと僕は思います。
では、なぜ褒めるのか。
それは「情報セキュリティ事故対応アワードとは」にも書いた、
→今後の模範となる、説明/情報開示パターンを国内のセキュリティ担当者に知ってもらいたい
の一言に尽きるのでは無いでしょうか。
もちろん、企業としては事故対応アワードに表彰されない無いように日々インシデントに対しての対策や対応を練らないといけません。
しかしながら、インシデントは「起きてしまう」ものです。
インシデントが起こってしまった時にこんなことをまず1番に考える必要はありませんが、「事故対応アワードに表彰されるだけのインシデント・レスポンスをしよう」と考えるのも悪くないかもしれません。
ここまでの内容はほぼ「第2回」の内容と変わりません。（もうしわけ）
ただ今回の第3回から大きく2つ変わったところがありました。
①事故対応アワードのツイッターアカウントができた
アワード中はハッシュタグの「 #事故対応アワード」で参加者のリアルタイムの意見をTwitterで観測できるという部分は第1回、第2回と変わらずでしたが、第3回からまさかのアカウントができるとは思いませんでした。
このアカウントではアワード中に話題なった内容のニュース情報やプレスリリース文、ハッシュタグの「 #事故対応アワード」でつぶやかれた参加者のツイートをRTしたりしてくれる非常にありがたいアカウントでした。
②アワード中にリアルタイムに記事が公開された
これはなかなかに驚きました。
このブログ後半のネタバレになってしまいますが、リアルタイムに公開された記事はこちらの2つです。
被害を受けてわかったこと、感じたことが非常に「リアル」に書かれていて興味深いです。
ただ、結構な分量があるので、アワード中に読むことは「僕は」できませんでした。
どちらかというとアワード審査員5名の話の内容を聞きたかったので。。。
さてさて、今回の事故対応アワードは、アワードとパネルディスカッション、質問コーナーの3段階構成で行われていました。
アワードの内容、パネルディスカッション。質問コーナーの内容に関して、僕が聞き取れたり把握できたりした部分をまとめました。
第3回情報セキュリティ事故対応アワード
選考概要
・調査件数、数百件
・ノミネート21件
・最終候補4件
最優秀賞（0社）
該当なし。
まさかの、「該当なし」でした。
第1回、第2回ともに1社選ばれていましたが、今回は無しということでした。
ただ、対応が良かった件がなかったというわけではなく、審査員の中で「推しインシデント」が割れたそうです。
ただ、「審査員のなかで割れるくらい、事故対応が良い企業が増えたのではないか」というコメントもされていました。
優秀賞（2社）
1社目
【受賞】
【インシデント内容】
・1年で4回、”なりすまし”による不正アクセス被害の情報を公開
・なりすまし不正アクセス回数が10回程度でも検知し、自主的にプレスリリースに掲載
【プレスリリース】
https://www.dinos-cecile.co.jp/whatsnew/topics_20170925.pdf
https://www.dinos-cecile.co.jp/whatsnew/pdf/topics_20170919.pdf
https://www.dinos-cecile.co.jp/pdf/topics_20170824-2.pdf
https://www.dinos-cecile.co.jp/whatsnew/pdf/topics_20170823.pdf
https://www.dinos-cecile.co.jp/whatsnew/topics_20170731.pdf
【受賞理由（審査員コメント含む）】
・多くのサイトで頻発しているであろう小規模の不正ログインに対して、都度情報公開して真摯に対応している。
・また、試行数10~20回程度の不正ログインを検知し、自ら対応している点は素晴らしい
・ 企業では被害にあったユーザにだけ被害の周知をしているが、公にはしてない企業が多いなか、公にしている
・リスト型攻撃など最近あまり聞かないが（減ってきているのかもしれないが）、発生していないということではないということを発信してくれている
・事故についてのプレスリリース内容の情報が少ない企業が多いなか、具体的な情報を発信してくれているところがよかった
【その他関連情報】
【セキュリティ ニュース】わずか1分11回のみの不正ログイン攻撃受ける - ディノス・セシールが公表（1ページ目 / 全1ページ）：Security NEXT
【セキュリティ ニュース】ディノス・セシール、再度パスワードリスト攻撃を検知（1ページ目 / 全2ページ）：Security NEXT
ASCII.jp：ディノス・セシール通販サイトに「なりすまし」による不正アクセス
2社目
【受賞】
ぴあ / B.LEAGUE
【インシデント内容】
・ぴあが受託開発したB.LEAGUEチケットサイトにおいて、Apache Struts2の脆弱性を突かれ、クレジットカードを含む個人情報が漏洩
【プレスリリース】
http://corporate.pia.jp/news/files/security_incident20170425.pdf
http://corporate.pia.jp/news/files/security_incident20170518.pdf
B.LEAGUEチケット等でのクレジットカード決済再開のお知らせ｜ぴあ株式会社
（3/27・16:00追記）「B.LEAGUEチケット」等でのクレジットカード決済一時停止のお知らせ - B.LEAGUE（Bリーグ）公式サイト
「B.LEAGUEチケット」等でのクレジットカード決済一時停止のお知らせに関する4月11日（火）時点の追加のお知らせ - B.LEAGUE（Bリーグ）公式サイト
B.LEAGUEチケット等でのクレジットカード決済再開に関する、現状のご報告 - B.LEAGUE（Bリーグ）公式サイト
【受賞理由（審査員コメント含む）】
・問題発覚後、対応状況を都度公開
・サービスの停止もすばやく行い、事故対応が的確、迅速であった
・Apache Struts2の脆弱性を突かれた、という情報をメディアで発信した
・カード被害額の公表は史上初
・被害者へのお詫びの手紙ではプレスリリースよりも詳細な情報を記載した
【その他関連情報】
ぴあ だからできた! チケット事業の経験を活かした事故対応 [事故対応アワード受賞レポート]｜セキュリティ｜IT製品の事例・解説記事
事故対応でB.LEAGUEが得た2つの教訓 [事故対応アワード受賞レポート]｜セキュリティ｜IT製品の事例・解説記事
またもStruts2で漏洩、ぴあ運営のB.LEAGUEサイトから流出したカード番号で被害 | 日経 xTECH（クロステック）
ぴあ運営のB.LEAGUEチケットサイトに不正アクセス--クレカ情報流出とされる被害も - CNET Japan
ぴあ、B.LEAGUE関連サイト不正アクセス問題で新たに約6500件のクレカ情報流出の恐れ - CNET Japan
ぴあ、Bリーグ不正アクセス問題 新たにカード情報6500件の流出可能性を発表 計4万件弱に - ねとらぼ
特別賞（0社）
該当無し
※実際にはあったが、辞退されたとのこと
報道賞（0社）
該当無し
パネルディスカッション
※パネルディスカッションで話題になった内容を列挙します
・今回の事故対応アワードの事象選出にあたって思ったこと
→今回受賞しなかった企業で、事故対応は早かったのに、内容がいまいちのものがあった
→早ければ良い、ってものでもない、中身との兼ね合い（バランス）が大事
→ただ、早いっていうのは「アワード的には」加点要素
・ソフトバンク・テクノロジーの不正アクセス事故について
→事故が発生した時、辻さんの頭の中ですぐに「事故対応アワードのことが頭に浮かんだ」とのこと
（辻さんの「頭の中でハッシュタグつけちゃいましたよ！」の一言は笑った）
→実際の事故が発生し、事故対応アワードで得た知見を、広報との連携やプレスリリースの作成に役立たせることができた
→今回の事故対応アワードのノミネートに21件上がったがソフトバンクテクノロジーはノミネートされず
【参考情報】
不正アクセスによる情報流出の可能性に関する詳細調査のご報告（最終報）｜ソフトバンク・テクノロジー株式会社 企業情報
不正アクセスのその後、ソフトバンク・テクノロジー 辻氏が語った体験談 (1) ミスが積み重なって起きた不正アクセス | マイナビニュース
・「付録C」について
→「付録C」とは、経済産業省が公開している『サイバーセキュリティ経営ガイドライン』についてくる「付録C インシデント発生時に組織内で整理しておくべき事項」という付録の略称（※2017年11月16日公開）
→インシデントが発生した時に組織内で整理しておくべき事項をまとめたもの
→「事故が発生した後」に使うものではなく、セキュリティ事故が発生する「前」から利用してもらいたい
【参考情報】
サイバーセキュリティ経営ガイドラインを改訂しました（METI/経済産業省）
サイバーセキュリティ経営ガイドライン（METI/経済産業省）
「付録C」は事故の情報公開の際や事件事故を取材する方々にも整理のために活用いただきたいですよ。 / サイバーセキュリティ経営ガイドラインを改訂しました（METI/経済産業省） https://t.co/C4Py25mtT1
— 辻 伸弘(nobuhiro tsuji) (@ntsuji) 2017年11月16日
・パスワードリスト攻撃について
→パスワードリスト攻撃って、言うほど「企業側」に責任ないのではないか。犯人が一番悪いが、ユーザー自身にも責任があるのではないか。
→ただ、システム的に「2段階認証」を導入していないのも企業として責任を果たしているとは言い切れないのではないか
→安易にパスワード変更するよりも、2段階認証したほうがおすすめ
質問コーナー
※事前に参加登録者からの質問に答えていこうコーナー
質問1：事故を起こす要因となった担当者は、社内でどうなってしまうのか？
→ソフトバンクテクノロジーの事故のときは、個人の問題（責任）でなはく、会社、組織の問題として扱い、処遇の変更は行わなかった
→ただ、一般論として、処分や処罰されたという報告は見るし、海外では解雇されるケ
ースもある
→2015年の年金機構の事故付近に「標的型攻撃訓練メール」が話題になり、開いたらクビだ！と言われた企業もあった模様
→一番の問題は、事故が起きたときに、「すぐ報告できる」かどうか（社内の雰囲気や運用のフローもあるけど）
質問2：経営陣と現場担当者で意見が別れたときにどうするべきか？
→ソフトバンクテクノロジーの事故のときは、出せるものは出すという方針と最初に取り決めた
→現場は「事故対応」のプロではないので、経営陣の判断に足る情報を収集し、報告し、経営陣の判断に従うという姿勢が大事
→可能性、とか不確定な情報は出すべきではないが、発表するときの折り合いは大事
→こういうときに「付録C」が役に立つ
質問3：事故対応で絶対にやっちゃいけないこととは？
→某社で、サイトが改ざんされていると報告されたが、社長が「風説の流布」だと一蹴したことがあった、OMG!!!!
→「非常に高度な攻撃を受けた」など、被害を受けた側があたかも問題がなかったとアピールするのは逆効果
→責任の擦り付け合いはNG
全体的にアワードに対して僕が感じたコト
・第1回、第2回と徐々に参加者の人数が増えてきたな、という感じ。それだけこの事故対応アワードの知名度が上がってきたんだなと感じました
・Twitterなどを見ていると、アワードに対する懐疑的な意見もありました。それは、事故によって被害を受けたユーザーにしてみれば、「被害を与えた企業が表彰されるのってどうなの？」と感じてしまうという点です。これは僕も感じたことでした。ただ、このアワードは決して「事故を起こしたこと」を表彰しているわけではなく、「事故を起こしたことへの対応」を表彰しています。
ですので、アワードを聞きに来た方々が、個々に所属する組織で同じことが起こらないようにするために活用するものなんです。事故が起こらない、起こさないということが一番目指すところだと僕は感じています。
そうそう、ステマではないですが、今回表彰されたB.LEAGUEの方が講演をしてくれるセミナーが今月3月16日に開催されるそうです。（辻さんの講演もありますね）
時間があれば聞きに行くのもいいかもしれませんね。
最後に。
サイバー攻撃は日々増加しています。攻撃の種類も日々進化、増加しています。
セキュリティ事故やインシデントは対策をとっていても、されてしまう時はされてしまうと思っています。
「起きたときに考えればいいや」では、被害が大きくなる可能性もあるので、起きる前から対応フローや対策は考えておくべきだと思います。
ぼくも企業でセキュリティの仕事（SOCアナリスト）をしていますが、一手先、2手先を見据えて準備しておこうと改めて感じました。
来年も「セキュリティ事故対応アワード」楽しみにしています！
ここまで読んでいただきありがとうございました。
ではでは。
