2020/5/28にNTTコミュニケーションズより、「当社への不正アクセスによる情報流出の可能性について」*1 というアナウンスがありました。
現在まだ詳細は調査中との事ですが、このインシデントを現時点でアナウンスされている情報を元に、セキュリティ対策等の推定を加えて情報処理推進機構(IPA)の「制御システムのセキュリティリスク分析ガイド」の手法に基づいたリスク分析を行ってみました。事実の部分には、引用元である上記の報告＊１を添えます。
ちなみにリスク分析にかかった時間は弊社が提供している、リスク分析ツールを使う事で、モデル化から約２時間で終わりました（このブログを書いている時間はもっとかかってますが）。
システム構成図
システム構成は、＊１で提示されているものを分析用にBHE/ECL監視制御網のみ省いた形でモデル化しました。
リスク分析：資産の整理と情報入力
ここでSvはサーバを意味しています。社内Ｓｖは社内サーバ群を指しています。また、サーバＢとサーバＣはまとめて情報管理Ｓｖとしています（資産の絞り込み）。
ここからは詳細情報が無いので推定です。ここで資産一覧表と重要度の記入を行い、接続関係マトリックスを作成し、データフローマトリックスを作成します。また、セキュリティ対策はどこまで出来ていたかは定かではありませんが、最初に侵害されたBHE(Biz ホスティング エンタープライズ)というクラウドサービスは2011年に開始され2018/3にはサービスを終了(*1)しているようです。つまりサービスの終了後はサポートも縮小されその後に十分なセキュリティ対策は出来ていなかったのでは無いかと推定されます。そのため、今回の分析では推定としてセキュリティ対策は十分とは言えなかったとしてみました。
また、データフローに関してはアクティブディレクトリとその管理部分が侵害され特権アカウントが窃取されてしまった場合、完全にチェックメイトとなります。つまりどんな対策がされていても、その対策を無効と出来るからです。
したがってAD関連のデータフローは特権の場合に、社内Svと直結と想定しました。
また、
・攻撃者は悪意有る外部の第三者
・事業被害は、機密情報の漏えいとし事業被害レベルを３
・攻撃拠点はAD SV、攻撃対象は社内Sv（社内サーバ群）としました。
リスク分析：攻撃ツリーと事業被害ベース分析
リスク分析ツールでは、１ボタンで危険経路リストとその攻撃の容易性を計算してリストアップしてくれます。この危険経路候補の中で、一度ＦＷに入りまた出てくるという現実的には起こりにくい（遠回りになる）経路を覗いて、事業被害ベースのリスク分析シートを生成します。この生成も１ボタンで完了です。
生成されたリスク分析シートに、脅威レベル、対策レベルを入力すれば、リスク値は自動的に計算されます。
ここで、侵入口として考えられる資産は、海外拠点とFWc(社内向けファイアウォール)ですが、天下のNTTコミュニケーションズ様ですから、FWcの防御は完璧と思われるため脅威レベルは最低の１としました。また、海外拠点はサプライチェーン攻撃とみなします。IPAの情報セキュリティ10大脅威では、2019,2020ともにサプライチェーンの弱点を悪用した攻撃は4位と高いポジションにいることから、脅威レベルは最大の3と考えました。
このシートは、攻撃ツリー事に生成されます。その生成され事業被害のリスク分析を行った結果をまとめるには、同じく弊社の攻撃ツリーのまとめツールを利用することで、一覧にすることができます。書き忘れましたが両方のツールともに無償提供させていただいています。
セキュリティ対策は、リスク値が高く、この対策レベルの低い資産を重点的に対策を行えば良い（例えば赤や水色の資産）ことになります。やはり海外拠点から入り侵害を続けるという攻撃ツリーのリスク値がＡと高く分析されました。
現実的なセキュリティ対策
ここから見える要注意部分（赤い部分）について以下に分析をしていきます。
①海外拠点の対策：サプライチェーンのセキュリティは、今年はじめの三菱電機へのサイバー攻撃でも同じパターンで、重要な要素です。具体的な対策としては、日本語ではIPAの「サプライチェーンのセキュリティ脅威に備える」が参考になりますが、より実践的なのは英国NCSCの「Supplu chain security guidance」では無いかと思います（グーグル クロームを使うと日本語訳できるので、それで読んで下さい）。
②情報管理Sv周り：ここは2018年にサービスが終わったにも関わらずそのまま放置されていたのが非常に大きな問題ではないかと思います。サービス停止後もできればアンチウィルス管理、パッチ適用などまめなメンテナンスが稼働中には必要ですし、利用しないのであれば即時の撤収が必要です。
また、このサービスはBHE/ECLサービス監視制御網で海外拠点に接続されています。このECLというオプションサービスは、コロケーション接続と呼ばれる顧客のシステムとクラウドをL2接続（乱暴に言うと直結）するオプションで、そのオプション含め海外拠点と接続されていたのであれば、海外拠点から何の障害も無くクラウドの管理部分に接続できたという事が推定されます。これは危険ではないでしょうか。
できれば管理部門だけでも認証系、多要素認証を含むアカウント管理、重要操作の承認などの対策を行うべきだったかと思います。
③Sv-Aから先の社内のサーバに関して：さきにも書きましたが、アクティブディレクトリの特権を取られると、チェックメイトです。ログも消される可能性も高いでしょう。そうならないようにするためには、AD Svの管理アカウントをAD運用サーバアカウントと分離するとか、AD Svの特権アカウントの運用サーバのキャッシュに残さないようにする、など徹底した特権アカウントの保護が必要と思います。管理の手間を考えると特権アカウント一つで全てやってしまいたくなるのはやまやまですが、慎重な扱いが必要と考えます。
リスク分析のまとめ
今回セキュリティリスク分析を行ってみて新たに気付いたのですが、「サービス終了後のシステムの管理」も重要だという事です。今まで退職者のアカウントはすぐに削除するという事は叫ばれていましたが、システムも使わないのであれば迅速に撤収する（あるいは監視する）事も考えなければいけないなと思いました。
ここまで書いて思い出しましたが、弊社のツイートでも、リモートワークのシステムを利用終了した時のセキュリティ管理もきちんと行って下さいと、書いていました。これも同様な考えですね。
*1 NTT コミュニケーションズ 「当社への不正アクセスによる情報流出の可能性について」
