セキュリティ概論
セキュリティ戦略
最終更新日: 2002年2月14日
作者 Christopher Benson (Inobits Consulting (Pty) Ltd) プログラム マネージャ Markus Vilcinskas、Peter Van Niman レビュー者 Christopher Budd、Glenn Berg 協力者 Denis Bensch、Dawie Human、Louis De Klerk、Johan Grobler (Inobits Consulting (Pty) Ltd)
マイクロソフト ソリューション フレームワーク
メモ : このホワイト ペーパーは、ベスト プラクティス シリーズの一部です。企業セキュリティのベスト プラクティスには、このシリーズを構成するホワイト ペーパーの一覧が掲載されています。 また、セキュリティの構成要素アーキテクチャも参照してください。
トピック
はじめに
セキュリティ戦略のまとめ方の概要
セキュリティ戦略定義の方法論
結果の吟味、シミュレーションの実施
ポリシーの有効性の見直し
はじめに
このドキュメントに記載されているセキュリティ方法論は、企業の IT (Information Technology) システム内のデータの可用性、整合性、および機密性を保護する戦略を、セキュリティ専門家が開発する上で役立つことを目指して設計されています。これは、情報リソース マネージャ、コンピュータ セキュリティ職員、および管理者にとって興味ある内容であり、コンピュータ セキュリティ ポリシーを確立しようとしている人には特別な価値があるものです。この方法論は、この重要なタスクにシステマチックなアプローチを提供し、最終的な予防措置として、災害時の緊急時対策を確立することまでを含んでいます。
IT システムのデータは、各種ソースからのリスク ― ユーザー エラーおよび悪意のある攻撃と悪意のない攻撃 ― にさらされています。事故は起きるものであり、攻撃者はシステムにアクセスでき、サービスを壊し、システムを使えないものにし、情報を改変、削除、または盗み出します。
IT システムは次のようなデータ状況に対して保護を加える必要があります。
機密性 - システムには未承認のままで公開されないように保護する必要がある情報が含まれています。実例 : 定期的な散布情報 (たとえば、収穫高レポート情報)、個人情報、および企業固有のビジネス情報。
整合性 - システムには未承認の、予期しない、または意図しない変更から保護する必要がある情報が含まれています。実例:国勢調査情報、経済指標、または金融トランザクション システム。
可用性 - システムにはミッション要件を満たすか、または実質的な損失を避けるために、タイムリーに利用可能な情報が含まれているか、サービスが提供されています。例:安全、生命維持、およびハリケーン予報に必須のシステム。
セキュリティ管理者は、適切なセキュリティ ポリシーと制御を開発するのに、どれだけの時間、金額、および努力を費やす必要があるのかを決定する必要があります。各組織では、具体的なニーズを分析し、リソースとスケジュールの要件と制約を決めることをお勧めします。コンピュータ システム、環境、および組織ポリシーは異なるため、おのおののコンピュータ セキュリティ サービスと戦略は一意のものになります。ただし、良いセキュリティの定理は変わらないため、このドキュメントはその定理に着目します。
セキュリティ戦略により、組織の貴重な時間を節約でき、何を成すべきかという大事な暗示が得られるのですが、セキュリティは一時的な活動ではありません。セキュリティはシステム全体のライフサイクルの中に組み込まれます。このドキュメントで説明する活動については、一般的に定期的に更新したり適宜改訂する必要があります。このような変更が必要になるのは、構成やその他の条件と状況が大きく変化するか、または組織としての規制やポリシーに変更が必要になった時点です。これは繰り返しの必要なプロセスです。この作業が終息することはないので、定期的な更新とテストを行うことをお勧めします。
セキュリティ戦略のまとめ方の概要
現状のポリシーの確認
有効なセキュリティ ポリシーと制御の組合せを確立するには、戦略を立てて現在のコンピュータ システムと、これを守るためのセキュリティ ポリシーと制御に存在する脆弱性を見つけ出す必要があります。コンピュータ セキュリティ ポリシーの現状については、以下のドキュメントの一覧を確認することで判断できます。この確認においては、存在するドキュメントの吟味だけではなく、ポリシーが欠如している分野に注意することもお勧めします。
物理的なアクセス制御のような物理的なコンピュータ セキュリティ ポリシー
ネットワーク セキュリティ ポリシー (たとえば、電子メールとインターネット ポリシー)
データ セキュリティ ポリシー (アクセス制御と整合性制御)
緊急災害回復計画とテスト
コンピュータ セキュリティの意識と訓練
コンピュータ セキュリティ管理と調整ポリシー
次のような機密情報を含むその他のドキュメント :
コンピュータの BIOS パスワード
ルーター構成のパスワード
アクセス制御ドキュメント
その他のデバイス管理パスワード
資産と既知の脅威に対する脆弱性の識別
組織のセキュリティ ニーズの査定には、既知の脅威に対する脆弱性の判断も含まれます。この査定には、組織が有している資産タイプの認識も伴うので、保護対策を立てる必要がある脅威の種類も分かります。次に典型的な資産と脅威の関連状況の例を示します。
銀行のセキュリティ管理者は、銀行情報の整合性が重要な資産であり、この整合性に妥協することで引き起こされる詐欺が重大な脅威であることが分かります。詐欺は、内部または外部からの攻撃者が引き起こすと考えられます。
Web サイトのセキュリティ管理者は、信頼性の高い情報を提供 (データの可用性) することがサイトの重要な資産であることを理解しています。この情報サービスへの脅威は、DoS 攻撃であり、外部から攻撃してくると考えられます。
法律事務所のセキュリティ管理者は、情報の機密性が重要な資産であると考えています。機密性への脅威は侵入攻撃で、内部または外部から攻撃が行われます。
すべての組織のセキュリティ管理者は、システム上の情報の整合性はウィルス攻撃により脅威にさらされることを理解しています。ウィルスは従業員が仕事用コンピュータにゲームをコピーすることにより持ち込まれたり、ビジネス機能を混乱させようという、外部の人による意図的な試みにより持ち込まれます。
考えられる攻撃方法、ツール、およびテクニックの識別
脅威の一覧表があれば (たいていの組織ではいくつか所持していると思われます)、セキュリティ管理者は、攻撃で使用される可能性があるいろいろな方法、ツール、およびテクニックを識別できます。方法としては、ウィルスやワームからパスワードと電子メール解析まで多岐にわたります。セキュリティ対策をたてても、それをくぐり抜ける新しい方法、ツール、およびテクニックが考案されていくため、管理者は常にこの分野の知識を更新していくことが重要です。
予防戦略と対処戦略の確立
各方法に対するセキュリティ計画としては、対処戦略だけでなく予防戦略も立てておくことをお勧めします。
予防戦略または攻撃前戦略は、既存のセキュリティ ポリシーの脆弱性を最小限にして緊急時対策を立てるための手順を示します。攻撃が引き起こす被害と、この攻撃中に攻略された弱点と脆弱性を判断すると、予防戦略の開発に役立ちます。
対処戦略または攻撃後戦略は、セキュリティ要員が使用して、攻撃による被害の程度を評価し、被害を修復または予防戦略で作成した緊急時対策を実施し、この経験と教訓をドキュメントにまとめ、できるだけ早急にビジネス機能を再開させるのに役立ちます。
テスト
セキュリティ戦略の最後の要素であるテストとテスト結果の確認は、予防戦略と対処戦略が組み込まれてから実施されます。テスト システムまたは研究室のシステムへの攻撃をシミュレーションすることで、どこに脆弱性が存在するのかを評価でき、これに応じてセキュリティ ポリシーと制御を調整できます。
このようなテストは、悲惨な結果をもたらすことがありますので、実際の生産システムでは行わないことをお勧めします。しかし、予算の制約で研究室やテスト用のコンピュータがない場合には、攻撃のシミュレーションは不可能になります。テストに必要な資金を確保するためには、攻撃のリスクと結果だけでなく、テスト プロシージャを含めたシステムの保護に必要なセキュリティ対策について、管理職に意識しておいてもらうことが重要になります。可能ならば、すべての攻撃シナリオを物理的にテストしてドキュメントを作成し、実装すべき最良のセキュリティ ポリシーと制御を決定します。
洪水や落雷といった自然災害のような、ある種の攻撃についてはテストできませんが、シュミレーションを行うことは役に立ちます。たとえば、すべてのサーバーが被害を受け焼失する結果となるサーバー室火災をシミュレーションします。このシナリオでは、管理者とセキュリティ要員の反応性をテストし、組織を稼働状態に戻すのにどれぐらいの時間がかかるのかを確認するのに役立ちます。
セキュリティ ポリシーと制御のテストと調整は、繰り返しプロセスです。これは終わることはないので、定期的に評価、改訂して、改善を実現していきます。
事故対応チーム
実践力を高めるには事故対応チームの設置が求められます。事故対応チームをセキュリティ専門家による予防努力の中に組み込むことをお勧めします。これに含まれるものを示します :
事故処理ガイドラインの作成
事故またはイベントに対応するソフトウェア ツールの識別
その他のコンピュータ セキュリティ ツールの研究開発
訓練と意識向上活動の実施
ウィルスに関する研究の実施
システム攻撃に関する研究の実施
このような努力により、組織が利用できる知識と事故の発生前と発生中に発行する情報を提供できるようになります。
管理者は、セキュリティ管理者と事故対応チームがこのような予防機能を完了した後に、事故の処理責任を事故対応チームに引き渡すようにすることをお勧めします。これはセキュリティ管理者がチームに関与したり一員となっていてはいけないことを意味しているのではなく、管理者の手がいつも空いているとは限らず、チームが自力で事故を処理できるようになるべきであることを意味しています。このチームはウィルス、ワーム、またはその他の悪意のあるコード、侵入、いたずら、自然災害、および内部からの攻撃のような事故に対応する責任を有します。このチームはコンピュータやネットワーク セキュリティに関連するあらゆる異常なイベントの分析にも関与することをお勧めします。
セキュリティ戦略定義の方法論
次のセクションでは、起こりうる攻撃と脅威を最小化するためのセキュリティ ポリシーと制御を実装するのに使用できるコンピュータ セキュリティ戦略を定義する方法論を議論します。この方法は悪意のある攻撃、悪意のない攻撃、または自然災害のようにコンピュータ システムに加えられるあらゆるタイプの攻撃に利用できるので、異なる攻撃シナリオにも繰り返して再利用可能です。この方法論は、「セキュリティへの脅威」で議論しているさまざまなタイプの脅威、攻撃方法、および脆弱性に基づくものです。次のフローチャートは、この方法論の概要を示しています。
.gif)
フローチャート 1
発生する攻撃の予測 / リスク分析
フローチャート 1 で概要を示した方法論の最初のフェーズでは、予想される攻撃と、この攻撃の防御方法を決定します。すべての攻撃に対して準備することは不可能です。このため、組織で最もあり得ると考える攻撃を想定します。攻撃を受けてから被害を修復するよりは、攻撃を防止または被害を最小限に食い止める方が賢明です。
攻撃を最小限にするためには、システムにリスクを引き起こすさまざまな脅威を理解し、セキュリティ制御を弱めるのに利用するテクニックを理解し、セキュリティ ポリシーに存在する脆弱性を理解することが必要です。このような攻撃の 3 つの要素を理解すると、発生タイミングや場所は分からないまでも、発生を予測するのに役立ちます。攻撃の予測は可能性を予測する問題であり、攻撃のさまざまな側面の理解に依存します。攻撃のさまざまな側面は、式で示すことができます。
脅威 + 動機 + ツールとテクニック + 脆弱性 = 攻撃
脅威の各タイプについて
システムに攻撃を行う可能性のあるすべての脅威を検討します。これには、悪意のある攻撃者、悪意のない脅威、および自然災害を含みます。以下の図はシステムに対するさまざまな脅威を分類したものです。
.gif)
図 1: システムに対する脅威
知識の浅い、または不注意な従業員や自然災害のような脅威には、動機や目標はありません。このため、攻撃を仕掛ける際にあらかじめ決まった方法、ツール、またはテクニックは使用されません。これらの攻撃またはセキュリティ侵害のほとんどすべては内部で生じるものです。組織外の人が仕掛けることはまずありません。
このようなタイプの脅威に対しては、セキュリティ要員はフローチャート 1 のガイドラインに従って、別々の予防戦略と対処戦略を作成する必要があります。
攻撃方法の各タイプについて
攻撃を仕掛けるためには、悪意のある攻撃者はシステム、セキュリティ ポリシー、および制御に存在するさまざまな脆弱性を攻略するための方法、ツール、またはテクニックを必要とします。悪意のある攻撃者は異なる方法を使用して同じ攻撃を仕掛けることができます。このため、防御戦略は、脅威の各タイプで使用される方法のタイプごとにカスタマイズする必要があります。繰り返しますが、セキュリティの専門家は、攻撃者が使用するさまざまな方法、ツール、およびテクニックの現状を把握しておくことが重要です。これについての詳細は、「セキュリティの脅威」で議論しています。次に、このようなテクニックを一覧にしたものを示します。
サービス拒否 (DoS) 攻撃
侵入攻撃
ソーシャル エンジニアリング
ウィルス
ワーム
トロイの木馬
パケット変更
パケット再生
パスワード解析
電子メール解析
予防戦略
予防戦略とは、攻撃が起きる前に攻撃を防止するために、前もって行う手順のことです。このステップでは、攻撃がどのようにコンピュータ システムに被害を与え、どの脆弱性を攻略するのかを見ます (ステップ 1 とステップ 2)。これらの評価で得られた知識は、攻撃を制御したり最小化するセキュリティ ポリシーを作成する際に役立ちます。次に示すのが予防戦略の 3 ステップです。
攻撃が引き起こす被害の判断
攻撃が攻略する脆弱性と弱点の判断
特定のタイプの攻撃に対して、システムの弱点と判断された脆弱性と弱点の最小化
このステップにしたがって攻撃の各タイプを分析すると副効果があります。異なる攻撃で多数の要因が重複するので、あるパターンが見えてきます。このパターンは、企業に最大のリスクをもたらす脆弱な部分を識別する際に役立ちます。データを失うコストとセキュリティ コントロールを実装するコストの比較をすることも必要です。リスクとコストの比較検討はシステム リスク分析の一環であり、「セキュリティ計画」のホワイト ペーパーにて議論しています。
セキュリティ ポリシーと制御は、すべての攻撃を除去するのに万全であるとは言い切れません。このため、セキュリティ コントロールが突破された場合のことを考えて、緊急時対策と回復計画を作成しておく必要があります。
攻撃により予想される被害の判断
予想される被害は、コンピュータのちょっとした不調から悲惨なデータ損失までの範囲にわたります。システムに引き起こされる被害は攻撃のタイプに依存します。可能ならば、異なるタイプの攻撃により引き起こされる被害についても、テスト環境または研究室環境を使用して明らかにしておきます。これによりセキュリティ要員は実験的な攻撃により引き起こされる物理的被害を理解できます。すべての攻撃が必ずしも同じ被害を引き起こすとは限りません。以下に実行すべきテスト例をいくつか示します。
研究室システムで電子メールのウィルス攻撃をシミュレーションして、どのような被害が引き起こされ、どのようにしてその状況から回復するかを考察します。
ソーシャル エンジニアリング手法を使用して、何も知らない従業員からユーザー名とパスワードを聞き出してみて、従業員が同意するかどうかを観察します。
サーバー室が火災に合った場合にどのようなことが起きるかをシミュレーションします。失われる生産時間と回復に要する時間を測定します。
悪意のあるウィルス攻撃をシミュレーションします。1 台のコンピュータを回復するのに要する時間をメモしておき、システム内で感染したコンピュータ数で掛け算を行い、ダウン時間または生産性損失量を確認します。
以前に述べた事故対応チームと協力して行うのも良い考えです。発生した被害のすべてのタイプを突き止める作業は個人よりはチームで行うものだからです。
攻撃により攻略される脆弱性または弱点の判断
特定の攻撃が攻略する脆弱性が発見されたならば、現在のセキュリティ ポリシーと制御を変更するか、新しいものを作成して、このような脆弱性を最小限にします。攻撃、脅威、および方法のタイプを判断できると、既存の脆弱性を容易に見つけられるようになります。これは実際のテストで証明できます。
次に示すのは起こり得る脆弱性の一覧です。これらは実際に存在する物のほんの一部だけを示しています。物理的セキュリティ、データ セキュリティ、およびネットワーク セキュリティの分野の例をあげておきます。
物理的セキュリティ
サーバーにアクセスする際の施錠と入室手続きは存在していますか。
十分な空調が行われていて、エア フィルタは定期的に清掃されていますか。空調のダクトは侵入に対する安全対策が施されていますか。
遮断されない電源と発電機が存在していて、保守手順の中でチェックされるようになっていますか。
消火設備およびポンプ設備があって、この機器に適切な保守手順がありますか。
ハードウェアとソフトウェアの盗難を防止する仕掛けがありますか。ソフトウェア パッケージとライセンス、およびバックアップは金庫の中にしまわれていますか。
データ、バックアップ、およびライセンス ソフトウェアをサイト外とサイト内に格納する手順は存在していますか。
データ セキュリティ
攻撃を制限するために、どのようなアクセス制御、整合性制御、およびバックアップ手順が設定されていますか。
ユーザーが同意する必要があるプライバシ ポリシーと手順がありますか。
データ アクセス制御 (承認、認証、および実装) には、どのようなものがあります。
データとアプリケーションの管理には、どのようなユーザー責任が存在していますか。
直接アクセス記憶装置の管理テクニックは定義されていますか。ユーザー ファイルの整合性への影響はどのようなものですか。
機密データを扱う手順はありますか。
ネットワーク セキュリティ
どのような種類のアクセス制御 (インターネット、 WAN (Wide Area Network) 接続等) がありますか。
認証手順はありますか。LAN (Local Area Network)、WAN、およびダイヤルアップ サーバーにどのような認証プロトコルを使用していますか。セキュリティ管理の責任者は誰ですか。
どのような種類のネットワーク メディアを使用していますか。たとえば、ケーブル、スイッチ、ルーター等。これらのメディアにはどのようなタイプのセキュリティがありますか。
ファイルとプリント サーバーにセキュリティは実装されていますか。
現状の組織では、インターネット、 VPN (Virtual Private Networks)、電子メール システム、およびリモート アクセスに暗号化と暗号技術を利用していますか。
組織では、ネットワーキング標準に準拠していますか。
予想される攻撃で攻略される脆弱性と弱点の最小化
以前の評価で決定されたセキュリティ システムの脆弱性と弱点を最小化することが、効果的なセキュリティ ポリシーと制御を開発する最初のステップです。これは予防戦略の大詰めとなるところです。脆弱性を最小にすることで、セキュリティ要員は、攻撃を受ける可能性と、攻撃を受けたときの攻撃の有効性の両方を最小にできます。あまりにも厳格な制御を実現しないように注意します。厳格になりすぎると、情報の可用性の方が問題となるからです。セキュリティ コントロールと情報へのアクセスの両者のバランスを注意深くとる必要があります。権限のあるユーザーには、情報はできるだけ自由に利用することができる環境作りをお勧めします。
緊急時対策の作成
緊急時対策は、攻撃がシステムに侵入してデータまたはその他の資産に被害を与えて、通常のビジネス運用を停止させて生産性を阻害する場合に作成する代替案です。この対策は、システムの復旧までに時間がかかる場合に利用します。最終目標としては、データの可用性、整合性、および機密性を維持することです－これがいわゆる「プラン B」です。
攻撃のタイプごとの計画、または脅威のタイプごとの計画、あるいは両方の計画を作成することをお勧めします。各プランは、攻撃がセキュリティ ポリシーを突破した場合にとるべきステップの集まりで構成されています。この緊急時対策は以下のように組み立てることをお勧めします :
組織を機能させ続けるために、誰がいつ、どこで何を行う必要があるかを検討します。
スタッフに最新の緊急時対策ステップを身に付けてもらうために定期的に訓練を行います。
バックアップの復元まで議論します。
ウィルス ソフトウェアの更新を議論します。
生産ラインを別の場所または別サイトに移すことまで議論します。
以下のポイントは、緊急時対策を作成するために評価すべき各種評価タスクの概要を示すものです。
組織のセキュリティ ポリシーと制御を評価して、脆弱性を最小にする機会を提供します。評価では組織の現在の緊急時対策と手順を検討し、緊急時対策に組み込むことをお勧めします。
現状の緊急対応手順の内容と、ビジネスの連続運用に与える影響とを評価します。
攻撃に対する計画的な対応を作成し、緊急時対策の中に組み込みます。この際に被害を限定し、攻撃がデータ処理操作に与える影響を最小化する範囲に注意します。
適切性を評価するため、最新のドキュメントと災害からの回復テストを含むバックアップ手順を評価し、緊急時対策の中に含めます。
災害からの復旧計画を評価して、一時的または長期運用環境を提供することの適切性を決定します。災害からの復旧計画には、必要なセキュリティ レベルのテストを含めて、セキュリティ要員が回復プロセス、一時操作、および組織が元の処理サイトに戻る動き、または新しい処理サイトに移る動きを通じて、セキュリティを推進し続けられるようにします。
上記タスクによる発見事項の概要を示す詳細文書を作成します。このドキュメントには、次の一覧を付けることをお勧めします。
緊急時対策をテストするシナリオ
依存性、組織外からの計画的援助、および重要なリソースを獲得することの難しさが計画に与える影響。
回復操作に見られる優先度一覧、およびそのような優先度を確立する際の論理的根拠
対処戦略
対処戦略は、攻撃に対する予防戦略が失敗した場合に実行されます。対処戦略では攻撃後または攻撃中に取るべきステップを定義しています。これは引き起こされた被害、および攻撃で攻略された脆弱性を明らかにし、なぜそのようなことが起きたのかを判定し、攻撃によって引き起こされた被害を修理し、もし緊急時対策が存在していれば、その実装に役立ちます。対処戦略と予防戦略の両方を一緒に機能させて、セキュリティ ポリシーと制御を開発し、攻撃と攻撃中に引き起こされる被害を最小にします。
攻撃中または攻撃後に実行するステップに事故対応チームを含めて攻撃を評価し、ドキュメントにまとめて教訓を得ることをお勧めします。
被害の査定
攻撃中に引き起こされた被害を確認します。復旧操作をできるだけ早く始められるように、この作業は迅速に行うことをお勧めします。被害の確認に時間がかかる場合には、緊急時対策を実行して、通常のビジネス運用と生産作業を継続できるようにします。
被害の原因の確定
被害の原因を確定するためには、攻撃がどのリソースに狙いを定めたのか、およびサービスにアクセスし破壊するために攻略した脆弱性は何かを理解する必要があります。システム ログ、監査ログ、およびオーディット トレールを確認します。このような確認を行うと、攻撃がシステムのどこから始まったか、他に影響を受けたリソースは何かを発見するのに役立ちます。
被害の修復
通常のビジネス運用を再開し、攻撃で失われたデータを復旧するために、できるだけ迅速に被害の修復を行うことがとても重要になります。組織の災害回復計画と手順 (「セキュリティ計画」で議論します) では、復旧戦略を論じることをお勧めします。事故対応チームも参加して回復、復元プロセスを処理して、復元プロセスで指導的役割を発揮することをお勧めします。
ドキュメント化と学習
攻撃が起きてしまった場合には、ドキュメントにすることが重要です。ドキュメント化では、攻撃について分かっていることをすべて論じることをお勧めします。この中には次のことを含めます。引き起こされた被害 (ハードウェア、ソフトウェア、データ損失、生産性の損失)、攻撃中に攻略された脆弱性と弱点、失われた生産時間量、および被害を修復するための手順。このようにして作成したドキュメントは、将来の攻撃の防止または被害の最小化のために予防戦略を修正する際に役立ちます。
緊急時対策の改善
もし、緊急時対策がすでに作成されているなら、それを改善し、時間を節約して業務を継続的に正しく機能させることができます。緊急時対策がまだ作成されていない場合には、以前のステップで作成したドキュメントを元にして適切な対策を作成します。
結果の吟味、シミュレーションの実施
セキュリティ戦略の 2 番目のステップは、最初のステップ (攻撃の予測) における調査結果を吟味することです。攻撃後または攻撃を防いだ後に、システムの観点から攻撃結果を確認します。この確認には以下の点が含まれます。生産性の損失、失ったデータまたはハードウェア、および回復に要する時間。また、攻撃をドキュメントに記録し、可能ならば攻撃の発生地点を追跡し、攻撃を仕掛けるのにどのような方法が使われたのか、およびどのような脆弱性が攻略されたのかを追跡します。最良の結果を得るためにテスト環境でシミュレーションを行います。
ポリシーの有効性の見直し
起きた攻撃に対する防御にポリシーが存在しているなら、有効性について確認してチェックすることをお勧めします。何もポリシーが存在しないのなら、将来の攻撃を最小化または防ぐために新しいポリシーを作成する必要があります。
ポリシーの適宜な調整
ポリシーの有効性が標準にまで達していないのなら、それに応じてポリシーを調整することをお勧めします。ポリシーの更新は、関係する管理要員、セキュリティ オフィサ、管理者、および事故対応チームで協調して実施する必要があります。ポリシーはすべて、組織の一般的な規則とガイドラインに従うべきです。たとえば、作業時間は朝の 8 時から夕方の 6 時までとします。セキュリティ ポリシーが存在している場合も新規に作成する場合も、ユーザーがシステムにログオンできる時間はこの時間帯のみとします。
実例
例 1: 悪意のない攻撃
従業員の John Doe は、自分のハードディスクに格納した情報を失いたくありません。John はこの情報のバックアップを作成したいので、サーバー上の自分のホーム フォルダにコピーしますが、そのサーバーは会社のメインのアプリケーション サーバーでもありました。サーバー上のホーム フォルダには、ユーザー用に定義したディスク割り当てスペースがありません。John のハードディスクには 6.4GB の情報があり、サーバーには 6.5GB の空きスペースがあります。アプリケーション サーバーには、ディスク スペースがないため、サーバーは更新と要求に対する応答を停止します。結果としては、ユーザーはアプリケーション サーバー サービスを否定されて、生産性が停止します。以下に、John がハードディスクを自分のホーム フォルダにバックアップすると決める前に行うべきであった方法論を示します。
.gif)
例 2: 悪意のある脅威 (外部の攻撃者)
Jane Doe は、ウィルスを作成し、趣味でシステムをハッキングしています。Jane は、世界中の電子メールシステムを破壊する新しいウィルスをネットワークに流します。
.gif)
例 3: 悪意のある脅威 (内部の攻撃者)
従業員の Bob Roberts は、宇宙船を設計する会社で働いています。Bob は競争相手から接触され、Bob の会社の最新設計の「Flingbot 2000」の情報を盗み出す見返りとして大金を提示されました。Bob には情報にアクセスするのに必要なアクセス権がありません。Bob は電話で管理者になりすまして、アクセス権を持つ従業員と会話しています。Bob は、サーバーの定期的な管理者作業を行っていると従業員に告げて、サーバー上のレコードと照合するために従業員のユーザー名とパスワードが必要であると伝えます。その従業員は承諾して、Bob にユーザー名とパスワードを教えます。
.gif)
例 4: 悪意のない脅威 (自然災害)
XYZ 社はサーバー室に火災保護検知システムを備えていません。同社のコンピュータ システムの管理者が、数冊のマニュアルを空調機の上に残していきます。夜間になって、空調機はオーバーヒートし、火災を発生させ、サーバー室とオフィス数室を焼失しました。
.gif)
このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。
このドキュメントは情報提供のみを目的としています。明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
Microsoft は、米国 Microsoft Corporation の米国およびその他の国における登録商標です。