富士ソフトが扱う blackberry QNX リアルタイムOS に 脆弱性が見つかり、米国FDA, 日本の厚労省が 医療機関や医療機器製造業者に対して注意喚起を行っている。
厚労省通知 2021年8月23日 『医療機器のオペレーティングシステムに係る脆弱性への対応について(注意喚起)』
本件については下記の記事の解説が分かり易い。
【ZD Net Japan 『米政府機関、ブラックベリー製品の脆弱性で注意喚起』より引用】
米サイバーセキュリティ・インフラセキュリティ庁（CISA）は、BlackBerryの製品に存在する「BadAlloc」の脆弱性に関するセキュリティアラートを発表した。BadAllocは、2021年の初めにMicrosoftの研究者が発表した脆弱性だ。
また米国時間8月17日、BlackBerryは同社の「QNX Real Time Operating System（RTOS）」がBadAllocの脆弱性の影響を受ける可能性がある問題についてのアドバイザリーを発表した。QNX RTOSは医療機器や自動車、工場などで使用されており、国際宇宙ステーションでも使われている。同社は最近、QNX RTOSがおよそ2億台の自動車で使われていると明らかにしたばかりだ。
CISAは、QNX RTOSは一部のIoT機器やOT/ICSシステムで使用されており、これらのシステムを保護するための対策が急務だと付け加えた。BlackBerryは影響を受ける製品の完全なリストを公開している。
CISAのアラートでは、「リモートの攻撃者にCVE-2021-22156を悪用されると、対象デバイスがサービス妨害状態に陥ったり、任意のコードが実行されたりする可能性がある。BlackBerryのQNX RTOSは幅広い製品で使用されており、この製品が侵害されると、悪意を持った攻撃者に極めて重要度が高いシステムの制御を奪われる可能性があり、国家的に重要な機能のリスクが高まる」と述べている。
「CISAは、現時点ではこの脆弱性が積極的に悪用されている事例を把握していない。CISAは、重要インフラ企業や、影響を受けるQNXベースのシステムを開発、保守、サポート、使用しているその他の組織に対して、影響を受ける製品にできる限り早くパッチを適用することを強く推奨する」
CISAによれば、一部のRTOSのソフトウェアをアップデートするには、機器を取り外すか、敷地外の施設に持ち込んで、メモリーを物理的に交換する必要があるという。
BlackBerryのアドバイザリーには、同社がこの脆弱性を修正するためにリリースした多数のアップデートの情報が掲載されている。Microsoftは4月に、BadAllocは25件のCVEにまたがる問題であり、消費者向け製品から医療用IoTや産業用IoTまでさまざま分野に影響を与える可能性があると述べている。
米国の政治専門ニュースメディアであるPoliticoは8月17日、4月にBadAllocの脆弱性に関する情報が開示されて以降、BlackBerryと米国の政府関係者との間で交わされてきた舞台裏での議論について報じた。
記事では、BlackBerryは同社の製品がBadAllocの影響を受けることを否定し、米政府がこの問題に関してアラートを公表することに抵抗したとされている。
また、CISAの担当者が、QNXシステムに関するセキュリティアラートについて、影響を受ける業界や国防総省などと事前に連携を取っていたことや、外国の政府関係者にもこの脆弱性について説明する予定であることも報じられている。
BlackBerryは6月に、QNXはAptiv、BMW、Bosch、Ford、GM、本田技研工業、Mercedes-Benz、トヨタ自動車、Volkswagenが製造する多数の自動車に採用されていると発表している。
【引用終わり】
サイバーセキュリティに関する脆弱性は市販後に見つかることがあり、それ自体はあってもまったく不思議ではないので、この脆弱性が見つかったからといって QNXの品質が悪いとは思わない。
どの製品にもありうるので、ここは粛々とパッチを当てたり、QNXの外側の環境で緩和策を取ることが重要と考える。
今回の記事で取り上げたのは、blackberry QNX について、日本の販売元の富士ソフトが QNXは IEC 62304（医療機器ソフトウェア - ソフトウェアライフサイクルプロセス）のソフトウェア安全性クラスC に準拠証明書付きで出荷されると宣伝しており、これが IEC 62304 のリスクベースアプローチの考え方から逸脱していて、単に商品を売るために 規格を利用しているに過ぎないことを示したかったからだ。
【QNX OS for Medical 概要・特長 】より引用
医療機器の複雑さが日増しに増加する昨今、規制の監視が益々厳しくなって来ています。根源が知られており事前認証されたコンポーネントを選択することで、認証プロセスが相当楽になります。QNX OS for Medical（医療用QNX OS）は、独立サードパーティにより「医療機器ソフトウェア - ソフトウェア ライフサイクル プロセス」の標準規格であるIEC 62304準拠であると評価されています。この製品はARMとx86プロセッサーでサポートされています。
医療用QNX® OSは、医療機器メーカー用のQNXソフトウェア システムズソリューションの主要素です。これは、市場投入前の認証業務に必要な時間と手間を低減することで医療関係のお客様が厳しい規制要件を満たすお手伝いをするためにデザインされています。医療用QNX OSは、QNXの標準オペレーティングシステムにより100% API互換で、お客様が最大限にソフトウェアを再使用し、それぞれ異なる認証要件を持つ複数製品用の共通プラットフォームを構築できるようになります。この製品は独立サードパーティ評価によるIEC 62304クラスC準拠証明書付きで出荷されます。
【引用おわり】
このブログサイトでも幾度となく、IEC 62304 が自動車ドメイン等で幅をきかせている機能安全規格ではなく、医療機器のインシデントに対して、医療機器のソフトウェア開発プロセスをリスクベースアプローチでの再発防止を目的として策定されたものであることを説明してきた。
機能安全規格では、製品に使用している部品の開発プロセスが機能安全規格が定めるプロセスどおりに作られているかどうかを認証することを推奨しているが、IEC 62304 はあくまでも医療機器の開発プロセスをリスクベースアプローチで開発することを求めていて、部品単位での規格適合など求めていない。
※機能安全という名前が良くない。安全（Safety）は機能（Function)ではない。機能的安全というのもおかしい。安全機能は手段でしかなく、本質を示していない。機能安全という言葉自体が安全の本質を目指していないと感じる。
そもそも、製品全体の構成要素の信頼性を高めることで安全性を確保しようとする設計は個別最適の発想（フォールト・アボイダンス）であり、ソフトウェアの規模が増大し、複雑化した現代では、まったくもって古い考え方である。1960年代の主流だった発想だ。
今では、左図の緑枠にあるように、製品の安全は「フェールセーフ」「フォールトトレランス」「エラー・プルーフ」といった、個々の構成要素に故障がバグがあっても安全側に倒れるようにしたり、冗長性を持たせたり、操作者は必ずミスをするという前提で設計するといった全体最適の発想を行うことが求められている。これが IEC 62304 で求められているリスクベースアプローチ（患者危害に至る危険状態が起こる要因を分析して、重大な危害が起こらないような対策を行う手法）だ。
だから、RTOSのような汎用部品が何の機器に組み込まれて、どのような機能や性能を実現するために使われるかが分からない状態で、安全性を評価することはできない。
例えば、列車で事故が発生したら速やかに列車を止めることが求められるが、飛行機で事故が発生したら、近くの空港まで飛行機を飛ばし続けなければらならない。同じ移動手段でも前者は止める、後者は動き続けることが求められる。
使用目的（意図する使用 = Intended Use）が定まらないと、リスク分析ができないと教えている。なぜなら、同じ材質、同じ形状をしていても何に使うのかによって、危険状態に至る可能性や発生する危害は変わるからである。
この図にあるように、細い木の棒は、アイスキャンディの棒かもしれないが、医師が口の中を診る際の舌圧子かもしれない。
後者の場合は、医療機器となり滅菌や一つ一つの包装が求められる。
同じ材質、同じ形状でも、意図する使用（Intended Use）によっては、リスクが変わるのだ。
よって、汎用製品である リアルタイムOS について、規格の認証が取れているから安全性が高いと主張しているのは、間違っているし、意味がない。
下記の誤った記事を見て欲しい。IEC 62304 を機能安全規格と同じように扱っている。さらに、IEC 62304 のソフトウェア安全クラスは、機器の意図する使用によってリスク分析を行いその評価によってクラスが変わるはずなのに、なにに使われるのか分からない段階で、ソフトウェア安全クラスC であると言っている。一番高いクラスにしておけばいいでしょという考えならば、それはリスクベースアプローチの本質をまったく理解していないことになる。ようするに、IEC 62304 の規格趣旨が理解できていない証拠である。
【MONOist 組込み開発ニュース『工業、自動車、医療機器の機能安全認証を取得した最新版RTOSを提供開始』】より引用
BlackBerryは2020年11月9日、機能安全認証を取得したリアルタイムOSの最新版「QNX OS for Safety 2.2」の提供を開始した。自動車や組み込みソフトウェア開発などにおいて、認証取得作業を軽減し、迅速なシステム開発を可能とする。
最新版のQNX OS for Safety 2.2は、「QNX Neutrino RTOS」をベースとする。第三者認証機関のテュフ ラインランドから、「IEC 61508 SIL3」（工業）、「ISO 26262 ASIL D」（自動車）、「IEC 62304 Class C」（医療機器）の機能安全認証を取得している。
さらに、「ISO 26262」「IEC 61508 TCL3/T3」の要件に準拠したC/C++ツールチェーンも採用している。これにより、QNXの機能安全性製品に安全認証取得済みのC++ランタイムライブラリが含まれることとなった。
同社は、最新版のQNX OSを利用することで、開発期間を短縮しながら安全性や信頼性の高いシステムを開発し、開発費用の削減が可能になるとしている。
【引用おわり】
一方で、富士ソフトは、IEC 62304 を医療機器のソフトウェア開発に適用する際に、支援を行うサービスも行っており、そのサービスを紹介したページでは、IEC 62304 の趣旨を正しく理解しているように見える。【対象ページ】
なぜ、このような矛盾が生じるのか。理由は簡単だ。QNX が IEC 62304 に準拠したと宣伝に使っている部門と、IEC 62304 をコンサルテーションしますといっている部門が異なっており、前者は IEC 62304 の中身を読んでおらず（または読んでいても理解しておらず）規格適合したと表明すれば、他のRTOSと差別化ができ、規格の趣旨をよく理解できていないユーザから購入してもらえると考えているからだ。
そして、規格の内容や趣旨を熟知している 第三者認証機関が 機能安全ではない IEC 62304 を汎用ソフトウェア製品に対して適合証明してしまうのか、これも商売になるからだ。（規格適合を証明するには相当な費用がかかる）
規格を熟知した認証機関が誤った使い方をしていることを知っていながら、規格適合証明を出しているのだから、こっちの方が罪が重いと思う。
このブログで必要に問題のあるソフトウェア製品について批判する記事を書くのは、これらの認証がエンドユーザの安全を目指して実施されているのではなく、単に商品を売りたいために認証を取っていると思うからだ。
ここで冒頭の blackberry QNX リアルタイムOS に 脆弱性が見つかり、米国FDA, 日本の厚労省が 医療機関や医療機器製造業者に対して注意喚起を行っているという件に話しを戻す。
blackberry QNX リアルタイムOS は 第三者認証機関のテュフ ラインランドから、「IEC
61508 SIL3」（工業）、「ISO 26262 ASIL D」（自動車）、「IEC 62304 Class C」（医療機器）の機能安全認証を取得している（IEC 62304は機能安全規格ではないので、この記述は誤り）と、富士ソフトはWEBサイトで、規格の認証を取得していて、他の製品より安全ですよと主張している。
揚げ足を取るつもりはないが、今回の脆弱性の発見で脆弱性を突かれると リアルタイムOSを使っている製品が悪用され、患者危害に至る可能性があるためパッチを当てる必要があることが分かった。
QNX は「信頼性が高いとされていた」ため、医療機器にも多く使用されていたので、米国や日本の規制当局が冒頭の注意喚起を出したわけだ。
QNXは自動車にも多く使われているようなので、自動車業界でも対応が求められているだろう。
ただ、QNXが対象システムのどこに、何に使われているのかによって、リスクの大きさは異なる。だから、製品ごとにリスク分析を行うことが重要なのであって、部品の製品開発のプロセスが規格に適合していることを主張するのはおかしいし、医療機器の場合、規格趣旨から特に間違っている。
この図を再掲するが、個別最適で安全設計をする時代ではないのだ。全体最適の発想で、意図する使用を明確にして、その上でリスクを分析し、危害の重大度を考慮し、重大な危害に至るケースを優先して、対策を立てていることが、患者や利用者の被害を効率てきに低減することにつながる。
このリスクベースアプローチの考え方を理解せずに、規格適合を主張し、商品を売ろうとする者は、場合によっては、エンドユーザのリスクを高めてしまっている可能性さえある。
汎用ソフトウェア部品を利用する開発者は、ソフトウェア部品の開発プロセスの認証を気にするのではなく、そのソフトウェアがどのような検証を行ったのか、テストの網羅性やテストケースの設計はどうだったのかを精査するべきだ。
規格ビジネスの悪は、規格が求める内容を理解しないユーザにお墨付きをちらつかせて商品を売ろうとする側面を増長させる点にある。
単純な商品販売における競争のための手段ならまあ、無駄ではないし、それもありかと思うが、そこにユーザの健康や安全がかかっているとすれば、それは間違いだと言わなければかえって危ないと思っている。
セキュリティ上の脆弱性は市販後に見つかったら、粛々を対応することでよい。
だた、これを期に、汎用ソフトウェア製品の規格適合証明が製品の安全性で担保するのは間違いであるということを再認識して欲しい。
