医療機関の脆弱性対応は、通常の変更管理とは少し性質が違います。厚生労働省のシステム運用編は、企画管理者は脆弱性情報を常に収集し、速やかに対応する必要があるとしたうえで、情報源としてNISC、IPA、製品・サービス提供事業者等を挙げています。また、近年はファームウェア、プログラム、EOS対象機器が攻撃対象になっており、ランサムウェアでも必要な脆弱性対策の見逃しが原因となる例があると説明しています。つまり、緊急脆弱性対応は「珍しい特例」ではなく、平時から起こり得る前提で設計すべき運用です。

しかも、厚労省の経営管理編は、経営層に対して、通常時から脆弱性対策、重要なアップデート、EOS等の情報を収集し、速やかに対策を講じることができる体制を整えるよう、企画管理者やシステム運用担当者へ指示することを求めています。ここで重要なのは、緊急脆弱性対応が情シス部門だけの判断では完結しないことです。情報収集は平時の体制整備、暫定判断は運用、診療影響を伴う判断は経営、という切り分けが必要です。

厚労省のシステム運用編はさらに、保守手続きについて、原則として事前申請・承認である一方、障害時や緊急を要する脆弱性対応では事後承認も想定されると明記しています。つまり、公的資料の立場は明確で、緊急時には通常フローを短絡化してよいが、無承認でよいわけではないということです。緊急脆弱性対応は、例外運用ではあっても、管理の外に置いてよい運用ではありません。

では、誰がいつ暫定判断するのでしょうか。
確立された事実として言えるのは、システム運用編が、脆弱性対策にあたって事前に事業者へ実施可否を確認し、他ソフトウェアへの影響も踏まえて判断することを求め、対応が難しい場合にはリスクに対する対策や管理方法を協議の上で代替策を講じる必要があるとしている点です。つまり、最初の技術判断は、システム運用担当者と事業者の協議が起点になります。

一方で、専門家の見解として実務的に整理すると、判断は少なくとも二段階に分けるのが安全です。
第一段階は、システム運用担当者＋事業者による技術的暫定判断です。ここでは、対象機器・対象バージョン・適用可否・想定影響・代替策の有無を短時間で見ます。
第二段階は、企画管理者、必要に応じて経営層による運用判断です。ここでは、診療への影響、停止の要否、紙運用や参照系環境への切替の必要性、関係者周知の要否を決めます。これは厚労省資料そのものの固定役割表ではなく、経営管理編、システム運用編、BCP手引きの要求事項をつないだ実務上の整理です。

緊急脆弱性対応の実務フローとしては、次の順に整理するとわかりやすいです。
まず、脆弱性情報の把握です。CSIRTは、BCP手引き上、脆弱性情報、攻撃予兆情報を常に収集・分析し、対応方針や手順を策定する組織とされています。したがって、緊急対応の入口は、NISCやIPAの注意喚起だけでなく、CSIRT、ベンダー通知、保守連絡網を含む情報収集ラインを持っていることです。

次に、緊急性の判定です。少なくとも今回確認した公的資料では、「CVSS何点以上なら緊急」「何時間以内に適用」といった全国一律の数値基準までは示されていません。したがって、緊急性は、自院で使用中か、外部接続点にあるか、管理者権限や保守経路に関わるか、診療停止や個人情報漏えいに直結するかで判断するのが実務的です。この整理は、厚労省の「速やかに対策を講じる体制」「影響確認」「代替措置」「被害拡大防止」の要求事項を運用へ落とした専門家の見解です。

そのうえで、すぐ当てられるなら速やかに適用、当てられないなら暫定措置へ進みます。厚労省は、脆弱性対策として、パッチ適用に加え、不要サービスや通信ポートの非活性化、ネットワークの構成分割、ネットワーク間のアクセス制御、マクロ停止、メールやファイルの無害化、EDRや振る舞い検知などを挙げています。したがって、緊急パッチが即時適用できない場合でも、露出面を減らす暫定措置は打てます。とくに、VPN、FW、外部保守回線、公開サーバ、管理者向け経路は優先度が高いと考えるのが自然です。

ここで重要なのが、クラウドとオンプレミスで対応の仕方が少し違うことです。厚労省は、オンプレミスでは個別の申請や承認が可能だが、パブリッククラウドでは個々の利用者ごとの保守申請・承認が難しい場合があるとしています。その場合は、事業者に保守対象時間を確認し、自院システムへの影響範囲、必要な代替措置を確認し、企画管理者へ報告した上で、院内及び関係者へ周知することが求められています。つまり、クラウドでは「事前承認が難しいから放置」ではなく、影響確認と周知の精度を上げるのが筋です。

さらに、もし単なる脆弱性対応ではなく、すでに攻撃兆候がある場合は、扱いが変わります。BCP手引きは、原因調査の結果、サイバー攻撃の兆候がある場合は、ネットワーク遮断により通信を遮断し、感染拡大を防止すること、必要に応じてバックドアの無効化、無効にされたセキュリティ機能の復帰、攻撃された脆弱性への対応を行うことを示しています。また、経営層への報告後、対象システムの使用中止、対応チームの設置、紙カルテ運用や参照系環境構築などの代替運用方針を定めることも求めています。つまり、「脆弱性の注意喚起」段階と「攻撃の兆候あり」段階は、承認レベルも初動も同じではありません。

このため、25日目の記事では、緊急脆弱性対応を少なくとも次の4類型に分けると実務に落とし込みやすいです。
A. 通常更新：通常の事前申請・承認で実施。
B. 緊急更新：運用担当＋事業者が技術暫定判断し、速やかに実施、その後に事後承認。
C. 緊急更新＋暫定措置：即時適用が難しいため、通信遮断・ポート閉塞・アクセス制限などを先行。
D. 攻撃兆候あり：経営層報告、使用中止判断、代替運用、証拠保全、所管官庁等への連絡を含む。
この4類型の区分自体は、厚労省文書の見出しではなく、現行資料を運用に落とした専門家の見解です。

また、緊急時ほど忘れやすいのが、事後記録です。システム運用編は、保守時にアクセスログの収集と作業計画書との照合、終了後の企画管理者への報告を求めています。したがって、緊急脆弱性対応でも、少なくとも
何の情報を起点に、誰が、いつ、何を判断し、何を実施し、何を見送ったか
を記録しておく必要があります。事後承認を認める運用ほど、記録が薄いと再発防止にも監査にもつながりません。

さらに、緊急対応後は通常運用へ戻す条件も必要です。システム運用編は、非常時の運用について、非常時のユーザアカウントや非常時用機能の手順整備、使用されたことの検知と監査、正常復帰後は継続使用できないよう変更することを求めています。したがって、緊急時に使った暫定アカウント、暫定接続、例外設定は、恒久化しないことが前提です。緊急対応は、例外を作ることではなく、管理された一時避難であるべきです。

最後に、報告先です。厚労省の医療分野サイバーセキュリティ対策ページは、サイバー攻撃を受けた場合だけでなく、その疑いがある場合や医療情報システム障害が発生した場合も、インシデント発生後速やかに連絡するよう案内しています。経営管理編でも、厚生労働省、都道府県警察の担当部署その他の所管官庁等へ速やかに報告するための手順・体制整備が求められています。したがって、緊急脆弱性対応が単なる更新作業で終わらず、攻撃兆候や障害へ発展した時点で、報告モードへ切り替える判断線を決めておく必要があります。