2017-07-18

組込み機器の情報セキュリティは何のため?

組込み機器の情報セキュリティの対応に対するモチベーションがなかなか上がらない。誰のために何のためにやっているんだろうと自問自答し,さらに,どこまでやればいいのか見当が付かないためやる気が起こらない。

そもそも,悪意を持ったハッカーなんかが居なければ,セキュリティ対策なんてしなくてよかったのではないか。5月に世界中で蔓延したランサムウェアのWannaCry は米国家安全保障局(NSA)から流出した Windows の脆弱性 EternalBlue を使ったものと言われている。 EternalBlue は流出するまで,諜報機関により米国の監視活動に利用されていたらしい。アメリカは脆弱性の元を作っておきながら,米国に機器を売る者に対しては情報セキュリティのハードルを世界最高の水準に上げている。本当に迷惑な話だ。

こんなことだから情報セキュリティの取り組みにはやる気が起きない。しようがないので,次のように考えようと思う。

昔々,善良な村人しかいない平和な村がありました。泥棒もいないので,村人は玄関に鍵などかける必要がありませんでした。あるとき,村外れの山から金の鉱脈が見つかり,一攫千金を狙った者が隣村からたくさん移住してきました。村はだんだん物騒になり,物取りや傷害事件が起きるようになりました。村人は玄関に鍵を書けざるを得なくなりましたとさ。

ネットワークを使うこともなかった,善良な村人(組込み機器開発者)は,機器同士がネットワークでつながる時代になり,開けっぱなしだった玄関に鍵を付けなければいけなくなったという訳だ。誰のせいかと言えば,悪いのは泥棒だが,そういう時代なのだからしようがないとしかいいようがない。

問題は鍵を付けるコストは誰が負担するのかという点だが,それは結局エンドユーザーが負担することになる。だから,エンドユーザーの期待に応えながら,コストが上がりすぎないようにしなければいけない。

情報セキュリティの問題は,どこまでやればいいのかという判断基準が難しい。

商品の価値について考えるとき,左図のように顕在的価値と潜在的価値に分けて考えるようにしている。

顕在的価値は商品カタログの目立つところに書かれる機能や性能で,潜在的価値は「当たり前に出来ている」と期待されていることで安全や安心を担っている部分となる。

情報セキュリティの価値は,潜在的価値の方だろう。潜在的価値について,多くのユーザーは商品購入の時にあまり意識していないが,一度でも痛い目にあったりすると,潜在的価値を重視するようになる。

ブランドの価値は,この潜在的価値の積み重ねがものを言ったりする。また,社会問題になるようなインシデントが起きると,この潜在的価値はたちまちクローズアップされて,商品価値の中で重要視されるようになる。

だから,この潜在的価値を高めるためのソリューションを提供できる会社は,WannaCry のような社会的インシデントが発生するとここぞとばかりに活気づく。

情報セキュリティ対策にモチベーションが上がらないもう一つの理由は,これだ。インシデントが発生すると儲かる商売って,弱みにつけ込んでいるような気がして何か釈然としない。(ちなみに,機能安全をきっかけに儲けようとする会社も同じ穴のむじなだと思うけど。)

でも,最近はしようがないのかなあ,と諦めている。なぜなら,お客さんが製品に対して情報セキュリティの確保を求めるようになってきたからだ。

エンドユーザーが情報セキュリティの価値を認めて,対応がされていない製品は買わないと言ってきたら,それはやらないわけにはいかないし,そういうお客さんが増えてきたら,逆にその部分の潜在的価値をアピールすることもできるようになる。

ただし,無限にコストを上げることはできないので,費用や工数と効果の折り合いをどこかで付けなければならない。

その折り合いのさじ加減は,業務ドメインや,その製品の意図する使用によっても変わってくるので,一般化はなかなかできないと思っている。例えば,機器の可用性の侵害を重視するFA,可用性と完全性の侵害が患者危害につながる可能性のある医療機器,機密性の侵害による信用の低下につながるデータセンターなどさまざまな機器,業務ドメインがある。

情報セキュリティのCIA(Confidentiality:機密性,Integrity:完全性,Availability:可用性)の優先順位は機器の特性や使用目的,扱うデータの種別によって変わるので,情報セキュリティ対策の優先度も変わるし,どの機器にも効く魔法の杖はないと思う。
 IoT という大きなくくりでは,費用と効果の折り合いは付けられないということだ。また,その折り合いは,その会社の製品のセキュリティに対するポリシーにも影響を受ける。というか,折り合いを付けるためには,ポリシーを定めないとなかなかうまくいかないということだ。

だから,製品の情報セキュリティは今後は,企業のブランド価値にようなものになっていくのだろう。製品のセキュリティに対するポリシーを持ち,ホワイトペーパーを出せるような企業は,企業の潜在的価値として情報セキュリティを捉えていて,そこに価値があり,ブランド力を高めることに貢献すると考えているのだと思う。

顧客が価値があると考えるのなら,情報セキュリティにもモチベーションを持って取り組まないといけないということか。

2017-07-09

なぜ,バリデーションが必要なのか?

2017年6月19日に GHS(一般社団法人ヘルスソフトウェア推進協議会)が IEC 82304-1(ヘルスソフトウェア—第1部:製品安全に関する一般要求事項)の解説セミナーを開催した。

GHSがヘルスソフトウェア国際規格の解説セミナーを開催(innavi net 記事)

このIEC 82304-1 解説セミナーの中で,「ヘルスソフトウェア製品のバリデーション」の講演があり,改めて,バリデーションって何?,バリデーションは何のためにやるのか?を考えてみた。

Validation(バリデーション)は日本語では「妥当性確認」と訳され,ISO 9000 (JIS Q 9000:2015)では次のように定義されている。

3.8.13 妥当性確認(validation)

 客観的証拠(3.8.3)を提示することによって,特定の意図された用途又は適用に関する要求事項(3.6.4)が満たされていることを確認すること。

  • 注記 1  妥当性確認のために必要な客観的証拠は,試験(3.11.8)の結果,又は別法による計算の実施若しくは文書(3.8.5)のレビューのような他の形の確定(3.11.1)の結果である。
  • 注記 2  “妥当性確認済み”という言葉は,妥当性確認が済んでいる状態を示すために用いられる。
  • 注記 3  妥当性確認のための使用条件は,実環境の場合も,模擬の場合もある。
一方,バリデーションと混同しがちな概念でベリフィケーション(検証)の定義はこうだ。

3.8.12 検証(verification)

 客観的証拠(3.8.3)を提示することによって,規定要求事項(3.6.4)が満たされていることを確認すること。
  • 注記 1  検証のために必要な客観的証拠は,検査(3.11.7)の結果,又は別法による計算の実施若しくは文書(3.8.5)のレビューのような他の形の確定(3.11.1)の結果であることがある。
  • 注記 2  検証のために行われる活動は,適格性プロセス(3.4.1)と呼ばれることがある。
  • 注記 3  “検証済み”という言葉は,検証が済んでいる状態を示すために用いられる。
バリデーション(妥当性確認)とベリフィケーション(検証)の2つの定義を比較してみる。

 英語 日本語  先頭  中間  末尾 
 Validation  妥当性確認 客観的証拠(3.8.3)を提示することによって 特定の意図された用途又は適用に関する要求事項(3.6.4)が 満たされていることを確認すること。
 Verification  検証 客観的証拠(3.8.3)を提示することによって 規定要求事項(3.6.4)が 満たされていることを確認すること。

3.8.3 客観的証拠(objective evidence)
 あるものの存在又は真実を裏付けるデータ(3.8.1)。

3.6.4 要求事項(requirement)
 明示されている,通常暗黙のうちに了解されている又は義務として要求されている,ニーズ又は期待。


結果,バリデーション(妥当性確認)とベリフィケーション(検証)を比較すると,その違いは,中間の「特定の意図された用途又は適用に関する」と「規程」の部分だけだということが分かる。

これでは,Validation(妥当性確認)とVerification(検証)の違いが分からないという技術者がいても不思議ではない。

Validation(妥当性確認)とVerification(検証)の違いを 1981年に Barry W . Boehm が "Software Engineering Economics, Prentice-Hall" で次のように説明し,多くの人が引用しているのでそれを見てみよう。

 英語 日本語  英文の説明 日本語の解釈 
 Validation  妥当性確認 Are we building 
the right product?
正しい製品(成果物)を開発しているか?
(顧客要求を満たす製品を作っているか?)
 Verification  検証Are we building 
the product right?
正しく製品(成果物)を開発しているか?
(仕様通りに作っているか?)

英語では,同じ単語で語順を変えることで上手いこと説明しているのだが,日本人にはなかなか解釈が難しいかもしれない。

バリデーションは正しい製品(成果物)を開発しているのか?(顧客要求を満たす製品を作っているのか?)と問うていて,ベリフィケーションは,正しく製品(成果物)を開発しているか?(仕様通りに作っているのか?)を問うているという解釈だ。

それでもValidation(妥当性確認)とVerification(検証)の違いがよく分からないという人は,なぜ,Validation(妥当性確認)とVerification(検証)を分けないといけないのかという視点で考えてみるとよい。

ソフトウェア製品の場合,Validation(妥当性確認)とVerification(検証)は分けて考えた方がよいのだ。なぜなら,仕様通りに開発したのに,顧客要求を満たす製品になっていないというケースがよくあるからだ。

<仕様通りに開発したのに,顧客要求を満たす製品にならない要因の例>
  • 仕様書が完璧でないため,システムの使用環境やユーザーニーズをよく知らない設計者(ソフトウェアの場合プログラマー)が,不足仕様の行間を自分の判断で埋めてしまった。
  • 2次,3次下請けと設計作業が分配されたため,要求仕様が伝言ゲームで誤って伝わった。
  • 顧客の要求が正しく要求仕様に反映されておらず,誤りや曖昧さのある要求仕様から設計仕様が作られた。
  • 顧客要求事項の範囲(上限,下限)が分析されておらず,要求事項として示されていなかったため,設計者が自分の感覚で範囲を決めてしまったが,実際は要求とずれていた。
  • 設計者(プログラマー)が検証仕様を作成したため,パスするテストケースしか想定しなかった。よって検証は全部合格だが,漏れがあり妥当性確認は合格しない。
  • 顧客Aの要求を満たすように作ったが,顧客Bや顧客Cはその仕様を望んでなかった。
  • 設計仕様に漏れや反映されていない要求仕様があったり,要求仕様を勘違いして設計仕様を作ったりしていた。
  • 汎用的に作られた市販ソフトウェア(OTS)が,当該製品の要求実現にマッチしていなかったのにその問題に気付かず置き去りにされた。
これらの例から分かるように,大規模ソフトウェア開発のように,開発作業を分業し,階層化すると,下位層に行けば行くほど,顧客要求がよく分からない状態で作業(プログラミング)を行うことになる。顧客要求が分からなくても,問題なく作業ができているなら,それはアーキテクチャ設計がよいからかもしれない。IN と OUT が明確な,汎用性の高いソフトウェアアイテムを多くして,ドメインに依存したソフトウェアアイテムを少なく,凝集されることができれば,多くの汎用性の高いソフトウェアアイテムの単体テストは容易になる。

しかし,そんなよいアーキテクチャ設計のソフトウェアシステムや,要求仕様を正確に反映している完璧な仕様書なんて滅多にないから,プログラマーが曖昧な仕様書の行間を読んでプログラムを書くことなど日常茶飯事だろう。クライアントからすると過去の製品の仕様や,製品の使用環境を知っていて,より正確に行間を読んでくれるプログラマーが「よく出来る人」という評価になる。

人に依存した開発をやっている組織ほど,仕様書の精度が低い。仕様書の精度が低いのにいい仕事ができているのは,Validation(妥当性確認)とVerification(検証)を同時に意識しながら,作業ができる技術者がいるからだと思う。

小さいプロジェクトで,職人的開発をしているチームほど,Validation(妥当性確認)とVerification(検証)の区別が付かない,必要性を感じない場合が多い。なぜなら,Validation(妥当性確認)とVerification(検証)を区別しなくても,上記のような問題が発生しないからだ。

別な言い方をすれば,その人は,Validation(妥当性確認)で必要なことが頭に入っている状態でプログラムを作っていて,Verification(検証)しているときに,一緒にValidation(妥当性確認)もしてしまっているのだ。老練な技術者は「ここだけは抑えておこう」「ここに何かあったら大変だ」という製品の要所を把握していて,常に要所に影響がないかアンテナを張っている。その要所である「ここ」が,基本機能や基本性能を実現している部分であり,クリティカルシステムならリスクコントロール手段となり,バリデーション項目になる。

アーキテクチャの良さが要所を守っているというケースもある。基本機能や基本性能を実現しているソフトウェアアイテムと付帯機能を実現しているソフトウェアアイテムの凝集度が良く,結合度が弱いアーキテクチャが実現できている場合,付帯機能部分の追加や修正に失敗しても,基本機能や基本性能に影響を与えない,もしくは要所を触ることができないようになっていれば,要所を守ることができる。

さて,「技術者は現場を知らなければダメだ!」と上司や先輩から言われたと思う。これは別な見方をすれば,「Validation(妥当性確認)できるエンジニアになれ!」ということで,Validation(妥当性確認)とVerification(検証)が同時にできる人材は,開発効率が高く,効率的にクレームが出ない製品を作れる技術者なので,「技術者は現場を知らなければダメだ!」はそういったエンジニアになれという意味なのだ。

また,顧客に対して頻繁に使い勝手を確認するような開発スタイル(アジャイルプロセス等)を取るという行為は,Validation(妥当性確認)とVerification(検証)を同時に実施して,開発効率を高めていると言える。ちなみに,クリティカルシステムで,このスタイルを推奨しない。なぜなら,ユーザーにValidation(妥当性確認)を求める方法では,通常の使用環境ではおきにくい危険状態に対するリスクコントロール手段に,ソフトウェアの修正が悪影響を与えているかどうかの確認が漏れる危険性があるからだ。クリティカルシステムでは,バリデーション項目を抽出して,テストがしにくくても1つ1つ確認する必要がある。

Validation(妥当性確認)を行うには,当該製品分野に対する深い知識が必要でその製品の「ユーザニーズの理解」「意図する使用(Intended Use)の理解」「市場要求との整合性の判断ができるスキル」が出来る人材が必要となる。

ちなみに,製品に搭載するソフトウェアの規模はどんどん大きくなっているので,プロジェクトメンバー全員が「Validation(妥当性確認)できるエンジニア」になるのは不可能だ。

だから,Validation(妥当性確認)とVerification(検証)は分けないといけないのだ。

IEC 82304-1 では,箇条 6 ヘルスソフトウェア製品のバリデーション で,6.1 バリデーション計画, 6.2 バリデーションの実施, 6.3 バリデーション報告 が要求となっていて,計画の要求の中には,「e)バリデーションを行う要員に必要な資格要件を特定する。教育訓練が必要な場合は,バリデーションを始める前に完了しておく。」や「f)バリデーションチームの,設計チームに対する適切な独立性レベルを定める。」などの要求も含まれている。

バリデーションを行う要員の必要な資格要件というのは,特定が難しそうだが,対象となるシステムの使用者が特定の資格を持っていたり,特定のワークフローで仕事をしているような場合,バリデーション要因としてそれらの知識の必要性を判断する。

ある意味,これまで経験則やキャリアの長さで判断していた「バリデーション要員のスキル」を見える化して,漏れのないバリデーションをするルールを策定したと言えるだろう。

また,バリデーション計画を立てるためには,製品要求事項を抽出しないといけないのだが,これが出来ない人が多い。

Use requirement(製品要求事項)と Specification (仕様)の区別が付かないのだ。Use requirement(製品要求事項)は「使用の必要条件」という意味なので,それがないと製品が成り立たない,製品の基本機能,基本性能の元となる要件だ。

それが何なのか答えられない技術者が多い。その理由を考えると,日本の製品は既存製品に対する改良,改善,追加を繰り返す製品開発が多く,遙か昔に作成したUse requirements(製品要求事項)を忘れてしまった,または,最初に作ったUse requirements(製品要求事項)も実は,他社の同等製品からコピーしたものだったということなのではないだろうか。

だから,技術者は,最近追加した機能や性能,あるいは,不具合で修正した仕様には詳しいものの,製品に搭載されている基本機能や基本性能が何かをズバリ答えられない。

逆に言えば,多くの製品開発は,基本機能や基本性能はすでに枯れてしまっていて,おまけの機能を追加することで成り立っているので,Use requirements(製品要求事項)が何かを知らなくても後継製品ができてしまうということだ。

これは2つの面で問題がある。1つは,付加機能を付け足した製品しか作れないのでイノベーションが起こらない(市場を拡大できる製品が生まれない)ということと,2つ目は,付け足した機能が,基本機能や基本性能に悪影響を及ぼす危険性があるということだ。

ソフトウェアの場合,ソフトウェアの構造(アーキテクチャ)が悪いと,付け足した機能が基本機能や基本性能に悪影響を及ぼす危険性が高くなる。要するにスパゲッティのようなプログラムに機能を追加すると,さらに絡まりが強くなって,また,システムのどこが要所かを理解しないエンジニアが意図せず大事な機能や性能を実現している部分を傷を付けてしまう可能性がある。

だから,ソフトウェアの構造が悪いシステムほど,バリデーションが重要になる。Use requirements(製品要求事項)の項目を1つ1つ確認することで,その製品の必要条件が満たされているかどうか,製品の基本となる可用性や完全性が侵害されていないかを確認するからだ。

別な見方をすれば,細かい付帯機能すべてを確認できなくても,バリデーションによって製品の基本機能や基本性能には問題がないことを確認できるということだ。(将来,小さい設計変更はあっても,リコールに至るような大きな問題を押さえ込める確率が高まる)

製品やソフトウェアの規模が大きくなればなるほど,Validation(妥当性確認)とVerification(検証)は明確に区別することが重要で,かつ,これからのソフトウェア開発においては,Use requirements(製品要求事項)の抽出を含むバリデーション計画・実施・報告 が重要な要素となるということがお分かりいただけたかと思う。

P.S.

ISO 26262 では,Validation Plan の立案は明示的に要求していないように思う。(もし,間違っていたら教えて欲しい) その理由は,これまで自動車はUse requirements(製品要求事項)が「走る」「曲がる」「止まる」とように変わらない=普遍だったからではないだろうか。でも,電気自動車や自動運転ができるようになると,Use requirements(製品要求事項)が変わったり,多様化して,付け足した付加機能が基本機能を脅かしたりする危険が出てくるのではないか。自動車のソフトウェアもValidationを重視した方が良くないか。(サプライヤは Validation Plan 書けなかったりして)

2017-04-23

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

ソフトウェアの変更容易性は最大のメリットだが,最大のデメリットでもある。信頼性の高いソフトウェアを苦労して作り上げても,たった一行の変更で,とんでもないバグを作り込んでしまうことができる。

仕上げたソフトウェアに対してシステムテストをどれだけ繰り返してもなかなか不具合は収束しないし,非常に分かりにくい問題が残ったまま出荷されることもある。

だからこそ,ソフトウェアの品質を高めるためにソフトウェアの開発プロセス,保守プロセスを管理する方法が研究され,実践されてきた。近代のソフトウェア品質論の歴史はソフトウェア開発プロセス研究の歴史といっても過言ではないだろう。

しかし,クリティカルなシステムにとっては次のことが成り立つ。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

もしも,明確な危害を防ぐリスクコントロール対策が講じられるのならば,そのリスクコントロール対策を確実にすることを優先した方がよい。

極端なことを言えば,ソフトウェア開発プロセスが十分でなくても,リスクコントロール対策が確実であれば安全な場合はある。ハードウェアによるリスクコンロールが確実に効いていて,ソフトウェアの不具合があっても安全が確保されることはある。

例えば,ソフトウェアが何らかの出力エネルギーを制御していても,過大なエネルギーの出力のみを防げば危害に至らないのであれば,ハードウェアのリミッタがリスクコンロール手段になりうる。

ところが,問題がエネルギーが過大かどうかではなく,出力の信号波形がだったりするとハードウェアのリスクコンロールでは難しい。電気メスの出力を凝固のパルスにしたつもりが切開のパルスになってしまうようなケースだ。

この場合こそ危害に結び付かないためのソフトウェアによる安全設計を行い,その設計が有効になっていることを確かにするためのプロセス管理を行う必要があるのだ。

ここで強調しておきたいのは,ソフトウェア品質を高めるのにプロセスアプローチは有効だが,製品やシステムの使用に対する安全を確保するために優先すべきはリスクコントロールであるということだ。

それを逆転して考えては絶対にダメだ。「ソフトウェアの開発プロセスがキチンと管理されていれば,システムは安全だ。」などと考えるのは愚の骨頂だ。

ちなみに IEC 62304(医療機器ソフトウェアーソフトウェアライフサイクルプロセス)は,プロセスアプローチとリスクベースアプローチの組合せだから,単純なプロセス管理ではない。

何が違うかと言えば,プロセス管理をする前にリスク分析を行い,危害に至らないようなリスクコントロールを行い,主にリスクがコントロールされていることを管理するアプローチとなっている。

だから,極端な話,ソフトウェア開発プロセスが規格要求通りにできていなくても,想定した危害がリスクコントロール手段で対策できていれば,規格の本質的な趣旨としてはよいと言える。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

なのはそのためだ。そのことを忘れで,規格に適合することばかり考えていると,本末転倒のことが起こる。IEC 62304 に適合しているのに,危害が発生してリコールになってしまうとか,意図する使用が確定しておらずどんなリスクが想定されるのか分からないままOTS(汎用の市販ソフトウェア)の開発プロセスが IEC 62304 に適合していると言ったりする。

ソフトウェア開発プロセスを生業としている人々は,いったいなんのためにソフトウェア開発プロセスを管理しているのか,その活動が開発者やエンドユーザーにどんな価値を生み出しているのかを考えてみるとよいと思う。

IEC 62304 は一般のソフトウェア開発で行われている ソフトウェア開発プロセス管理 とは別に,ソフトウェアリスクマネジメントプロセス を持っている。これは,危害の一因となりうるソフトウェアアイテムやリスクコントロールに関わるソフトウェアのプロセス管理(要求定義,検証,トレーサビリティ,変更管理)を実施することだ。

リスク低減に関するソフトウェアのプロセス管理があることが,一般的なソフトウェア開発プロセスと異なる。更に言えば,IEC 62304 はソフトウェアプロジェクト管理の際に,重要視される予算管理や日程管理の要求がない。

医療機器ソフトウェアやヘルスソフトウェアのソフトウェアプロセス管理の第一目的はリスク低減なのだ。

それを理解しておかないと,ソフトウェア開発のプロセスを管理するという手段が目的になってしまう。

それって,医療機器ソフトウェアの世界の話だけじゃないんじゃないかと思う。ソフトウェア開発プロセスの管理能力の向上が,開発者やエンドユーザーにとってどんな価値を生み出すのかなぜなぜ分析してみるとよいのではないだろうか。


P.S.

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

をレビューワ-が意識するかしないかでソフトウェアレビューの内容も変わってくる。意識していれば,危害が発生しないか,発生しないためのリスクコントロールがキチンと管理されているかに重点が置かれるが,意識していないと,プロセス要求の一つ一つに適合しているかどうか重箱の隅をつつくことになる。

対象となるソフトウェアやソフトウェアが搭載されるシステムがどのように使われるのかをよく知らない,知りたいと思わないレビューワ-ほど,重箱の隅をつつくことに一生懸命になり,指摘が多くなればなるほど,自分が規格に詳しいことに対して鼻高々になるようだ。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

を理解しているレビューワ-はどうしたら危害を防げるのか,リスクコントロールが効いている状態を保てるのかを開発者と一緒になって考えるし,プロセス管理の甘さがどうして危害につながる可能性があるのかを指摘し,説明することができる。