岡山県精神科医療センターのランサムウェア事案調査報告書の全文を読みました

こんにちは、TRSUTDOCKのよもぎたです。

タイトルの通り、いま話題の岡山県精神科医療センターのランサムウェア事案調査報告書の全文を読みました。Zennにはややそぐわないとかもしれませんが、感想文です。

定番のpiyokangoさんによるまとめは2024年6月時点のものがこちらです。

はじめに

率直な感想

まず初めに、医療情報システムへの大きな不安を覚えました。そしてそれらを構築、保守運用するベンダに対して不信感が芽生えました。ずっとIT業界でお仕事してきましたが、医療情報システムに関わったことはありません。なくて良かったと思います。僕がもし関わっていたら、良心の呵責に押しつぶされてしまっていたでしょう。それくらい酷いものだと感じました。少なくとも、本事故に関わっている医療情報システムベンダは自分本位の商売するためにモラルハザードを起こしていたと思います。

原因はお粗末なもの

報道でも人災と表現されているくらい、原因は稚拙でお粗末なものです。SNSでもいろいろと指摘されていますね。集約すると、

• 脆弱性の放置
• 推測可能なユーザー名、パスワードの使いまわし
• 最小権限（最小特権）の原則の無視

といったところになるかな、と思います。
なお、「人災」というのは本報告書の総括に下記のように記載されている表現なので、報道は正しくは引用ですね。

本件事案は、徳島県つるぎ町立半田病院、大阪急性期・総合医療センターの報告書の指摘事項とまったく同じ脆弱性が招いたランサムウェア被害であり、厚労省ガイドラインの遵守で十分に防げた事案であった。脆弱性の放置や推測可能なパスワードの使いまわしなどは、サイバー攻撃が進化する中で「閉域網神話」による思考停止が招いた「人災」ともいうべきものである。

対応に見習うべき点はある

あちこちで糾弾されていますが、対応の中に見習うべき点もあると感じました。次の４つです。

• 初期にクロノロジー（時系列の記録）を取り始めている
• 初期に攻撃者と連絡・交渉しないと決定している
• プレスリリースがそれなりに早く分かりやすい
• 医療提供を継続するために最大限、努力したように見えます。大変なご苦労があったと思います。

とくに2つ目の決定は英断だと思います。

今後の対策は参考になる

この点は見出しの通りです。報道もSNSも、ダメなところにフォーカスしすぎだと思います。この記事は、この点にも触れていきたいと思います。

余談

「閉域網神話」を信じさせられてきた本件の病院関係者が、「セキュリティ対策過激派」になったな、と感じました。一方、提供者である医療情報システムベンダは変化に追従出来ていないと感じました。
全国津々浦々にある病院や薬局が、過激派にはならなくとも、必要なサイバーセキュリティ対策を十分に行うようになるのか、ならないのか。徳島県つるぎ町立半田病院や大阪急性期・総合医療センターの事故の後、本事故がほぼ同様の原因で起こっていることと、医療情報システムベンダの姿勢と商売を考えると、道のりは長いな、と感じます。

原因

直接の原因（推測）

原因は、「5. 概要編」の「5.5 原因」と、「6. 詳細編：推測攻撃経路および手順」としておよそA4用紙6ページにわたってまとめられています。より詳しくは

1. 初期侵入～探索
2. 認証情報窃取
3. 水平展開～暗号化
4. 推測される攻撃の一覧と緩和策

の4つの節で構成されています。

まず「5.5 原因」で語られていて、報道やSNSでよく引用されている下記の部分。

① 保守用 SSL-VPN装置のID/PWが、administrator/P@ssw0rd という推測可能なものが使用されていた。
② 病院内のすべての Windows コンピューターの管理者のID/PWも、上記と同じadministrator/P@ssw0rd が使いまわされていた。
③ SSL-VPN装置の脆弱性が2018年の設置以降、修正されておらず、過去、ランサムウェア攻撃に使用された脆弱性が複数存在した。
④ すべてのサーバー・端末ユーザーに管理者権限を付与していた。
以上のことから、初期侵入は、①保守用 SSL-VPN装置への辞書攻撃 、②窃取した資格情報を売買するInitial Access Broker からの資格情報の購入、③SSL-VPN装置の脆弱性の悪用、以上いずれかが原因と推測される。

これだけでおなかいっぱいです。これは報告書でも「徳島県つるぎ町立半田病院、大阪急性期・総合医療センターで発生したランサムウェア事案とまったく同じである。」とされており、過去の教訓が全く生かされていないことが分かります。

また、病院や薬局は厚生労働省の監督下にあると思っていました。しかし、本報告書の中で「厚労省ガイドラインの遵守で容易に防げたものである。」と記載されており、監督官庁のガイドラインが遵守されていないことが分かります。
今回被害に遭ったのは、個人経営のクリニックではなくて、独立行政法人の病院です。そこですら、厚労省のガイドラインが守られていないというのは驚きとともに、病院薬局全体に強い不信感が芽生えました。

しかし、受付で「あなたのところは大丈夫ですか？」と聞いたところで答えが得られるはずもなく、病気になったら病院で診てもらわないわけにはいかず、病気にならなくても多くの人は健康診断を受診していて...これ以上考えたくはありません。

復旧困難となった原因

本件では、電子カルテデータを保存していたストレージの全喪失、バックアップ全喪失という事態になっています。

オンラインのバックアップは全て攻撃者に発見されて削除されたとのことです。これは探索が容易なネットワーク構成だったことを原因と考えているようです。

では、オフラインのバックアップや書き換え不能なメディアでのバックアップはなかったのか？

オフラインのバックアップは正しく取得されておらず、リストアできなかったとのことです。
書き換え不能なメディアでのバックアップについては言及はあるものの、取得自体考えられていなかったと思われます。

そのため、電子カルテデータをもとにしていた分析用のデータウェアハウス（DWH）から電子カルテデータを復旧させたとのことです。DWHに救われた形ですが、オフラインバックアップの点検、オフラインバックアップからの復旧試験を行っていれば、しなくてよい負担でした。

改めて、バックアップは取得したら点検、リストア試験まですべき、と痛感させられました。

対策

対策は大きく「7 詳細編 復旧について」「8 詳細編 組織的対策」「9 詳細編 人的対策 」の3章、A4用紙17ページにわたり記載されています。

復旧について

「7.1 セキュリティの原則」「7.2 復旧における要求事項」は次の通りに定められています。業種業界を問わず、広く適用可能だと感じましたので、それぞれ引用します。

7.1 セキュリティの原則
復旧対策では、基本原則を次のように定め、考え方のよりどころを示した。
◼ 多層防御：各システム、ネットワークでのリスクの認識、対策のガイダンスと共有、異常や脅威の警告、Fail Safe、安全なバリア、バリアのすり抜けの防止、避難と復旧方針を示すこと。
◼ 最小特権：管理者アカウントの使い回しの禁止、永続的でない一時的・制限された管理者権限の付与を計画すること。
◼ 攻撃表面の最小化：承認されたアプリケーションの使用と脆弱性管理、電子署名されたプログラムとスクリプトのみ許可、必要最小限のポート許可、接続先制限を実施すること。
◼ 知る必要性に基づくアクセス権の付与：役割（ロール）ベースの アクセス制御、属人化（集中）の排除、申請と承認の分離を行うこと。
◼ 管理接続の保護：サーバー管理専用端末の設置と多要素認証、業務ネットワークとは異なる専用ネットワーク、VLANでの接続を行うこと。
◼ 資格情報の保護：複雑性や定期変更を求めず、長いパスフレーズを使用する、パスワードの漏えいの定期的なチェックを行い、Windows資格情報の保護設定を実施する。
◼ レガシー保護と更新計画：古いOS、脆弱なプロトコルを抱えているシステムの刷新、刷新までの防御と検出、対応のための計画と立案を実施する。
◼ 責任分界点の明確化：サイバーセキュリティ条項、サプライチェーンを含めた監査権を求める契約を締結する。

7.2 復旧における要求事項
復旧設計における具体的な要求事項は、以下のとおりである。
① Security By Design、Security By Default に基づき初期侵入を確実に阻止すること。
② 仮に侵入を許しても水平展開を阻止し局所化すること。
③ 情報の窃取を極力防止すること。
④ 脅威検出が容易であること。
⑤ 迅速に復旧が可能で医療行為が継続できること。

■だったり丸数字だったり揃ってなくて気持ち悪いですが、原文がこれなんです。

「当たり前のことだ」「教科書みたいだ」という内容ですが、当たり前のことをきちんとやることは大切です。そして、ステークホルダーの理解を得たり、予算や人手、スケジュールを確保するのは意外と難しかったりすると思います。そんな中で、このような事故の教訓として上記のような事柄が示されているのは、説得材料として有益だと思います。

一方「原則」は各項目の粒度というかレベル感というか、そういうモノがそろっていないように感じます。たとえば、Windows資格情報の保護設定を実施する。というところですね。サーバ、仮想基盤、各種端末、データベース、各種アプリケーション...Windowsの守備範囲が広いのは確かですが、Windows以外もあると思います。というか、自分たちで利用するならば、そのあたりをきちんと自分たちにマッチしたものにアップデートする必要があると思います。

そしてどちらも全体的に抽象度が高い。汎用性が高いとも言えますが、自分たちの組織、システム、サービスに当てはめて考える時に、具体を考える必要があります。7.3から本件の病院での具体が語られていて、参考になることは多いです。実際に活用しようというときに、ざっと見出しだけでも見るとよいかな、と思います。

組織的対策

全体を見渡して

ここではISO/IEC 27002:2022の要求事項が多く引用されています。それに病院ということで、厚労省のガイドラインと、総務省・経済産業省 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドラインも引用されています。

このなかで、Security By Design、Security By Defaultへの対応がうたわれています。考え方を頭に叩き込んで、実践していきたいと考えます。

ただ、全体的に組織的対策なのか、技術的対策なのか、やや曖昧というか、ブレを感じるのと、ここでも粒度・レベル感にバラツキがあると感じるも事実です。まぁ私もやりがちですが。

活用する際はよく吟味、整理する必要がありそうです。

8.3.7 WindowsUpdateについて

ここではおよそ1ページを使って、WindowsUpdateしない理由はないこと、WindowsUpdateしないのは怠慢である、ということを詳細な背景、根拠とともに説明しています。DLL Hellについてまで、いまは解決されていることに言及しています。

8.3.8 医療機器におけるサイバーセキュリティについて

病院なので医療機器とされていますが、最近注目されているOTセキュリティ分野が近そうだと感じました。ただ、関わっていないし、突っ込んで資料読んだり考えたことも無いので、それ以上はなんとも言えません。

人的対策

ここでは教育と脆弱性情報及び脅威情報の入手と共有について記載されています。信頼できる情報源、一次情報が多いのが、病院らしいと感じます。

• JPCERT/CC
• CIS Advisory
• CISA Known Exploited Vulnerabilities Catalog
• Microsoft
• Adobe
• Google

Adobeが入っているのは、Acrobat関連でしょうかね。MacやiPhoneを使っているならAppleは必須ですし、ここも参考にしつつ自組織に合わせてアップデートする必要があります。

感想

全体を通して、情報システムを使って何かを提供する組織、その中でもITスタッフにとって他人事ではなく、日々進歩するサイバー攻撃に対して常にアンテナをはり、組織の中に対策を実装していくことの大切さを実感しました。幸いなことに、世の中にはその際に利用すべきリソース、参照すべきリファレンスが提供されていることも確認できました。

セキュリティ対策やシステムの保守運用は、直接売り上げや利益につながるものではなくて、言ってしまえば何も起きず普段通り情報システムを使えることが最大の成果だと思います。そうした中、予算と人員を確保し、他部門の情報システムの利用に口をはさむのは並大抵のことではないとも思えます。

幸い、いま私が働いている企業はセキュリティに理解があり、セキュリティスタッフとしては働きやすい位置にいると感じています。それでも、時には難しさも感じます。

本件のような事故を教訓に、世間の理解が進むことを切に願います。

番外編：忖度はあったのか

事案調査委員会委員長による冒頭の「ランサムウェア事案調査報告書によせて」の中で「病院理事長、院長からは、病院への忖度なく」報告書策定するよう求められたとあります。

確かに、「ベンダーにセキュリティポリシーや脆弱性管理を丸投げしている病院の責任は非常に重いといわざるを得ない。」（24ページ）「本件事案は厚労省ガイドラインを遵守していれば十分に防げたものであった。」（28ページ）のように病院に直言している記述もありました。

報道にも引用された「人災」の記述は「総括」の最後、54ページに次のように記載されています。

本件事案は、徳島県つるぎ町立半田病院、大阪急性期・総合医療センターの報告書の指摘事項とまったく同じ脆弱性が招いたランサムウェア被害であり、厚労省ガイドラインの遵守で十分に防げた事案であった。脆弱性の放置や推測可能なパスワードの使いまわしなどは、サイバー攻撃が進化する中で「閉域網神話」による思考停止が招いた「人災」ともいうべきものである。改めて、医療情報システムベンダー、医療機器ベンダーと病院関係者による、外部接続点のリスクの再評価、基本的なセキュリティ設定の見直しを切に要望するものである。

---

しかし、本件を事故ではなくて事案と呼んでいる時点で、病院への遠慮があるように感じられます。

他にも、病院の責任を軽く扱うような記述はいくつかありました。

「5 概要編」のはじめ、「5.1 インシデント概要」の終盤には

本件事案の原因は、病院及び電子カルテシステムを構築したA社の同ガイドラインの理解不足、過去のインシデント事例の軽視、「閉域網過信」によるセキュリティ意識の欠如に起因するものである。

とあり、完全にベンダに責任転嫁しています。

「5.8.1 技術的対策」の中に「ベンダーのセキュリティポリシーについて」という見出しの中では、

発注者たる病院側に第一義的な責任があり、本来、厚生労働省ガイドラインや、病院が求めるセキュリティポリシーを提示し、それに見合う製品、システムを導入すべきである。

としています。ここにもベンダへの丸投げ感を感じてしまいます。

もちろん、システムを構築するベンダもガイドラインを理解し遵守する必要はあります。しかし、ガイドラインやポリシーを提示して終わりではないハズです。それを発注者の病院が提示し、きちんと実装できているか、具体をチェックするべきです。そのためには、病院にもガイドラインの理解が求められます。

この点に関しては、厳しい指摘を避け、あいまいな記述に終始しているように感じました。（個人の意見、感想です）

一方、ベンダに対しては次のように厳しい目を向けています。（「5.9 概要編まとめ」28ページ）

病院はインシデント発生後の2024年6月に、医用画像管理システムの更改を企図し、ある医療情報システムベンダーに提案を求めたところ、その医用画像管理システムベンダーはサポートが終了したOSを組み込んだ製品を公然と提案してきた。医療という社会生活に欠かせない重要インフラを担う、という意識がないベンダーが我が国の医療界には存在していることに留意すべきである。

これでベンダにガイドラインやポリシーを提示して終わりに出来るはずがありません。

---

「5.3 情報漏洩」では様々な理由を付けて「情報の閲覧、情報の漏洩の可能性は極めて低いと考えられる。」と結論付けています。

県警が情報漏洩を確認したとしていますし、「5.6 事案の時系列」によれば2024年6月7日に「病院長が岡山県警察本部で流出した要配慮個人情報を確認。」しているにも関わらず、です。

---

「8.3 病院、電子カルテベンダー、機器ベンダーの課題整理」の「8.3.1 病院の丸投げ体質について」では次のような記述があります。

本来、プライム事業者である電子カルテベンダーが、こうした問題を病院に報告し、発注者たる病院と共に課題解決を行うべきであるが、病院側のセキュリティ意識の低さや厚労省ガイドライン、2省ガイドラインの理解不足から、プライム事業者たる電子カルテベンダーにセキュリティも含めた丸投げ状態となっていたのは事実である。プライム事業者としては、契約の目的であるシステムの稼働を最優先することから、「閉域網神話」を盾にセキュリティは劣後する。

病院はベンダーを監督する立場なのではないでしょうか。近年病院経営は厳しいとして、IT人材を外部に頼らざるを得ないとするような記述が同じ節にあります。しかし、対応過程での物品の調達力や人材の動員力からすれば、世間とは、少なくとも私が働いてきた環境からは、感覚がズレているように感じました。

---

社会の一員として、組織の一員として、いろいろと難しいことがあるのは確かです。しかし、セキュリティに関わる者として、自分の倫理観と信念「みんなで幸せになろうよ。」は出来るだけ大切にしていきたいと感じています。

最後までお読みいただきありがとうございました。