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

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

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

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

リスクチェックリスト

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

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

– 製品に関するリスク

例としては，次がある．

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

例としては，次がある．

コンポーネント識別

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

リスクツリー

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

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

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

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

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

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

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

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

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

(nil)

Notes:

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

risk = nil;