スタディスト事件？
日経xTechの記事で、スタディスト事件なるものが発生し本日最終報告書が公開されていたことを知りました。
マニュアル作成・共有サービス「Teachme Biz」を手掛けるスタディストは2018年7月23日、6月26日に公表した同サービスへの不正アクセスは、従業員の作業ミスによるものだったと発表した。可能性があるとしていた顧客データの流出もなかったという。
最終報告書はこちらです。
不正アクセスによる一部データ流出の可能性に関する詳細調査のご報告（最終報） - 株式会社スタディスト
何も無かったので良かったですね、と言うのは間違いないのですが報告書を読むと一介のインフラエンジニアとして思うことがありますのでまとめておきます。
思うこと
1. ISMSの取り扱いがよくわからない
まずは、以下の対策が気になりました。
・セキュリティ管理体制の整備
ISMSに準拠した形でのセキュリティ委員会およびワーキンググループを設置。社内外のセキュリティリスクに対する活動推進を総合的に管理、監督。
スタディストって、ISO27001の認証をすでに受けていますよね。
ISO27001においては、セキュリティー委員会の常設は取得条件なのですが、これが機能していなかった、ということなのでしょうか。
しかも、上記のページ、よく見ると・・。
有効期限日が切れていますよね・・。認証自体は更新していて、ホームページの更新忘れなのでしょうか。他の会社を見てみましたが、有効期限が切れている会社はなかったです。
ともかく、ISMSに準拠した形でのセキュリティ委員会の設立が対策になっているにもかかわらず、一方でISMS取得済みというのがチグハグなのが否めません。
とりあえず、ISMS取得済みということで話を進めます。
2. リスクアセスメント、そしてその対応ができていないのではないか
今回、インフラエンジニアが誤って本番に接続してしまったことが、問題のトリガーになっています。
・本番環境へのアクセス経路を厳密化
業務用端末と運用端末の分離を実施。社内外からの意図しない接続を防ぐため、本番環境への接続はVPN経由のみに制限するなど、本番環境へのアクセス経路や権限を厳密化。
ISMSを取得しているのであれば、リスクアセスメント時に、本番と開発のネットワークが同居しているリスクを列挙できているはずです。これはなぜ許容されてしまったのでしょうか。許容されていなかったとすれば、なぜ対策されていなかったのでしょうか。この点についてマネジメントレビューを受けていたでしょうから、最終的には最高セキュリティー責任者（普通は社長）の責任であると思います。
今回問題が起こったから塞ぐというふうに読めるのですが、そもそもISMSの目的は事前にリスクを洗い出し、優先度・緊急度の高いものから対応していくということが主旨のはずです。
ISMSの取得が目的となってしまい、実際のPDCAが回っていない、ということはどこでもよくある話ですがその状況と同じではないのかなと思いました。
問題への対処は大事ですが、最も大事なことはISMSの根幹であるリスクアセスメント、優先リスクへの対処、またきちんとそれがなされているかのチェックと改善、といういわゆるPDCAを、スタディスト社でどう回すかが不明なのが、私の違和感の根本になると考えています。
なぜ、開発と本番の同居をISMS取得時に見逃してしまったのかを知りたいです。
インフラエンジニアはそのリスクが排除されていないことでたまたま失敗してしまっただけであり、リスクの作りこみはもっと前（環境構築時）から始まっていたのではないかと考えます。
3. 障害報告書に徹底、厳密、強化と言う言葉は使うべきではない
徹底、厳密、強化と言う言葉が何か所も見受けられます。私が障害報告書をレビューするなら、この表現は極力避けます。
・本番環境へのアクセス経路を厳密化
・運用ルールの強化および徹底
・重要作業のマニュアルにおける管理の徹底
・ログデータのより詳細な取得と管理、解析力の強化
・従業員教育の徹底
これらの言葉は行動を表す言葉ではありません。「がんばる」という言葉のニュアンスと似ているのですが、程度の問題であり行動を客観的に表している言葉ではありません。
例えば、
「品質管理部を新設する。この部署にて、開発部署の作業ログを監査し適正であることを担保する。かつ、外部監査時に品質管理部が適正に監査していることは毎回確認する重点ポイントとする。」
という書き方をすれば、徹底していることが行動として表現できます。徹底というのは今年の徹底と、3年後の徹底が同じである保証がなく定量的な表現ではないということです。
よくお客様サイドで言うのは、「徹底できなかったから問題になってるんだから、対策が徹底というのはおかしいだろう」という指摘です。確かに私もそう思います。
自社の報告書で、再発防止策に「徹底」もしくはそれに似た言葉が出てきたら注意しましょう。たいてい対策になっていないので、再発するでしょうし、かつ、次の報告書にも「徹底」と言う言葉が出てきたら末期状態（PDCAが回らない）です。
4. 役員の怒りが見える
そもそも本件、第一報については「不正アクセスの可能性」ということで社会に報告しています。第三者にて調査を進めたら結局は「社内の開発部のオペレーションミス」となってしまいました。初動の段階で、社内のみと気が付いていたら第一報の表現も変わっていたはずです。社内のインフラエンジニアが初動の段階できちんとログ解析ができていれば良かったのに、しかも原因がインフラエンジニア。インフラエンジニアめ！。そんな怒りが透けて見えます・・。
・ログデータのより詳細な取得と管理、解析力の強化
社内ネットワークログの保存を徹底。ネットワークトラフィックの監視も強化し、管理を徹底。保存したログに対して適切な解析が行われる体制を整備。
徹底が2回も書いてありますものね。
まあ、もし社外からの不正アクセスだったとしても、解析にこれだけ時間がかかったことでしょうから、今回を機に整備するのはとても正しいと思います。
整備が何を示すかはわからないのですが、きちんとお金をかけてソフトウェアやアプライアンスを購入し設置すべきと思います。お金をかけられるなら、ここにも外部ベンダーを入れ、役員レベルで動作を検収すべきでしょう。このあたりに、お金をかけない判断をする経営者は意外に多いものです。何もなければ1円にもないのでコストを抑えがちです。しかし、一旦問題が起こると、ちゃんと整備しとけばよかった・・となります。セキュリティー投資の「あるある」だと思います。
5. 従業員へのセキュリティ教育の徹底・・・それってISMS
2番と同じツッコミです。
・従業員教育の徹底
今後は二度とこのような事態が発生しないよう、これらの遵守を徹底するとともに、さらなるセキュリティ対策強化に取り組んでまいります。
従業員へのセキュリティ教育はISMSの基本ですね。
6. ちょっとした皮肉
サービス自身がマニュアル作成・共有サービスなのに、
・重要作業のマニュアルにおける管理の徹底
アプリインストールやアカウント設定等の重要な作業のマニュアルは、公開時のレビューを徹底。公開後も半期に一度見直しを実施。
マニュアルのレビューが徹底されていないという皮肉。Teachme Bizの機能一覧を見ていますが、レビュー機能がないなあ・・。
Teachme Bizの機能｜マニュアル作成ツール Teachme Biz
補記
ちなみに、第一報の素早い公開や、第三者機関にすぐ調査を依頼したことそのものは、対応としては正しいと思います。その結果やプロセスが役員から見てあまりにもひどくて、このような荒々しい最終報告書となったのではと推察します。
ただ、ISMSを正しく運用できていなかったのは、役員の責任です。問題が起きて初めてPDCAが回っていなかったことが露呈したのだと思いますが、もし普通にISMSを運用していたら、「開発と本番のネットワークが一緒で危険」という項目が上がってこないはずはないです。もし役員レベルでそこに気が付けないとしたら、役員にセキュリティーの知識を持つ人（CSO）を選定すべきです。
なぜなぜ分析、という有名な障害解析方法によれば、障害の原因は2つに分割できます。
・作りこみ要因・・・障害となる動作を設計・構築時に作りこむこと。本来はシステムテスト・運用テストにて検出されるべきなのが、なぜかすり抜けて本番フェーズに入ってしまった。
・流出要因・・・作りこまれた要因が、何らかのトリガーにより露出してしまった要因。
結局のところ、インフラエンジニアのミスは流出要因でしかありません。なぜ本番と開発ネットワークの同居を本番リリース時に見逃してしまったのか。また、それがなぜ放置され続けて来たのか。
中途入社でインフラエンジニアとしてアサインされたら、なぜか本番と開発が同じネットワークだった。先輩に聞いたが「そういうものだ」と一蹴された。みたいなことはこれもまた「あるある」だと思います。
本来はISMSで、そういったリスクを抽出し、能動的に対処するべきなのですが、ISMS取得が目的だとすると、あえてそのようなリスクに目をつぶったり、運用で対処するなどの名のもとに許容してしまったりします。
かわいそうなのはインフラエンジニア・・ということにもなりかねません。作りこみ要因についてはコストや無知、などの問題も絡むのですが、結局のところこちらの対策が将来のセキュリティー強化そのものになります。
ということで、なかなかのスタディスト社の報告書だったので、長文となりましたが、参考となれば幸いです。もちろん、個人（インフラエンジニア）の見解となります。
