今回はリスク分析をおこなう上で分析者が良くつまずく落とし穴を避けるコツについて解説します。
①資産ベース分析でどの脅威(攻撃手法)について対策を調査すれば良いかわからない
資産ベース分析では、資産の持つ機能を考えておこりうる脅威(攻撃手法)を選択して、その攻撃手法の対策を記述する、と説明されています。これは、調査検討すべき脅威の数を減らすために行う事ですが、そのためには資産の機能の詳細を検討しなければなりません。
またこの機能詳細は、例えばその資産の管理者権限を奪取されたようなケースでは、役割は意味をなすかもしれません。
ですのであまり厳密に機能が何なのでどの攻撃手法についてと考えるより、全部について調べるくらいの感覚でまとめれば良いのでは無いかと思います。
ただし、物理的侵入と過失操作で分類されている対策はシステムや建物の話ですので資産ベースでは考える必要はありません。
②脅威と対策の切れ目がわからない
分析者が良く陥るのが、脅威と対策を混同してしまうことです。例えば評価する資産の手前側のファイアウォールがある場合、それを資産の対策として入れ込んでしまう。
そうすると、事業被害ベース分析の攻撃ツリーの評価では、ファイアウォールを評価したあと、その下流にある資産の対策として、再度ファイアウォールをダブルカウントしてしまう事になります。
資産の手前側にあるファイアウォールは資産ベースでは対策に入れない(脅威が低減していると考える)、事業被害ベースでは一つの資産としてファイアウォールを考えるというやり方をすればすっきりすると思います。
③脅威レベルをどうやって考えれば良いかわからない
脅威レベルは、どれだけ攻撃をうける可能性があるか、と考えると良いと思います。手軽でやる気になるニンジンがぶら下がっていれば脅威は上がります。そんなイメージではいかがでしょう?
④事業被害ベース分析で脅威の決め方がわからない
事業被害ベースでは攻撃ツリーで脅威を考えます。その時の侵入口はどこでしょう?
まず侵入口での脅威を考えて、次に攻撃ステップでの脅威を考えて、としてざっくりと脅威を考えるのが良いのではないでしょうか。
⑤資産ベース分析だけではダメなのか?
ガイドにも説明はありますが、資産ベースではむら無く全部の資産をチェックします。それでもある程度は大丈夫です。
でも制御システムでは、その対策は個別の資産に打てるでしょうか?結局守るためにはシステムのどこかで代表的な対策を立てる必要が出てくるのでは無いかと思います。
そういう時には、事業被害ベース分析の方が有効で、効果的です。
⑥資産をリストアップしすぎる
あれもこれもと資産全部をリストアップすると、最初の分析でギブアップしてしまう場合が多いです。確かにもれなく分析を行うのには全部のリストアップが望ましいですが、特に事業被害ベース分析で資産の数が増えると、攻撃ルートの数があっというまに膨らんでしまいます。
似たような資産はできるだけまとめたり、これは絶対安全だろうというものを省略したり、一方で、これは危険な入り口になるなというものはきちんと入れておく(リモートメンテナンスの口などは最も危険です)といった対応を検討しましょう。
⑦ファイアウォールをダブルカウントしてしまう
アプライアンス型(ソフトウエアではなくてスイッチのような形をしているもの)のファイアウォールは、制御システムでは関所の様な大切な役割をします。事業被害ベース分析の際は、ファイアウォール自体も資産で評価をしますが、そのファイアウォールに守られている資産の対策としてファイアウォールを追加すると、対策としてファイアウォールがダブルカウントされてしまい正確さを欠きます。これは要注意です。
⑧ログ収集を対策として考えている
ログ収集は、インシデントが発生したあと何が起こったのかを調べるのにはとても大切ですが、リアルタイムには守ることができません。その観点からIPAのガイドでは、ログ収集は常時監視していて問題が発生した時にすぐに対応し被害を低減できるのであれば対策として考えても良いが、チェックもしないでただ記録しておくのは対策とはしていません。
⑨何でもかんでも対策レベル3
対策レベル3は、まず破られない対策にのみ与えられるようにしています。現実的には攻略コストが見合うかという点が判断基準になるのでしょうけれど、対策レベルが3にできるものはそうそうありません。多層防御で防ぐという方法はあるかもしれませんが。
ガイドの例に載っていないけれど、これは対策レベル3だと判断された場合には、対策レベル3の根拠を分析シートにメモしておくのが良いでしょう。
まとめのあたりでもまた落とし穴はありますが、ここまででとりあえず思いつくのはこれくらいでしょうか。
まだあった気もしますが、思い出したらまた書きます。
次回は、分析結果のまとめについて書きます。