
関連するソリューション

マネージドサービス(運用・保守)

セキュリティサービス
フェロー 関原 弘樹 
先週のことですが夜道を帰りがけ、ふと晴天の夜空を見上げると満月の一部が赤銅色に暗くなっているのに気づき、そういえばこの数日前に皆既月食に関するニュースがあったことを思い出しました。
この広い太陽系における稀有なイベントのタイミングを正確に予想してきた先人の知恵に感心しつつ、しばしのあいだ童心に帰りゆっくりと欠けてゆく月を眺めていました。
(ちなみに心はなんとか昔に帰れるレベルでしたが、視力は2度と帰れないレベルになっていることがわかりました。)

写真AC
さて、今回のコラムはまたしても発生してしまった病院におけるランサムウェア被害についてとなります。
大阪の大病院がランサムウェアの被害に
速報として病院側からは
「10/31 に「ランサムウエア」の攻撃により電子カルテシステムに障害が発生し、緊急以外の手術や外来診療の一時停止など通常診療ができない状況となっています。
現時点(11/1 17 時現在)で復旧のめどが立っておらず、明日以降も当面の間、休診とさせていただきます」
とのコメントが出ています。
そして、本稿執筆中の11月上旬時点でも診療業務は通常の状態に戻ることはできず、電子カルテシステムは一部の稼働にとどまる状態のようで、病院による11月7日の会見では病院全体のシステムの完全復旧は来年1月になる見込みと発表されています。

https://www.gh.opho.jp/pdf/info20221109.pdf より
インシデントレスポンス体制
サイトを確認してみるとSAJは令和4年度 厚生労働省委託事業として医療情報セキュリティ研修を受託しているようですね。
医療情報セキュリティ研修事業
インシデント対応業務の詳細については情報がありませんでしたが厚生労働省とSAJは他の事業でも接点があり密接な関係を築いているようです。
今後の医療セクターのセキュリティという観点ではこの専門チームの派遣が今回だけの特別なスキームなのかどうか(公営ではない大病院で同時多発的に同様のインシデントが発生した際に同様のサポートを期待するのは難しいのか?)はちょっと気になるところではあります。
システムの被害状況
さすがに病床数に比例した大きなイントラネット持っており被害が拡大してしまいました。
また、これだけのクライアント端末数だと当然AD(ウインドウズドメイン)でのアクセス管理となりますが調査結果からはADログに大量のログオン失敗の痕跡があったようで、もう少し早く気付ける仕組みがあればと悔やまれますが、短時間?(執筆時点で潜伏期間の情報は見つけられませんでした)でこれだけの規模に広げたということで
「侵入者の巧妙な横展開は恐るべし!」
といったところでしょうか。

出典:Microsoft 本画像はイメージとなり今回のインシデントとの関連はございません。
不幸中の幸い
しかしながら前記の様にこれをもってしても通常業務への全面的な復旧はさほど劇的には進んでいないようで、(セオリーとしての)オフラインバックアップを取って安心するのではなく、その網羅性やハードウェアとマニュアルを含めたリカバリプロセスの整備と検証の必要性を指摘する声も聞こえてきます。

出典:Wikipedia 本画像はイメージとなり今回のインシデントとの関連はございません。
サプライチェーン経由で侵入された疑い

https://www.seichokai.or.jp/system/upload/bellkitchen/news/1667807474_003299000.pdf
より抜粋
リリースでは「当施設から給食を提供している○○様のシステム障害との関係については、現在調査中です。」となっていますが前記SAJの調査チームによる調査の結果をもとにした各種報道では所謂「クロ」という見方が大勢を占めています。
「同じ会社のVPN」というちょっと謎なワードでの報道もありましたが、この給食を提供する事業者ではシステムをリモートからメンテナンスできるようにVPNアプライアンスを利用したリモートアクセスシステムを導入していたようです。
報道からはこのリモートアクセスシステムは昨年ランサムウェア被害を受けた徳島県の病院と同じVPNアプライアンス(FortiGate 60E)によるシステムだったようで、昨年来広く脆弱性とそれを利用したサイバー攻撃が周知されていて早急なアップデートを求められていたそのアプライアンスのファームウェアについても脆弱性が残ったままのバージョンを利用していたとのことです。
結果、VPNを糸口に給食事業者のサーバもしくは端末を踏み台にしてADログの情報からRDP(リモートデスクトップ)で病院側のイントラネットに侵入し、マルウェアの展開を広げたようだと推測されています。
(個人的には「なぜこのサプライヤー(給食を納入事業者)にRDPを利用する業務プロセスが必要であったのか?」という点がまだよく理解できていません。
病院側のDCにホスティングされたサーバ上で自由な操作ができるインタラクティブシェル(RDP)がなぜ必要なのか?なぜHTTPS上のGUIやAPIが使えないのか?)
いずれにせよ、推測されたように本当に侵入経路が給食事業者経由であればサプライチェーン攻撃の典型的な事例となり今後も語り続けられるインシデントになるでしょう。
[参考]
手前味噌ですが参考として弊社のコンサルティングサービスで提供している月次のセキュリティアウェアネス関連資料からサプライチェーン攻撃に関する部分を転載します。
ご興味のある方はご連絡ください♪
セキュリティトピックス 今月のトピックスより


©株式会社インフォメーション・ディベロプメント
サイバー・セキュリティ・ソリューション部 コンサルティンググループ
3つの教訓
ここでは3つ挙げてみましょう。
①ランサムウェア攻撃に対しバックアップが無事であれば一定のRPO(Recovery Point Objective/目標復旧時点)へ復帰できる可能性は高いが、そのRTO(Recovery Time Objective/目標復旧時間)に関して正しく設定し、達成するためには“幅広いシナリオ検討と入念な準備”がなければ難しい。
②主要な業務委託先のセキュリティ態勢をBCP(事業継続計画)の観点から委託開始時点及び定期的に確認することは既に一般的になっている。
しかしながら、それが書面上の形式的なレベルにとどまっていないか?
ということを改めて問い直すとともに、より実践的に現場レベルでもサプライチェーンのセキュリティレベルを引き上げるために
「流行しているサイバー攻撃やシェアの高いITデバイスの脆弱性」
等のタイムリーなセキュリティ情報を”必要に応じてサプライチェーン内で共有“し、その対応状況を確認し合う仕組みが不十分な場合は早急に確立する必要がある。
⓷自社の業務委託先とのシステム連携は業務プロセスを精査し、エンドポイントから独立したデバイス上で(FW, L3SW)“ネットワークフローを限定し、必要最小限のアクセス権限(管理者権限を使わない)で実行”する。
システム構築時に追加コストを避けるあまりこの部分を疎かにすると必要以上のリスクを抱えることになるため、リスクが具現化した際にそれ以上のコストを負担することになる。
いかがでしょうか?
(ご覧の様にここではサプライチェーン経由で侵入が行われた前提で記載しております)
【エバンジェリスト・ボイス】RTO/RPO/RLO/MTD より

https://www.idnet.co.jp/column/page_034.html
■■【付録】サプライチェーンのセキュリティに関するトピック■■
付録として最後にタイムリーなニュースに少しだけ触れておきます。
お時間の許す方はごらんください。
先月10月28日に経済産業省と公正取引委員会から
「サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて」
と題するガイドラインのリリースがありました。
連名での公表についてやや疑問に思う方もいらっしゃるとおもいますが、私が独自ルートを含めて調査した範囲では
「下請法については、従来から、経済産業省(中小企業庁)と共管で、公表を伴う強い措置である勧告は公取委だけしかできないが、それぞれで、相談対応、指導等はしてきている。今回の宣言は、制度の基本的な枠組みを変えるものではないが、この分野について、公取委と経済産業省で連携して、やれることはしっかりやりますというもの」
となっています。
公正取引委員会は彼ら自身が法令違反への調査能力を持ちますのでかなり強い影響力を持っています。
サプライチェーン全体のサイバーセキュリティ向上のための取引先とのパートナーシップの構築に向けて
https://www.jftc.go.jp/dk/guideline/unyoukijun/cyber_security.html
https://www.meti.go.jp/policy/netsecurity/hontai_1028.pdf

目次を確認すると
「第2 中小企業等におけるサイバーセキュリティ対策」が経済産業省より
「第3 取引先との関係構築」が公正取引委員会より
といった格好の構成となっています。
----
第1 はじめに
第2 中小企業等におけるサイバーセキュリティ対策
1 サイバーセキュリティお助け隊サービス
2 セキュリティアクション
3 中小企業の情報セキュリティ対策ガイドライン
4 サプライチェーン・サイバーセキュリティ・コンソーシアム
第3 取引先との関係構築
1 パートナーシップ構築宣言
2 取引先への対策の支援・要請についての考え方
(1)取引の対価の一方的決定
(2)セキュリティ対策費の負担の要請
(3)購入・利用強制
QA
第4 おわりに
----
第2の「中小企業等におけるサイバーセキュリティ対策」についてはこれまで経済産業省(およびIPA)が推進してきた中小企業をセキュリティ面でサポートする施策をまとめて紹介し、その利用を促しています。
第3の「取引先との関係構築部分」についてはまとめるといたってシンプルで
「発注者が起点となりサプライチェーン全体のセキュリティ向上のための施策を実施することは大歓迎です。しかし、必要なコストは発注先に押し付けるのではなく、法令に従い受発注側双方で納得のいくような形で分担するように」
ということが強調されています。
まあ、「2 取引先への対策の支援・要請についての考え方」の「(3)購入・利用強制」では「合理的な必要性」、「正当な理由」との文言が並びますが、例によってロジックはいくらでも組み立てられそうなところではあります。
おわりに
コロンブスの卵で有名なクリストファー・コロンブスという大航海時代の冒険家はみなさまもご存じだと思います。
彼はスペイン王室のバックアップで数回の大西洋横断をし、カリブ海の島々を発見するなどの功績を上げます。
しかし彼とそのチームは結果的に最後となった1504年の航海で絶体絶命のピンチに陥っていました。
目的の島に到達するも現地の住民との交渉に失敗してしまい、食料の調達ができずに瀕死の状態に陥ってしまったのです。
窮地を脱するために彼は最後の大勝負をもくろみました。
どうしたかというと、ドイツの数学者から入手してあった天体暦で3日後に皆既月食が起こるのを知り、現地の住民に「今すぐ食料を持ってこなければ月を隠してやる!」と脅迫をしたのです。
結果、3日後に暦の予測どおり皆既月食が起こり、月はその輝きを失います。
それに驚いた現地の住民はコロンブスの元へ大量の食糧を運んで月を元に戻すよう懇願したそうです。
コロンブスの大勝利です(*^^)v

「十分に発達した科学技術は、魔法と見分けがつかない」(ちょっと違う!?)
現代では勇敢な冒険者というよりは非道の奴隷商人というイメージを持たれているコロンブスの“どう受け止めたらいいのかわからない、、なんとも微妙な逸話”ですが、どちらにせよ古今東西 ”正しい知識と正しい情報を持っていなければ対等な交渉はむずかしい” と理解しておきます。
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara,
CGEIT, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,
AWS Certified Security – Specialty,
Azure Solutions Architect Expert,
Google Cloud Certified Professional Cloud Security Engineer,
Oracle Cloud Infrastructure 2021 Certified Architect Professional,
Oracle Cloud Platform Identity and Security Management 2021 Certified Specialist,