マイクロソフトの Securing Windows 2000 Server ソリューション
第 3 章 ‐ セキュリティ リスク管理の統制について理解する
トピック
セキュリティ リスク管理とセキュリティ フレームワーク プラクティス
セキュリティ リスクの追跡、計画、スケジュール作成、および報告
この章は、MSF (Microsoft Solutions Framework) と MOF (Microsoft Operations Framework) を利用して今日使われているセキュリティ分析手法の中から、実績のある手法を参考にして書かれたものです。MSF は、エンタープライズ アーキテクチャとインフラストラクチャ展開のプロジェクト ライフ サイクルについて、この計画、構築、安定化、および展開の各段階におけるガイダンスを提供します。MOF は、情報技術 (IT) 業務用の管理システムを開発または改善する方法についてアドバイスを提供します。MSF または MOF の詳細については、この章の末尾にある 「詳細情報」セクションを参照してください。
この章では、ガイダンスの主な 3 つのプロセスを定義します。これらは、セキュリティ プロジェクトのライフ サイクル中に発生するリスク管理活動の観点から見たセキュリティ リスク管理の統制 (SRMD)、およびセキュリティ リスクのフレームワークです。
安全を確立するために必要なものと、これを維持する方法を定義するために、企業が利用できる主なプロセスが 3 つあります。以下、これらの主なプロセスを高レベルで定義します。
評価
この段階では、セキュリティの評価を行うために、企業の環境から必要な情報を収集します。現況を効果的に分析できるように十分なデータを収集してから、企業の情報資産が潜在的脅威からどの程度保護されているかを判定する必要があります。セキュリティ評価に加えて、後の段階でセキュリティ アクション プランを作成し、実装プロセス中にこれを実行します。
開発と実装
この段階では、セキュリティ アクション プランを実行し、評価の段階で定義された、環境に対する推奨された変更を実装することが中心となります。セキュリティ アクション プランに加えて、セキュリティ リスク危機管理計画も作成します。
実施
この段階では、安全性を保つために必要に応じて環境に修正および更新を実施します。作業プロセス中には、侵入テストとインシデント レスポンス戦略を実行します。これらの作業は、企業内でセキュリティ プロジェクトを実装する目的を明確化するのに役立ちます。作業プロセス内で、インフラストラクチャを安全な状態に保つために、監査と監視も実行します。
セキュリティ リスク管理とセキュリティ フレームワーク プラクティス
セキュリティ プランの執行中、2 種類のリスク管理活動が、プロジェクトのライフ サイクル中に継続されます。1 つは、プロジェクト自体に固有のリスクを管理する仕事で、もう 1 つは、セキュリティ コンポーネントと関連するリスクを管理する仕事です。プロジェクトのリスクは、プロジェクトのライフ サイクル中しか評価されませんが、セキュリティ リスクは、ソリューションまたはシステムのライフ サイクル全体を通じて評価を行うことが必要です。MSF リスク管理統制は、プロジェクトとセキュリティの両方の評価を対象にリスクを管理するためのベースとなります。セキュリティ リスク管理の規範例が、このガイドの第 4 章「セキュリティ リスク管理の統制を適用する」にさらに解説されています。
このソリューション ガイドでは、セキュリティ リスク管理の統制 (SRMD) が定義されています。SRMD は、MSF Risk Management Discipline (RMD) から派生したものです。2 つの作業の明確な区別を保つために、プロジェクト リスクのコンテキストでは RMD が使われ、セキュリティ リスクの評価作業に言及する場合には SRMD が使われます。RMD は、SRMD 開発用の主要ツールとして用いられます。
RMD と SRMD の両プロセスはどちらも、ユーザーの環境におけるプロジェクトと作業の全体を通じて、予防的手法、継続的なリスク評価、意思決定への統合を主張します。
コンピュータ システムのセキュリティは、情報資産のセキュリティを確実なものとし、新たな脅威や脆弱性が発生していないかどうかを監視するために、予防的かつ継続的に実施する必要があります。自社のテクノロジ インフラストラクチャに新機能を加えたときには必ず、情報のセキュリティについて考慮することが必要です。加えて、修正された環境内で作業するために、ビジネスのプロセスや手順を一部変更して、新たな情報資産を保護する必要のある場合があります。
セキュリティ リスク管理の統制には、以下の 9 つの手順があります。
- 評価
資産の査定と評価
- セキュリティ リスクの識別
セキュリティ リスクの分析と優先順位の決定
セキュリティ リスクの追跡、計画、スケジュール作成
開発と実施
セキュリティ改善策の開発
セキュリティ改善策のテスト
セキュリティ知識を取り込む
実施
資産の新規追加/変更とセキュリティ リスクの追加/変更について再評価する
新規対策または修正対策の安定化と展開
これらの手順は、評価、実装、作業という 3 つの主な段階として SRMD の中に統合されています。
評価
以下のセクションでは、企業の評価タスクをセキュリティ分析の開始部分の土台に加えます。資産の査定と評価は、セキュリティ分析の第一歩です。変動するリスクを評価するには、出発点がどこなのかを知る必要があるからです。セキュリティ分析のプロセスは、自社の環境において安全を確保する価値のある資産を特定し、セキュリティ適用の優先順位を決定するための一連の戦略です。
資産の査定と評価
資産の査定とは、関連当事者が情報に与える相対的な価値であり、情報を開発するために要した労力の大きさも関係します。評価とは、ある資産の維持に要する費用、資産が失われた場合または破壊された場合の損害金額、および別の当事者がこの情報を入手した場合に得るであろうメリットを見積ることです。資産の価値には、資産が実際に損なわれた場合に発生するであろう識別可能なコストをすべて反映する必要があります。
セキュリティ リスクの識別
セキュリティ リスクの識別により、プロジェクト チームのメンバはディスカッションを実施して、潜在的なセキュリティ リスクを炙り出すことができます。脅威、脆弱性、攻略手法、対策に基づいて、情報を収集します。
セキュリティ リスクの分析
セキュリティ リスクの分析は、潜在的な脆弱性を悪用するために使われる可能性のある潜在的な攻撃、ツール、方法、テクニックを分析するために用いられます。セキュリティ リスクの分析は、リスクを識別し、安全予防手段を正当化する理由となり得る損害の可能性を評価する方法です。
セキュリティ リスクの分析には、主な目標が 3 つあります。それは、リスクの識別、潜在的脅威による影響の定量化、そして、リスクの影響と対策費用の間で経済的なバランスを取ることです。リスクのレベルを見積るために情報が収集されます。それは、チームが下す高度な判断に基づいて、セキュリティ リスクに対し最大の改善効果が得られるようにするためです。
続いて、この分析を使ってセキュリティ リスクに優先順位を付けます。それにより、会社は重要性が最も高いセキュリティ問題に対処すべく、資金や人材を集中的に投入することができます。
リスク分析は、セキュリティ プログラムの目的を企業の事業上の目的や必要条件と統合するためにも役立ちます。事業とセキュリティのそれぞれの目的が一致するほど、両方の目的の完全達成が近づくことになります。
分析は、会社がセキュリティ プログラムに充当する適正予算を見積もり、このプログラムを構成するセキュリティ コンポーネントを策定することにも役立ちます。会社の資産価値と潜在的な脅威がわかれば、資産を守るにはどの程度の投資が必要かについて、合理的な決定を下すことができます。
セキュリティ リスクの追跡、計画、スケジュール作成
セキュリティ リスクの追跡、計画、スケジュール作成では、セキュリティ リスク分析で得た情報を使って、リスク軽減の戦略と危機管理戦略、およびそれらを包含する計画を立てます。セキュリティ リスクのスケジュール作成では、セキュリティ プロジェクトの構築段階で立てたさまざまな改善戦略のスケジュールを決めます。このスケジュール作成では、実装すべき標準的な日々の作業手順だけでなく、セキュリティ計画がどのように承認され、情報アーキテクチャの中に組み込まれるかを考慮に入れます。
開発と実装
評価プロセス中の作業により、適切な対策を開発および実装できます。評価プロセスの成果により、効果的な対策の展開とセキュリティ学習戦略の実装にスムーズに移ることができます。
セキュリティ リスク改善策の開発
セキュリティ リスク改善策の開発とは、評価段階で作成した計画を受けて、この計画を用いて構成管理、修正プログラム管理、システム監視および監査、ならびに作業方針および手続きを含む新しいセキュリティ戦略を策定するプロセスです。さまざまな対策が開発中であるため、この進展を徹底的に追跡および報告することが重要です。
セキュリティ リスク改善策のテスト
セキュリティ リスク改善策のテストは、改善戦略が開発され、関連するシステム管理の変更が済み、これらの効果を判定するための方針と手続きが書かれた後に実施されます。テストのプロセスがあるおかげで、チームは、どうすればこれらの変更を生産環境の中に展開できるかを考えることができます。テスト プロセスの間、セキュリティ リスクがどの程度制御されるかを基準に対策の有効性が評価されます。
セキュリティ リスクの学習
セキュリティ リスクの学習では、チームが資産をどう保護したかについての知識を取り込むプロセスを形式化し、発見した脆弱性と弱点の悪用に関する資料を文書化します。IT 部門が新しいセキュリティ情報を学習すると、会社の資産を保護するセキュリティ対策の有効性を常に最適化するには、この情報を取り込んで再展開する必要があります。さらに、トレーニングまたはセキュリティ啓発の掲示板により、業界に向けてセキュリティ教育を実施する必要があります。
注 これらの手順は論理的なガイドとして書かれたものであり、特定のセキュリティ リスクを取り扱う際に必ずしも順番に行う必要はありません。セキュリティ チームは、特定の情報資産に関するセキュリティ問題、脅威、脆弱性に関して経験を積む中で、識別、分析、計画の手順を繰り返すことがよくあります。
会社は、正式なリスク管理プロセスを策定し、この中でセキュリティ対策の開始方法と評価方法、および個々のまたは一群のセキュリティ リスクに関して、どんな状況が発生した場合に次の手順に進むのかを定義する必要があります。
作業
作業サイクルが強固で一貫していれば、セキュリティ チームは、信頼性が高く予測可能な成果を生み出すメカニズムを手にすることができます。セキュリティ プロジェクトの初期段階で評価プロセスを執行することで、チームは、企業全体の資産の新規追加/変更を再評価する方法について、知識を増すことができます。そうなれば、資産の新規追加/変更に対する新しい対策と変更された対策を安定させて展開することが、社内の日常作業の一部となります。
資産とセキュリティ リスクの新規追加/変更について再評価する
これらは、本質的には管理変更プロセスですが、セキュリティの構成管理プロセスでもあります。新しい対策とセキュリティ ポリシーが完成すれば、リリース管理へとつながります。
新規対策または修正対策の安定化と展開
作業段階では、これらのプロセスは、システム管理、セキュリティ管理、ネットワーク管理の各チームによって管理されます。サービス監視、サービス制御、ジョブ スケジュール作成は、作業段階における新たなプロセスです。セキュリティ管理者はこのプロセスで、改善された新しい対策を執行します。
セキュリティ サービス デスク、インシデント管理、問題管理の学習
サポート段階では、IT 企業内の作業グループは、セキュリティ サービス デスクからの強力なセキュリティ管理、インシデント管理、問題のエスカレーション管理によって、安全な環境を支えます。
サービス レベル管理、財務管理、可用性管理
MSF と MOF は、強力なセキュリティ管理プログラムの開発、展開、維持を支援するために作られたもので、豊かな実績を持っています。MSF と MOF の実績ある経験をうまく活用すれば、リソースの完全性、機密性、可用性を提供する環境を作り上げることができます。
セキュリティ管理は、サービス レベル管理、財務管理、サービス コミュニティ管理、可用性管理、容量管理、人員管理における強力な管理によって最適化されます。
セキュリティ リスク管理のフレームワーク
概要
フレームワークには MSF プロセス モデルが利用されており、IT セキュリティ ソリューションの構築と配備のための一連の高度な業務が説明されています。フレームワークは、特定の手続きの流れを指示することよりも、広範囲にわたる IT プロセスを含めた概要を示すことのできる柔軟性が特徴です。プロセス モデルには、プロジェクトの開始からライブ展開まで、ソリューションのライフ サイクルが網羅されています。
.gif)
図 3.1: 段階ごとに見たセキュリティ フレームワーク プロセス モデルの主要管理点
MSF プロセス モデルを使用して、ソフトウェア アプリケーションを開発し、インフラストラクチャ テクノロジを展開することができます。プロセス モデルは、ソリューションの増分バージョンを短いサイクルで繰り返し開発することで、変化するプロジェクトの必要条件に対応できるように作られた反復サイクルに従います。継続的なリスク管理とテスト サイクルにより、これが可能になります。
プロセス モデルの各主要管理点では、プロジェクトに関する多くの重要な質疑応答やディスカッションが行われます。たとえば、以下のような質問です。チームはプロジェクトの範囲に関して合意しているか? チームは先に進む前に十分な計画を立てたか? チームは約束どおりのものを構築したか? 顧客や企業のパートナにとって、ソリューションは適切に機能しているか? 上図と関連するセキュリティ プロジェクトの主なプロセス 6 点について、以下に概略を説明します。
プロジェクトの定義を開始する
プロジェクトの開始段階では、セキュリティ プロジェクトを成功させるために必要な、最も基本的な要件の 1 つを取り扱います。それは、プロジェクト チームとセキュリティ プログラムを 1 つに結び合わせることです。チームを開始するプロセスは、開始段階の最後に仕上げの調整を行うまで続きます。チームの全員が、セキュリティ ソリューションにおける明確な達成目標を持ち、セキュリティに関するビジネス ニーズを把握しておく必要があります。この段階では、セキュリティ管理の周辺に存在するビジネス上の課題や機会を識別することに重点が置かれます。セキュリティ管理に関わる全当事者が、これらのプロセス期間中に、目標、仮定、制約を明確にする必要があります。
セキュリティの評価と分析
セキュリティ管理の評価と分析は、MSF 手法の計画段階で実施されるプロセスです。このプロセスには、企業の評価、資産の評価、脅威の識別、脆弱性の評価、およびセキュリティ リスクの評価が含まれます。これらは一体となって、有効な対策を展開するための計画を構成します。
セキュリティ改善策の開発
セキュリティの評価と分析の段階で得られた情報は、セキュリティ改善策の開発手段となります。開発者は、これらの期間中、プロジェクトのこれまでの段階で確認されたリスクを改善するための対策を開発、テスト、および評価する作業を常に実行しています。こうしたセキュリティ改善策の開発プロセスは、開発チームによる単位テストを受け、品質基準に基づいて評価されます。
セキュリティ改善策のテストとリソース機能のテスト
セキュリティ改善策のテストとリソース機能のテストのプロセスには、比較的予想の難しい結果が含まれます。機能テストで得られた予期しない結果には、安定化の段階でテスト プロセスによってタグが付けられ、管理されます。構築段階では既知の計画や仕様を基に作業が進められますが、発見される障害の数や深刻度は一切わかりません。マイクロソフトでは、脆弱性の解決策のクオリティを示し、その時点での解決策の公表日を予測するため、バグを収束させ、障害を削減する技術を使用しています。
セキュリティ ポリシーと対策の展開
セキュリティ ポリシーと対策を展開するプロセスは、MSF 手法を展開する段階の全体を通じて継続され、MOF プロセスのサイクルに至るまで続きます。対策を展開するこのプロセスにより、対策とセキュリティ ポリシーのタイプが、コアとサイトの 2 種類に大別され、それぞれにセキュリティ コンポーネントが付属する構成になります。コアに特有のセキュリティ コンポーネントは、セキュリティ ソリューション全体に関係する中心的 (重要) な場所に配置されます。サイトに特有のコンポーネントは、ユーザーがセキュリティ ソリューションにアクセスして使うことができる個々の場所に配置されます。
展開完了
セキュリティ リスク管理の知識は、展開完了の主要管理点が近づいた段階で得られるものです。展開間近の段階で学んだ教訓を取り入れることで、ソリューションは作業段階に入り、完成されたプロジェクトは MOF プロセス サイクルへに渡されます。
セキュリティ プロジェクトのプロセスについてさらに詳しくは、Microsoft Solution for Security Services Guideを参照してください。
セキュリティ プログラム チームの結成
MSF プロセス モデルの評価プロセスにおいて、環境のセキュリティ保護のために極めて重要な手順があります。これは、セキュリティ プログラムの作成です。このセキュリティ プログラムの原則は、社内の総合セキュリティの目的、範囲、方針、優先順位、基準、および戦略を決定することです。セキュリティ プログラムのメンバは社内の上級管理者です。セキュリティ管理グループは、セキュリティ プログラムによって管理されるポリシーを実装および管理する中間管理者層と報告チームで構成されます。
セキュリティ プログラムは、トップダウン方式で開発すべきです。すなわち、開始、支援、および方向付けを経営陣が実施し、中堅の責任者、最後は従業員にまで行き渡るという方式です。しかし、サポートは、トップダウン、ボトムアップ、およびミドルアウトの各方式を組み合わせて、セキュリティ管理のアイデアを開発および支持することになるでしょう。今日の企業の多くは、開発とサポートにボトムアップ方式を採用しています。その場合、IT 部門は経営陣から適切な支援と方向付けを得ずにセキュリティ計画を開発することになります。したがって、セキュリティ プログラムが、企業のより大きな事業目的から逸脱してしまう可能性があります。
経営陣は、プロセスの発足に必要な役割と責任を社内に割り振ることで、セキュリティ プログラムの作成を開始すべきです。経営陣が関わることで、ビジネスとテクニカルな環境が変化すると共に、プログラムの強さを維持し、発展させることができます。セキュリティ プログラム内で役割を作ることにより、企業がセキュリティを単なる関心事ではなく、事業の中心的な部分として見ていることが確認されます。
セキュリティ プログラムに加え、経営陣はセキュリティ管理グループを設立する必要があります。セキュリティ管理グループは、セキュリティ プログラムのほとんどの面を監視する直接的な責任を負います。通常、社内のセキュリティ プログラムはセキュリティ ポリシーを策定しますが、セキュリティ管理グループは、セキュリティの構成を実施し、監視します。
企業と企業のセキュリティ ニーズおよび環境の規模に依存して、セキュリティ管理は、中央集権的または分権的に機能する 1 人またはグループで構成されることになります。
評価
プロセス モデルにおいて説明されている、脅威を評価するためのセキュリティ フレームワークは、セキュリティの専門担当者による、企業の IT インフラストラクチャにおけるデータの可用性、完全性、および機密性を保護するための戦略開発を支援するためのものです。これは、情報リソース責任者、コンピュータ セキュリティ担当者、および管理者に関連することであり、コンピュータ セキュリティのポリシー確立に努める人々には、特に価値のあることです。フレームワークは、この重要なタスクに対する体系的な取り組みを提供すると共に、最終的な安全措置として、障害発生時の危機管理計画の確立をも視野に入れたものです。
機密性
企業の IT インフラストラクチャには、不正な開示からの保護を必要とする情報が含まれている場合があります。たとえば、収穫高の報告書、個人情報、社外秘のビジネス情報など、情報をまく (流す) タイミングが重視されるものです。機密保持により、データ処理の各接続点で必要なレベルの機密性を確実に提供し、不正な開示を防止できます。データがネットワーク内のシステムとデバイス上にある間、転送時、送信先で受信された時に、一貫したレベルの機密性が維持されるべきです。
完全性
IT インフラストラクチャには、不正な、予期しない、または故意でない改変から保護されなければならない情報が含まれています。たとえば、人口調査の情報、経済指標、金融取引システムなどです。情報とシステムの正確さと信頼性が保証され、データの不正な改ざんが防止できれば、完全性が守られます。
可用性
IT インフラストラクチャは、使命遂行の必要条件を満たすために、または大きな損失を回避するために、タイムリーに発信する必要のある情報を含み、あるいは、このような性質のサービスを提供することもあります。たとえば、安全装置、生命維持、および一貫したネットワーク接続が不可欠な重要なシステムがこれに相当します。可用性は、認証された個人に対し、データとリソースへのタイムリーなアクセスと信頼性を保証することになります。
セキュリティ管理者は、適切なセキュリティ ポリシーと管理を策定するために投入する時間、資金、および労力を判断する必要があります。企業は、特定のニーズを分析してから、このリソース、スケジュール作成の必要条件と制約について判断する必要があります。コンピュータ システム、環境、および企業ポリシーがそれぞれ異なるので、社内のコンピュータ グループの安全確保の戦略は困難です。
セキュリティ戦略により、企業は貴重な時間を節約でき、何をすべきかについて重要な注意喚起が提供されますが、セキュリティは一度限りの働きではありません。セキュリティとは、環境を構築するシステム ライフ サイクルの不可欠な部分なのです。この章で説明する作業は、一般に定期的な更新または適切な改訂を必要とするものです。このような変更は、構成その他の条件が大幅に変わる場合、または企業の規則やポリシーに変更が必要とされる場合に実施されます。これは反復されるプロセスであり、決して終わりがなく、定期的な改訂とテストが必要です。
組織的な評価
効果的な一連のセキュリティ ポリシーと管理を確立するには、コンピュータ システムと現在のセキュリティ ポリシー内に存在する脆弱性、およびそれを保護する管理システムを判断するための戦略を使う必要があります。レビューを行う際に、環境内でポリシーが欠けているところに注目し、また、存在するポリシーに関する文書を調査する必要があります。ポリシーのレビューに加え、法務担当は、セキュリティ ポリシーのすべてが企業の法律規定に準拠していることを確認する必要があります。コンピュータ セキュリティ ポリシーの現況は、以下のリストを検討することで、判断できます。
物理的なアクセス制御などの物理的なコンピュータ セキュリティ ポリシー
ネットワーク セキュリティ ポリシー (たとえば、電子メールとインターネットのポリシー)
データ セキュリティ ポリシー (アクセス制御と完全性制御)
危機管理計画、およびこれらのテスト
コンピュータ セキュリティの啓発とトレーニング
コンピュータ セキュリティの管理と調整のポリシー
機密情報を含むその他のポリシーに関する文書。以下に例を示します。
コンピュータの基本入出力システム (BIOS) パスワード
ルーター構成のパスワード
アクセス制御の文書
その他のデバイス管理パスワード
脅威の分析
脅威のリスト (ほとんどの企業はいくつかの脅威を識別できます) を作成することは、セキュリティ管理者が、攻撃に悪用される可能性のあるさまざまな弱点を識別するのに役立ちます。セキュリティ対策を欺くための新しい方法、ツール、および手法が絶えず考案されているため、管理者がこの分野の情報を継続的に更新することが重要です。
予想できる攻撃を判断し、この攻撃への防御対策を策定するための脅威分析プロセスの概略が図 3.1 の計画段階に示されています。すべての攻撃に対して備えることは不可能です。したがって、企業が予想できる最も可能性の高い攻撃に対して備えます。攻撃後に損害を修復するよりも、攻撃を予防するか、または最小限に抑えることの方が常に得策です。
攻撃を最小限に抑えるには、システムにリスクをもたらすさまざまな脅威、セキュリティ制御を出し抜くために使われる可能性のある技法、セキュリティ ポリシーの中に存在する脆弱性について理解することが必要です。攻撃の 3 要素であるこれらの点について理解しておけば、発生のタイミングや場所までは難しいにしても、発生そのものを予測する助けとなります。攻撃の予測とは攻撃発生の可能性を予測することであり、攻撃のさまざまな側面についてどこまで理解できるかに依存します。攻撃のさまざまな側面は、以下の等式によって表現できます。
脅威の誘因 + 弱点を悪用する方法 + 資産の脆弱性 = 攻撃
悪意を持った攻撃者は、同じ攻撃を仕掛けるのに異なる方法を用いる可能性があります。したがって、セキュリティ戦略は、脅威エージェント (脅威をもたらす要因) が悪用しそうなタイプごとにカスタマイズする必要があります。
脆弱性の評価
企業のセキュリティ ニーズを評価する作業には、既知の脅威に関連する脆弱性の判断を含める必要があります。この評価には、企業が保有する資産のタイプと、この資産に対してどんな種類の損害が及ぶ可能性があるかを確認する作業が伴います。
攻撃によって被る可能性のある損害を判断する
企業の環境内の資産が被るの可能性のある損害は、軽度のコンピュータ エラーから致命的なデータ損失まで、さまざまな規模のものが考えられます。システムが被る損害は、攻撃のタイプによって異なります。可能なら、テスト環境または試験環境を使って、さまざまなタイプの攻撃によって生じる損害を明らかにすると良いでしょう。そうすれば、セキュリティ担当者は、物理的損害を正確に評価することができます。どんな攻撃を受けた場合でも、損害のタイプや規模が同じとは限りません。たとえば、以下のようなテストを実行するとよいでしょう。
試験用システムでの電子メール ウイルスによる攻撃のシミュレーション。引き起こされる損害と、必要となる復旧処理を判断するための分析を行います。
従業員がソーシャル エンジニアリングによる攻撃を受けやすいかどうかを判断するテスト。思いもよらない従業員からユーザー名とパスワードを取得できるかどうかを試すというテストです。
データ センターに発生する障害の訓練またはシミュレーション。失われた生産時間と復旧に要した時間とを計測します。
悪意を持ったウイルス攻撃のシミュレーション。1 台のコンピュータを復旧するのに要した時間を計測します。この時間要因に、システム内で感染したコンピュータの台数を掛けて、ダウンタイムの長さまたは生産性の損失量を確かめます。
このプロセスにインシデント レスポンス チームを加えるのもよいでしょう。個人よりもチームの方が、発生したさまざまな損害のタイプをすべて発見できる可能性が高いからです。インシデント レスポンス チームは、セキュリティ インシデントの優先順位化と、セキュリティ インシデントを解決するためのエスカレーション パスを管理します。
攻撃の標的となり得る脆弱性または弱点を判断する
特定の攻撃の標的になる可能性のある脆弱性を発見できれば、現行のセキュリティ ポリシーと制御を修正するか、または新しいポリシーや制御を実装して、脆弱性を最小限に抑えることができます。攻撃、脅威、および方法のタイプを判断できれば、より簡単に既存の脆弱性を発見できます。これは侵入テストによって証明できます。
セキュリティ リスクの計画、スケジュール作成
弱点を悪用する各方法に対し、企業のセキュリティ計画は、予防と対処の両方の戦略を備えている必要があります。
予防戦略、すなわち攻撃される前に実施する戦略は、既存のセキュリティ ポリシーにおける脆弱性を最小限に抑え、危機管理計画を開発するのに役立つ一連の手順です。攻撃がシステムにもたらす損害と、攻撃の間に利用される弱点と脆弱性について判断を下すことで、対処戦略を開発する助けになります。
対処戦略、すなわち攻撃を受けてしまった後に実施する戦略は、セキュリティ担当者が攻撃による損害を評価し、損害を修復し (つまり、対処戦略において開発された危機管理計画を実装し)、経験を文書化してそこから学習し、できるだけ早くビジネス機能を復旧させるために役立ちます。
予防戦略
予防戦略は、攻撃を未然に防ぐために実施しておくべき、事前に定められた一連の手順です。手順には、攻撃がどのようにしてコンピュータ システムに影響または損害を与え得るかを考察し、悪用され得る脆弱性について調べる作業が含まれます (手順 1 と 2)。それらの評価手順において得られる知識は、攻撃を制御または最小限に抑えるためのセキュリティ ポリシーを実装する上で役に立ちます。以下は、予防戦略の 4 つの手順です。
攻撃がもたらす損害について判断します。
攻撃の標的となる脆弱性と弱点について判断します。
最初の 2 つの手順で定義された特定の攻撃に関して判断された脆弱性と弱点を最小限に抑えます。
実装すべき対策の適切なレベルを判断します。
これらの手順に従って各種の攻撃を分析することで得られる副産物があります。すなわち、さまざまな攻撃のうちで重なり合う要因が、パターンとして浮き彫りにされてくるのです。このパターンは、最大のリスクを引き起こす脆弱性の存在する領域を特定するのに役立ちます。
注 データ損失のコストとセキュリティ制御を実装するためのコストのバランスを取ることも必要です。これらのリスクとコストを比較検討することも、システムのリスク分析の一部です。
対処戦略
対処戦略は、攻撃を防ぐための予防戦略が失敗したときに実装されます。対処戦略では、攻撃を受けている最中または受けた後に行うべき手順が定義されます。この戦略は、攻撃において引き起こされた損害と悪用された脆弱性を確認するのに役立ちます。対処戦略はまた、攻撃が発生した原因、攻撃によってもたらされた損害を修復する方法、危機管理計画を実装する方法をも判断します。
予防と対処の戦略は、両者が一体となって機能し、攻撃とそれが引き起こす損害を最小限に抑えるためのセキュリティ ポリシーと制御を開発します。イベントの評価と文書化を行い、そこから学習する作業を支援するために、攻撃を受けている最中または受けた後に実施される手順の中に、事故対応チームを含めるべきです。
対処戦略には、以下の 3 つの手順が含まれています。
損害を抑える。
攻撃中に発生した損害を抑制することで、損害規模の拡大を抑えることができます。たとえば、環境にウイルスが侵入した場合、ウイルスに感染したサーバー台数を確認するよりも先に、サーバーをネットワークから切断することで、できるだけ早く損害を抑えようとするはずです。これは、可能な限り速やかに行う必要があります。
損害を評価する。
攻撃中に発生した損害について判断します。企業の業務をできる限り早く再開できるように、これは可能な限り速やかに行う必要があります。損害をタイムリーに評価することが不可能な場合、業務を正常に続行し、生産性を維持できるように、危機管理計画を実装すべきです。
損害の原因について判断する。
損害の原因を判断するには、攻撃目標とされたリソースは何か、および、アクセスを得たりサービスを混乱させるためにどんな脆弱性が悪用されたかを理解することが必要です。システム ログ、監査ログ、監査記録を見直します。これらの見直しを行うことで、システムのどこで攻撃が始まったのか、および、他のどんなリソースが影響されたのかを知る助けになる場合がよくあります。
損害を修復する。
正常な業務の復旧と攻撃中に失われたデータの復旧のために、できる限り迅速に損害を修復することが非常に重要です。企業の障害復旧計画とこの手続きは復元戦略を網羅している必要があります。復元と復旧のプロセスを処理し、復旧のプロセスにガイダンスを提供するために、インシデント レスポンス チームを利用できる態勢も整えておくべきです。このプロセスの実行中に、損害を隔離して拡大を防ぐために、危機管理策が執行されます。
危機管理計画
危機管理計画とは、システムが攻撃の侵入を受け、データまたはその他の資産に損害を与えた結果、正常な業務が妨害されたり生産性が低下した場合に備えて開発される代案です。システムをタイムリーに復元できない場合に、危機管理計画が実行されます。究極的には、データの可用性、完全性、機密性を維持することが目標です。つまり、危機管理計画とは "計画 B" に相当するものなのです。
危機管理計画は、攻撃と脅威の各タイプに対応するように作成すべきです。各計画には、攻撃を受けた場合に実行する一連の手順を含める必要があります。危機管理計画には、一貫して以下の対策を含めることが望まれます。
業務を停止させないために、誰が、いつ、どこで、何をしなければならないかを規定すること。
職員が最新の危機管理手順を常に把握しておけるように、定期的にリハーサルを実施すること。
バックアップ サーバーから情報を復元する作業を網羅しておくこと。
ウイルス対策ソフトウェア、サービスパック、修正プログラムの更新を含むこと。
基幹業務用のサーバーを別の場所に移動させる手段を用意すること。資金に余裕があれば、基幹業務用のサーバーの複製を緊急対策用の場所に集めておくことをお勧めします。 。
現行のセキュリティ ポリシーと危機管理計画についての事後分析を含めること。
以下に挙げる点は、危機管理計画の作成時に実施する必要のある、さまざまな評価タスクをまとめたものです。
脆弱性を最小化するためのあらゆる機会を利用できるように、企業のセキュリティ ポリシーと制御を評価します。評価においては、現行の緊急対応策、およびそれらの危機管理計画への統合に取り組む必要があります。
現行の緊急対応策と、それが業務に与える効果について評価します。
攻撃に対する計画的対応を準備して危機管理計画に組み込みます。このときに、どの程度の対応を準備すれば損害を限定し、攻撃がデータ処理業務に与える影響を最小限に抑えるのに十分であるかを検討します。
最新の文書と障害復旧テストを含め、バックアップ手順を評価して、この妥当性を判断します。評価の結果は危機管理計画に含めます。
障害復旧計画を評価して、これに伴う手順が、暫定的または長期にわたる操作環境を提供するのに十分かどうかを判断します。障害復旧計画には、企業が必要とするセキュリティのレベルをテストする手順を含める必要があります。これは、セキュリティ担当者が、復旧、暫定業務、元の処理サイトに戻る、または新サイトに移行するなどのプロセス全体を通じて、セキュリティを継続的に実施することが可能かどうかを判断できるようにするためです。
上記のタスクを実行するために必要な、さまざまな調査結果を示す詳しい文書を作成します。この文書には、以下の内容がリストアップされているべきです。
危機管理計画をテストするためのユーザー シナリオに関する詳細。
社外や不可欠なリソースから支援を得るなどの依存が危機管理計画に与える影響についての詳細。
復旧作業において守られる優先順位と、それを確立するために使われる根拠のリスト。
エスカレーション パスに関する詳細。危機管理計画が執行された場合、そこから発生するどんな問題も、最適な IT 操作担当者または業務担当者まで確実にエスカレートされるようにするためです。
実装
実装する制御の厳しさが度を越えないように気をつけてください。厳しすぎると、情報の可用性が問題となる場合があるからです。セキュリティ制御と情報へのアクセスの間で、入念にバランスをとることが必要です。
シミュレーション攻撃のテスト
セキュリティ戦略、テスト、テスト結果の見直しの最後の要素は、対処戦略と予防戦略が配備された後に行われます。テスト システムまたは試験用システムに対してシミュレーション攻撃を実施することで、さまざまな脆弱性が存在する場所を見極めることができます。そして、それに基づいて企業のセキュリティ ポリシーと制御を調整することができるのです。
これらのテストは、実運用の基幹業務システム上で実行すべきではありません。大災害となる可能性があるからです。しかし、予算上の制約で試験用またはテスト用 コンピュータがない場合には、シミュレーション攻撃自体が行えない可能性があります。テストに必要な資金を確保するために、経営陣は、攻撃のリスクと結果を認識すると共に、テストの手順を含め、システムの保護に必要となる可能性のあるセキュリティ対策について知っておくことが重要です。実装すべき最善のセキュリティ ポリシーと制御について判断するために、可能であれば、攻撃シナリオのすべてを物理的にテストし、文書化しておくべきです。
自然災害のようにテスト不能な攻撃もありますが、それでもシミュレーションは役に立ちます。たとえば、火災の場合は、サーバー ルーム内のサーバーすべてが被害を受けて失われたという設定でのシミュレーションが可能です。この障害シナリオは、管理者とセキュリティ担当者の対応をテストしたり、正常な業務再開までに要する時間を確かめるのに役立ちます。
テスト結果に基づいてセキュリティ ポリシーと制御を調整する作業は、反復的なプロセスです。このプロセスには決して終わりがなく、改善措置を実装できるように、定期的に評価および修正する必要があります。
作業
明確に定義されたエスカレーション パスと問題の管理は、インシデント レスポンス プログラムにとって不可欠な要素です。セキュリティ プロジェクトの初期段階でインシデント レスポンス計画を一貫して執行することにより、チームは、企業全体を通じて問題解決の有効性を高めることができます。結果を文書化してセキュリティ プロジェクトから学習することは、新しいプロジェクトによって前進しようとしている全員にとって有益です。作業プロセスにおいて学習されたこの種の教訓を集めることで、次のセキュリティ プロジェクトに向けた評価、開発、および実装タスクを簡単に完了できるようになります。
インシデント レスポンス
企業がセキュリティ計画のベスト プラクティスを完全に実装したいと願うなら、セキュリティ事故に対応するチーム (インシデント レスポンス チーム) の結成が必要です。システム セキュリティを確実にするための予防的な努力の中に、インシデント レスポンス チームの関与が必要です。予防的な努力には、以下が含まれます。
インシデント処理のガイドラインを策定する。
コンピュータ犯罪に対する法的処置に至るまでのエスカレーション パスと手続きを策定する。
インシデントとイベントに対応するためのソフトウェア ツールを識別する。
その他のコンピュータ セキュリティ ツールを研究および開発する。
トレーニングと啓発活動を実施する。
ウイルスに関する調査を実施する。
システム攻撃を研究する。
これらの努力により、インシデントの発生中および事前に問題に対処するのに役立つ知識が得られます。
セキュリティ管理者は、必要に応じて企業のためにセキュリティ監査を監視および管理する立場であることが必要です。セキュリティ管理者は、セキュリティ ドメインに対するセキュリティ ポリシーを実装する責任を負う権威者 (個人またはグループ) であることが必要です。セキュリティ管理者とインシデント レスポンス チームがこれらの予防対策を完了した後、管理者は、インシデントを処理する責任をインシデント レスポンス チームに移すべきです。
これは、セキュリティ管理者がチームの一員として引き続き関与してはならないという意味ではありません。ですが、セキュリティ管理者は常に仕事ができる状態だとは限らないため、インシデント レスポンス チームが自らインシデントを処理できなければならないのです。チームはインシデントに対応する責任を負うことになりますが、同時に、コンピュータまたはネットワークのセキュリティと関わりを持つ可能性のある非常事態を分析する働きにも加わるべきです。
文書化と学習
攻撃が発生したら、これを文書化することが重要です。文書化は、攻撃によって生じた損害 (ハードウェア、ソフトウェア、データ損失、生産性の損失)、攻撃の際に悪用された脆弱性と弱点、失われた生産時間の長さ、損害を修復するために実行した手順、修復作業のコストを含め、既知の攻撃範囲すべてを網羅すべきです。こうして作成されたドキュメントは、予防戦略を修正して将来の攻撃を予防し、損害を最小限に抑えるのに役立ちます。
危機管理計画の実装
危機管理計画が既に存在する場合、それを実装することで時間を節約し、業務を円滑に継続することができます。危機管理計画が存在しない場合は、前の手順で作成された文書に基づいて、適切な計画を立てます。
結果の吟味とシミュレーションの実施
攻撃を受けた後、または攻撃を防御した後に、企業のシステムと予防戦略に関して、結果の見直しを行います。見直しには、生産性の損失、失われたデータまたはハードウェア、攻撃から復旧するまでに要した時間に関する詳細を含める必要があります。シミュレーションはテスト環境内で実施すべきですが、最善の成果を得るには、生産環境に似た環境であることが望まれます。
ポリシーの有効性の見直し
発生した攻撃に対する防御にポリシーが存在する場合、見直しを行い、その有効性をチェックすべきです。ポリシーが存在しない場合は、将来の攻撃を最小限に抑えるか、または防止するために新しく起草する必要があります。
既存のポリシーの有効性が基準に満たない場合は、基準を満たすように調整すべきです。ポリシーの更新については、該当する管理職スタッフ、セキュリティ管理者、IT 管理者、およびインシデント レスポンス チームが調整する必要があります。ポリシーはすべて、企業の一般規則とガイドラインに準拠すべきです。たとえば、標準営業時間が、仮に午前 8 時から午後 6 時までとします。セキュリティ ポリシーは、更新または作成の際に、ユーザーがこの時間枠の間しかシステムにログオンできないように指定することが可能です。
セキュリティ リスク管理の統制
以下のセクションは、MSF と MOF を利用して今日使われているセキュリティ分析手法の中から、実績のある手法を参考にして書かれたものです。MSF は、エンタープライズ アーキテクチャとインフラストラクチャ展開のプロジェクト ライフ サイクルについて、計画、構築、安定化、および展開の各段階におけるガイダンスを提供します。MOF は、情報技術 (IT) 業務用の管理システムを開発または改善する方法についてアドバイスを提供します。セキュリティ リスク管理の統制 (SRMD) はここで詳しく定義されており、ご使用の環境に適用できる知識を得ることができます。SRMD は、詳細にわたるプロセスであり、どの脅威や脆弱性が特定の企業に対して潜在的に最も大きな影響を持つかを判断する上で役に立ちます。
セキュリティ リスクの識別
セキュリティ リスクの識別は、企業のセキュリティを評価する際の第一歩です。セキュリティ リスクを効果的に管理するには、プロジェクト チームが合意に達した上で、結果の分析とリスクに対処するための実行計画の作成に進むことができるように、明確に規定することが必要です。セキュリティ リスクの範囲は、プロジェクト チームが保護しようとするテクノロジに限られますが、チームは、テクノロジ、プロセス、環境、人を含め、セキュリティ リスクのあらゆる発生源に対処できるよう、十分に広い範囲に焦点を当てておくべきです。
自由に意見を出し合うことはセキュリティ リスクを識別する 1 つの方法ですが、インターネット上には、セキュリティ問題に関する多数の情報源があります。見直しを行えば表面に見られるセキュリティ リスクの攻撃に使える、既存の脆弱性に対する評価または侵入テストが、会社に既にあるかもしれません。
目標
セキュリティ リスクを識別する手順の目標は、企業の資産を脆弱なものとする既知のセキュリティ リスクのリストをチームが作成することです。このリストは、可能な限り包括的なものとし、テクノロジ、ビジネス、人、戦略など、エンタープライズ アーキテクチャのあらゆる面を網羅すべきです。
リスク管理とは、リスクを識別および分析して管理するための計画を立てるプロセスのことです。セキュリティ リスクは、システムの脆弱性および強さ、ならびに関連する脅威エージェントの判断に照らして、想定される脅威により、または想定される脅威の影響で予想される損失と定義されます。
情報の収集
セキュリティ リスクを識別する手順に対する情報の収集には、脅威に関して入手可能な情報を収集すること、弱点を悪用するために使われている現行の方法や技法のリストを作成すること、企業の資産に害を与えるために悪用される可能性のある、システムやポリシーの脆弱性を分析することが含まれます。脅威には、情報とシステムに対する外部からの潜在的危険の一切が含まれます。脆弱性とは、脅威に攻撃ポイントを与えるソフトウェア、ハードウェア、または手順上の弱点を言います。これらのリスクは、多くの場合、ビジネス慣習、アプリケーション、データ、インフラストラクチャ アーキテクチャを含む、企業環境に対するさまざまに異なる見解に由来します。
ポリシー、手順、ガイドライン、テンプレート、企業のテクノロジ インフラストラクチャの現状に関する情報という形式のセキュリティ計画に対して企業が取っている現在のアプローチ、およびチームの経験は、この手順への情報収集を決める上で役に立ちます。
セキュリティ チームは、資産そのものから得た情報、あるいは、脆弱性分析または侵入テストに使われたツールの成果から得た情報を参考にできます。セキュリティ問題に関するチームおよび利害関係者の認識についての情報を収集するためのグループ内でのディスカッション、さらには正式なセキュリティ ワークショップも、情報を得るのに役立つことでしょう。
リスクを識別する活動
チームは、セキュリティ リスクを識別する手順で自社が直面するリスクを明確に示すことにより、セキュリティ問題の明瞭な記述またはリストを作成しようとします。新しい状況に関連するリスクを識別するために、セキュリティ チームのワークショップまたはディスカッションを連続的に行うことは有用です。
テクノロジと環境は急速に変化するため、セキュリティ リスクの識別を一度限りの活動として扱わないことが重要です。このプロセスは、企業の業務のライフ サイクルで、定期的に繰り返し実施する必要があります。
構造化された手法
セキュリティ リスク管理のために、構造化された手法を使うことは極めて重要です。構造化された手法により、セキュリティ上の問題処理のためにチームの全員が一貫した機構を使用できるからです。この手順の中で脅威の分類を行えば、再現と測定が可能な一貫したアプローチを提供するのに役立ちます。
脅威の分類
セキュリティ チームは、脅威の分類 (カテゴリまたは分類学という呼び名もあります) をさまざまな目的に使うことができます。リスクを識別する際には、いろいろな領域で発生するセキュリティ リスクについて思考を働かせる刺激として使用できます。また、ディスカッション中には、分類は、類似する脅威をグループにまとめるための便利な方法となり、数の多い脅威を処理する作業の複雑さを軽減します。脅威の分類は、チームがプロジェクト全体を通じてリスクの状態を監視し、報告するための共通の用語を提供する目的にも使用できまう。
セキュリティ リスクのステートメント
セキュリティ リスクのステートメントとは、企業の既存のセキュリティ状態と、潜在的でまだ実現していないセキュリティの成果との間の因果関係を自然言語で表現したものです。
セキュリティ リスク ステートメントの最初の部分は "条件" と呼ばれており、ここでは何らかの害を及ぼす可能性があるとチームが考える既存の状態または潜在的脅威を記述します。リスク ステートメントの 2 番目の部分は "結果" と呼ばれており、ここでは資産に対する機密性、完全性、および可用性の好ましくない喪失を記述します。
2 つのステートメントは、不確かな (言い換えれば、確率が 100% 未満の) 関係、または因果関係を含意する "その場合 (then)" または "～となる可能性がある (may result in)" などの言葉でリンクされます。
以下に、このガイドで使われているリスク ステートメントを紹介します。
もし脅威エージェントが脆弱性を悪用するためにツール、テクニック、または手法を使うと、その場合、資産に対する (機密性、完全性、または可用性) の喪失が影響を及ぼす可能性があります*。*
セキュリティ リスク ステートメントは、リスク分析を通じて作成されます。リスク分析の手法には、定性的手法と定量的手法という 2 つのタイプがあります。定性的手法と定量的手法は、どちらかが他方よりも優れているというわけではありません。この 2 つはそれぞれ、リスクの識別作業を構造化するのに有益なツールとなります。定量的手法で収集した情報が、定性的手法のベースとなります。
.gif)
図 3.2: セキュリティの条件と結果のリスク ステートメント
拡大表示する 以下の手順は、上図のプロセスの各部を詳しく説明したものです。
.gif){kind=link}
各脅威について、条件と結果のリスク ステートメントを定義します。
脅威エージェントが脅威を発生させ、脆弱性を悪用した場合、攻撃はリスクにつながります。攻撃は、機密性、完全性、可用性を損なうことで、資産に損害を与える場合があります。したがって、攻撃は会社の損失となる危険性を発生させることになります。しかし、これらの危険性には、予防手段による対策が可能です。
脅威の確率 (TP) を割り当てます (最低 0% ～ 最高 100%)。脅威の確率とは、潜在的な脅威エージェントが環境に入ってくる確率のことです。
実効増倍率 (CF) を割り当てます (最低 1 ～ 最高 10)。実効増倍率とは、脅威が資産の弱点を潜在的に悪用しようとする度合いのことです。
労力 (E) をランク付けします (最低 1 ～ 最高 10)。労力とは、攻撃者が弱点を悪用するのに必要とされるスキルのことです。
リスク係数 (RF) を判断します。これは、実効増倍率を労力で除したものです。
式 (TP × RF) を使って脅威の頻度レベルを算定します。
脆弱性要因をランク付けします (最低 1 ～ 最高 10)。脆弱性の資産に対するリスクがどの程度の規模になるかを判断してください。
資産の優先順位 (AP) を判断します (最低 1 ～ 最高 10)。以下の基準に基づいて、会社の各資産について資産優先順位を判定してください。資産の評価は複雑なプロセスであり、仕上げるまでに時間が掛かる場合があります。資産評価の詳細については、この章の末尾に掲載されているこのテーマへのリンクを参照してください。企業の資産に優先順位を付ける作業は、利用可能な予算でいくつの資産の安全を確保できるかを判断する上で、極めて重要です。
社内の環境に基づいて、各資産に関する以下の質問への回答を調査してください。優先順位付きの資産リストを作成する助けになります。
その資産は会社にとってどんな価値がありますか?
その資産を維持または保護するのに、どれだけの費用が掛かりますか?
その資産は、会社に対してどれだけの利益をもたらしますか?
競争相手にとって、その資産はどの程度の価値があるでしょうか?
その資産を作り直すか、または復旧するのに、どれだけの費用が掛かりますか?
その資産の取得または開発には、どれだけの費用が掛かりましたか?
式 (VF × AP) を使って影響度 (IF) を算定します。
式 (脅威の頻度レベル × 影響度/1,000) を使って、危険要因 (EF) を算定します。危険要因は、表 3.2 の下に続く手順で単一損失予測値 (SLE) を計算するために、パーセンテージとして表現されます。
セキュリティ リスクのステートメントを生み出すための 2 部にわたる定式化プロセスには、企業内に現存する観察可能な (かつ潜在的に制御可能な) 条件で潜在的な結果を資産に連結させるという利点があります。チームがセキュリティ リスクの条件を識別することにのみ焦点を当てる別のアプローチでは、セキュリティ リスク管理の計画戦略を策定する際に、セキュリティ リスクの分析プロセスにおける後の段階で、チームがリスク条件を見直さなければならなくなる可能性があります。
注 セキュリティ リスク ステートメントは、純粋な "IF-THEN" ステートメントではありません。むしろ、可能性があるのに発生していないリスクの結果を探る事実のステートメントなのです。
仮定上の "IF-THEN" ステートメントを検討して代案を比較考察し、起こりえる事象、結果を列挙することで計画を策定することが役立つ場合があります。ただし、セキュリティ リスクを識別する段階での目標は、できる限り多くのセキュリティ リスクを識別することだけです。セキュリティ リスクの分析と管理の方法については、このプロセスの後の段階まで保留します。
作成するセキュリティ リスク ステートメントには、条件と結果が含まれていなければなりません。チームのメンバは、徹底的なセキュリティ リスク分析の一部として、基礎をなす共通の根本原因を追究するために、セキュリティ問題の条件の類似性を探して自然なグループ化を目指し、続いて、それぞれの関係をさかのぼって調べるべきです。根本原因が判明したら、関係を条件の根本原因から順に見直すことも有益です。これにより、セキュリティの脅威に関連する損失全体または失われた機会をより正確に認識するために、社外の資産に対する影響が調査されることになります。
セキュリティ リスクを識別する間は、同一の条件が、関連する複数の結果を生じることも珍しくはありません。しかし、その逆も当てはまる場合があります。すべて同一の結果を生じる複数の条件が存在する可能性もあるのです。場合によっては、企業のある領域で識別されたセキュリティ リスクの結果が、別の領域ではリスク条件となることもあります。セキュリティ リスク分析を行い計画を立てる間に、セキュリティ リスクどうしの依存と関係を考慮に入れて適切な決定を下すことができるように、これらの状況を記録しておく必要があります。
社内のセキュリティ リスクどうしの関係によっては、1 つのリスクを軽減することで、結果として、これに依存しているリスクのグループ全体を軽減することがあります。さらに、このようにして企業のリスク プロファイル全体が変化することもあります。セキュリティ リスク識別の初期段階でそれらの関係を文書化しておくと、根本原因または配下の原因に対処するためにリソースの調査を効率的に行うことができる、包括的で柔軟な、効果的なセキュリティ リスク計画を導くのに役立つ情報を提供できます。最も重要なセキュリティ リスクについては、識別の手順でこのような追加情報を取り込むことのメリットと、計画段階でその後の分析と優先順位の決定を迅速に済ませること、および依存関係と根本原因を再調査することとの間でバランスを取るべきです。
企業内の資産を評価する
資産の金銭的価値を算出することは、リスク管理における重要な部分です。事業の管理者は、多くの場合、資産のセキュリティ保護のために費やすべき費用と時間を算出する際に、資産価値を指標として用います。多くの企業は、障害復旧計画の一環として、資産価値のリストを保持しています。以下の評価モデルは、定量分析の手順 8 に述べた詳細に従って資産に優先順位を付ける方法を決定する際に役立ちます。
資産価値を適切に評価するには、以下の 3 つのプライマリ ファクタを計算します。
その資産が企業に対して持っている総合的な価値。直接金銭的に、資産の価値を計算するか、または見積もります。たとえば、通常 1 日 24 時間、週 7 日無休で営業している電子商取引の Web サイトがあり、顧客のオーダーから 1 時間当たり平均 2,000 ドルの利益を生んでいるとします。その場合、Web サイトの年間評価額は、販売収入の観点から 17,520,000 ドルであると自信をもって言明することができます。
資産を失った場合に直接的に被る金銭的な影響。上記の Web サイトが 6 か月にわたって利用不能になった場合、危険性は計算上、年間 .000685% となります。この危険性のパーセンテージに資産の年間評価額を掛けることで、この場合の直接帰属損失は 12,000 ドルになると予測できます。
資産を失った場合に間接的に被る事業上の影響。この例では、企業はそうしたインシデントで被る悪評判に歯止めをかけるために、10,000 ドルの広告費を支出すると見積っています。加えて、企業は年間売上の 1% の .01、すなわち 17,520 ドルの損失を予想しています。この場合、広告費の増額分と年間売上収入の損失分を合わせて、間接的な損失は総額 27,520 ドルになると予測できます。
表 3.1 資産評価の例
| 資産 | 価値 | 危険要因 | 直接的影響 | 間接的影響 |
|---|---|---|---|---|
| 電子商取引の Web サイト | 年間 $17,520,000 | 年間 6 時間、または .000685 | $12,000 | $27,520 |
重大な脅威の包括的リスト。
各脅威が発生する確率。
企業が 12 か月間で 1 つの脅威によって被る可能性のある損失の見込み。
推奨される予防手段、対策、行動。
アウトプット
セキュリティ リスクを識別する作業から得られる最小限のアウトプットは、セキュリティ チームが相対したリスクの明瞭ではっきりとした一致したステートメントであり、これは、セキュリティ問題のリストとして文書化されます。表の形になったセキュリティ問題のリストは、セキュリティ リスク管理プロセスの次の段階である分析にとって、主要な情報です。
セキュリティ リスクの識別手順では、根本原因と波及効果の識別、影響を受ける当事者、所有者など、そのほかにも有用な情報が大量に得られることがよくあります。
セキュリティ チームが作成するセキュリティ リスク ステートメントや、根本原因と波及効果の情報を表形式で記録しておくことは、良い習慣だと考えられています。社内で使える明確な分類学があれば、セキュリティ リスクを脅威ごとに分類するための追加情報も、セキュリティ リスク情報を使ってセキュリティの知識ベースを構築または使用する際に役立つ場合があります。
セキュリティ チームがリスク識別プロセス中に記録するとよい情報には、そのほかに以下のものがあります。
制約
状況
仮定
要因
セキュリティ リスクどうしの依存関係
関連する課題
事業資産の所有者
チームの懸念
セキュリティ リスクの分析と優先順位の決定
セキュリティ リスクの分析と優先順位の決定は、セキュリティ評価のプロセスにおいて 2 番目に大きな手順です。セキュリティ リスクの分析には、意思決定をしやすくするために、セキュリティ リスク データ (脅威、弱点の悪用、脆弱性) を変換して 1 つの形式の中にまとめる作業が含まれます。セキュリティ リスクの優先順位を決定することで、セキュリティ チームのメンバは、最も重要なセキュリティ リスクに必ず最初に取り組むことができます。
この手順で、セキュリティ チームは、セキュリティ リスクの識別手順で作成したセキュリティ問題のリスト項目を検討して優先順位を決定し、セキュリティ アクション プランを作成します。
セキュリティ アクション プランにおいて、企業のセキュリティ チームは、セキュリティ問題のリストを用い、環境内の課題の管理を目的とする特定の戦略を執行する計画を立て、ここにリソースを集中させることができます。
チームはまた、行動に移す優先順位が低いためにリストから外すことが考えられるセキュリティ課題があれば、それがどれなのかを識別することができます。このセキュリティ実装段階が完成に近づき、企業の環境が変化するにつれて、セキュリティ リスクの識別とセキュリティ リスク分析を繰り返して、セキュリティ アクション プランの有効性を確認しなければなりません。新しいセキュリティ リスクが発生したり、逆に、優先順位が低くなった古いセキュリティ リスクが削除されたり、割引かれたり、"非活性化" されたりすることもあります。
目標
セキュリティ リスクの分析手順における第 1 の目標は、セキュリティ問題の影響を軽減するために、セキュリティ アクション プランにおいてそれらに優先順位をつけ、企業のリソースを集中的に注ぐだけの重要性を持つのはどれなのかを判断することです。
情報の収集
リスク分析プロセスの間、チームは自らの経験に頼り、また、セキュリティ リスク ステートメントに関する他の関連ソースから得た情報を参考にします。未処理のセキュリティ リスク ステートメントを優先順位付きのマスタ リスク リストに変換する方法についての情報は、企業のセキュリティ ポリシーと手続き、業界知識のセキュリティ データベース、脆弱性分析、セキュリティ シミュレーション、および個々の資産所有者から取得してください。
セキュリティ リスクの分析作業
セキュリティ アクション プランにおける優先順位を決める作業のために、定性的および定量的技法が多く存在します。セキュリティ リスク分析のための簡単な技法の 1 つは、確率および影響という広く受け入れられている 2 つのリスク コンポーネントから得られるコンセンサス チーム予測を使う方法です。これらの予測値を掛け合わせて、リスク 危険性と呼ばれる 1 つの測定基準を算出することができます。
セキュリティ リスクの確率
セキュリティ リスクの確率は、セキュリティ リスク ステートメントのリスク条件の部分で記述される状況が実際に発生する可能性の尺度です。リスク ステートメントには、以下で記述する部分のように、会社にとって時間やお金では測れない要素が含まれる場合があります。
"もし、脅威エージェントが、脆弱性を悪用するためにツール、テクニック、または手法を使うと..."
脆弱性に乗じるために弱点を悪用する脅威は、リスク ステートメントの条件の部分です。特定のタイプの脅威 (特に脅威が自然災害である場合) では、既知の脆弱性や弱点が悪用されることはありません。
リスクのランク付けのために、リスクの確率に数値を使うことをお勧めします。セキュリティ リスクの確率がゼロ以下の場合、脅威はセキュリティに対して問題をもたらしません。確率が 100% であれば、セキュリティ リスクは確実であり、既知の問題である可能性があります。
業界または企業のリスク データベースは、多数のプロジェクトのサンプルに基づいており、既知の確率予測には役立つ場合がありますが。周知のとおり、確率は予測と適用が極めて困難です。ただし、プロジェクト チームは自然言語の用語で経験を表現できるため、以下の表に表現されるように、これらの用語を確率の数値範囲に割り当て直すと役に立ちます。
表 3.2 リスクの確率
| 範囲 | 計算値 | 表現 | スコア |
|---|---|---|---|
| 1% ～ 14% | 7% | 極めて確率が低い | 1 |
| 15% ～ 28% | 21% | 低い | 2 |
| 28% ～ 42% | 35% | ありそうでない | 3 |
| 43% ～ 57% | 50% | 50 – 50 | 4 |
| 58% ～ 72% | 65% | おそらく | 5 |
| 73% ～ 86% | 79% | 可能性が高い | 6 |
| 87% ～ 99% | 93% | ほとんど確実 | 7 |
| スコア | 金銭的な損失 |
|---|---|
| 1 | $100 未満 |
| 2 | $100 ～ $1,000 |
| 3 | $1,000 ～ $1 万 |
| 4 | $1 万 ～ $10 万 |
| 5 | $10 万 ～ $100 万 |
| 6 | $100 万 ～ $1,000 万 |
| 7 | $1,000 万 ～ $1 億 |
| 8 | $1 億 ～ $10 億 |
| 9 | $10 億 ～ $100 億 |
| 10 | $100 億超 |
| 確率 影響 | 低 = 1 | 中 = 2 | 高 = 3 |
|---|---|---|---|
| 高 = 3 | 3 | 6 | 9 |
| 中 = 2 | 2 | 4 | 6 |
| 低 = 1 | 1 | 2 | 3 |
| 優先順位 | 条件 | 結果 | 確率 | 影響 | 危険性 |
|---|---|---|---|---|---|
| 1 | ウイルスが 電子商取引 Web サイトに感染 | サーバーの再構築に 6 時間を要した。 | 80% | 3 | 2.4 |
| 2 | 新しいプログラミング言語用のコーディング基準がない | 潜在的にセキュリティの脆弱性が大きい状態で出荷。 | 45% | 2 | 0.9 |
| 3 | 仕様書がない | 一部の製品セキュリティ機能が実装されなかった。 | 30% | 2 | 0.6 |
重要性が極めて高いアクションの識別。
依存関係の強調。
リスクがもたらす危険性の計算に使う方法は、リスク管理計画の中に慎重に文書化しておくべきです。また、さまざまな要因の重要性を比較検討しつつ、計算にチームの意図が確実かつ正確に反映されるように配慮する必要があります。
資産に対する脅威を識別するために、リスク分析を行います。そして、識別された各脅威について、リスク ステートメントを作成します。リスク ステートメントは、脅威に関する情報と、脅威が万一発生した場合の、脅威の影響に関する情報を組み合わせます。
表 3.6 マスタ セキュリティ リスク リストの内容
| 項目 | 目的 | 状態 |
|---|---|---|
| セキュリティ リスクのステートメント | リスクを明確に示す。 | 必須 |
| 確率 | 脅威が発生する可能性を定量化する。 | 必須 |
| 影響 | 損失の深刻度または機会コストの大きさを定量化する。 | 必須 |
| ランク付けの基準 | 重要な尺度を選ぶ。 | 必須 |
| 優先順位 (ランク) | アクションに優先順位を付ける。 | 必須 |
| 所有者 | リスク アクション プランに対するフォロースルーを確実に行う。 | 必須 |
| 軽減計画 | 予防策を説明する。 | 必須 |
| 危機管理計画とトリガ | 是正策を説明する。 | 必須 |
| 根本原因 | 効果的な介入計画を導く。 | 必須 |
| 下流効果 | 適切な影響の予測を保証する。 | 省略可能 |
| コンテキスト | 浮上するリスクにおけるチームの意図を理解するために、背景情報を文書化する。 | 省略可能 |
| 実装のための時間 | リスク制御が一定の時間枠内で実装されることの重要性を理解する。 | 省略可能 |
| 項目 | 目的 |
|---|---|
| セキュリティ リスクの識別名 | 報告または追跡を目的に、チームがリスクを一意に識別するために使う名前。 |
| セキュリティ リスクのソース | セキュリティ リスクの発生元となる基礎領域の広い分類。セキュリティ リスクの反復的な根本原因を求めるべき領域を識別するために使われます。 |
| セキュリティ リスクの条件 (脅威/弱点の悪用) | 損失につながる可能性のある既存の条件を説明する語句。これは、セキュリティ リスク ステートメントの最初の部分を形成します。 |
| リスクの結果 (脆弱性/資産への影響) | リスクが結果を生んだ場合に発生するであろう損失を説明する語句。これは、セキュリティ リスク ステートメントの 2 番目の部分を形成します。 |
| セキュリティ リスクの確率 | リスク条件が実際に発生し、損失が生じる可能性を表す、ゼロよりも大きく 100% よりも小さい確率。 |
| 資産への影響の分類 | リスクが発生する可能性のある影響のタイプの広い分類。 |
| 資産の危険性 | リスクの総合的な脅威。実際に損失が発生する可能性と潜在的損失の大きさのバランスを取ります。チームはリスク 危険性を使ってリスクのランク付けを行います。危険性は、リスクの確率と影響を掛け合わせて算出します。 |
| リスクのコンテキスト | セキュリティ リスクの状況を明確にするのに役立つ追加の背景情報を含む段落。 |
| 関連するセキュリティ リスク | 相互依存するリスクを追跡するためにチームが使うリスク識別名のリスト。 |
確率を下げるために、脅威の条件 (脅威、弱点の悪用) に対処する。
症状ではなく、セキュリティ問題の根本原因を探す。
資産影響を最小限に抑えるために、資産結果 (脆弱性と資産) に対処する。
セキュリティ問題の根本原因を判断し、続いて、それに影響を与え得る類似した状況、または、同じ原因から発生するその他の資産を探す。
セキュリティ リスクの間で、脅威、弱点の悪用、脆弱性からの相互作用と依存関係に気をつける。
さまざまなプロジェクト リスク条件を減らすために、いくつかの計画アプローチがあります。以下に、その例を挙げます。
チームが制御できるプロジェクト リスクについては、脅威の条件の確率を下げるのに必要なチーム リソースを用います。これは、予防型のセキュリティ リスク管理手法です。
チームの管理が及ばないところにあるプロジェクト リスクについては、潜在的な次善策を見つけるか、または介入権限を持つ個人にセキュリティ リスクを移管 (エスカレート) します。
チームの管理が及ばないところにあるプロジェクト リスクで、移管することも、予防的に管理することもできないものについては、チームは、資産に対する影響または資産の損失を最小限に抑えるための計画を策定すべきです。これは、対処型のセキュリティ リスク管理手法です。
セキュリティ アクション プラン
セキュリティ アクション プランの策定には、主に 6 つの手法があります。チームは、セキュリティ リスクのアクション プランを立てる際に、ここに簡潔にリストアップした各項目に関連する質問を検討すべきです。各手法は、以下にさらに詳しく定義されています。
調査 : セキュリティ チームは、このセキュリティ リスクについて十分に知っていますか? アクションを決定する前に、脅威、弱点の悪用、脆弱性、または資産の特性に対する判断の精度を高めるために、これらのコンポーネントをさらに調査する必要がありますか?
容認 : 危機管理計画を作成する以外は、リスクを受け入れ、先行策は何も講じないつもりですか? 資産の ALE 値が資産の値を下回り、ビジネスへの影響が小さいなら、リスクを受け入れることを検討してもよいでしょう。セキュリティ リスクが実際に発生した場合でも、企業は結果を受け入れることができますか?
回避 : リスクのソース、またはリスクに対する資産の危険性を消去することで、リスクを避ける方法がありますか? これはリスクに対する極端な反応であり、リスクの影響が資産から得られる便益を上回る場合にのみ実行されるべきです。企業は、実装プロジェクトの範囲を変更することで、リスクを回避することができますか?
移管 : リスクに対する責任を保険や管理サービス会社など、別の当事者に部分的に転嫁することで、リスクを移管することは可能ですか? リスクの移管は、セキュリティにとって益々重要な戦略となりつつあります。企業は、セキュリティ リスクを別のグループ、チーム、個人、または外部組織に移管することで、それを避けることができますか?
軽減 : リスクに対する資産の危険性を予防的に変えたり、資産に対する企業の依存度を変えることによって、リスクを軽減することができますか? ALE が資産価値を下回り、前もって予防的な行動を取ることが可能な場合には、リスク軽減戦略を検討してください。軽減は、主要なリスク管理戦略です。脅威の確率を低下させたり、またはセキュリティ リスクの資産影響を小さくするために、何かできることがありますか?
危機管理計画 : 計画されたインシデント レスポンスによって、影響を小さくすることが可能ですか? 適切に構築された危機管理計画は、リスクが問題またはインシデントとなった際に、影響を弱めることができます。セキュリティ インシデントの後に、トリガを使って危機管理計画を適切に執行することができます。
調査
セキュリティ プロジェクトにおけるリスクの多くは、不完全な情報を取り巻く不確実性と関係しています。知識不足と関係のあるセキュリティ リスクは、先に進む前に、脅威、弱点の悪用、脆弱性、または資産そのものについての知識を深めることによって、効果的に解決または管理できることがよくあります。
たとえば、チームには、セキュリティ実装計画を完了する前に、脆弱性の評価を行ったり、セキュリティの反復訓練を実施して、セキュリティの侵害に対応するチームの技能、または環境について、知識を深めておくという選択が可能です。チームが、リサーチを行うという決定を下した場合、セキュリティ アクション プランには、テスト対象領域、回答すべき問題、また、スタッフの配置、必要な設備など、適切なリサーチ提案を含めるべきです。
容認
セキュリティ リスクの中には、特に自然災害と関連する脅威などのように、効果的な予防や是正策を使って介入することが事実上不可能なものがあります。したがって、セキュリティ チームは、セキュリティ問題を単に受け入れるだけになる場合があります。しかし、このような場合でも、予防型の軽減計画または対処型の危機管理計画を策定すべきです。セキュリティ リスク監視の責務を継続するには、適切なリソースと追跡測定基準を確立する必要があります。
注 容認は、"何もしない" 戦略ではありません。企業のセキュリティ アクション プランの中に、チームがリスクを受け入れることを決めた根拠を文書化しておくべきです。
回避
セキュリティ リスクが、評価の範囲を変えることで極めて容易に制御できるものとして識別される場合があります。そのような方法で評価の範囲を変えてセキュリティ リスクを全部 "排除" することを回避テクニックと言います。これらの場合、セキュリティ アクション プランには、その決定の根拠を文書化して記録しておくべきです。また、セキュリティ実装計画は、設計の変更や範囲変更のプロセスが必要となった場合に、必ず更新しなければなりません。
移管
時には、管理を目的に、セキュリティ リスクを企業外の別の組織に移管することも可能です。セキュリティ リスクが移管される例として、以下が挙げられます。
保険。
より優れた専門知識を持つ外部のコンサルタントを使う。
サービスをアウトソーシングする。
セキュリティ リスクを移管しても、リスクがなくなったわけではありません。一般に、移管戦略によって新たなセキュリティ リスクが生まれ、やはり予防型の管理が必要になります。しかし、リスクを移管することで、脅威は、より許容しやすいレベルに下がります。たとえば、IT インフラストラクチャをアウトソーシングすれば、セキュリティ リスクをセキュリティ チームの外に移管することができます。しかし、企業が保護しようとしている資産の機密性に関して、新しいセキュリティ リスクを生み出す可能性があります。
軽減
セキュリティ リスクの軽減には、セキュリティ リスクの発生を予防すること、または影響や結果を許容レベルまで低下させるための予防的行動を取ることが含まれます。軽減によってセキュリティ リスクを予防的に管理することは、回避の手法とは異なります。これは、セキュリティ リスクを回避する場合には、評価の範囲を変えることで、許容できないリスクのある活動が発生するのを避けるのに対して、軽減の場合は、脅威を予防して許容できるレベルに抑えることに焦点が当てられるためです。
セキュリティ リスクを軽減することの主な目標は、脅威が発生する確率を下げることです。たとえば、有力なパスワード ポリシーを使えば、外部のユーザーがパスワードを入手して給与体系にアクセスする確率を下げることになります。
危機管理計画
セキュリティ リスクの危機管理計画には、攻撃を予防する努力が効を奏さなかった場合にアクティブ化できる 1 つまたは複数のインシデント レスポンス計画を立てる作業が含まれます。軽減計画を持つものも含め、セキュリティ リスクのすべてを対象に危機管理計画を作成しておくことは、良い習慣です。それは、単純な理由によります。企業が予防型のセキュリティ計画をどんなに巧みに策定しても、未知の脅威、弱点の悪用、または脆弱性はやはり存在していて、資産に害を与える可能性があるのです。
セキュリティの危機管理計画では、脅威が発生した場合に何をすべきかを示すと同時に、資産影響を最小限に抑える方法と結果を重視する必要があります。チームは、インシデント レスポンス計画と事業再開計画を作成し、攻撃中と攻撃後に効果的な対応が確実にできるよう備えておくべきです。
遭遇する可能性のある脅威、弱点の悪用、脆弱性のタイプに基づいて、危機管理計画のトリガ値を確立することができます。セキュリティの場合、トリガは通常イベントです。つまり、そのイベントを収集して、適切なレスポンス チームに危機管理計画を行動に移すよう通知する方法が必要なのです。
危機管理計画のトリガには、以下の 2 つのタイプがあります。
日付トリガ : 日付トリガは、日付を中心に構築されます。一般に、その時点までに何かが発生しなければならない最新の日付が使われます。日付は、何らかのセキュリティ対策を実行すべき時を指定する企業のガイドラインまたは法的な指針に従って設定されることがあります。
しきい値トリガ : しきい値トリガは、測定またはカウントが可能なものに依存します。たとえば、侵入検出システムによって捕えられた監査済みイベントは、危機管理計画について何らかの検査と、場合によってはアクティブ化を行う正当な理由になります。
危機管理計画の執行に遅延が一切生じないように、セキュリティ チームが、危機管理計画のトリガとその関連する測定基準について社内の他のチームと合意しておくことが重要です。
活動のスケジュール作成
セキュリティ リスク管理と制御活動のスケジュール作成は、プロジェクトの活動全般のスケジュール作成に関して MSF が推奨する標準的な手法と変わりません。セキュリティ チームは、セキュリティの改善または制御活動がセキュリティ リスクの評価と管理の予想される部分であることを理解しておく必要があり、そのことは重要です。
アウトプット
セキュリティ アクション プランを作成することで得られるアウトプットには、上記の 6 つの手法のうちの 1 つを用いて、予防および対処の両方のタイプのセキュリティ管理計画を含めるべきです。この 6 つとは、危機管理計画の調査、容認、回避、移管、軽減、および策定です。これらのセキュリティ計画を実装するための具体的なタスクは、標準的なセキュリティ実装スケジュールの中に組み込む必要があります。テクニカルな環境に対して何らかの変化があれば、これを機能仕様の中に文書化する必要があります。
セキュリティ アクション プランとスケジュールは、コミットされているリソースと範囲における調整を説明し、結果として、セキュリティ チーム メンバが完成する個々のタスクを指定する一連のセキュリティ アクション項目になることが必要です。マスタ セキュリティ リスク リストは、予防型 (軽減) および対処型の危機管理計画に含まれる追加情報を反映するように更新する必要があります。セキュリティ リスク管理計画は、セキュリティ リスク アクション フォームの中に 1 つのドキュメント形式でまとめておくと便利です。
セキュリティ実装スケジュールとセキュリティ実装計画を更新する
セキュリティ実装計画には、予防型および対処型の両方の計画を含める必要があります。セキュリティ実装計画を更新する際には、以下の点を検討します。
リスク発生の確率と影響を含むリスク条件
リスクが発生する確率の上昇、またはリスクの金銭的な影響の低下など、条件が変化した場合には、チームはリスク管理計画を更新しなければなりません。
軽減努力の有効性
チームは、軽減努力の一部が有効性に乏しいことに気付く場合があります。これは多くの場合、実装したテクニカル ポリシーがビジネス プロセスと競合していることが原因です。従業員が、事業目標達成のためにテクニカル ポリシーを回避することで、これを無効にしてしまうこともあります。
危機管理計画の有効性とトリガ
やがて、リスク管理計画において識別されたセキュリティ リスクが実際に発生する時が来ます。セキュリティ インシデントの後に、危機管理計画がどの程度有効だったか、また、対応開始のためのトリガが有効だったかどうかを判定します。
チームは、以下の 3 つの時間枠において、セキュリティ リスクを監視する必要があります。
リアルタイム : コンピュータとネットワーク デバイスを継続的に監視し、リスクに基づいて予定の判断を下すために、侵入検出ソフトウェアなどのアプリケーションを使います。
定期的 : 隔月または年 4 回など、定期的にリスクの評価を行います。
臨時 : 不定期でリスクの評価を行います。臨時の監視は、多くの場合、大規模なセキュリティ インシデントが発生するか、またはネットワークが変更された場合に、これに応じて実施されます。
セキュリティ リスク改善策の開発
対策と作業手順の開発は、企業のセキュリティ戦略にとって不可欠です。セキュリティ リスクは、テクノロジ ハードニング プロセスを通じて、または、企業全体にわたるポリシーを開発することによって、予防的に管理できます。
多くの場合、オペレーティング システム、アプリケーション、またはデータベースの既定インストールでは、IT 管理者またはソフトウェア開発者にとって扱いやすいように、セキュリティ設定を緩めてあります。これらのテクノロジが生産展開されるまでは、展開されるテクノロジは "ハードニング プロセス" の一部でなければなりません。メンバ サーバーのハードニングと特定サーバーの役割の詳細については、このガイドの第 6 章「Base Windows 2000 Server のハードニング」および第 7 章「特定サーバーの役割のハードニング」を参照してください。
サーバーのハードニング プロセスには、既定のセキュリティ設定と不要なソフトウェア コンポーネントの削除が含まれる場合があります。IT 担当者は、ソフトウェアとセキュリティ修正プログラムの最新版をインストールするために、既知のテクノロジの脆弱性、および弱点を悪用するために使われる現行の方法についても、常に最新情報を知っておく必要があります。
セキュリティ戦略の開発プロセスには、実現していないセキュリティ リスクの追跡と報告を行うためのシステム、ポリシー、手続きの作成も含まれます。これは、テクノロジ インフラストラクチャにおける予防策の確実な機能を支援すると同時に、新しいポリシーや手続きの有効性を確認します。
また、即対応を要する不審なイベントまたは潜在的な脅威をキャッチするための報告制度も設けるべきです。セキュリティ リスクの追跡のための自動システムに加えて、手動のプロセスも使えます。セキュリティ リスクを追跡することで、プロジェクト チームは、計画を調整して、新しいセキュリティ リスクに対応することができます。
追跡は、リスク アクション プランの監視機能です。追跡は、セキュリティ アクション プランを効果的に実装するために不可欠です。追跡により、予防策または危機管理計画をタイムリーに、プロジェクト リソースの制約の範囲内で確実に完了することができます。リスク追跡の間にチームが実施する主要な活動は、リスク測定基準を監視して、計画されたリスク アクションが発効するよう、イベントが確実にトリガされるように目を配ることです。
目標
改善策の開発プロセスの目標は、必要なアーキテクチャ上の変更、および、手続きにおける新しいプロセスや変更を文書化することです。
情報の収集
セキュリティ リスク改善策の開発プロセスに対する主要な情報は、企業のセキュリティ リスクにとっての脅威、弱点の悪用、および脆弱性を特定する具体的なセキュリティ改善策と危機管理計画を含むセキュリティ リスク計画です。改善策の開発では、執行される可能性のある危機管理計画のための確認されたトリガを監視する目的で、システムとプロセスを開発することが要求されます。
開発活動
セキュリティ リスク改善プロセスの開発活動は、一般的なインフラストラクチャ展開プロジェクトの開発活動に似ています。たとえば、システムの修正プログラム用の変更管理に使う手法の開発です。インフラストラクチャに対する設計変更は、機能仕様の中に文書化する必要があります。また、新しいセキュリティ要件に対応するように、ポリシーと手続きの修正が必要な場合があります。このプロセスの間に、監視と監査の機能を提供するために新しいシステムが実装された場合、これらのシステムの設計と管理も指定する必要があります。
ポイント イン タイム トリガ 測定基準が割り当てられ、継続的に追跡される可能性のあるプロジェクト 測定基準の例として、以下を挙げることができます。
アプリケーション、サービス、またはオペレーティング システムを対象とする未解決のオープン セキュリティの掲示板。
インフラストラクチャ エンジニアが週ごとに記録する平均残業時間。
週ごとの要件改訂または管理変更の要請の件数。
リスクの状態を報告する手続きも、この段階で策定すべきです。リスク報告は、チーム自身でも使用でき、プロジェクト委員会への外部報告としても使えるものでなければなりません。
セキュリティ チームに関して、通常のリスク状態報告では、各リスクに適用できる以下の 4 つのリスク管理状況を検討する必要があります。
リスクは解決済みで、リスク アクション プランを完了しつつあるところ。解決済みのリスクはすべて終了しているものとして文書化し、セキュリティ アクション プランの中に記録保管すべきです。
リスク アクションが一貫しており、リスク管理計画のスケジュールどおりに実施されている。
一部のリスク アクションがリスク管理計画と一致していない。この場合は、是正策を定義し、実装する必要があります。
1 つまたは複数のリスクに関して、リスクの状況が大幅に変化している。この場合は、リスク アクション プランを練り直す必要があります。
プロジェクト委員会をはじめとするプロジェクトの利害関係者への外部報告に関しては、チームはトップ リスクを報告し、続いて、リスク管理アクションの状況をまとめなければなりません。リスクの以前のランキングと、各リスクがトップ リスク リストに掲載されていた回数を示すことも役に立ちます。
リスクを管理するためにプロジェクト チームが行動を起こす時に、プロジェクトの総合リスク 危険性が許容可能なレベルに近づき始めるべきです。
アウトプット
改善段階のアウトプットは、セキュリティの変化の仕様であり、それらは以下の場所で更新する必要があります。
機能仕様
作業方針および手続き
更新されたセキュリティ実装計画
更新されたセキュリティ実装スケジュール
セキュリティ改善策のテスト
セキュリティと改善策のテスト手順は、セキュリティ計画の有効性が確実にテストされるように作られています。チームは、セキュリティ アクション プランの有効性を判断するために、予防型と対処型の両方の戦略 (対策と手順) のテストと関連のある活動を積極的に実施すべきです。
新たにできた対策、ポリシー、手順の有効性を測定するために、それらが対処するように意図されている各リスクを検討すべきです。続いて、企業内の脅威、弱点の悪用、脆弱性、資産に関して、各リスクについて関連のある戦略をテストします。
セキュリティ リスク改善策のテストに基づいて、効果、有効性、およびセキュリティ トリガ イベントに対する反応性を改善するために、セキュリティ アクション プランの修正が必要になる場合があります。
セキュリティ テスト計画の執行によって学習された成果と教訓は、続いてテスト 文書に組み込まれ、企業のセキュリティに関する知識ベースの一部となります。これらの計画の有効性を判断するには、テスト中にできる限り多くの情報を取り込むことが重要です。
目標
セキュリティ改善策のテスト プロセスの目標は、プロジェクト チームがトップ セキュリティ リスクを対象に作成したさまざまなセキュリティ計画の有効性をテストすることです。セキュリティ アクション プランでは、以下について評価とテストを実施する必要があります。
危機管理/軽減計画の有効性。
危機管理計画のトリガまたはイベントと関連するセキュリティ測定基準。
テクノロジ対策。これには、正しく実装されたかどうかを判断するための 2 回目の脆弱性評価が含まれる場合があります。
情報の収集
セキュリティ リスク制御プロセスに対する情報は、各セキュリティ問題への対処に役立つように、プロジェクト チームのメンバが行うべき活動を詳述するセキュリティ アクション フォームです。テストの結果には、企業のセキュリティ要件にとって適切かどうかを判断するために、予防型および対処型の計画の有効性が文書化されている必要があります。
テスト作業
セキュリティ改善策のテスト作業では、策定された各対策とインシデント計画の有効性を測定すべきです。新しい対策が原因で発生する可能性のある新しい 2 次的なセキュリティ リスクを検出するために、セキュリティ リスク改善策のテストを継続的に実施することが重要です。
アウトプット
セキュリティ改善策のテスト手順から得られるアウトプットは、結果をまとめた文書、または、"問題データベース" です。これは、自社用のセキュリティ アクション プランの実装を完了させる方向に向かって、文書の進展を支援することができます。また、テスト チームが、どのセキュリティ戦略が役立ったか、どれが役に立たなかったか、および、新しく作られたポリシーと手続きの有効性について要約を作成すれば、役に立ちます。
セキュリティ知識を取り込む
セキュリティの評価と実装のプロセスで得られた知識は、将来使えるように取り込むべきです。これは、セキュリティ リスク評価プロセスの 6 番目で最後の段階であり、セキュリティ リスク管理活動に、戦略的、企業的、組織的な視点を加えます。
最も重要なのは、このセキュリティ評価中に策定された対策、ポリシー、手続きを将来のプロジェクト チームが再利用できるように取り込むことです。企業が将来の IT イニシアティブに着手する時に、それらのプロジェクトでは、実装される新しいソリューションが確実に安全なものとなるよう、評価によって得られた知識を活用することができます。
セキュリティ リスクの評価によって学習された知識は、最新情報を提供できるように、タイムリーな形式で取り込むべきです。セキュリティに関する知識の取り込みは、主に以下に挙げる 3 つを目的で実行されます。
学習した教訓の取り込み。特に、セキュリティ リスクの識別と成功した軽減戦略に関するもの。これは、他のチームにとって役立つために行うもので、そのようにして、セキュリティの知識ベースを増やしていきます。
企業がインシデント レスポンス計画を執行し、他の領域で再使用する能力の点で、作業の迅速性の効果を高める。
チームからフィードバックを取り込むことで、セキュリティ リスクの評価プロセスを改善する。
セキュリティ リスクの学習を取り込む
セキュリティ リスクの分類は、以前の経験で学習した教訓が将来のセキュリティ リスク評価を実施するチームで確実に利用できるようになる、有力な手段です。以下に挙げるのは、以下のリスク分類を使って頻繁に記録される学習内容の 3 つの主な側面です。
新しいリスク : チームが以前にセキュリティ リスクとして確認されたことのない問題に遭遇した場合、何らかの兆候 (脅威、弱点の悪用、脆弱性、またはその他の指標) がこのセキュリティ リスクを予測していなかったかどうかを検討する必要があります。将来、セキュリティ リスクの状態を確認しやすくするために、既存のセキュリティ リスク リストを更新する必要のある場合があります。あるいは、チームは既存のセキュリティ知識ベースに追加すべき新しいセキュリティ リスクを確認していた可能性もあります。
成功した軽減戦略 : セキュリティ リスクの軽減に成功した戦略と不成功に終わった戦略の両方の経験を取り込みます。標準的なセキュリティ リスクの分類を使うことで、関係するリスクをグループ化する有意義な方法が利用できます。この結果、チームは、過去に成功したセキュリティ リスク管理戦略の詳細を容易に発見できるのです。
成功した危機管理戦略 : 危機管理計画が、ある資産について特定タイプの脆弱性を保護することで成功した場合には、別の資産の保護にも役立つ場合があります。
セキュリティ リスクの学習を管理する
セキュリティ リスク管理の技法を使う企業は、セキュリティ リスクを管理するために、構造化された手法を案出する必要があることに気づかされることがよくあります。これを円滑に行うには、以下の 3 つの条件を満たす必要があります。
変更してもよいという承認を添えて、特定のセキュリティ リスク分類領域の所有権を与えることで、自身の属するセキュリティ チームの個人と責任を共有します。誰に所有権を与えるべきかについての決定は、資産のタイプや資産の分類と関連します。
複雑さと使いやすさを考慮して、セキュリティ リスクの分類と、包括的な対策の必要性の間でバランスを取ります。場合によっては、プロジェクトのタイプごとに異なるリスク分類を行うことで、使いやすさが大幅に改善することがあります。
セキュリティ リスクの分類、定義、テスト、有効性基準の監視、および測定基準を説明するためのセキュリティ知識ベースを維持して、新しいセキュリティ対策の作業経験とユーザーを取り込みます。
コンテキストに固有のセキュリティ リスクの分類
セキュリティ リスクの識別は、特定ソリューションの実装のためにリスクの分類を策定することで、絞り込みが可能です。たとえば、アプリケーション開発プロジェクトでは、このプロジェクトに対する特定のセキュリティ リスク分類と、もう一方で、インフラストラクチャ展開プロジェクトに対するセキュリティ リスクの分類があります。セキュリティのコンテキストの中で経験を積むにつれて、セキュリティ ポリシーと手続きは、より具体的なものにして、成功した軽減戦略と関連させることができます。
セキュリティ知識ベース
セキュリティ知識ベースは、将来のセキュリティ リスク評価を支援するために教訓を記録保管する目的で使われる正式または略式の機構です。何らかの形式の知識ベースがなければ、企業はセキュリティ管理に対する予防型の手法を採用するのに手間取ることがあります。
この知識ベースの中に一連の既知の脅威、弱点の悪用、および脆弱性が取り込まれていれば、これらを軽減する計画をより簡単に立案できます。これは、調査が取り込まれているためです。 セキュリティ知識ベースは、セキュリティ リスク管理のデータベースとは異なります。後者は、個々のセキュリティ リスク項目、計画、および状態を保存および追跡するために使用します。
セキュリティ リスクのための知識を管理する
セキュリティ リスクの知識ベースは、セキュリティ リスク管理における継続的な改善を推進する中心的な要素です。
最初に、企業のセキュリティ プロジェクトとプロセスのチームは、知識ベースを持っていない可能性が高いと言えます。チームは、セキュリティ リスクの評価に着手する際に、毎回新たに取り組まなければなりません。この環境では、セキュリティ リスク管理へのアプローチは通常、対処型です。つまり、プロジェクトにトリガを与える侵害または何らかのイベントが発生した後に対応が行われるのです。この状況では、企業の目標は、積極的なセキュリティ リスク管理の、より高い次のレベルに移行することです。
後に企業は、人材、プロセス、およびテクノロジに関して、セキュリティ問題に精通した、または内容に関する専門知識を持つ熟練のメンバによって得られた暗黙の習得知識を用いて、略式のセキュリティ知識ベースを開発する場合があります。これは多くの場合、セキュリティ委員会を実装することでアーカイブされます。この手法は、セキュリティ リスクの積極的な評価管理を促すものであり、セキュリティ ポリシーの導入を通じて、予防型の管理に道を開く可能性もあります。
知識ベースの最初の開発レベルへの到達は、セキュリティ リスクの識別に、より構造的な手法を提供することで実現します。企業は、セキュリティ問題を正式に取り込み、インデックスを付けることでセキュリティ リスクの根本原因を識別すると、さらに予防的な管理を実施できるようになります。
最後に、賢明な企業は、セキュリティ リスクにつながりそうな指標だけでなく、セキュリティ リスクを管理するために採用した戦略と成功率も記録します。この形式の知識ベースがあれば、セキュリティ リスク プロセスのセキュリティ識別および計画の手順は、多くのチームの共有経験に基づいたものにすることが可能であり、企業は、セキュリティ リスク管理のコストを最適化し始めることができます。
セキュリティ リスク知識ベースを社内でどう実装するかを考慮する際には、経験的に知られている以下の事柄を参考にしてください。
作業に繰り返しの部分が増えるにつれて (たとえば、セキュリティに影響を与える他のプロジェクト、または、進行中の作業プロセスを中心的に扱うなど)、セキュリティ リスク知識ベースの価値は上昇します。
企業が類似するセキュリティ レビューを実施している場合、知識ベースはあまり複雑でない方が簡単に維持できます。
セキュリティ リスク管理は、チームがセキュリティ リスクについて考えなくて済むほど自動的なプロセスにすべきではありません。繰り返しの多い状況でも、ビジネス環境、攻撃者のスキル、テクノロジは常に変化しています。セキュリティ チームは、配置されている人材、プロセス、およびテクノロジに基づいて、自社の環境にふさわしいセキュリティ リスク管理戦略を評価する必要があります。
まとめ
この章では、MSF と MOF に策定されているセキュリティ分析の手法とプロセスの中から、実績のある手法を取り上げて説明しました。また、企業内の資産を守るためのコストを判断するために、SRMD の中で使われているプロセスについて詳述しました。最後に、企業の環境に対する攻撃を予防し、またこれに対応する目的で、セキュリティ アクション プランを立て、これを遂行するためのセキュリティ チームを形成する手順を推奨しました。
詳細情報
MSF については、以下を参照してください。https://msdn.microsoft.com/library/cc963603.aspx
MOF については、以下を参照してください。https://technet.microsoft.com/library/cc506049.aspx
コンピュータ犯罪については、以下を参照してください。https://www.gocsi.com/press/20020407.html
脅威の評価については、以下を参照してください。『Threat Assessment of Malicious Code and Human Threats』(Lawrence E. Bassham & W. Timothy Polk 著、米国立標準技術研究所 (NIST) Computer Security Division) (https://csrc.nist.gov/)
情報のセキュリティにおけるベスト プラクティスについては、以下を参照してください。https://www.iso.org/iso/home.htm
ハッキングについては、以下を参照してください。https://www.hackingvoip.com/
Microsoft TechNet が提供しているセキュリティの脅威に関する情報は、以下のサイトでご覧になれます。https://technet.microsoft.com/library/cc723507.aspx
米国立標準技術研究所 (NIST) が提供している資産の評価に関する情報は、以下のサイトでご覧になれます。https://csrc.nist.gov/archive/asset/
目次
第 3 章 ‐ セキュリティ リスク管理の統制について理解する
付録 E ‐ セキュリティで保護された LDAP および SMTP 複製を行うためのドメイン コントローラでのデジタル証明書の構成