0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

大阪急性期・総合医療センター「情報セキュリティインシデント調査委員会報告書」のまとめと感想

Last updated at Posted at 2023-03-28

本記事の概要

昨年、令和4年10月31日に、大阪の病院でランサムウェアの感染事案が発生し、病院の業務に大きな支障をきたす等、大きな話題となりました。

本事案において、病院から報告書が公開されました。
一通り読んだので個人的にポイントだと思う点等をまとめようと思います。

なお、前例として、徳島県のつるぎ町立半田病院における事例も非常に有名かつ有用ですので、まだご覧になっていない方(特にセキュリティに関わる方、ITベンダー、病院関係者等)はぜひご一読いただくと非常にためになると思います。

病院の規模

大きな組織と小さな組織では、当然予算や扱う情報量等が異なり、セキュリティ体制にも大きな差が生まれます。
そのため、被害にあった病院の規模をまずざっくりと把握しておこうと思います。
比較として上述した半田病院を用います。

大阪急性期・総合医療センター つるぎ町立半田病院
総病床数 865床 ※1 120床※2
職員数 2014人※1   204人※3
主なIT担当者数 7人※4   1人※5

※1:本報告書 p.22
※2:半田病院のWEBページ
※3:令和4年度 半田病院経営委員会本資料p.21
※4:本報告書 p.24 (「決して潤沢な要員とは言えない」p.17)
※5:半田病院の報告書 p.28 (「少しパソコンに詳しい庶務係がIT担当一人で兼任」)

なお、共に各府県が定める「災害拠点病院」に指定されており、各地域において中心的な役割を持つ病院です。

NWへの侵入経路

(この章以降を読む際は、報告書概要版のp.2もしくは、報告書のp.13 図1 ネットワーク構成図と感染状況 を見ながら読んでいただくとわかりやすいかと思います。)

本事案における侵入経路は、本病院が病院食に使用していた給食センター経由である可能性が高いとされています。(p.11)

あらゆる組織は他の組織と何らかの繋がりがあるものですが、その繋がりの中の最も弱い部分を攻撃し、別の組織へと攻撃対象を拡大するようなサイバー攻撃を、一般にサプライチェーン攻撃といいます。
本事案は、まさにサプライチェーンが問題となった事例と言えます。

給食センターへの侵入

当該給食センターへの侵入は、CVE-2018-13379が用いられた可能性が高いとされています。(p.45)

この脆弱性は、FortiOS に存在する脆弱性で、FortiOS は主に外部NWから内部NWに接続するためのVPN機器として使用されています。
2020年11月頃から、世界中の当該脆弱性の影響を受ける機器のIPアドレス、VPN接続を行うためのユーザアカウント名、平文のパスワードの一覧が公開されており、JPCERT/CC等から注意喚起が行われてきたという経緯があります。
(本件における当該機器のバージョンは侵害発生時には5.4.2であったと示されています。(p.37)
しかし、Fortinetによると、影響を受けるバージョンは5.4.6-5.4.12とされています。
この点、p.13 図1を見ると、「5.4.8」であると書かれており、こちらが正で、p.37は誤記だと思われます。)

本事案においても、給食センターで使用されていたVPN機器のグローバルIPアドレス、ID、パスワードが公開されている一覧に載っていたため、これが侵入経路であると考えられています。(p.45)

給食センターから病院NWへの侵入

給食センター内のあるサーバ(サーバーA)が、脆弱なID・パスワードを使用しており、容易に侵害されてしまったようです。(p.12)

このサーバーAと関連するサーバとして、病院側の給食管理用サーバ(サーバーB)が存在します。
サーバーAは、サーバーBのID・パスワードを使用して、サーバーBの共有フォルダに対して、業務で使用するファイルを日々送受信していました。(p.45)

サーバーBは、閉域網を通じて、給食センターのシステムとつながっており、間にはファイアウォールが存在していましたが、このファイアウォールではRDP接続が許可されていました。
結果、攻撃者はサーバーAを侵害後、サーバーA内に保存されているサーバーBの認証情報を用いて、サーバーBへRDP接続を行い、感染拡大に成功します。

なお、サーバーA内に保存されているサーバーBの認証情報は、Mimikatzを用いて窃取されたとされています。(p.45)

病院NW内の横展開

サーバーBには、NICが2つ存在しており、一つは閉域網を通じて給食センターと、もう片方は直接病院内のNWとつながっていました。
このNICの二枚挿しについては、正確なNW分割が難しくなることから、一般に推奨されていません。
詳細については、この記事が詳しいかと思います。

つまり、サーバーBが侵害されると、直接病院内NWへ接続可能であったようです。
また、「サーバーA内に保存されているサーバーBの認証情報」は、サーバーBのBuilt-In Administratorのものであり、これは病院のその他のサーバーでも共通のパスワードが使用されていました。(p.46)
よって、サーバーBから病院内のその他のサーバーへ容易に感染拡大が行われました。

さて、この点、本報告書が公開される数日前に、多数の病院システムを手掛けるとあるベンダーが「病院ごとに同じIDとパスワードを使いまわす状態で構築を行っていた」として、報道されています。
なお、このようなバッドプラクティスは、他社でもあるという指摘もあります。

ランサムウェア感染

上記までの手段で各サーバへアクセスを行った攻撃者は、サーバをランサムウェア「Elbie(エルビー)」に感染させました。(p.11)
また、攻撃者グループ「Phobos(フォボス)」の可能性が高いとされています。(p.27)

この部分、一般に「攻撃者グループ名」と「用いられたランサムウェア名」が少しごちゃごちゃしていてややこしいのですが、私が調べた限り、「ElbieはPhobosの亜種」の可能性が高そうです。
(さらにややこしいことに、「亜種」「リネーム」「リブランディング」等の用語もぐちゃぐちゃですが、あまり厳密に使い分けはしていません。)

まず、(私が不勉強なのもありますが、)「Elbie(エルビー)」というランサムウェア自体あまり有名なものではないと思います。
検索した限り、この記事くらいしか参考になりそうなものがありませんでした。

「Phobosの亜種」という根拠ですが、
こちらの記事に「This ransomware is part of the Phobos family.」とある点
Phobosの検体解析結果の「以下のファイル拡張子を持つファイルについては暗号化しません」というリストに「.elbie」が含まれている(=自分や仲間が一度暗号化したものを暗号化しないようにするため?)という点
Phobosには亜種が多数存在するとみられているという点
があります。(逆に言うと、これくらいしか見つかりませんでした。)

感染後、データが暗号化され、身代金を要求する文面(ランサムウェアノート)がパソコン上に表示されました。
なお、ランサムウェアの手口として、
(1)データを暗号化することでシステムを使えなくする。これを復旧するために身代金を要求する
(2)データを窃取し、データの公開をしない代わりに身代金を要求する
という2点を根拠に脅迫する、「二重脅迫」が有名です。
この(2)があることから、ランサムウェアに感染した場合は、情報漏洩が起こったと考えることが自然となります。

この点、本事案では、フォレンジック調査等の結果から、情報漏洩の可能性は極めて低いとされています。(p.12)
個人的にも、
・報告書内のフォレンジック調査の部分で、データの送信量について触れられている点(p.46)
・Phobos は二重脅迫の手口を用いていないとする記事がある点
・私が知る限り、Elbie及びPhobosのリークサイトは存在しない点
から、この点の信頼度は高そうと考えています。

個人的に気になった点

さて、本事案における大切なポイントは多数挙げられますが、すべてについて触れることは難しいので個人的に気になった点について2点だけ触れておこうと思います。

契約書でのセキュリティ要件

2013 年に導入した医療機器で、Windows 2000 を搭載していたケースがあった。Windows 2000 は 2005 年にサポートが終了しており、有償の延長サポートも 2010 年に終了していたが、その 3 年後に病院にWindows 2000 搭載の機器を販売していたことになる。(p.50)

あるシステムで、ウイルス対策ソフトが設定されていないことが判明し、ウイルス対策ソフトの導入を求めた際に、何故ウイルス対策ソフトを導入しなかったのか、という質問に対して、建物設備として入札がなされ、その入札仕様にウイルス対策ソフトが入っていなかったことから導入をしていない、との回答があった。(p.51)

という記載があります。

是非ともベンダー各位(エンジニアだけでなく営業も含む)には知っておいていただきたいのですが、
基本的には、
「システム開発を受託したベンダは,契約に明示的な規定が置かれていない場合であっても」
「その当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することを(少なくとも黙示的に)合意していたものと解される可能性が高い」
のです(参考)。

また、半田病院の件でも指摘されていた通り、「IT素人の病院側」と「ITのプロのベンダー側」という構図である以上、セキュリティに関する必要最低限の知識を持っている事や助言を行う事の(少なくとも倫理的な)義務はあると考えます。

「タダ働き」はするべきではないという意見には賛成ですが、「上記のような配慮は前提として価格設定等を行う必要がある」ということだと思います。

インシデントレスポンスでの盲点

専門家チームとの初会合(障害発生 2 日目)の際に、セキュリティ関係以外で助言を受けたことは、「情報統制を徹底すること」「職員のメンタルケアに注意すること」「こんなときだからこそ、ちゃんと休息をとること」の 3 点だった。(p.60)

インシデントレスポンスを行う中では、どうしても「早く対応しなければ」という思いから、従業員などの関係者の負担が増えます。
本件では、「命に直結する仕事」「世間的に注目度の高い事件」「客と直接相対する仕事場」「数カ月に及ぶ影響があった」等、対応する病院関係者の方々のメンタル面の負担は相当なものであったことは想像に難くありません。

インシデントレスポンスの早い段階でこれらの助言がされ、適切に対応されたことは非常によかったと思います。

その他、一般的に言われるインシデントレスポンスにおける盲点として、「対応のために社員の労働時間が労働基準法を超える」というものもあり、経営者や管理職の方々は認識しておく必要があるかと思います。

まとめ

本事案は、対応に数億円かかる見込みであることに加え、病院の業務に支障がでた、つまり人の命に係わる事案でした。
本報告書は、病院関係者、ITベンダー、セキュリティ技術者等、様々な人にとって、非常に参考になる報告書だと思うので、是非ともご一読されることをお勧めします。

最後となってしまい恐縮ですが、このような報告書を公開されることは、広く業界・世間に大きなプラスの影響を与えると感じています。
本報告書を公開された病院の姿勢は本当に素晴らしいと思います。
ありがとうございます。

以上、読んでいただきありがとうございました。

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?