マイクロソフトの Securing Windows 2000 Server ソリューション

トピック

	セキュリティ リスク管理とセキュリティ フレームワーク プラクティス
	セキュリティ リスク管理のフレームワーク
	セキュリティ リスク管理の統制
	セキュリティ リスクの追跡、計画、スケジュール作成、および報告
	セキュリティ リスク改善策の開発
	セキュリティ改善策のテスト
	セキュリティ知識を取り込む
	まとめ

この章は、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 プロセスを含めた概要を示すことのできる柔軟性が特徴です。プロセス モデルには、プロジェクトの開始からライブ展開まで、ソリューションのライフ サイクルが網羅されています。

図 3.1: 段階ごとに見たセキュリティ フレームワーク プロセス モデルの主要管理点

MSF プロセス モデルを使用して、ソフトウェア アプリケーションを開発し、インフラストラクチャ テクノロジを展開することができます。プロセス モデルは、ソリューションの増分バージョンを短いサイクルで繰り返し開発することで、変化するプロジェクトの必要条件に対応できるように作られた反復サイクルに従います。継続的なリスク管理とテスト サイクルにより、これが可能になります。

プロセス モデルの各主要管理点では、プロジェクトに関する多くの重要な質疑応答やディスカッションが行われます。たとえば、以下のような質問です。チームはプロジェクトの範囲に関して合意しているか? チームは先に進む前に十分な計画を立てたか? チームは約束どおりのものを構築したか? 顧客や企業のパートナにとって、ソリューションは適切に機能しているか? 上図と関連するセキュリティ プロジェクトの主なプロセス 6 点について、以下に概略を説明します。

セキュリティ プロジェクトのプロセスについてさらに詳しくは、Microsoft Solution for Security Services Guideを参照してください。

セキュリティ プログラム チームの結成

MSF プロセス モデルの評価プロセスにおいて、環境のセキュリティ保護のために極めて重要な手順があります。これは、セキュリティ プログラムの作成です。このセキュリティ プログラムの原則は、社内の総合セキュリティの目的、範囲、方針、優先順位、基準、および戦略を決定することです。セキュリティ プログラムのメンバは社内の上級管理者です。セキュリティ管理グループは、セキュリティ プログラムによって管理されるポリシーを実装および管理する中間管理者層と報告チームで構成されます。

セキュリティ プログラムは、トップダウン方式で開発すべきです。すなわち、開始、支援、および方向付けを経営陣が実施し、中堅の責任者、最後は従業員にまで行き渡るという方式です。しかし、サポートは、トップダウン、ボトムアップ、およびミドルアウトの各方式を組み合わせて、セキュリティ管理のアイデアを開発および支持することになるでしょう。今日の企業の多くは、開発とサポートにボトムアップ方式を採用しています。その場合、IT 部門は経営陣から適切な支援と方向付けを得ずにセキュリティ計画を開発することになります。したがって、セキュリティ プログラムが、企業のより大きな事業目的から逸脱してしまう可能性があります。

経営陣は、プロセスの発足に必要な役割と責任を社内に割り振ることで、セキュリティ プログラムの作成を開始すべきです。経営陣が関わることで、ビジネスとテクニカルな環境が変化すると共に、プログラムの強さを維持し、発展させることができます。セキュリティ プログラム内で役割を作ることにより、企業がセキュリティを単なる関心事ではなく、事業の中心的な部分として見ていることが確認されます。

セキュリティ プログラムに加え、経営陣はセキュリティ管理グループを設立する必要があります。セキュリティ管理グループは、セキュリティ プログラムのほとんどの面を監視する直接的な責任を負います。通常、社内のセキュリティ プログラムはセキュリティ ポリシーを策定しますが、セキュリティ管理グループは、セキュリティの構成を実施し、監視します。

企業と企業のセキュリティ ニーズおよび環境の規模に依存して、セキュリティ管理は、中央集権的または分権的に機能する 1 人またはグループで構成されることになります。

評価

プロセス モデルにおいて説明されている、脅威を評価するためのセキュリティ フレームワークは、セキュリティの専門担当者による、企業の IT インフラストラクチャにおけるデータの可用性、完全性、および機密性を保護するための戦略開発を支援するためのものです。これは、情報リソース責任者、コンピュータ セキュリティ担当者、および管理者に関連することであり、コンピュータ セキュリティのポリシー確立に努める人々には、特に価値のあることです。フレームワークは、この重要なタスクに対する体系的な取り組みを提供すると共に、最終的な安全措置として、障害発生時の危機管理計画の確立をも視野に入れたものです。

機密性

企業の IT インフラストラクチャには、不正な開示からの保護を必要とする情報が含まれている場合があります。たとえば、収穫高の報告書、個人情報、社外秘のビジネス情報など、情報をまく (流す) タイミングが重視されるものです。機密保持により、データ処理の各接続点で必要なレベルの機密性を確実に提供し、不正な開示を防止できます。データがネットワーク内のシステムとデバイス上にある間、転送時、送信先で受信された時に、一貫したレベルの機密性が維持されるべきです。

完全性

IT インフラストラクチャには、不正な、予期しない、または故意でない改変から保護されなければならない情報が含まれています。たとえば、人口調査の情報、経済指標、金融取引システムなどです。情報とシステムの正確さと信頼性が保証され、データの不正な改ざんが防止できれば、完全性が守られます。

可用性

IT インフラストラクチャは、使命遂行の必要条件を満たすために、または大きな損失を回避するために、タイムリーに発信する必要のある情報を含み、あるいは、このような性質のサービスを提供することもあります。たとえば、安全装置、生命維持、および一貫したネットワーク接続が不可欠な重要なシステムがこれに相当します。可用性は、認証された個人に対し、データとリソースへのタイムリーなアクセスと信頼性を保証することになります。

セキュリティ管理者は、適切なセキュリティ ポリシーと管理を策定するために投入する時間、資金、および労力を判断する必要があります。企業は、特定のニーズを分析してから、このリソース、スケジュール作成の必要条件と制約について判断する必要があります。コンピュータ システム、環境、および企業ポリシーがそれぞれ異なるので、社内のコンピュータ グループの安全確保の戦略は困難です。

セキュリティ戦略により、企業は貴重な時間を節約でき、何をすべきかについて重要な注意喚起が提供されますが、セキュリティは一度限りの働きではありません。セキュリティとは、環境を構築するシステム ライフ サイクルの不可欠な部分なのです。この章で説明する作業は、一般に定期的な更新または適切な改訂を必要とするものです。このような変更は、構成その他の条件が大幅に変わる場合、または企業の規則やポリシーに変更が必要とされる場合に実施されます。これは反復されるプロセスであり、決して終わりがなく、定期的な改訂とテストが必要です。

組織的な評価

効果的な一連のセキュリティ ポリシーと管理を確立するには、コンピュータ システムと現在のセキュリティ ポリシー内に存在する脆弱性、およびそれを保護する管理システムを判断するための戦略を使う必要があります。レビューを行う際に、環境内でポリシーが欠けているところに注目し、また、存在するポリシーに関する文書を調査する必要があります。ポリシーのレビューに加え、法務担当は、セキュリティ ポリシーのすべてが企業の法律規定に準拠していることを確認する必要があります。コンピュータ セキュリティ ポリシーの現況は、以下のリストを検討することで、判断できます。

機密情報を含むその他のポリシーに関する文書。以下に例を示します。

脅威の分析

脅威のリスト (ほとんどの企業はいくつかの脅威を識別できます) を作成することは、セキュリティ管理者が、攻撃に悪用される可能性のあるさまざまな弱点を識別するのに役立ちます。セキュリティ対策を欺くための新しい方法、ツール、および手法が絶えず考案されているため、管理者がこの分野の情報を継続的に更新することが重要です。

予想できる攻撃を判断し、この攻撃への防御対策を策定するための脅威分析プロセスの概略が図 3.1 の計画段階に示されています。すべての攻撃に対して備えることは不可能です。したがって、企業が予想できる最も可能性の高い攻撃に対して備えます。攻撃後に損害を修復するよりも、攻撃を予防するか、または最小限に抑えることの方が常に得策です。

攻撃を最小限に抑えるには、システムにリスクをもたらすさまざまな脅威、セキュリティ制御を出し抜くために使われる可能性のある技法、セキュリティ ポリシーの中に存在する脆弱性について理解することが必要です。攻撃の 3 要素であるこれらの点について理解しておけば、発生のタイミングや場所までは難しいにしても、発生そのものを予測する助けとなります。攻撃の予測とは攻撃発生の可能性を予測することであり、攻撃のさまざまな側面についてどこまで理解できるかに依存します。攻撃のさまざまな側面は、以下の等式によって表現できます。

脅威の誘因 + 弱点を悪用する方法 + 資産の脆弱性 = 攻撃

悪意を持った攻撃者は、同じ攻撃を仕掛けるのに異なる方法を用いる可能性があります。したがって、セキュリティ戦略は、脅威エージェント (脅威をもたらす要因) が悪用しそうなタイプごとにカスタマイズする必要があります。

脆弱性の評価

企業のセキュリティ ニーズを評価する作業には、既知の脅威に関連する脆弱性の判断を含める必要があります。この評価には、企業が保有する資産のタイプと、この資産に対してどんな種類の損害が及ぶ可能性があるかを確認する作業が伴います。

攻撃によって被る可能性のある損害を判断する

企業の環境内の資産が被るの可能性のある損害は、軽度のコンピュータ エラーから致命的なデータ損失まで、さまざまな規模のものが考えられます。システムが被る損害は、攻撃のタイプによって異なります。可能なら、テスト環境または試験環境を使って、さまざまなタイプの攻撃によって生じる損害を明らかにすると良いでしょう。そうすれば、セキュリティ担当者は、物理的損害を正確に評価することができます。どんな攻撃を受けた場合でも、損害のタイプや規模が同じとは限りません。たとえば、以下のようなテストを実行するとよいでしょう。

このプロセスにインシデント レスポンス チームを加えるのもよいでしょう。個人よりもチームの方が、発生したさまざまな損害のタイプをすべて発見できる可能性が高いからです。インシデント レスポンス チームは、セキュリティ インシデントの優先順位化と、セキュリティ インシデントを解決するためのエスカレーション パスを管理します。

攻撃の標的となり得る脆弱性または弱点を判断する

特定の攻撃の標的になる可能性のある脆弱性を発見できれば、現行のセキュリティ ポリシーと制御を修正するか、または新しいポリシーや制御を実装して、脆弱性を最小限に抑えることができます。攻撃、脅威、および方法のタイプを判断できれば、より簡単に既存の脆弱性を発見できます。これは侵入テストによって証明できます。

セキュリティ リスクの計画、スケジュール作成

弱点を悪用する各方法に対し、企業のセキュリティ計画は、予防と対処の両方の戦略を備えている必要があります。

予防戦略、すなわち攻撃される前に実施する戦略は、既存のセキュリティ ポリシーにおける脆弱性を最小限に抑え、危機管理計画を開発するのに役立つ一連の手順です。攻撃がシステムにもたらす損害と、攻撃の間に利用される弱点と脆弱性について判断を下すことで、対処戦略を開発する助けになります。

対処戦略、すなわち攻撃を受けてしまった後に実施する戦略は、セキュリティ担当者が攻撃による損害を評価し、損害を修復し (つまり、対処戦略において開発された危機管理計画を実装し)、経験を文書化してそこから学習し、できるだけ早くビジネス機能を復旧させるために役立ちます。

予防戦略

予防戦略は、攻撃を未然に防ぐために実施しておくべき、事前に定められた一連の手順です。手順には、攻撃がどのようにしてコンピュータ システムに影響または損害を与え得るかを考察し、悪用され得る脆弱性について調べる作業が含まれます (手順 1 と 2)。それらの評価手順において得られる知識は、攻撃を制御または最小限に抑えるためのセキュリティ ポリシーを実装する上で役に立ちます。以下は、予防戦略の 4 つの手順です。

これらの手順に従って各種の攻撃を分析することで得られる副産物があります。すなわち、さまざまな攻撃のうちで重なり合う要因が、パターンとして浮き彫りにされてくるのです。このパターンは、最大のリスクを引き起こす脆弱性の存在する領域を特定するのに役立ちます。

注 データ損失のコストとセキュリティ制御を実装するためのコストのバランスを取ることも必要です。これらのリスクとコストを比較検討することも、システムのリスク分析の一部です。

対処戦略

対処戦略は、攻撃を防ぐための予防戦略が失敗したときに実装されます。対処戦略では、攻撃を受けている最中または受けた後に行うべき手順が定義されます。この戦略は、攻撃において引き起こされた損害と悪用された脆弱性を確認するのに役立ちます。対処戦略はまた、攻撃が発生した原因、攻撃によってもたらされた損害を修復する方法、危機管理計画を実装する方法をも判断します。

予防と対処の戦略は、両者が一体となって機能し、攻撃とそれが引き起こす損害を最小限に抑えるためのセキュリティ ポリシーと制御を開発します。イベントの評価と文書化を行い、そこから学習する作業を支援するために、攻撃を受けている最中または受けた後に実施される手順の中に、事故対応チームを含めるべきです。

対処戦略には、以下の 3 つの手順が含まれています。

危機管理計画

危機管理計画とは、システムが攻撃の侵入を受け、データまたはその他の資産に損害を与えた結果、正常な業務が妨害されたり生産性が低下した場合に備えて開発される代案です。システムをタイムリーに復元できない場合に、危機管理計画が実行されます。究極的には、データの可用性、完全性、機密性を維持することが目標です。つまり、危機管理計画とは "計画 B" に相当するものなのです。

危機管理計画は、攻撃と脅威の各タイプに対応するように作成すべきです。各計画には、攻撃を受けた場合に実行する一連の手順を含める必要があります。危機管理計画には、一貫して以下の対策を含めることが望まれます。

以下に挙げる点は、危機管理計画の作成時に実施する必要のある、さまざまな評価タスクをまとめたものです。

実装

実装する制御の厳しさが度を越えないように気をつけてください。厳しすぎると、情報の可用性が問題となる場合があるからです。セキュリティ制御と情報へのアクセスの間で、入念にバランスをとることが必要です。

シミュレーション攻撃のテスト

セキュリティ戦略、テスト、テスト結果の見直しの最後の要素は、対処戦略と予防戦略が配備された後に行われます。テスト システムまたは試験用システムに対してシミュレーション攻撃を実施することで、さまざまな脆弱性が存在する場所を見極めることができます。そして、それに基づいて企業のセキュリティ ポリシーと制御を調整することができるのです。

これらのテストは、実運用の基幹業務システム上で実行すべきではありません。大災害となる可能性があるからです。しかし、予算上の制約で試験用またはテスト用 コンピュータがない場合には、シミュレーション攻撃自体が行えない可能性があります。テストに必要な資金を確保するために、経営陣は、攻撃のリスクと結果を認識すると共に、テストの手順を含め、システムの保護に必要となる可能性のあるセキュリティ対策について知っておくことが重要です。実装すべき最善のセキュリティ ポリシーと制御について判断するために、可能であれば、攻撃シナリオのすべてを物理的にテストし、文書化しておくべきです。

自然災害のようにテスト不能な攻撃もありますが、それでもシミュレーションは役に立ちます。たとえば、火災の場合は、サーバー ルーム内のサーバーすべてが被害を受けて失われたという設定でのシミュレーションが可能です。この障害シナリオは、管理者とセキュリティ担当者の対応をテストしたり、正常な業務再開までに要する時間を確かめるのに役立ちます。

テスト結果に基づいてセキュリティ ポリシーと制御を調整する作業は、反復的なプロセスです。このプロセスには決して終わりがなく、改善措置を実装できるように、定期的に評価および修正する必要があります。

作業

明確に定義されたエスカレーション パスと問題の管理は、インシデント レスポンス プログラムにとって不可欠な要素です。セキュリティ プロジェクトの初期段階でインシデント レスポンス計画を一貫して執行することにより、チームは、企業全体を通じて問題解決の有効性を高めることができます。結果を文書化してセキュリティ プロジェクトから学習することは、新しいプロジェクトによって前進しようとしている全員にとって有益です。作業プロセスにおいて学習されたこの種の教訓を集めることで、次のセキュリティ プロジェクトに向けた評価、開発、および実装タスクを簡単に完了できるようになります。

インシデント レスポンス

企業がセキュリティ計画のベスト プラクティスを完全に実装したいと願うなら、セキュリティ事故に対応するチーム (インシデント レスポンス チーム) の結成が必要です。システム セキュリティを確実にするための予防的な努力の中に、インシデント レスポンス チームの関与が必要です。予防的な努力には、以下が含まれます。

これらの努力により、インシデントの発生中および事前に問題に対処するのに役立つ知識が得られます。

セキュリティ管理者は、必要に応じて企業のためにセキュリティ監査を監視および管理する立場であることが必要です。セキュリティ管理者は、セキュリティ ドメインに対するセキュリティ ポリシーを実装する責任を負う権威者 (個人またはグループ) であることが必要です。セキュリティ管理者とインシデント レスポンス チームがこれらの予防対策を完了した後、管理者は、インシデントを処理する責任をインシデント レスポンス チームに移すべきです。

これは、セキュリティ管理者がチームの一員として引き続き関与してはならないという意味ではありません。ですが、セキュリティ管理者は常に仕事ができる状態だとは限らないため、インシデント レスポンス チームが自らインシデントを処理できなければならないのです。チームはインシデントに対応する責任を負うことになりますが、同時に、コンピュータまたはネットワークのセキュリティと関わりを持つ可能性のある非常事態を分析する働きにも加わるべきです。

文書化と学習

攻撃が発生したら、これを文書化することが重要です。文書化は、攻撃によって生じた損害 (ハードウェア、ソフトウェア、データ損失、生産性の損失)、攻撃の際に悪用された脆弱性と弱点、失われた生産時間の長さ、損害を修復するために実行した手順、修復作業のコストを含め、既知の攻撃範囲すべてを網羅すべきです。こうして作成されたドキュメントは、予防戦略を修正して将来の攻撃を予防し、損害を最小限に抑えるのに役立ちます。

危機管理計画の実装

危機管理計画が既に存在する場合、それを実装することで時間を節約し、業務を円滑に継続することができます。危機管理計画が存在しない場合は、前の手順で作成された文書に基づいて、適切な計画を立てます。

結果の吟味とシミュレーションの実施

攻撃を受けた後、または攻撃を防御した後に、企業のシステムと予防戦略に関して、結果の見直しを行います。見直しには、生産性の損失、失われたデータまたはハードウェア、攻撃から復旧するまでに要した時間に関する詳細を含める必要があります。シミュレーションはテスト環境内で実施すべきですが、最善の成果を得るには、生産環境に似た環境であることが望まれます。

ポリシーの有効性の見直し

発生した攻撃に対する防御にポリシーが存在する場合、見直しを行い、その有効性をチェックすべきです。ポリシーが存在しない場合は、将来の攻撃を最小限に抑えるか、または防止するために新しく起草する必要があります。

既存のポリシーの有効性が基準に満たない場合は、基準を満たすように調整すべきです。ポリシーの更新については、該当する管理職スタッフ、セキュリティ管理者、IT 管理者、およびインシデント レスポンス チームが調整する必要があります。ポリシーはすべて、企業の一般規則とガイドラインに準拠すべきです。たとえば、標準営業時間が、仮に午前 8 時から午後 6 時までとします。セキュリティ ポリシーは、更新または作成の際に、ユーザーがこの時間枠の間しかシステムにログオンできないように指定することが可能です。

ページのトップへ

セキュリティ リスク管理の統制

以下のセクションは、MSF と MOF を利用して今日使われているセキュリティ分析手法の中から、実績のある手法を参考にして書かれたものです。MSF は、エンタープライズ アーキテクチャとインフラストラクチャ展開のプロジェクト ライフ サイクルについて、計画、構築、安定化、および展開の各段階におけるガイダンスを提供します。MOF は、情報技術 (IT) 業務用の管理システムを開発または改善する方法についてアドバイスを提供します。セキュリティ リスク管理の統制 (SRMD) はここで詳しく定義されており、ご使用の環境に適用できる知識を得ることができます。SRMD は、詳細にわたるプロセスであり、どの脅威や脆弱性が特定の企業に対して潜在的に最も大きな影響を持つかを判断する上で役に立ちます。

セキュリティ リスクの識別

セキュリティ リスクの識別は、企業のセキュリティを評価する際の第一歩です。セキュリティ リスクを効果的に管理するには、プロジェクト チームが合意に達した上で、結果の分析とリスクに対処するための実行計画の作成に進むことができるように、明確に規定することが必要です。セキュリティ リスクの範囲は、プロジェクト チームが保護しようとするテクノロジに限られますが、チームは、テクノロジ、プロセス、環境、人を含め、セキュリティ リスクのあらゆる発生源に対処できるよう、十分に広い範囲に焦点を当てておくべきです。

自由に意見を出し合うことはセキュリティ リスクを識別する 1 つの方法ですが、インターネット上には、セキュリティ問題に関する多数の情報源があります。見直しを行えば表面に見られるセキュリティ リスクの攻撃に使える、既存の脆弱性に対する評価または侵入テストが、会社に既にあるかもしれません。

目標

セキュリティ リスクを識別する手順の目標は、企業の資産を脆弱なものとする既知のセキュリティ リスクのリストをチームが作成することです。このリストは、可能な限り包括的なものとし、テクノロジ、ビジネス、人、戦略など、エンタープライズ アーキテクチャのあらゆる面を網羅すべきです。

リスク管理とは、リスクを識別および分析して管理するための計画を立てるプロセスのことです。セキュリティ リスクは、システムの脆弱性および強さ、ならびに関連する脅威エージェントの判断に照らして、想定される脅威により、または想定される脅威の影響で予想される損失と定義されます。

情報の収集

セキュリティ リスクを識別する手順に対する情報の収集には、脅威に関して入手可能な情報を収集すること、弱点を悪用するために使われている現行の方法や技法のリストを作成すること、企業の資産に害を与えるために悪用される可能性のある、システムやポリシーの脆弱性を分析することが含まれます。脅威には、情報とシステムに対する外部からの潜在的危険の一切が含まれます。脆弱性とは、脅威に攻撃ポイントを与えるソフトウェア、ハードウェア、または手順上の弱点を言います。これらのリスクは、多くの場合、ビジネス慣習、アプリケーション、データ、インフラストラクチャ アーキテクチャを含む、企業環境に対するさまざまに異なる見解に由来します。

ポリシー、手順、ガイドライン、テンプレート、企業のテクノロジ インフラストラクチャの現状に関する情報という形式のセキュリティ計画に対して企業が取っている現在のアプローチ、およびチームの経験は、この手順への情報収集を決める上で役に立ちます。

セキュリティ チームは、資産そのものから得た情報、あるいは、脆弱性分析または侵入テストに使われたツールの成果から得た情報を参考にできます。セキュリティ問題に関するチームおよび利害関係者の認識についての情報を収集するためのグループ内でのディスカッション、さらには正式なセキュリティ ワークショップも、情報を得るのに役立つことでしょう。

リスクを識別する活動

チームは、セキュリティ リスクを識別する手順で自社が直面するリスクを明確に示すことにより、セキュリティ問題の明瞭な記述またはリストを作成しようとします。新しい状況に関連するリスクを識別するために、セキュリティ チームのワークショップまたはディスカッションを連続的に行うことは有用です。

テクノロジと環境は急速に変化するため、セキュリティ リスクの識別を一度限りの活動として扱わないことが重要です。このプロセスは、企業の業務のライフ サイクルで、定期的に繰り返し実施する必要があります。

構造化された手法

セキュリティ リスク管理のために、構造化された手法を使うことは極めて重要です。構造化された手法により、セキュリティ上の問題処理のためにチームの全員が一貫した機構を使用できるからです。この手順の中で脅威の分類を行えば、再現と測定が可能な一貫したアプローチを提供するのに役立ちます。

脅威の分類

セキュリティ チームは、脅威の分類 (カテゴリまたは分類学という呼び名もあります) をさまざまな目的に使うことができます。リスクを識別する際には、いろいろな領域で発生するセキュリティ リスクについて思考を働かせる刺激として使用できます。また、ディスカッション中には、分類は、類似する脅威をグループにまとめるための便利な方法となり、数の多い脅威を処理する作業の複雑さを軽減します。脅威の分類は、チームがプロジェクト全体を通じてリスクの状態を監視し、報告するための共通の用語を提供する目的にも使用できまう。

セキュリティ リスクのステートメント

セキュリティ リスクのステートメントとは、企業の既存のセキュリティ状態と、潜在的でまだ実現していないセキュリティの成果との間の因果関係を自然言語で表現したものです。

セキュリティ リスク ステートメントの最初の部分は "条件" と呼ばれており、ここでは何らかの害を及ぼす可能性があるとチームが考える既存の状態または潜在的脅威を記述します。リスク ステートメントの 2 番目の部分は "結果" と呼ばれており、ここでは資産に対する機密性、完全性、および可用性の好ましくない喪失を記述します。

2 つのステートメントは、不確かな (言い換えれば、確率が 100% 未満の) 関係、または因果関係を含意する "その場合 (then)" または "〜となる可能性がある (may result in)" などの言葉でリンクされます。

以下に、このガイドで使われているリスク ステートメントを紹介します。

もし脅威エージェントが脆弱性を悪用するためにツール、テクニック、または手法を使うと、その場合、資産に対する (機密性、完全性、または可用性) の喪失が影響を及ぼす可能性があります。

セキュリティ リスク ステートメントは、リスク分析を通じて作成されます。リスク分析の手法には、定性的手法と定量的手法という 2 つのタイプがあります。定性的手法と定量的手法は、どちらかが他方よりも優れているというわけではありません。この 2 つはそれぞれ、リスクの識別作業を構造化するのに有益なツールとなります。定量的手法で収集した情報が、定性的手法のベースとなります。

図 3.2: セキュリティの条件と結果のリスク ステートメント
拡大表示する

以下の手順は、上図のプロセスの各部を詳しく説明したものです。

セキュリティ リスクのステートメントを生み出すための 2 部にわたる定式化プロセスには、企業内に現存する観察可能な (かつ潜在的に制御可能な) 条件で潜在的な結果を資産に連結させるという利点があります。チームがセキュリティ リスクの条件を識別することにのみ焦点を当てる別のアプローチでは、セキュリティ リスク管理の計画戦略を策定する際に、セキュリティ リスクの分析プロセスにおける後の段階で、チームがリスク条件を見直さなければならなくなる可能性があります。

注 セキュリティ リスク ステートメントは、純粋な "IF-THEN" ステートメントではありません。むしろ、可能性があるのに発生していないリスクの結果を探る事実のステートメントなのです。

仮定上の "IF-THEN" ステートメントを検討して代案を比較考察し、起こりえる事象、結果を列挙することで計画を策定することが役立つ場合があります。ただし、セキュリティ リスクを識別する段階での目標は、できる限り多くのセキュリティ リスクを識別することだけです。セキュリティ リスクの分析と管理の方法については、このプロセスの後の段階まで保留します。

作成するセキュリティ リスク ステートメントには、条件と結果が含まれていなければなりません。チームのメンバは、徹底的なセキュリティ リスク分析の一部として、基礎をなす共通の根本原因を追究するために、セキュリティ問題の条件の類似性を探して自然なグループ化を目指し、続いて、それぞれの関係をさかのぼって調べるべきです。根本原因が判明したら、関係を条件の根本原因から順に見直すことも有益です。これにより、セキュリティの脅威に関連する損失全体または失われた機会をより正確に認識するために、社外の資産に対する影響が調査されることになります。

セキュリティ リスクを識別する間は、同一の条件が、関連する複数の結果を生じることも珍しくはありません。しかし、その逆も当てはまる場合があります。すべて同一の結果を生じる複数の条件が存在する可能性もあるのです。場合によっては、企業のある領域で識別されたセキュリティ リスクの結果が、別の領域ではリスク条件となることもあります。セキュリティ リスク分析を行い計画を立てる間に、セキュリティ リスクどうしの依存と関係を考慮に入れて適切な決定を下すことができるように、これらの状況を記録しておく必要があります。

社内のセキュリティ リスクどうしの関係によっては、1 つのリスクを軽減することで、結果として、これに依存しているリスクのグループ全体を軽減することがあります。さらに、このようにして企業のリスク プロファイル全体が変化することもあります。セキュリティ リスク識別の初期段階でそれらの関係を文書化しておくと、根本原因または配下の原因に対処するためにリソースの調査を効率的に行うことができる、包括的で柔軟な、効果的なセキュリティ リスク計画を導くのに役立つ情報を提供できます。最も重要なセキュリティ リスクについては、識別の手順でこのような追加情報を取り込むことのメリットと、計画段階でその後の分析と優先順位の決定を迅速に済ませること、および依存関係と根本原因を再調査することとの間でバランスを取るべきです。

企業内の資産を評価する

資産の金銭的価値を算出することは、リスク管理における重要な部分です。事業の管理者は、多くの場合、資産のセキュリティ保護のために費やすべき費用と時間を算出する際に、資産価値を指標として用います。多くの企業は、障害復旧計画の一環として、資産価値のリストを保持しています。以下の評価モデルは、定量分析の手順 8 に述べた詳細に従って資産に優先順位を付ける方法を決定する際に役立ちます。

資産価値を適切に評価するには、以下の 3 つのプライマリ ファクタを計算します。

表 3.1 資産評価の例

資産が競争相手にとってどれだけの価値を持つかも検討すべきです。たとえば、こちらのサイトがダウンしている間に、競争相手が以前こちらの Web サイトから取得した顧客情報を使用できた場合、莫大な収入を競争相手に奪われる可能性があります。

定量的リスク分析を行う際に使える可能性のある方法や式は多数あり、プロセスに挿入できる変数も多数あります。以下は上記の手順 10 に続く追加手順で、定量的セキュリティ リスク分析を成功させるために用います。

定量的リスク分析から得られたインプット項目は、明確に定義された目標と結果を導き出します。以下のリストは、これまでの手順の結果から一般的に何が得られるかを示します。

アウトプット

セキュリティ リスクを識別する作業から得られる最小限のアウトプットは、セキュリティ チームが相対したリスクの明瞭ではっきりとした一致したステートメントであり、これは、セキュリティ問題のリストとして文書化されます。表の形になったセキュリティ問題のリストは、セキュリティ リスク管理プロセスの次の段階である分析にとって、主要な情報です。

セキュリティ リスクの識別手順では、根本原因と波及効果の識別、影響を受ける当事者、所有者など、そのほかにも有用な情報が大量に得られることがよくあります。

セキュリティ チームが作成するセキュリティ リスク ステートメントや、根本原因と波及効果の情報を表形式で記録しておくことは、良い習慣だと考えられています。社内で使える明確な分類学があれば、セキュリティ リスクを脅威ごとに分類するための追加情報も、セキュリティ リスク情報を使ってセキュリティの知識ベースを構築または使用する際に役立つ場合があります。

セキュリティ チームがリスク識別プロセス中に記録するとよい情報には、そのほかに以下のものがあります。

セキュリティ リスクの分析と優先順位の決定

セキュリティ リスクの分析と優先順位の決定は、セキュリティ評価のプロセスにおいて 2 番目に大きな手順です。セキュリティ リスクの分析には、意思決定をしやすくするために、セキュリティ リスク データ (脅威、弱点の悪用、脆弱性) を変換して 1 つの形式の中にまとめる作業が含まれます。セキュリティ リスクの優先順位を決定することで、セキュリティ チームのメンバは、最も重要なセキュリティ リスクに必ず最初に取り組むことができます。

この手順で、セキュリティ チームは、セキュリティ リスクの識別手順で作成したセキュリティ問題のリスト項目を検討して優先順位を決定し、セキュリティ アクション プランを作成します。

セキュリティ アクション プランにおいて、企業のセキュリティ チームは、セキュリティ問題のリストを用い、環境内の課題の管理を目的とする特定の戦略を執行する計画を立て、ここにリソースを集中させることができます。

チームはまた、行動に移す優先順位が低いためにリストから外すことが考えられるセキュリティ課題があれば、それがどれなのかを識別することができます。このセキュリティ実装段階が完成に近づき、企業の環境が変化するにつれて、セキュリティ リスクの識別とセキュリティ リスク分析を繰り返して、セキュリティ アクション プランの有効性を確認しなければなりません。新しいセキュリティ リスクが発生したり、逆に、優先順位が低くなった古いセキュリティ リスクが削除されたり、割引かれたり、"非活性化" されたりすることもあります。

目標

セキュリティ リスクの分析手順における第 1 の目標は、セキュリティ問題の影響を軽減するために、セキュリティ アクション プランにおいてそれらに優先順位をつけ、企業のリソースを集中的に注ぐだけの重要性を持つのはどれなのかを判断することです。

情報の収集

リスク分析プロセスの間、チームは自らの経験に頼り、また、セキュリティ リスク ステートメントに関する他の関連ソースから得た情報を参考にします。未処理のセキュリティ リスク ステートメントを優先順位付きのマスタ リスク リストに変換する方法についての情報は、企業のセキュリティ ポリシーと手続き、業界知識のセキュリティ データベース、脆弱性分析、セキュリティ シミュレーション、および個々の資産所有者から取得してください。

セキュリティ リスクの分析作業

セキュリティ アクション プランにおける優先順位を決める作業のために、定性的および定量的技法が多く存在します。セキュリティ リスク分析のための簡単な技法の 1 つは、確率および影響という広く受け入れられている 2 つのリスク コンポーネントから得られるコンセンサス チーム予測を使う方法です。これらの予測値を掛け合わせて、リスク 危険性と呼ばれる 1 つの測定基準を算出することができます。

セキュリティ リスクの確率

セキュリティ リスクの確率は、セキュリティ リスク ステートメントのリスク条件の部分で記述される状況が実際に発生する可能性の尺度です。リスク ステートメントには、以下で記述する部分のように、会社にとって時間やお金では測れない要素が含まれる場合があります。

"もし、脅威エージェントが、脆弱性を悪用するためにツール、テクニック、または手法を使うと..."

脆弱性に乗じるために弱点を悪用する脅威は、リスク ステートメントの条件の部分です。特定のタイプの脅威 (特に脅威が自然災害である場合) では、既知の脆弱性や弱点が悪用されることはありません。

リスクのランク付けのために、リスクの確率に数値を使うことをお勧めします。セキュリティ リスクの確率がゼロ以下の場合、脅威はセキュリティに対して問題をもたらしません。確率が 100% であれば、セキュリティ リスクは確実であり、既知の問題である可能性があります。

業界または企業のリスク データベースは、多数のプロジェクトのサンプルに基づいており、既知の確率予測には役立つ場合がありますが。周知のとおり、確率は予測と適用が極めて困難です。ただし、プロジェクト チームは自然言語の用語で経験を表現できるため、以下の表に表現されるように、これらの用語を確率の数値範囲に割り当て直すと役に立ちます。

表 3.2 リスクの確率

計算に使われる確率の値は、範囲の中央値です。これらのマッピング テーブルを用いた、確率を定量化するための別法として、チームが同意を与えた確率範囲または自然言語の表現を数値のスコアにマップする方法があります。セキュリティ リスクを表すために数値のスコアを使う場合、作業を効果的に行うには、優先順位を決定するプロセスで、すべてのセキュリティ リスクに対して同じ数値スコアを使うことが必要です。

不確実性を定量化するためにどんな手法を使うにしても、チームは、各リスクに関する一致した見解を表す、リスクの確率に対する 1 つの値を引き出す手法も開発しなければなりません。

セキュリティ リスクの影響

リスクの影響とは、資産に対する悪影響によって発生する損失の深刻度、あるいは、資産が機密性、完全性、または可用性を失うことになる損失の大きさを予測したものです。これは、セキュリティ リスク ステートメントの後半で定義したセキュリティ リスクの結果を直接的な尺度であるべきです。

"…その場合、資産に対する (機密性、完全性、または可用性) の喪失が影響を及ぼす可能性があります。 "

損失は金銭的な観点から、または資産に関する主観的な測定スケールを用いて計測できます。セキュリティ リスクの影響がすべて金銭的に表現できるのであれば、損失の大きさまたは機会コストを定量化するために金銭的な値を使う方法は、企業のスポンサーにとっては見慣れているという利点があります。金銭的な影響は、作業とサポートにおける長期的なコスト、市場シェアの喪失、追加作業における短期的なコスト、または機会コストなどです。

状況によっては、1 〜 5 まで、または 1 〜 10 までの主観的なスケールの方が、セキュリティ リスクの影響を測定するのに、よりふさわしい場合もあるでしょう。主観的なスケールを使ってよい一例として、資産の適切な正味価値を迅速に算定できないような状況が挙げられます。セキュリティ アクション プランにおけるセキュリティ リスクのすべてに同じ測定単位を使う限り、通常は、単純な優先順位決定技法で十分です。

表 3.3 損失資産のスコアリング システムの例

影響を見積るためのスコアリング システムは、企業ごとに異なります。また、各企業の価値観やポリシーを反映するものでなければなりません。たとえば、10,000 ドルの金銭的な損失は、あるチームや企業にとっては許容範囲であっても、別の企業にとっては許容範囲を超えている場合があります。致命的な影響に対しては、たとえば 100 などの人為的に高い数値をあてると、確率が非常に低いリスクであっても、確実にリスク リストのトップに上昇し、ここに留まることになります。

セキュリティ リスクの危険性

リスク 危険性は、資産に対する総合的なセキュリティ リスクを測定し、実際の損失が発生する可能性を表現する情報と、潜在的な損失の大きさを表現する情報を 1 つの予測値にまとめます。セキュリティ チームは続いて、セキュリティ問題にランク付けをするために、リスク 危険性の大きさを使うことができます。最も単純な形式の定量的リスク分析では、リスク 危険性は、リスクの確率と影響を掛け合わせて算出します。

確率と影響の定量化にスコアを使う際には、スコアの可能な組み合わせを考慮して、それを低/中/高のリスク カテゴリに割り当てるマトリックスを作成すると便利な場合があります。1 が低で 3 が高の 3 部からなる確率のスコアと、やはり 1 が低で 3 が高の 3 部からなる影響のスコアを使います。結果は、各セルがリスク 危険性の予想値となる表の形式に表現されます。この配列では、斜め方向に上昇する変動幅の中の位置に応じて、リスクを低/中/高に簡単に分類できます。

表 3.4 リスクのスコアリング マトリックス

危険性範囲: 低 = 1 〜 2; 中 = 3 〜 4; 高 = 6 〜 9

この表形式の利点は、セキュリティ リスクのレベルをスポンサーと利害関係者に提出する現状報告書の中でカラー (右上隅のハイ リスク ゾーンには赤、左下隅のロー リスク ゾーンには緑、斜線に沿ったミドル リスク ゾーンには黄) を使って掲載できることにあります。わかりやすく、かつ明確な用語を使うことで、これらの値の意味が伝わりやすくなります。"ハイ 危険性" よりも "ハイ リスク" の方が理解しやすいからです。

その他の定量的技法

セキュリティ リスク分析の目標は、セキュリティ リスクの優先順位を決め、セキュリティ アクション プランを推進し、セキュリティ管理に対するリソースの割り振りに関する意思決定を進めることなので、セキュリティ チームは、リスクの優先順位を決める方法を選ぶ際に、プロジェクト、チーム、利害関係者にとって適切な選択をすべきです。

一部の企業は、要求されている時間枠、潜在的な機会利益の大きさ、確率予測の信頼性、物理的資産または情報資産の評価など、チームがランク付けプロセスにおいて参考にしたいその他のコンポーネントにおいて、係数に対して加重された、複数の属性を持つ技法を使うことでメリットを得ることができます。

"最適な"セキュリティ リスク分析手法を選択するか、複数の手法を組み合わせるかは、セキュリティ アクション プランにおいて、セキュリティ リスク分析を行う労力と、不正確または (利害関係者にとって) 防御不能な優先順位決定を選択することの間で適正なバランスを保つことに依存します。セキュリティ リスク分析は、優先順位の決定を支援し、意思決定を推進するために行うべきであり、分析のための分析とならないように注意します。

セキュリティ リスクの優先順位決定に定量的または半定量的手法を使った成果は、ビジネス ガイドライン、ポリシーと手続き、データ、テクノロジ インフラストラクチャのコンテキストにおいて評価すべきです。半定量的手法は、企業が定量化可能なセキュリティ対策を準備できるように、何らかの種類の定性的対策で始まります。

アウトプット

セキュリティ リスク分析により、優先順位の決まったセキュリティ アクション リストがチームに与えられ、セキュリティ リスクの計画を立てる作業のガイドとなります。優先順位の決定に使われる条件、コンテキスト、根本原因、測定基準などのセキュリティ リスクの詳細情報 (確率、影響、危険性) は、多くの場合、各リスクについてリスク ステートメント フォームに記録されます。これについては、この章で後ほど詳しく説明します。

マスタ セキュリティ リスク リスト

アクション プランの作成を必要とする主要なセキュリティ リスクのリストは、セキュリティ アクション プランの中で定義します。セキュリティ アクション プランは、セキュリティ リスクを発生させる条件、潜在的な悪影響 (結果)、リスクのランク付けに使われる基準または情報 (確率、影響、危険性など) を明らかにします。2 つの要素 (確率と影響) による予測手法を使ったマスタ リスク リストの例を以下に示します。

表 3.5 マスタ リスク リストと優先順位付けの例

危険性は、確率ﾗ影響として計算されます。影響は、低 = 1、中 = 2、高 = 3 です。

マスタ セキュリティ リスク リストは、セキュリティ リスクの評価情報をすべて集めたものであり、継続的なセキュリティ リスク管理プロセスの基礎をなす活きた文書です。評価、計画、構築、展開、作業を含む IT のライフ サイクル全体を通じて、常に最新の状態に保っておく必要があります。

マスタ セキュリティ リスク リストは、予防型または対処型のリスク管理を支援するための基本的な文書です。このリストは、以下に対するベースを提供することで、チームの意思決定を可能にします。

リスクがもたらす危険性の計算に使う方法は、リスク管理計画の中に慎重に文書化しておくべきです。また、さまざまな要因の重要性を比較検討しつつ、計算にチームの意図が確実かつ正確に反映されるように配慮する必要があります。

資産に対する脅威を識別するために、リスク分析を行います。そして、識別された各脅威について、リスク ステートメントを作成します。リスク ステートメントは、脅威に関する情報と、脅威が万一発生した場合の、脅威の影響に関する情報を組み合わせます。

表 3.6 マスタ セキュリティ リスク リストの内容

リスク ステートメント フォーム

個々のセキュリティ リスクを分析する際に、または、特定の脅威、弱点の悪用、脆弱性に関連するセキュリティ計画の活動の際に、そのセキュリティ リスクに関する情報のすべてを文書の形式で表示すると便利です。これは、セキュリティ リスク ステートメント フォームと呼ばれます。セキュリティ プロジェクトのプロセスについてさらに詳しくは、『Microsoft Solution for Security Services Guide』を参照してください。

セキュリティ リスク ステートメントのリストには、通常、識別と評価の段階で作成されたマスタ セキュリティ リスク リストからのフィールドが含まれています。また、セキュリティ リスク管理のプロセス中に、チームが必要とする追加情報を加えることもできます。フォローアップ アクションのためにリスクがセキュリティ チームに割り当てられる場合には、セキュリティ リスク ステートメントのリストをマスタ リスク リストとは別の文書として扱う方が簡単な場合もあります。リスク ステートメント フォームを作成する際にチームが検討すべき情報は、以下のとおりです。

表 3.7 リスク ステートメント フォーム

トップ セキュリティ リスク リスト

セキュリティ リスク分析では、どの問題がアクションに値するかをセキュリティ チームが判断するのに役立つよう、各セキュリティ リスクの脅威を比較検討します。セキュリティの管理とこれに関連する計画は、他の活動から時間と労力を奪うため、セキュリティ チームにとって重要なことは、最高の価値を持つ資産を保護するために絶対的に必要な作業を行うことです。

セキュリティ リスクを監視するための単純ながら効果的な技法は、主要なセキュリティ問題のトップ セキュリティ リスク リストを作成することです。リストができれば、セキュリティが影響を受ける可能性のある他の活発な IT プロジェクトで使えるように、すべての利害関係者に公開することができます。

企業は、時間、リソース、資産など、いくつかの要因に基づいて、トップ セキュリティ リスク リストに何を掲載するかを決定する必要があります。管理すべき主要なセキュリティ リスクをいくつか選択したら、それを中心に計画を策定するために、チームのリソースを配分しなければなりません。

セキュリティ リスクのランク付けの後、チームは、セキュリティ アクション プランを総合的なセキュリティ評価計画に組み込む方法、およびセキュリティ リスク管理戦略に集中的に取り組むべきです。

セキュリティ リスクの非アクティブ化

より予防的で積極的な管理を必要とする他の問題にチームが集中できるように、セキュリティ リスクを非アクティブ化する、つまり、非アクティブとして分類することが可能です。あるセキュリティ リスクが非アクティブとして分類されることは、そのセキュリティ リスクが、その時点でその特定の脅威を追跡するのに必要な労力に値しないという判断を評価チームが下したことを意味します。セキュリティ リスクを非アクティブ化する決定は、セキュリティ リスク分析の間に下されます。

脅威の確率が事実上ゼロであり、極めてありそうもない状況のため、確率ゼロが続く可能性が高いという理由で、一部のセキュリティ リスクは非アクティブ化されます。また、資産に与える影響が、予防型の軽減戦略または対処型の危機管理戦略を策定する労力を注ぐに値するしきい値を下回るという理由で、非アクティブ化されるセキュリティ リスクもあります。そうしたケースでは、それらのセキュリティ リスクの潜在的結果を被った方が、費用効果が高いのです。

セキュリティ チームが、予測可能なすべての状況において、確率が (したがって、危険性も) 低いレベルに留まるという確信を持っていない限り、危険性が低い場合でも、この資産影響しきい値を超えるレベルでセキュリティ リスクを非アクティブ化することは、あまりお勧めできません。セキュリティ リスクを非アクティブ化することは、セキュリティ リスクを解決することと同じではないのです。非アクティブ化されたセキュリティ リスクが、ある条件の下で再び現れる場合もあります。また、セキュリティ チームがそのリスクをアクティブとして分類しなおし、セキュリティ リスクの評価活動を再開することも考えられます。

ページのトップへ

セキュリティ リスクの追跡、計画、スケジュール作成、および報告

プロセスの次の手順は、セキュリティ アクション プランで識別されたセキュリティ リスクを追跡してから、これらを改善するために、計画、スケジュール、および報告のプロセスを実装することです。前の手順で明らかにされた優先順位に基づいて、チームは、テクノロジ インフラストラクチャを修正し、新しいセキュリティ手続きとプロセスを実装することで、予防的に変更を実施します。

予防的な管理ができないリスクが存在する場合には、対処型の計画を策定しておき、イベントが引き起こされた時にそれを執行します。計画が策定された後に、修正案の実装スケジュールが作られます。最後に、チーム メンバには、対処すべきさまざまな改善タスクが割り当てられます。

スケジュール作成には、セキュリティ アクション プランを評価プロジェクト スケジュールに実装するのに必要なタスクの統合が含まれます。実装は、セキュリティ アクション プランを個人に割り当て、その状態を積極的に追跡することによります。

報告は、プロジェクトとプロセスの範囲または定義が変わったために変化したリスクを再定義する作業から成ります。このタイプの報告は、リスク変化管理としても知られています。報告の構成要素には、セキュリティ リスクをプロジェクト内で管理されているリスクのトップ ナンバーから締め出すことも含まれます。下図は、手順全体を図示したものです。

図 3.3: リスクの追跡、計画、スケジュール作成、報告
拡大表示する

目標

セキュリティ リスク計画とスケジュール作成の手順の主な目標は、セキュリティ リスク分析中に識別されたトップ セキュリティ リスクを制御するための詳しいアクション プランを策定し、それらを確実に完成するために、標準的なプロジェクト管理プロセスと統合することです。

インプット

セキュリティ リスク計画は、標準的なプロジェクト計画プロセスとインフラストラクチャと密に統合すべきです。ご注意いただきたいのは、セキュリティ評価プロジェクト自体と関連するリスクが存在することです。しかし、それらのリスクは実際のセキュリティ リスクそのものとは異なります。セキュリティ アクション プランの実装には、プロジェクト全体に対するリスクが付きまといます。このリスクは、MSF リスク管理統制の方法論を使って管理すべきです。セキュリティ アクション プランの実装に対するプロジェクト リスクには、通常、時間、金銭、リソースが含まれます。

セキュリティ リスク計画プロセスへのインプットには、マスタ セキュリティ リスク リスト、トップ セキュリティ リスク リスト、セキュリティの知識ベースからの情報だけでなく、セキュリティ アクション プランとセキュリティ実装スケジュールも含まれます。

計画のための行動

資産の危険性を少なくする計画を策定する際には、以下の点を心がけるべきです。

さまざまなプロジェクト リスク条件を減らすために、いくつかの計画アプローチがあります。以下に、その例を挙げます。

セキュリティ アクション プラン

セキュリティ アクション プランの策定には、主に 6 つの手法があります。チームは、セキュリティ リスクのアクション プランを立てる際に、ここに簡潔にリストアップした各項目に関連する質問を検討すべきです。各手法は、以下にさらに詳しく定義されています。

調査

セキュリティ プロジェクトにおけるリスクの多くは、不完全な情報を取り巻く不確実性と関係しています。知識不足と関係のあるセキュリティ リスクは、先に進む前に、脅威、弱点の悪用、脆弱性、または資産そのものについての知識を深めることによって、効果的に解決または管理できることがよくあります。

たとえば、チームには、セキュリティ実装計画を完了する前に、脆弱性の評価を行ったり、セキュリティの反復訓練を実施して、セキュリティの侵害に対応するチームの技能、または環境について、知識を深めておくという選択が可能です。チームが、リサーチを行うという決定を下した場合、セキュリティ アクション プランには、テスト対象領域、回答すべき問題、また、スタッフの配置、必要な設備など、適切なリサーチ提案を含めるべきです。

容認

セキュリティ リスクの中には、特に自然災害と関連する脅威などのように、効果的な予防や是正策を使って介入することが事実上不可能なものがあります。したがって、セキュリティ チームは、セキュリティ問題を単に受け入れるだけになる場合があります。しかし、このような場合でも、予防型の軽減計画または対処型の危機管理計画を策定すべきです。セキュリティ リスク監視の責務を継続するには、適切なリソースと追跡測定基準を確立する必要があります。

注 容認は、"何もしない" 戦略ではありません。企業のセキュリティ アクション プランの中に、チームがリスクを受け入れることを決めた根拠を文書化しておくべきです。

回避

セキュリティ リスクが、評価の範囲を変えることで極めて容易に制御できるものとして識別される場合があります。そのような方法で評価の範囲を変えてセキュリティ リスクを全部 "排除" することを回避テクニックと言います。これらの場合、セキュリティ アクション プランには、その決定の根拠を文書化して記録しておくべきです。また、セキュリティ実装計画は、設計の変更や範囲変更のプロセスが必要となった場合に、必ず更新しなければなりません。

移管

時には、管理を目的に、セキュリティ リスクを企業外の別の組織に移管することも可能です。セキュリティ リスクが移管される例として、以下が挙げられます。

セキュリティ リスクを移管しても、リスクがなくなったわけではありません。一般に、移管戦略によって新たなセキュリティ リスクが生まれ、やはり予防型の管理が必要になります。しかし、リスクを移管することで、脅威は、より許容しやすいレベルに下がります。たとえば、IT インフラストラクチャをアウトソーシングすれば、セキュリティ リスクをセキュリティ チームの外に移管することができます。しかし、企業が保護しようとしている資産の機密性に関して、新しいセキュリティ リスクを生み出す可能性があります。

軽減

セキュリティ リスクの軽減には、セキュリティ リスクの発生を予防すること、または影響や結果を許容レベルまで低下させるための予防的行動を取ることが含まれます。軽減によってセキュリティ リスクを予防的に管理することは、回避の手法とは異なります。これは、セキュリティ リスクを回避する場合には、評価の範囲を変えることで、許容できないリスクのある活動が発生するのを避けるのに対して、軽減の場合は、脅威を予防して許容できるレベルに抑えることに焦点が当てられるためです。

セキュリティ リスクを軽減することの主な目標は、脅威が発生する確率を下げることです。たとえば、有力なパスワード ポリシーを使えば、外部のユーザーがパスワードを入手して給与体系にアクセスする確率を下げることになります。

危機管理計画

セキュリティ リスクの危機管理計画には、攻撃を予防する努力が効を奏さなかった場合にアクティブ化できる 1 つまたは複数のインシデント レスポンス計画を立てる作業が含まれます。軽減計画を持つものも含め、セキュリティ リスクのすべてを対象に危機管理計画を作成しておくことは、良い習慣です。それは、単純な理由によります。企業が予防型のセキュリティ計画をどんなに巧みに策定しても、未知の脅威、弱点の悪用、または脆弱性はやはり存在していて、資産に害を与える可能性があるのです。

セキュリティの危機管理計画では、脅威が発生した場合に何をすべきかを示すと同時に、資産影響を最小限に抑える方法と結果を重視する必要があります。チームは、インシデント レスポンス計画と事業再開計画を作成し、攻撃中と攻撃後に効果的な対応が確実にできるよう備えておくべきです。

遭遇する可能性のある脅威、弱点の悪用、脆弱性のタイプに基づいて、危機管理計画のトリガ値を確立することができます。セキュリティの場合、トリガは通常イベントです。つまり、そのイベントを収集して、適切なレスポンス チームに危機管理計画を行動に移すよう通知する方法が必要なのです。

危機管理計画のトリガには、以下の 2 つのタイプがあります。

活動のスケジュール作成

セキュリティ リスク管理と制御活動のスケジュール作成は、プロジェクトの活動全般のスケジュール作成に関して MSF が推奨する標準的な手法と変わりません。セキュリティ チームは、セキュリティの改善または制御活動がセキュリティ リスクの評価と管理の予想される部分であることを理解しておく必要があり、そのことは重要です。

アウトプット

セキュリティ アクション プランを作成することで得られるアウトプットには、上記の 6 つの手法のうちの 1 つを用いて、予防および対処の両方のタイプのセキュリティ管理計画を含めるべきです。この 6 つとは、危機管理計画の調査、容認、回避、移管、軽減、および策定です。これらのセキュリティ計画を実装するための具体的なタスクは、標準的なセキュリティ実装スケジュールの中に組み込む必要があります。テクニカルな環境に対して何らかの変化があれば、これを機能仕様の中に文書化する必要があります。

セキュリティ アクション プランとスケジュールは、コミットされているリソースと範囲における調整を説明し、結果として、セキュリティ チーム メンバが完成する個々のタスクを指定する一連のセキュリティ アクション項目になることが必要です。マスタ セキュリティ リスク リストは、予防型 (軽減) および対処型の危機管理計画に含まれる追加情報を反映するように更新する必要があります。セキュリティ リスク管理計画は、セキュリティ リスク アクション フォームの中に 1 つのドキュメント形式でまとめておくと便利です。

セキュリティ実装スケジュールとセキュリティ実装計画を更新する

セキュリティ実装計画には、予防型および対処型の両方の計画を含める必要があります。セキュリティ実装計画を更新する際には、以下の点を検討します。

チームは、以下の 3 つの時間枠において、セキュリティ リスクを監視する必要があります。

ページのトップへ

セキュリティ リスク改善策の開発

対策と作業手順の開発は、企業のセキュリティ戦略にとって不可欠です。セキュリティ リスクは、テクノロジ ハードニング プロセスを通じて、または、企業全体にわたるポリシーを開発することによって、予防的に管理できます。

多くの場合、オペレーティング システム、アプリケーション、またはデータベースの既定インストールでは、IT 管理者またはソフトウェア開発者にとって扱いやすいように、セキュリティ設定を緩めてあります。これらのテクノロジが生産展開されるまでは、展開されるテクノロジは "ハードニング プロセス" の一部でなければなりません。メンバ サーバーのハードニングと特定サーバーの役割の詳細については、このガイドの第 6 章「Base Windows 2000 Server のハードニング」および第 7 章「特定サーバーの役割のハードニング」を参照してください。

サーバーのハードニング プロセスには、既定のセキュリティ設定と不要なソフトウェア コンポーネントの削除が含まれる場合があります。IT 担当者は、ソフトウェアとセキュリティ修正プログラムの最新版をインストールするために、既知のテクノロジの脆弱性、および弱点を悪用するために使われる現行の方法についても、常に最新情報を知っておく必要があります。

セキュリティ戦略の開発プロセスには、実現していないセキュリティ リスクの追跡と報告を行うためのシステム、ポリシー、手続きの作成も含まれます。これは、テクノロジ インフラストラクチャにおける予防策の確実な機能を支援すると同時に、新しいポリシーや手続きの有効性を確認します。

また、即対応を要する不審なイベントまたは潜在的な脅威をキャッチするための報告制度も設けるべきです。セキュリティ リスクの追跡のための自動システムに加えて、手動のプロセスも使えます。セキュリティ リスクを追跡することで、プロジェクト チームは、計画を調整して、新しいセキュリティ リスクに対応することができます。

追跡は、リスク アクション プランの監視機能です。追跡は、セキュリティ アクション プランを効果的に実装するために不可欠です。追跡により、予防策または危機管理計画をタイムリーに、プロジェクト リソースの制約の範囲内で確実に完了することができます。リスク追跡の間にチームが実施する主要な活動は、リスク測定基準を監視して、計画されたリスク アクションが発効するよう、イベントが確実にトリガされるように目を配ることです。

目標

改善策の開発プロセスの目標は、必要なアーキテクチャ上の変更、および、手続きにおける新しいプロセスや変更を文書化することです。

情報の収集

セキュリティ リスク改善策の開発プロセスに対する主要な情報は、企業のセキュリティ リスクにとっての脅威、弱点の悪用、および脆弱性を特定する具体的なセキュリティ改善策と危機管理計画を含むセキュリティ リスク計画です。改善策の開発では、執行される可能性のある危機管理計画のための確認されたトリガを監視する目的で、システムとプロセスを開発することが要求されます。

開発活動

セキュリティ リスク改善プロセスの開発活動は、一般的なインフラストラクチャ展開プロジェクトの開発活動に似ています。たとえば、システムの修正プログラム用の変更管理に使う手法の開発です。インフラストラクチャに対する設計変更は、機能仕様の中に文書化する必要があります。また、新しいセキュリティ要件に対応するように、ポリシーと手続きの修正が必要な場合があります。このプロセスの間に、監視と監査の機能を提供するために新しいシステムが実装された場合、これらのシステムの設計と管理も指定する必要があります。

ポイント イン タイム トリガ 測定基準が割り当てられ、継続的に追跡される可能性のあるプロジェクト 測定基準の例として、以下を挙げることができます。

リスクの状態を報告する手続きも、この段階で策定すべきです。リスク報告は、チーム自身でも使用でき、プロジェクト委員会への外部報告としても使えるものでなければなりません。

セキュリティ チームに関して、通常のリスク状態報告では、各リスクに適用できる以下の 4 つのリスク管理状況を検討する必要があります。

プロジェクト委員会をはじめとするプロジェクトの利害関係者への外部報告に関しては、チームはトップ リスクを報告し、続いて、リスク管理アクションの状況をまとめなければなりません。リスクの以前のランキングと、各リスクがトップ リスク リストに掲載されていた回数を示すことも役に立ちます。

リスクを管理するためにプロジェクト チームが行動を起こす時に、プロジェクトの総合リスク 危険性が許容可能なレベルに近づき始めるべきです。

アウトプット

改善段階のアウトプットは、セキュリティの変化の仕様であり、それらは以下の場所で更新する必要があります。

ページのトップへ

セキュリティ改善策のテスト

セキュリティと改善策のテスト手順は、セキュリティ計画の有効性が確実にテストされるように作られています。チームは、セキュリティ アクション プランの有効性を判断するために、予防型と対処型の両方の戦略 (対策と手順) のテストと関連のある活動を積極的に実施すべきです。

新たにできた対策、ポリシー、手順の有効性を測定するために、それらが対処するように意図されている各リスクを検討すべきです。続いて、企業内の脅威、弱点の悪用、脆弱性、資産に関して、各リスクについて関連のある戦略をテストします。

セキュリティ リスク改善策のテストに基づいて、効果、有効性、およびセキュリティ トリガ イベントに対する反応性を改善するために、セキュリティ アクション プランの修正が必要になる場合があります。

セキュリティ テスト計画の執行によって学習された成果と教訓は、続いてテスト 文書に組み込まれ、企業のセキュリティに関する知識ベースの一部となります。これらの計画の有効性を判断するには、テスト中にできる限り多くの情報を取り込むことが重要です。

目標

セキュリティ改善策のテスト プロセスの目標は、プロジェクト チームがトップ セキュリティ リスクを対象に作成したさまざまなセキュリティ計画の有効性をテストすることです。セキュリティ アクション プランでは、以下について評価とテストを実施する必要があります。

情報の収集

セキュリティ リスク制御プロセスに対する情報は、各セキュリティ問題への対処に役立つように、プロジェクト チームのメンバが行うべき活動を詳述するセキュリティ アクション フォームです。テストの結果には、企業のセキュリティ要件にとって適切かどうかを判断するために、予防型および対処型の計画の有効性が文書化されている必要があります。

テスト作業

セキュリティ改善策のテスト作業では、策定された各対策とインシデント計画の有効性を測定すべきです。新しい対策が原因で発生する可能性のある新しい 2 次的なセキュリティ リスクを検出するために、セキュリティ リスク改善策のテストを継続的に実施することが重要です。

アウトプット

セキュリティ改善策のテスト手順から得られるアウトプットは、結果をまとめた文書、または、"問題データベース" です。これは、自社用のセキュリティ アクション プランの実装を完了させる方向に向かって、文書の進展を支援することができます。また、テスト チームが、どのセキュリティ戦略が役立ったか、どれが役に立たなかったか、および、新しく作られたポリシーと手続きの有効性について要約を作成すれば、役に立ちます。

ページのトップへ

セキュリティ知識を取り込む

セキュリティの評価と実装のプロセスで得られた知識は、将来使えるように取り込むべきです。これは、セキュリティ リスク評価プロセスの 6 番目で最後の段階であり、セキュリティ リスク管理活動に、戦略的、企業的、組織的な視点を加えます。

最も重要なのは、このセキュリティ評価中に策定された対策、ポリシー、手続きを将来のプロジェクト チームが再利用できるように取り込むことです。企業が将来の IT イニシアティブに着手する時に、それらのプロジェクトでは、実装される新しいソリューションが確実に安全なものとなるよう、評価によって得られた知識を活用することができます。

セキュリティ リスクの評価によって学習された知識は、最新情報を提供できるように、タイムリーな形式で取り込むべきです。セキュリティに関する知識の取り込みは、主に以下に挙げる 3 つを目的で実行されます。