明治大学が再び不正アクセスを受けた可能性があると記事を書いたら、やはり不正アクセスを発表していました。この件に関する明治大学の公式発表を拝見しましたが、直感的には、再発の可能性は高い気がします。
■公式発表
不正アクセスによるＳＰＡＭメールの送信及び個人情報漏えいについて
◆キタきつねの所感
そうだろうな・・・という状況証拠（学生のTwitter投稿）がありましたので、明治大学としてはいつ発表するかだけの問題だった気がしますが、学校発表の文章に隠された意図が読み取れていたので（個人的には）良かったなと思っています。
改めて公式発表を見てみますと、ものの見事に前回のインシデントと同じ形で攻められています。Office365のクラウドログイン情報経由で、SPAMメールの踏み台、メール送受信記録のダウンロードによる個人情報漏えいについては、手口も含めほとんど変わりません。
つまり、明治大学が事件後の対応を間違えたと言っても過言ではないと思います。
日経の記事には「再発防止策を進めている途中だった」といった明治大学側の対応が書かれています。つまり間に合わなかったのだと・・・
明治大学は18年7月26日にも、同様の不正アクセスを受けていたことを公表していた。再発防止の対策を進めているなかで今回の漏洩が発覚した。
（日経XTech記事より引用）
では、明治大学はどんな対策を進めていた（はず）のでしょうか？この部分については、前回の事件を受けての公式発表にこんな風に記載されています。
４ 今後の再発防止策
本学では，今回の事案が発生したことを踏まえ，学内情報システムで使用しているアカウント及びパスワードについて，より一層の厳重管理をするようルール化し，周知徹底を図ります。また，外部専門機関と連携しながら監視体制を強化し，情報システム全体のセキュリティを向上させ，個人情報の更なる適正管理に努めます。
（7/26の明治大学公式発表より引用）
つまり２点。「関係者へのパスワード啓蒙教育」「監視体制の強化」が進められていた（はず）のだと思われます。
私から見れば、Office365（クラウド）を攻められたことに対する危機感がなかった気がします。自校のシステム（オンプレ）ではなく、クラウドを大学自身が選択した、ここがポイントになるかと思います。パスワードの使いまわしがこれだけ世の中で警鐘を鳴らされている中で、IDとパスワードの脆弱性を突かれて攻撃を受けたという事に対し、大学の偉い方はあまり事態を把握できてなかったのではないでしょうか？
もっと言えば、Office365のログイン口がWebに公開されており、大学がOffice365を使っている事を公開しているのですから、学生や教職員だけでなく、攻撃者から見ても「楽に（不正）ログイン」できると思うべきだったのではないでしょうか。
明治大学が進めていたであろう、「関係者へのパスワード啓蒙教育」「監視体制の強化」について、明治大学公式発表から時系列をまとめたので、そちらで見ていく事にします。
※1回目のインシデント発表内容から記載しています。
| 日時 | 出来事 | 備考 |
| 2018/6/30（土） | 専任職員1名のメールアカウントに対し、第三者の不正アクセスを受け、外部へ415件のSPAMメールが送信される 当該アカウントの送受信データ及び添付書類がダウンロードされ、外部へ漏洩 |
漏洩した送受信データの中に、学生、教職員、卒業生、学外者の個人情報が含まれていた |
| 2018/7/12（木） | 所属機関のメールアカウントに対し、第三者の不正アクセスを受け、外部へ30件のSPAMメールが送信される 当該アカウントの送受信データ及び添付書類がダウンロードされ、外部へ漏洩 |
漏洩した送受信データの中に、学生、教職員、卒業生、学外者の個人情報が含まれていた |
| 2018/7/26（木） | 明治大学が、第三者の不正アクセスを受けSPAMメール送信のインシデント2件があった旨を発表 | ※公式発表（1回目） |
|
↓↓↓今回の事件範囲 |
||
| 2018/7/28（土） | 専任教員1名のメールアカウント（A)に対し第三者の不正アクセスを受け、外部へ5677件のSPAMメールが送信される 当該アカウントの送受信データ及び添付書類がダウンロードされ外部に漏洩 |
漏洩した送受信データの中に学生、教職員、卒業生、学外者の個人情報が含まれていた |
| 2018/8/2（木） | 客員研究員のメールアカウント（B）に対し、第三者の不正アクセスを受け、外部へ927件のSPAMメールが送信された | |
| 当該客員教員（B）はパスワードを変更 | ■客員教員Bは攻撃に気づいている？ | |
| 2018/8/28（火） | 明治高等学校教諭の所有するメールアカウント（C)に対し第三者の不正なアクセスを受け、225件のSPAMメールが送信された | |
| 2018/10/13（土） | （B)のアカウントが再度不正アクセスを受け、外部へ143件のSPAMメールが送信された | |
| 2018/10/17（水） | 明治大学情報基盤本部が学生向けにパスワード再設定をする旨の通達を出す | |
| Twitterで学生が強制パスワード変更の件をつぶやく | ||
| 2018/10/18-10/28 |
明治大学 全学生 パスワード変更期間 |
期間中にパスワード変更しなかった場合はアカウントがロックされる |
| 2018/10/22 | ※当Blog記事にてインシデント懸念を発表 | |
| 2018/10/24 | 明治大学が、第三者の不正アクセスを受けSPAMメール送信、個人情報漏えいのインシデント3件があった旨を発表 | ※公式発表（2回目） |
まず気になったのが、7/26（木）の1回目の公式発表の後、すぐに別な不正アクセスを7/28（土）に受けている点です。SPAMメール件数（5000件超）、事件発表が無かった事から考えても、明治大学は「監視体制の強化」をこの時点ではしていなかったものと推測されます。
言い方が悪いのですが事件報道が出ると、模倣犯が「試してみようかな・・・」と同じ手法でアクセスしてくる事がありえるのですが、緊急対策を終わらせてからインシデント発表をするか、その脆弱性がまだつぶせてない場合、あるいは原因究明に時間がかかる場合、当該システム（外部からのメールアクセス）を止めるのが普通ではないかと思いますが、そのままメールシステムが継続利用が出来ており、監視も不十分で、2日後には攻撃が成功していた、、、これはとても恥ずかしい事なのではないでしょうか。
2点目として挙げたいのが、2人目の不正アクセスを受けた客員教員（B）が8/2にパスワード変更した際の対応です。この時、客員教員（B）は不正アクセスに気づいてたと考えるのが自然です。だとすれば学内で報告があがったのでしょうか？10月になって慌てて学生のパスワードリセットをしようとしていますが、8月の時点で（客員教員Bから報告を受けて）大学側が気づいていれば、10月の被害は受けずに済んだと思います。
推測となりますが、客員教員Bは「気づいた」が「隠そうとした」のかと思います。ウィルス感染やランサム被害、被害規模を抑えるのは初動と言われていますが、学内のセキュリティインシデントで考えると、上まで報告があがらない事自体に問題がある、そう考えて対策を打つ事が必要だと思います。
3点目としては、同じく客員教員（B）が8/2にパスワード変更をした部分、その後10/13に客員教員（B)のアカウントが再侵害されます。ここでのポイントは、パスワードを変えたのに不正アクセスを再度受けている事です。
ここも推測でしかありませんが、可能性が最も高いのが「容易に類推できるパスワード」を客員教員（B）がセットした事だと思います。
どんなケースか例を挙げてみますと、
※原因は容易に類推できるパスワードだった（または他サイトで漏洩したパスワードを使っていた）事
※原因は容易に類推できるパスワードだった（※または前のパスワードから推測が可能だった）事
この推測が当たっていたとすれば、パスワード教育をいくらしても、また不正アクセスを受けてしまう率が高いと思います。
今回の事件を受けての対策にアカウントロックがあり、そこから考えると、不正アクセス被害を受けた専任教員（A）や高等学校教諭（C）のアカウントは、あまり使われてなかったアカウントだった可能性もあるかも知れません。
明治大学は、個人情報が漏洩した対象者に対して、個別に状況の説明と謝罪をしている。再発防止策として、一定期間パスワードを変更していない利用者のアカウントをロックするほか、システムのセキュリティーを強化したり、利用者向けの講習会を開催したりするという。
（日経XTech記事より引用）
その他の対策としては、何を意味するか分からない便利なフレーズ「システムのセキュリティ強化」と利用者向けの講習会、いわゆる（パスワードの）啓蒙教育があります。当然前回の事件を受けて、改めて教育は実施されたと思うのですが、、、また「講習会」を開催するのであれば、やはり現状の（学生の）パスワード運用はあまりよく無いのではないかと思われます。
講習会も明治大学の規模であればすぐに終わらないと思いますので、、、おそらく脆弱ではないパスワード運用の重要性が全学生に浸透していくには時間がかかるでしょう。だとすれば、大学側がその間の監視を強化していく、あるいは追加セキュリティ対策の実装を急ぐべきなのではないでしょうか。
普通の対策実行スピードでは、また不正アクセス施行は続く可能性は高いと思います。
前回の記事でも書きましたが、Office365運用に多要素認証は必須なのではないかと思います。（あるいは能力値の高いリスクベース認証でしょうか・・）
更新履歴
- 2018年10月27日PM（予約投稿）
