2017-10-22

「ASIL-Dを達成しています」の怪

最近,「ISO 26262 の ASIL D を達成しています」という汎用OSやソフトウェア部品の宣伝をネット上で見かける。

このような広告を見るたびに首をかしげたくなる。

左の図は,GHS(ヘルスソフトウェア推進協議会)のリスクマネジメントトレーニング講座で毎回使っているスライドだ。

Intended Use意図する使用が決まらないとリスク分析ができないという説明に使っている

左の細長い木の棒は何に使うのでしょうか?という問いに対して,上がアイスキャンディーの棒で,下が医師が喉の奥を診るために使う舌圧子になるという説明だ。

ようするに,同じ形状,材料であっても,使用目的が変わるとアイスキャンディーの棒になったり,舌圧子(医療機器:電子機器でなくても Medical Device になる)になったりすることを説明している。

アイスキャンディの棒も舌圧子も滅菌はしているだろうが,医療機器とする場合は,法規制上のハードルも高くなる。舌圧子の場合,病気にかかっているかもしれない子供の口の中に入れるため,滅菌,包装,表面のなめらかさなどの要求が厳しくなる。裏返せば,「舌圧子が原因で菌に感染するリスク」「舌圧子が原因で口の中を傷付けるリスク」が想定され,そのリスクを受容するために求められる機能や性能を達成しないとリスクが残留してしまうということだ。

左の木の棒がソフトウェアだったらどうだろう。ソフトウェアは変更が容易なため,ソフトウェアを変更することによって Intended Use(意図する使用)が変わってしまうということはある。現在あるソフトウェアをユーザーの求めに応じて「使いやすくしたい」「より性能を高めたい」「より多くの機能を追加して付加価値を高めたい」と考え,実行することは良いことだが,それによってIntended Use(意図する使用)が変化し,予想していなかったリスクが潜在してしまうかもしれないことを考えているだろう。

例えば放射線治療器 Therac-25 は1980年台に死傷者6名を出すソフトウェア起因の事故を起こした。これらの事故の原因の1つに,コンソール画面上で各種の設定を行っている際に,途中で最初のモード選択が間違っていることに気付いたら,気付いた時点で修正をかけられるようにして欲しいという要望がユーザーからあった。その求めに応じて,ソフトウェアを変更したところ,コンソール上の設定値と,実際の機器の設定に不整合を発生させる不具合が生じて事故に至った。(IEC 62304 実践ガイドブック 2.1.2章で解説)

これは,ユーザインタフェースをソフトウェアで改善しようとしたところ,想定外の大きな新たなリスクを作り込んでしまった事例だ。

ソフトウェアシステムは規模が増大し,複雑化する一方だ。そのため,アーキテクチャ設計の重要性が再認識されているが,ソフトウェアの構造は見えにくいだけに,ぐちゃぐちゃなソフトウェアもたくさんある。

だからこそ,ソフトウェアの個々の部品の信頼性を積み上げて,システムの安全性を担保しようとすることには無理がある。ソフトウェアの個々の部品の信頼性を高める努力をしつつも,そこにも不具合があるかもしれないとい疑いを持って,システムが安全になるような設計をしなければならない。

だから,汎用のOTS/SOUPを取り上げて,それを使えばシステムが安全であるかのような主張はおかしいと思う。

なぜなら,その汎用部品が何に使われるのかによって,リスクは変わるからだ。リスクが変われば,リスクコントロール手段も変わる。システムにとって万能なリスクコントロールはない。

だから,汎用のOTS/SOUPができることは信頼性を高めることであって,安全性を高めることではない。

「想定した使用通りにちゃんと動きます」「こういった異常を想定した機能や性能を備えています」とは言えても,「このコンポーネントを使えば安全です」とは言えるはずがない。

信頼性が高いと自慢するOTSのテストのエビデンスを見せてもらったことも何度からある。確かに,大量のドキュメントを作っていることは分かる。しかし,テストシナリオが無限にあるようなOTS(例えばRTOS)では,テストの量だけならいくらでも増やせる。

問題は,テストケース,テストシナリオの質であったり,テスト設計者のテストに対するコンセプトが重要なのだ。OTSを使用する際に,ここは危ないとか,ここは注意しないといけないというケースをテストケースに組み入れているかどうかを見ないといけない。

だから,「OTSの設計プロセスが規格を満たしている」とか,「基準に適合している」と主張する会社の商品はかえって怪しいと思った方がよい。

それよりは,どんなテストをしているのか,どんなコンセプトでテストをしているのかといった,信頼性の根拠の中身を説明してくれる会社の製品を選んだ方がよいと思う。

自動車業界がこのことを身にしみて分かるようになるのは,おそらく2030年ごろではないかと予想している。その頃になると,電気自動車や水素自動車が普通になり自動運転だけでなく,さまざまな便利な機能が自動車に組み込まれるようになって,新規参入する企業も増え,汎用部品を組み合わせてアセンブリするだけの製造業者も増えるだろう。

そんな,機能がごちゃごちゃに組み合わさった状態では,「ASIL D の部品でござる」を主要な部分に使うだけではシステム全体の安全は確保できない。システムとしてどうやってリスクの高い部分と低い部分を分離するか(凝集度を高めて,結合度を下げるか)を考え,想定したリスクに対するリスクコントロール手段を実装するかが重要になるはずだ。

ようするに個々の部品の信頼性を高める個別最適の発想から,システム全体で安全を確保する全体最適の発想に考え方をシフトしていかないと,市場で発生するインシデントやアクシデントの追いつかなくなるのだ。

自動車業界は機械部品や電気部品の信頼性を高めることでシステムの安全性を担保する1960年台からある Zero-defect 的なやり方を2000年以降のソフトウェア開発にも無理矢理適用しようとしているように見えるバグは1つでもあっては許さん潔癖なソフトウェアを納品せよといった感じ

ソフトウェア技術者はもうとっくに限界に来ているやり方を無理強いされてさぞ苦労していると思う。その苦労もあと10年経つと限界だということが自動車メーカーも分かってきて,根本的に考え方を個別最適から全体最適の発想にシフトしないと安全は確保できないことが分かるようになると思う。

2017-07-26

医機連から公開されたIEC 62304適用に関する質疑応答集(Q&A)

医機連(一般社団法人日本医療機器産業連合会)が2017年5月17日に厚労省から発出された『医療機器審査管理課長通知:医療機器の基本要件基準第12条第2項の適用について』の運用に関する留意点について,質疑応答集(Q&A)を公開した。

ようするに,IEC 62304(JIS T 2304)への適用に関する通知が5月17日に厚労省から出たが,その通知だけではよく分からない点があるので,業界の総意として質疑応答集(Q&A)を公開したということである。

医療機器審査管理課長通知:医療機器の基本要件基準第12条第2項の適用について』では,2017年11月25日から適用される医療機器の基本要件基準(平成17 年厚生労働省告示第122 号)の第12 条第2項の規定(プログラムを用いた医療機器に対する配慮)に適合するためには,基本的に JIS T 2304(IEC 62304)に適合することや,薬事申請時に JIS T 2304 への適合性を説明する資料の記載事例などが説明されている。

医機連から公開された 質疑応答集(Q&A)は,この厚労省通知だけでは,実運用上不明な点をクリアにするために作成された。

医機連(一般社団法人日本医療機器産業連合会)は保健・医療用の用具、機器、器材、用品等の開発、生産、流通に携わる事業者団体の参加のもと、1984(昭和59)年2月に設立された,医療機器系の業界団体の元締めである。

今回発行された質疑応答集(Q&A)は,医機連の法制委員会配下の医療機器プログラム対応WGで策定したものだ。

機能安全規格である IEC 61508 や IEC 26262 と IEC 62304(医療機器ソフトウェアーソフトウェアライフサイクルプロセス) の違いは,IEC 62304 は各国の医療機器規制に付随する基準の適合確認のために使用される点である。

そのため,企業から見れば,その規格に適合(当該規格への適合が絶対条件ではないが・・・)していないと商品を売れなくなるかもしれないため,規格の運用についても詳細なルールが必要だ。

2017年5月17日に発出された厚労省通知だけでは,その詳細な運用ルールが分からないところがあるので,通知の行間を埋める質疑応答集(Q&A)が必要となる。

例えば,IEC 62304(JIS T 2304)は IEC版では2006年版と2012年版があり,JIS では 2014年版と2017年版がある。初版と追補版の二種類が存在する。医療機器の基本要件基準第12条第2項では,「最新の技術に基づいたライフサイクルプロセス」への適用を求めているため,新しい方の規格の方に適合する必要がありそうだが,旧規格からの移行期間はあるはずだ。前述の厚労省通知には規格の版については何も書いていない。しかし,初版の移行期限はいつかがはっきりしないと運用ができない。

そこで,今回,質疑応答集(Q&A)で,移行期限は 2022 年 2 月 28 日までの移行を推奨とするという見解が示された。

また,本ブログでも取り上げた『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』についても,医機連の見解が下記のように示された。
Q02:医療機器に搭載する OTS(off-the-shelf、市販されている既製の)ソフトウェアについても、第 12 条第 2 項への適合を示す必要がありますか。
A02:基本要件基準第 12 条第 2 項は、プログラムを用いた医療機器に対する要求事項を規定したものであり OTS 等を含むプログラム全体として JIS T 2304 への適合を示すことが求められます。なお、医療機器を構成する個々のプログラムの構成要素(製造販売業者の開発品や OTS など)を個別に適合を確認することは求めていません。
これにより,医療機器が搭載するOTS(off-the-shelf、市販されている既製の)ソフトウェアに対して IEC 62304 の個別の適合は求めていないことがはっきりした。

なぜ,OTS(off-the-shelf、市販されている既製の)ソフトウェアが単独で IEC 62304 に適合することが規格の趣旨を逸脱している(規格が本質的に何を目指しているのかを理解していない)のかについては,『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』を読んでいただきたい。

IEC 61508 や IEC 26262 は各国の法規制の要件にはなっていないと思う。そのせいかもしれないが,これらの機能安全規格は OTSの開発プロセスに対する規格の適合を推奨している。

規格が規制に使われる場合,できているかいないかが,法に適合しているかどうかの判断材料になることがある。よって,規格の適合が努力目標では済まない場合もあるし,製造業者の法的な責務となるケースがある。

IEC 62304 の場合,医療機器製造販売業者に対する責務という側面があり,OTSソフトウェア供給者はその責務を直接負うことができないため,OTSソフトウェアの単独認証が意味がないという面もある。業界の構造やサプライチェーンのしくみが根本的に違うから,そういった相違が生まれるのかもしれない。

ちなみに,医薬品,食品,医療機器,化粧品などの分野でレギュレトリーサイエンスという分野の科学が検討されつつある。(レギュレトリーサイエンス学会のサイト

レギュレトリーサイエンスとは
レギュラトリーサイエンスとは我々の身の回りの物質や現象について、その成因や機構、量的と質的な実態、および有効性や有害性の影響をより的確に知るための方法を編み出し、その成果を用いてそれぞれの有効性と安全性を予測・評価し、行政を通じて国民の健康に資する科学です。
言わば規制の有効性や規制がもたらす安全性を科学しようという取り組みだ。医療や食品だけに有効な科学ではないだろうから,他の業界にも広がっていくのかもしれない。

いずれにせよ,医療機器ドメインでは医機連から質疑応答集(Q&A)が発行されたことで,今後は IEC 62304 への適合を単独で示すOTSソフトウェアは出てこないだろうと思う。

2017-07-22

組込み機器のサイバーセキュリティどこまでやればいいか考える際の3つの視点

組込み機器のサイバーセキュリティ,どこまでやればいいのか判断するのが難しい。

商品の価値という目で見れば,多くの組込み機器に取ってサイバーセキュリティは潜在的価値(=ユーザーにとって当たり前に出来ていて欲しいこと)なので,できればコストをかけずに達成したい。

一方で,悪意を持ったハッカーは何をやってくるのか分からないと考えると,最悪のケースが次々を浮かんできて,どこまでサイバーセキュリティの対策をやればいいのか見当が付かない。

組込み機器のサイバーセキュリティはどこまでやればいいのかは,1つの視点だけで考えていたら答えがでないような気がする。

そこで,「1. 危害の大きさ」「2. 悪用の可能性」「3. 製品のライフサイクル」の3つの視点で,どこまでやればいいのか,最低限のハードルはどこかを考えてみる

1. 悪用による危害の視点

マルウェアや悪意を持ったハッカーの攻撃で,機器が受ける危害の大きさを考えてみる。サイバー攻撃による危害は情報セキュリティの3要素であるCIA(Confidentiality:機密性,Integrity:完全性,Availability:可用性)の侵害で考えるとよいのではないかと思う。

例えば,可用性の侵害とは,機器が使えなくなるとどんな困ったことになるかを考える。重要な機器ほど動かなくなると大変だ。例えば,ペースメーカーや人工呼吸器などの生命維持装置の可用性が侵害されたら,患者の死につながる。でも,個人のPCが感染して使えなくなっても人は死なない。その人の仕事ができなくなるだけだ。ただ,事務所中のPCが感染すると事務所の仕事が止まるので,危害は大きくなる。できるのかどうかは別にして使えなくされたらどんな影響があるのかを考えるのが可用性の侵害だ。

完全性の侵害とは,機器内部の情報が改ざんされるとどんな困ったことになるかを考える。重要な情報,例えば,検査装置の診断結果が「治療が必要」だったのが「正常」に改ざんされると,必要な治療が行われなくなる。事務に使っているPCで送ったメールの内容が変えられてしまったら,業務に支障がでるかもしれない。以前,PCを遠隔操作されて,本人の意思とは無関係に脅迫メールを送ったとして誤認逮捕された事件があった。改ざんや成りすましによる影響を考えるのが,完全性の侵害だ。

機密性の侵害とは,機器が扱う情報が外部に流失してしまうと,どんな困ったことになるのか考える。企業にとっては,情報の流失は信用の低下を招くので,機密性の侵害を重要視する製品もあるだろう。例えば,企業内で使用するネットワークプリンタなどだ。個人情報を扱わないなど機器が保持する情報がそれほど重要でなく,流失してもさほど大きな危害には至らない機器もあるかもしらない。機密性の侵害を,可能性や完全性の侵害よりも低いと考える考え方もあるが,情報が漏洩してしまったときの企業の社会的評価の低下を重要視する場合もある。

このように,悪用の可能性をひとまず考えずに,悪用されてしまったとして,機器のCIAの侵害を評価すると,起きてしまったときの影響の大きさを推察することができる。影響が大きければ大きいほど,確実な対策が求められる。もしも,CIAの侵害が起こらないことを証明できれば,サイバーセキュリティの対策は終わりにできる。

CIAの侵害が起こらないと言い切れないのであれば,「悪用の可能性」を考慮しなければいけない。

2. 悪用の可能性の視点

悪用の可能性では,まず,侵入の経路を分析する。IoTというとネットワークに接続されることが前提なので,侵入経路はあるのだが,ネットワーク接続やポータブルメディアのインタフェースを持たない組込み機器もあるので,そういった機器は悪用の可能性が極めて低い。(ROMを引っ剥がすといった可能性もあるのでゼロとは言えないが)

よって,侵入経路がない,または侵入経路を施設のゲートウェイが抑えているといった場合は,悪用の可能性が低くなるので,ハードルを下げられるかもしれない。しかし,サイバーセキュリティの場合,悪意を持ったハッカーが攻撃の意思を持っていると,可能性が低くてもチャレンジしてくる可能性があるため,悪用可能性が低いから対策しなくていいとはなかなか言い切れない。

例えば,汎用OSで既知の脆弱性がある場合,その脆弱性のパッチを当てていなければ,悪用される可能性は高いし,使っていない TCP/IP のポートが開いていればこれまた悪用の可能性は高まる。悪用の可能性を低くできるならば,コストが許す限り低くした方がよい。

なお,機器の外部環境に条件を付けることで,悪用の可能性を低くすることができる。例えば,施設内のネットワークとインターネットとの間にゲートウェイを設置してもらい,ゲートウェイで不審な通信をカットしてもらうようなケースだ。このような場合,機器のセイバーセキュリティのための環境条件が守られていないと,悪用の可能性が上がってしまうことをユーザーにアピールする必要がある。

また,ネットワーク接続があっても,RTOSを使い,プログラムがリードオンリーの領域でしか動かないならば,これまた悪用の可能性は下がる。ネットワーク経由でプログラムを書き換える機能を持たない,動的メモリ上でタスクが動かないなら,その機器が踏み台になる可能性はあっても,機器自体が発症する可能性はない。

ちなみに,ホワイトリスト式のアンチウイルスソフトウェアを搭載する行為もそれに似ていて,ホワイトリストに載っているアプリやサービス以外は動かないという設定にしておけば,マルウェアが機器上で発症することができなくなる。

脆弱性が多い機器は,悪用の可能性が高く,悪用の可能性が高い機器は,それだけ対策もたくさん取らなければならない。汎用性の高いOSを使っている機器は,結果として悪用可能性も高くなってしまう。

3. 製品のライフサイクルの視点

製品を市場に出す前と出した後の視点で考える。市販後に用意にソフトウェアをアップデートできるならば,市販前の対策はそれほどやらなくてもいいかもしれない。OTS(商用で即利用可能なソフトウェア製品)を使っている場合は,既知の脆弱性,未知の脆弱性があるので市販前も市販後もどっちも対応が必要になるかもしれない。

Windows や Linux には多くの脆弱性が見つかるので,市販前に分かっているぶんはパッチの適用が必要だし,市販後に発覚した場合は,パッチを当てる必要があるかどうか判断して実行する。

パッチが当てやすくなっていたとしても,全部やる必要があるかないかは,1の危害の重大度と2の悪用の可能性で評価するしかない。

脆弱性が見つかりにくいマイナーなOSを使っていれば,市販後の対応もほとんどなくなる可能性はある。

セキュリティインシデントが起こってしまった後に対応すれば済む場合は,市販前にはコストのかかる対策は行わずに,市販後に対応について準備をしておけばいいかもしれない。セキュリティインシデントが起こってしまうと取り返しが付かないような製品には,市販前の対策を十分にとって,悪用の可能性を低くしておかなければいけない。

「1. 危害の重大度の視点」「2. 悪用の可能性の視点」「3. 製品のライフサイクルの視点」の3つは,それぞれ関係性があってややこしいが,まずは,他の視点こ考慮せずに,それぞれの視点で組込み製品のサイバーセキュリティを評価してみて,その上で,どの対策をするとどこの影響を抑えることができるのかを考えてみたらどうだろうか。