マネジメントと開発は遠いようで近かった(リスクマネジメントと脅威分析)

昨日のゼミで、ISO/IEC 27005の改訂について、委員の方に紹介いただく場がありました。それを聞いていて、しかもその後の議論の中で思ったんですが、セキュリティマネジメントのリスクアセスメントと脅威分析(分析レベル)の手法って似てるなと。何をいまさら…とお思いでしょうが、そもそもソフトウェア工学にしてもマネジメントとはコミュニティも違う訳で…あとは前の会社の時に15408と27001の間にはギャップがギャップが…と言われ続け、固定観念があったのかもしれません。まあ言い訳な訳です。(いいわけぇもんが…)

で、要求分析における脅威分析では、資産ベースのアプローチをとることが多いです。私が講義で紹介するミスユースケースの分析手順もそうですし、C.Haleyがまとめたセキュリティ要求分析の要素にもばっちり「asset」が登場します。で、この資産ベースのアプローチは、もともとこの27005から来ていると思われます。27005では、分析のアプローチは以下の2つと言われています。

  • 資産ベースのアプローチ
    守るべき資産を洗い出し、資産に対する脅威(リスク源)を識別する
  • イベントベースのアプローチ
    リスクに影響のあるイベントのシナリオを想定し、リスクを見積る

実は、このイベントベースというか攻撃シナリオベースのアプローチが、最近注目されているようです。この紹介があった後に、私が、「イベントベースでは、脅威が十分に洗い出されたという網羅性はどのように保証するのか」という質問をしました。実は、このイベントベースのやり方は日本以外ではわりと使われているようです。なぜかというと、資産ベースはどうしてもボトムアップで資産を洗い出しでいくので、手間がかかる。それに対し、イベントベースは、「このシナリオにフォーカスしてみたい」という場合に使うんだそうで。だから、私の解釈では、イベントベースは網羅性をそもそも解決するものとしていないと。日本人は、資産ベースが好きなんだそうですね。細かい性質に合っているのかな。あとねえ~わたくしも元ベンダーですので、お客さんが、「これって何分の何で起きるの?」とか、「100%リスク対策できてるの?」とか、言うじゃないですか。ちょっとセキュリティかじった人なら、「分母なんかねえんだよ!」「100%なんてあるわけないだとクソが!」ということは理解できるけど、でも…じゃないですか。すいませんクソは言いすぎでした。

ちなみに、脅威分析に関しては、この資産ベースとイベントベース以外に「 事業被害ベース」という方法があります。このシステムではどんな被害を受けるとまずいか、から考える手法です。情報処理推進機構(IPA)の発行する「制御システムのセキュリティリスク分析ガイド第2版」では、資産ベース分析を行った後にこの事業被害ベース分析を行うことになっています。でも実は、事業被害ベース分析の中でも攻撃シナリオを検討することになっています。ですから、どれか一つのアプローチを排他的にする必要もないですよね。まあ要はケースバイケースで使い分けしたり、補完的に使えばいいということでしょうか。