KAOS (49) リスク管理 (3.2.2-2)

25/09/2014 – 7:25 AM

リスク評定

リスクについて，これまでに検討を行った．ここでは，その定義に従って，リスクを評価する．ここでは，リスクに対してどう対処するかを（対処しないことを含めて）考えることができる．

質的評定

正確に，生じやすさと生じたときの影響の度合いを見積もることはできない．従って，リスクレベルのように，区分値で表現することが一般的に行われる．

例えば，生じやすさは，「まれに」から「頻繁に」までの間で幾つかに分ける．影響の度合いについては，「低い」から「甚大な」の間で幾つかに分ける．

間をいくつに分けたとしても，これで表を作ることができる．ある事象（安全性でいえば危害）が左上に相当すればリスクは小さく，右下であればリスクは大きいといえる．

ISO 26262 ASIL

ISO 26262 ASIL

ISO 26262 の場合，以前に見たように3変数（E:生じやすさ，S：重傷度，C：制御可能性）なので，少し複雑な表になる．しかし，下側と右側に，より影響の大きいものを並べると，右下がリスク（ASIL）としては高くなる．リスクとしては，Aが大きくDが小さい（QMは，通常の品質管理システムが組織で動作していれば良い．即ち，開発／保守プロセスに対する新たな制約がない）．

ちなみに，S/E/Cの3変数の区分値については，ISO 26262 の表１〜３で目安が示されている 1．

表の位置を見ながら細かな考察をしたところで，もちろん意味は余りないが，どのリスクが高いかを相対的に知ることができる．

量的評定

先の区分値に対して，特定の値を割り当てたることにより，数値化することもできる．数値化することによって，リスク度を計算できる．先の，生じやすさ「まれに」に対して，0.1を与える．影響度合い「甚大な」に対して，0.9を割り当てる．そうすると，リスク度としては，0.09を得ることができる．

ここでの数字は，正確さを何ら主張しない．複数のリスクを比較するのに容易なだけで，付加情報がなければ，先の表の結果と変わらない．ただ，思い込みの防止にはなる．

(nil)

Notes:

  1. ただ，OEMでバラツキがあっても困るため，SAEのJ2980を含め，具体化が検討されている ↩
By nil | Posted in KAOS, リスク, 安全, 要求, 要求工学 | KAOS (49) リスク管理 (3.2.2-2) はコメントを受け付けていません

KAOS (48) リスク管理 (3.2.2-1)

24/09/2014 – 7:15 AM

私には，次のことが明らかである．セキュリティは，技術によって解決可能な問題ではない．確かに解決策は，技術的な要素を含む．しかし，セキュリティというのは，基本的に，人間の問題である 1

リスク管理は，次の3つからなる：リスクの識別，リスク評定，リスク制御

最初は，リスクの識別から．即ち，如何にリスクを見つけるかである．

リスクチェックリスト

いつでも出てくるチェックリストである．以前に見た要求のカテゴリ（12回，13回，14回，15回）を，このチェックリストの元とすることができるとしている．

全体は，作るべき製品に関するリスクとプロセス（正確にはプロジェクト）に関するリスクに分かれる．

– 製品に関するリスク

例としては，次がある．

  • 機能のモレ，不完全
  • 製品が動作する環境に対する誤った前提
  • ハザード・脅威
  • 重要な製品特性における信頼性のギャップ

– プロセスに関するリスク

例としては，次がある．

  • 要求の変化
  • 人員不足
  • 非現実的なスケジュールと予算

コンポーネント識別

コンポーネント（もちろん設計レベルではない．要求の中にある構成要素のこと）を考えて，そのコンポーネントのリスクを考える．あとで，合算するという考え方である．

リスクツリー

信頼性の議論には，故障木（fault trees）という考え方がある（FTA，Fault Tree Analysis に代表される）．故障木は，コンポーネントの構造を反映している．

セキュリティには，脅威木 (attack tree)・攻撃木 (threat tree) という考え方がある．最近は，攻撃木といういい方が一般的か 2．

冒頭の引用文を含む書籍から，攻撃木の例を示す．

attack tree

攻撃木（アタックツリー）

これは，情報空間ではなく，物理空間の例であり，書籍の中で説明用として最初に提示されているものである．基本的には，下位のOR結合によって上位が構成される．AND結合の場合は，明示的に示す（「立ち聞きする」を参照）．この基本形を用いて，容易さ，費用といった様々な側面から，セキュリティについて解析する．

要求を引き出す技術の利用

第2章では，要求を引き出すための技術を見た．これは，いわば「正」の要求を見つけることが目的であった．ユースケースで云う基本系列に相当するような，「〜できること」で示されるものである．

シナリオのそれぞれの場所で，「もし〜だったら（what if）」を考える 3．要求のネガティブな側面は，この方法によって見つけることができる．

また，このほか前章ででてきた技術である「知識の再利用」や「グループセッション」も利用することができる．

 (nil)

Notes:

  1. Schneier B., Secrets & Lies, John Wiley & Sons, 2000. ↩
  2.  脅威と攻撃は，もちろん概念として異なる．脅威は，「望まない事態の潜在的な原因」（ISO/IEC 27000）である．定義になっていない気もするが，安全性でいえば，危害に対するハザード（危険源）に相当する．攻撃は実際のセキュリティに対する侵害を指すが（「アセットに対し，破壊・さらす・変更・使用不可・盗む・得るという許可されていないアクセスを行う，或いは利用すること」(ISO/IEC 27000），考えるときには，そういう攻撃があったら，と考えることで脅威の多くを識別可能である（残りは，つい間違えたというパターンである） ↩
  3. what-if レビュー技術というのは，化学プラントなどのエンジニアリングの世界で，HAZOPなどとともに発達してきた．ブレインストーミングの逆バージョンともいえて，体系立っている分けではない．その分，思いも掛けないハザードを見つける可能性がある．実施に当たって，その分野での経験が必要なのは云うまでもない ↩
By nil | Posted in ISO/IEC 27000, KAOS, セキュリティ, リスク, 脅威, 要求, 要求工学 | Tagged , , , , | KAOS (48) リスク管理 (3.2.2-1) はコメントを受け付けていません

KAOS (47) リスク分析 (3.2.1-3)

23/09/2014 – 10:53 AM

結論として，我々は，リスクと危険の区別に対して，別の見方をしなくてはならない．特に政治との関係において 1．

安全性が重要な他の分野として医療がある．医療には，様々な規格があるが，ここでは，ISO 14971:2007を見てみる．医療機器のためのリスク管理についての規格である 2．

前回，ハザードと危害までの距離をテーマにした．ISO 14971 には，明快な図が示されているので紹介したい．

14971_hazard_events_situation_harm

ISO 14971 ハザードとリスク

ハザード状況は，定義（2.4）では，「人，資産ないしは環境が一つ以上のハザードにさらされている状況」である．素直にJISに従うと，危険状態．収まりが良いとは思うが，ここでは，situationを状況と訳す．概念が異なる場合は，コトバも変えるというのは，少し前にLamsweerdeさんの指摘にあった．

ハザードから危害の間には，距離がある．自動車が片目になっているからといって，たちどころにドライバに危害が及ぶわけではない．

P1は，ハザードがハザード状況になる確率

P2は，ハザード状況が危害になる確率

リスクの定義は，以下であった．

リスクとは，危害の発生確率と危害の重大さの組み合わせである

いま，危害の重大さをSとする．危害の発生確率Pは，P1×P2と表現できるので，リスク度は次で計算できる（SはSeverityで，危害の大きさ．重傷度）．

R = S  × P1 × P2

上記に合わせると，ASILは，次の形となる．

R = S  × 1 × (E × C)

S: 危害の重大さの程度

E: ハザード状況の起こりやすさ

C: ドライバの危害を回避する可能性

但し，ハザード状況に相当するのは，ハザード事象(hazardous events)である（事象に重きがある，ハザード的事象）．ハザード事象の定義は以下である．

combination of a hazard (1.57) and an operational situation (1.83)

ハザードと動作状況の組

一昔前に，ワイドショーでレポータが話すような事象（成り行き）である．

「Aさんは，早朝，普通に道を歩いていました．幹線道路ではないのですが，朝は抜け道に使われます．狭い道路を車は，早い速度で通過します．そこで事故に遭いました．近くにいた人の話では，ブレーキの音はしなかったそうです．」

ブレーキの故障というハザードを考えたときに，どういう状況で生じるかによって，危害の程度が違う（ワイドショーだと方向者視点になる．歩行者の様子が気になると思うが，ISO 26262 が気にしているのは，ドライバおよび同乗者への危害である．念のため）．その状況になる確率を考える．車の全利用状況のうち，この状況（朝 AND 抜け道 AND 急ぐ）になるのはどの程度かである．

E（ハザード状況の起こりやすさ）が，その状況の程度である．

C（回避可能性）は，その状況でドライバはどの程度回避できるかである．

P2に相当する値は，このEとCの積として計算する．

もちろん，ハザード状況は複数存在している．モレなく検討しなければならない．

さて，P1に相当するものは，でてこない．なぜならば，アイテムが対象だからである．FTAなどでやるようにパーツ毎に積み上げるといったことをASIL計算時はできない．故障が起きたらと考えるので，（あえて書けば）確率は，1 になる．

今回は，ISO 14971（医療）と ISO 26262 （乗用車）でのリスク計算の類似性と違いについて考えてみた．

リスクは数値化することで，客観的にものごとを考えやすくなる．それはメリットである．人間は，明日も今日までと同様に続くと思いがちであり，数値を見ることによって，あらためて考えることもあるに違いない．

しかし，危害は非連続的であり，危害自身を計算することはできないことに注意しなくてはいけない．

(nil)

Notes:

  1. Luhman, N., Risk A Sociological Theory p.31 ↩
  2. JISのタイトルは，「医療機器−リスクマネジメントの医療機器への適用」である．マネジメントを何故訳さないのだろう． ↩
By nil | Posted in ISO 14971, KAOS, リスク, 医療, 安全, 自動車, 要求, 要求工学 | KAOS (47) リスク分析 (3.2.1-3) はコメントを受け付けていません