リスク分析の３つのアプローチとセキュリティの7S - セキュリティコンサルタントの日誌から

（追記）2019年02月12日に追記を行いました。

リスク分析は、セキュリティ戦略策定の上で欠かせない基本的なアプローチです。

以前、日経SYSTEMSの記事「セキュリティコスト５つの掟」（2018年10月号）にて、一部のインタビュー記事が紹介されましたが、そこで取り扱われたリスク分析の考え方について、自分の考え方について少し整理をしておきたいと思います。

tech.nikkeibp.co.jp

リスク分析の概要

リスク分析とは、基本的に以下のステップで行います。

セキュリティ対策の現状把握を行い、現時点のリスクを特定・把握する。
対策の優先度を決定する。
対策の実装に向けたロードマップを策定する。

セキュリティ予算・リソースは通常有限であり、足りないことが一般的ですので、この分析をしてその年にやるべき対策を決定するのが主なスコープです。

セキュリティ対策の現状把握

リスク分析を行う際に、一番悩むポイントとして、「どのようにセキュリティ対策の現状把握を行うか？」という点です。

筆者の経験では、リスク分析のアプローチは大きく３種類に分類されると考えています。

ベースラインアプローチ
リスクベースアプローチ
ビジネスプロセスアプローチ

アプローチ１：ベースラインアプローチ

ベースラインアプローチとは、あらかじめ実現すべきセキュリティレベル（ベースライン）を決定し、システムや組織が目標としているセキュリティレベルに達しているか否か判断するアプローチで、ギャップ分析とも呼ばれます。

このベースライン（実現すべきセキュリティレベル）としては、様々なガイドラインや規制を活用することが一般的です。以下に代表的なガイドラインを示します。

ISO270001
Critical Security Control
PCI-DSS

例えば、Critical Security Controlの場合、AuditScript社がだしているようなスクリプトで評価する方法などが考えられます。（AuditScripts.com）

ここで注意すべきことが複数存在します。

第一に、各ガイドライン・規制の特徴を正確に把握することです。具体的に技術的に詳しく踏み込んでいるガイドラインもあれば、かなり汎用的な表現にまとめられているものも存在します。各セキュリティベンダーは、こうした利点・欠点を活用しながら、独自のフレームワークを作成していたりします。

第二に、どのように評価するかという点です。簡単な方法はチェックリストによるチェックです。しかし、チェックリストでは申告者の認識違いなどがあり、過大評価される結果になりがちです。一方、コンサルタントを使った評価では、具体的なドキュメントを確認したり、記録を確認したりするなどして、その品質を担保していきます。

アプローチ２：リスクベースアプローチ

リスクベースアプローチとは、ベースラインアプローチをある程度実施し、基本的な対策を実装した組織がやるべき一つ成熟度を上げた手法です。これは、ある特定のリスクを防止するために必要な対策を見極めるアプローチで、「脅威シナリオ分析」とも呼ばれます。

ここで重要なことは、一般的にリスクが高いとされる脅威を選択すること、そしてシナリオを適切かつ緻密に作成することです。そのシナリオを作成するためには、Threat Intelligenceなどを活用するなどして、最新のシナリオを取り入れていきます。

そして、どういう条件の場合において攻撃が成功するのか、なにが単一障害点（Single Point of Failure）となるのか、そしてどんな新しいセキュリティ施策（Security Control）を導入するとその可能性を下げることができるのか、多層防御（Defense-In-Depth）の概念から検証します。

これを実際に行う際には、いくつか実施レイヤーが存在すると考えられます。非常に細かくやる場合は攻撃者の攻撃手口（TTP）と自社の環境を見比べ「XXというセキュリティコントロールが機能しない場合、その点が単一障害点となり被害が拡大する」ですとか「攻撃者がAというアプローチではなく、Bというアプローチをとった場合、防ぐことができない」などの分析結果が考えられます。

アプローチ３：ビジネスプロセスアプローチ

ビジネスプロセスアプローチは、よりビジネスプロセスに寄り添ったリスク分析手法です。この考え方は、複雑なビジネスプロセスを持っている、あるいは拠点間で様々な分業が行われているなど、リスクベースアプローチで対象とするような技術的リスクだけでなく、ビジネスプロセス上のリスクも含めて評価することを目的としています。特に最近では、BECのようなビジネスプロセスを悪用したような攻撃も増えていますので、こうした分析手法も徐々に注目を浴びています。

具体的な方法は、まずビジネスプロセスをまず整理します。その時には、全てのビジネスプロセスを追いかけると複雑になるため、主要なデータ（個人情報など）に注目し、その流れを追いかけることで関係のあるプロセスに着目します。そのうえで、どのような処理が行われているか、そしてどんな攻撃を受ける可能性があるかを分析していく手法です。

方法論（机上評価 vs. 実機評価）

ここまで、３種類のアプローチを紹介しましたが、これは机上評価という方法論に特化して説明してきました。ここでは、この方法が、テクニカルな方法でもこの考え方は適当できることを考えて行きます。

方法論１：机上評価

ここまで紹介した方法は、机上評価と呼ばれる方法です。この方法は、技術、プロセス、組織面から網羅性を担保して分析できる一方、ヒアリングやアンケートに基づいて行われるため、勘違いや認識齟齬、実際の技術やプロセスの実効性などについてあまり掘り下げられない可能性があります。

方法論２：実機評価

一方、実機評価と呼ばれる方法も存在します。実機評価とは、セキュリティ診断やペネトレーションテストなどを意味し、技術的観点を中心に、予防（Prevention）、検知（Detection）、対応（Response）の観点から分析を行います。技術的観点には深く分析することができる一方、マネジメント的観点、あるいはプロセス的観点についてはあまり網羅できないという特徴があります。

ベースラインアプローチに該当する実機評価は、脆弱性スキャンと呼ばれる方法です。パッチが適切にあたり、ハードニングが適切に行われている状態をベースラインとする一方、各機器が持つセキュリティレベルをチェックして、適用されていないパッチ、あるいは脆弱な設定などを洗い出し、そのギャップを分析する方法です。

また、リスクベースアプローチに該当する実機評価は、ペネトレーションテスト、あるいはRed Team Exerciseと呼ばれる方法です。つまり、実際にある目標に対する脅威を想定して、どんな攻撃パターンで目的を達成できるか、技術的な観点から監査を行います。最近金融庁などから話題になっているTIBER（Threat Intelligence Based Ethical Red Teaming）やTLPT（Threat Lead Penetration Test）などは、このシナリオ・リスクにより注目した概念だと考えられます。

最後のビジネスプロセスアプローチについては、ビジネス的観点を重視にされているため、ビジネスを知っているセキュリティ専門家でないと実施できない方法です。強いて言えば、高度なTIBER・TLPTはこれに該当すると言えますが、まだまだビジネスリスクにまで焦点を当てた実機評価は少ないでしょう。

補足：机上評価と実機評価の使い分けはどのようにすべきか？

評価軸１：取り組みやすさ

第一の評価軸として、「取り組みやすさ」が挙げられます。

机上評価の場合、自社環境を知っていればすぐに評価を行うことができ、また自社内で専門のスタッフが存在すれば、コスト負荷もなく実施することができるという点が挙げられます。そのため、取り組みやすい方法だと言えます。

また、新しい攻撃手法が出てきてもその多くは詳細なTTPs の差異であることが多いため、脅威シナリオを大幅に見直すことは少なく、多くの場合は特定のポイントを見直して終わることが一般的になるでしょう。

一方、技術評価の場合、「取り組みやすさ」という観点からは弱い部分があります。攻撃者と同じ立場で実施してもらうため、通常は外部セキュリティベンダーを活用して実施を行います。そのため、それなりにコスト負担をする必要があります。実際、金融庁の調査レポートなどでは、具体的金額が示されており、それなりの予算を確保しておく必要があります。さらに言えば、実施に際しても現行のビジネスに影響が出ないように、あるいはビジネス部門へ配慮しながら実施を行うために調整・準備コストという観点からも取り組み難易度は高いと言えます。

評価軸２：網羅性

第二の観点として、「網羅性」が挙げられます。机上評価の場合、環境全体を把握したうえで評価を行うために様々なケースを想定し、網羅的な検証を行うことができます。

一方、実機評価の場合、環境内の情報は最低限しか知らせず、公開情報をもとにTTPs に従った攻撃を行います。そのため、偶然セキュリティ運用チーム内のヒューマンエラーにより攻撃が成立する、あるいはたまたま条件がそろったために情報が奪取できたなど、結果についても個別具体的な要因に影響を受ける可能性があり、「そのヒューマンエラーがあまり起きなかった場合、あるいはそれ以外の弱い点はどこがあるのか？」といった網羅的な評価をやりきることは難しいと言えます。また、環境内の情報を最低限しか知らずに適宜調査をしながら侵入テストを行うという性質上、セキュリティ対策全体を俯瞰した上で問題点を洗い出すという側面に極めて弱く、あくまでも「侵入してきた攻撃者が時間内に調査した限りにおける弱点を洗い出す」という性質がどうしても強くなってしまうと言えます。

評価軸３：評価の信頼性

第三の観点として、「評価の信頼性」が挙げられます。ここまで、机上評価はメリットばかりが上がっていましたが、この点では机上評価は弱いと言えます。机上評価の最大の欠点は、評価者が既存のテクノロジーやプロセスを課題に評価してしまったり、各プロセスやテクノロジーが完璧に動くこと前提に評価してしまうなどの問題点が挙げられます（もちろん、その点も考慮してやるべきなのですが、そうしたテクノロジーやプロセスが適切に動かないケースはそれこそ様々な可能性があるので、ある程度想定を置いて行うしかできないでしょう）。外部のコンサルタントをいれた場合でも、基本的にこうしたプロセスの検証は限られた時間でやるため、ある程度定性的かつ包括的な評価にならざるを得ないと思います。

しかし、攻撃者はテクノロジーやプロセスの不完全性を突いて攻撃を行ってくることも多いわけですので、机上評価の結果を盲信してしまうと、思わぬ部分に課題があるというケースが考えられます。

一方、実証評価の最大の利点はこの「評価の信頼性」です。いくら机上で問題がないと評価しても実際に悪用できることを示してしまえば、非常に説得力を持って改善プロセスを動かすことができます。特に、ヒューマンエラーやプロセスの不備など、机上評価ではあらわれにくい課題が実証評価ではあらわれてきます。特に、テクノロジーの不備だけでなく、プロセス上の不備、不完全性をも悪用して検証が行われるため、実際に悪用できるのか否か、という点にシンプルな解を得られるという点です。

補足：プロセスの実効性をより深く検証する方法は？

ここまで読むと、プロセス面の実行性をより深く検証する方法はないのか？という疑問がわいてきます。部分的には存在します。

例えば、セキュア開発ライフサイクルなどの実効性を確認する場合は、当該製品のセキュリティ診断結果を見つつ、関連するドキュメントや成果物などを仔細に分析していく監査的なアプローチなどを取ることにより検証ができると言えます。

一方、例えばインシデント発生時の対応プロセスを検証するのであれば、サイバー演習と呼ばれる方法が有効でしょう。これは、実際にセキュリティインシデントが発生したと仮定して、模擬訓練を行う方法で、本来は避難訓練と同様に訓練が目的です。しかし、この方法を通じて、どのようなプロセス上の欠点があるか洗い出すことができます。例えば、金融庁や金融ISACが実施しているサイバー演習は、適宜イベントと呼ばれる状況付与を与え、それに基づいてダイナミックに対応する練習を行う手法を採用しています。こうした方法を取ることで、プロセスの実効性、メンバーへの浸透度合などを評価することができるでしょう。