対象となる環境
古いOSを含む機器を、診療への影響を抑えながら使う環境
医療機器や専用端末では、機器本体を長期間使用する一方で、搭載OSのサポートが先に終了する場合があります。
医療機器メーカーの保守条件、診療アプリケーションとの互換性、診療への影響から、OSの更新やセキュリティソフトの追加を一律に行えないこともあります。
既存機器を使い続けながら対策を進めるには、OSの状態だけでなく、機器がどこへ接続し、どの経路で通信しているかを確認する必要があります。
- 医療機器、電子カルテや予約、会計などの診療システム、職員端末が接続している。
- サポートが終了したOSを含む古いOSや、専用アプリケーションを使用する機器がある。
- 機器ごとに更新時期、保守条件、管理主体が異なる。
- 有線と無線の接続環境が併存している。
- 診療への影響から、機器やネットワークを一斉に変更しにくい。
- 病棟、外来、検査、診察室、処置室、歯科診療室、受付、事務など、用途の異なる接続場所がある。
確認したい通信
古いOS、異なる保守条件、限られた運用体制
サポートが終了したOSを含む機器が残る
医療機器や専用端末では、搭載OSのサポートが終了していても、機器メーカーの保守条件や診療アプリケーションとの互換性から、OSだけを更新できない場合があります。
セキュリティソフトを追加できない機器もあるため、端末側の対策だけでなく、対象機器の通信が通るネットワーク側で確認と制御を補完する必要があります。
接続状況の変化を把握しにくい
医療機器の更新、保守用端末の接続、職員端末の追加によって接続状況が変わると、管理台帳と実際のネットワークが一致しないことがあります。 問題が起きたときに確認対象を絞るには、現在の接続端末と通信経路を把握できる状態が必要です。
部門を越える通信経路が残る
診療に必要な通信と不要な通信が分かれていないと、一台の端末で問題が起きたときに、ほかの医療機器、診療システム、職員端末へ到達できる経路が残ります。 一方で、必要な通信を確認せずに一律の制御を適用すると、診療業務へ影響する可能性があります。
規模によって停止の影響と運用体制が異なる
大規模病院で複数部門を同時に変更すると、異常が起きた場合の影響範囲と原因を絞りにくくなります。 クリニックや歯科診療所では、ネットワークの停止が受付、診療、会計など施設全体へ影響しやすい一方、専任のIT担当者を置きにくい場合があります。 施設規模に合わせて対象を区切り、診療時間、保守事業者との分担、切り戻し方法を確認してから変更する必要があります。
解決方針
施設規模と診療への影響に合わせて、確認と制御の範囲を決める
機器に近い場所で通信を確認する
医療機器、診療システム、職員端末が接続するアクセスエッジにTiFRONTを配置し、対象となる通信がTiFRONTを通過する構成を検討します。 サポートが終了したOSを使用する機器を含め、端末へのソフトウェア追加を前提にせず、ネットワーク側から確認できる範囲を補完します。 TiFRONTの導入は、OSの脆弱性を解消したり、メーカーサポートを延長したりするものではありません。
検知モードでイベントを確認してから制御を検討する
通信の遮断が診療へ影響する場合は、TiMatrixの対応項目を検知モードで運用し、検知による通信遮断を行わずにイベントとアラートの内容を確認できます。 TiMatrixで選択できる動作は項目ごとに異なるため、対象項目で検知モードを利用できることを確認します。 診療に必要な通信と業務影響を確認してから、制御を適用する項目と範囲を決めます。
脅威の兆候を確認対象へ結び付ける
vCATは、ネットワーク内部に用意した仮想的なトラップへの接続を手掛かりに、確認すべきアクセス元端末と事象を把握するために使用します。 vTrapへの接続を検知したアクセス元端末について、TiFRONTを通過する通信を遮断します。 判断はTiControllerが行うため、診療への影響と対象範囲を確認したうえで利用します。
必要な通信を残して範囲を分ける
通信範囲の制御を行う場合は、医療機器、診療部門のシステム、職員端末に必要な通信を整理し、TiFRONTを通過する通信へポリシーを適用します。 機器メーカーやシステム管理者と必要通信と例外を確認し、代表構成で検証してから適用範囲を広げます。
有線と無線の役割を分ける
有線端末ではIntelligent Defense Switch、無線端末ではSecurity APを接続場所に応じて検討します。 Security APはIntelligent Defense Switchと同じ機能セットではないため、vCATやマイクロセグメンテーションを無線側で利用できる前提にはしません。
規模に応じて管理方法を変える
大規模病院では、部門や棟ごとに対象範囲を分け、TiControllerで管理対象となる機器、端末、イベント、ポリシーを共通の管理体系で扱います。 中小病院、クリニック、歯科診療所では、少数のSwitchやSecurity APへ接続する端末を確認し、医療機器メーカー、保守事業者、院内担当者の作業分担を決めます。
配置する場所
医療機器や職員端末が接続するアクセスエッジ
TiFRONT Intelligent Defense Switchは、医療機器や職員端末などが有線で接続するアクセスエッジへ配置します。
対象となる通信がSwitchを通過するとき、対応する機能による可視化、検知、通信制御の対象になります。
無線接続ではSecurity APを検討できますが、有線側のSwitchとは対応機能が異なります。
下位スイッチ内で完結する通信や、TiFRONTを通らない別経路の通信は、同じ範囲で確認または制御できません。
大規模病院では、病棟、外来、検査などの部門ごとにアクセスエッジを確認し、代表部門から段階的に配置します。
クリニックや歯科診療所では、医療機器、診療システム、職員端末が集まる少数のSwitchまたはSecurity APを確認し、施設全体への影響を抑えられる配置を検討します。
有線・無線の接続場所を、施設規模に合わせて整理
使用する製品と機能
院内ネットワークで使用するTiFRONT
TiFRONT Intelligent Defense Switch
有線端末が接続するアクセスエッジで、対応機能の実行点になる。
TiFRONT Security AP
無線端末の接続環境を提供し、TiControllerによる管理対象になる。 Security APはvCATとマイクロセグメンテーションに対応しない。
TiController
管理対象となる機器、端末、イベント、ポリシーの運用をまとめる。
TiMatrix
SwitchまたはSecurity APを通過する通信から、対応する攻撃通信を識別し、設定に応じて検知または制御する
vCAT
Switch上の仮想的なトラップへの接続から、確認すべき兆候を捉える
マイクロセグメンテーション
Switchを通過する通信へ、端末や通信の条件に応じたポリシーを適用する
※ 利用できる製品と機能は、モデル、PLOS、ライセンス、TiControllerとの構成によって異なります。
導入後に変わること
接続場所ごとに確認できる範囲を整理する
| 導入前の状態 | 導入後に確認・実行できること | 成立条件 |
|---|---|---|
| サポートが終了したOSを含む機器へ端末側の対策を追加できない | 対象機器がTiFRONTを通過する通信を、ネットワーク側の確認対象にする | 対象機器の接続要件と保守条件を確認し、通信がTiFRONTを通過する配置にする |
| 接続端末やイベントの確認方法が部門ごとに分かれている | 管理対象となる機器、端末、イベントを共通の管理体系で確認する | TiControllerの管理対象、接続条件、管理項目を確認する |
| 通信を遮断した場合の診療への影響が分からない | TiMatrixの検知モードで通信を遮断せず、イベントとアラートの内容を確認する | 対象項目で検知モードを利用できることを確認する |
| 院内で確認すべき兆候を見つけにくい | vTrapへの接続をイベントとして確認し、アクセス元端末の調査につなげる | vCATに対応するSwitch、ライセンス、TiControllerとの接続を確認する |
| 必要な通信と不要な通信が分かれていない | 確認済みの条件に応じて、Switchを通過する通信へポリシーを適用する | 医療機器とシステムの必要通信、例外、対応モデル、ライセンスを事前に確認する |
| クリニックや歯科診療所で専任担当者を置きにくい | 少数の管理対象機器、接続端末、イベントをTiControllerから確認する | 院内担当者、医療機器メーカー、保守事業者の作業分担を決める |
導入の進め方
代表ラインで確認してから対象を広げる
- 病院、クリニック、歯科診療所の規模と、診療への影響が大きい業務を整理する。
- 医療機器、診療システム、職員端末の接続場所、OSの状態、管理主体を整理する。
- 部門内、施設内、上位ネットワーク、保守接続の通信経路を確認する。
- 医療機器メーカーの保守条件、必要通信、変更可能な時間帯を確認する。
- 大規模病院では代表部門、中小病院では優先する接続場所、クリニックや歯科診療所では限定したSwitchまたはSecurity APを対象に検証する。
- TiMatrixの検知モードでイベントとアラートを確認し、必要な例外と制御時の影響を確認する。
- イベント確認、設定変更、障害対応、切り戻しの手順と担当者を決める。
- 大規模病院ではほかの部門や施設へ段階的に広げ、クリニックや歯科診療所では施設内の残る接続場所を確認する。
TiFRONTの導入だけで、医療安全、法令、ガイドラインへの適合を保証するものではありません。
TiFRONTを配置しても、サポートが終了したOSの脆弱性が解消されるわけではありません。
機器の更新可否と更新計画は、医療機器メーカーや保守事業者と別途確認します。
Security APはvCATとマイクロセグメンテーションに対応しません。
利用できる製品と機能は、モデル、PLOS、ライセンス、TiControllerとの構成によって異なります。
適用前に確認すること
TiFRONTが担当する範囲と医療機器側の条件
- 対象機器の通信がTiFRONTを通過するか。
- 下位スイッチ内または別経路で完結する通信があるか。
- サポートが終了したOSを含む機器と、更新可能な機器を区別できるか。
- 医療機器やシステムの保守条件、接続要件、必要通信を確認できるか。
- 有線と無線のどちらへ配置し、それぞれでどの機能を利用するか。
- 必要なポート数、PoE、性能、電源、冗長化条件を満たすモデルはどれか。
- 使用する機能に必要なPLOS、ライセンス、TiController構成は何か。
- 検証方法、変更可能な時間帯、切り戻し手順を定義できるか。
- クリニックや歯科診療所では、院内担当者、医療機器メーカー、保守事業者の作業分担を決められるか。
- UTM、ファイアウォール、EDR、バックアップ、端末認証など、TiFRONT以外の対策が担う領域はどこか。