4<- index ->6


5. セキュリティインシデントへの対応 English

この章では、コンピュータセキュリティインシデントが、ホスト、ネットワーク、サイトもしくは複数サイトの環境に、発生する以前・ 発生時・発生後に利用するガイダンスを提供します。コンピュータセキュリティが、突破されたとき、実践における考え方は、計画に従って実行するということです。これは、その突破が外部の侵入者の攻撃によるものであれ、予期せぬダメージであれ、学生がソフトウエアの脆弱性を攻略する何か新しいプログラムをテストしていて起きたのであれ、従業員の不満によるものであれ、いえることです。上記のような起こりうる各イベントについては、あらかじめ適切な緊急時対応計画 (コンティンジェンシープラン)に対応を示しておく必要があります。

伝統的なコンピュータセキュリティにおいて、サイト全体のセキュリティ計画において極めて重要であるにもかかわらず、通常、もし攻撃が起きたら実際にどのように 対応するかについて、あまり注意を払っていません。その結果、攻撃を受けている最中には、多くの意思決定が急いでなされて、インシデントの攻撃元をたどる危険を犯し、訴訟のために使用される証拠も収集し、そのシステムの復旧の準備もし、システム中の価値あるデータの保護する、といったものになってしまいます。

最も重要なことのひとつで、しばしば見落とされていることは、有効なインシデントへの対応の恩恵は、経済的なものであるということです。技術者と経営管理者の両者がインシデントに対応するようにするのには、かなりの(人的)資源が要求されます。 インシデントを効率的に対応する訓練がなされているならば、それが起きた場合、より少ない時間ですみます。

世界規模のネットワークであるがために、大部分のインシデントは、ひとつのサイトにとどまりません。ひとつの OS(オペレーティンング システム)の脆弱性は、無数のシステムについてもいえることがあり、そして脆弱性への攻撃の多くは、ネットワーク内部からのものです。それゆえ、できるだけ早く関連するのすべてのサイトに知らされることが重要です。

他の恩恵は、広報(パブリック リレーションズ)と関係があります。コンピュータセキュリティインシデントについてのニュースは、その組織体の信用にダメージを与えるものです。現在と将来の顧客にとって有効なインシデントへの対応は、ネガティブな面を最小限にするものです。

有効なインシデントへの対応についての最後の恩恵として、法的な論点と関連があります。近い将来、組織体が、そのノードのひとつがネットワーク攻撃に使用されたことに責任を負うことも考えられます。同様に、パッチや対策を開発する人は、もしパッチもしくは対策が有効でなくシステムを変更してしまうときや、パッチもしくは対策自体がシステムを破壊してしまうときに、訴えられることになるかもしれません。オペレーティング システムの脆弱性と、攻撃のパターンを知り、これらの潜在的な脅威に対して適切な方法を採用することが、想定される法的な問題を避けるのに重要です。

この章の各節では、セキュリティ インシデントに対応する、あなたのサイトのポリシーを作成するための概要と入門を提供いたします。 節は以下のとおりです。:

(1) 準備と計画立案 (インシデントに対応する際の目的と目標事項)
 
(2) 通知 (インシデントが起きた場合に、誰が連絡先となるか)
  • ローカルのマネージャーや担当者
  • 法執行機関と捜査機関
  • コンピュータ セキュリティ インシデントへの対応を行うチーム
  • 被害を受けた関連サイト
  • 内部のコミュニケーション
  • 広報(パブリック リレーションズ)とプレス リリース
(3) インシデントの識別 (インシデントであることと、その重要性)
 
(4) 対応 (インシデントが起きた場合、何をすべきか)
  • - 通知(インシデントについて誰に通知すべきか)
  • - 証拠とログの保護 (どの記録がインシデントの前と最中、後に採る必要があるか)
  • - 隔離(どのようにダメージを限定することができるか)
  • - 根絶(どのようにインシデントの原因を絶つか)
  • - 復旧(どのようにサービスとシステムを再度築くか)
  • - フォローアップ(インシデント後にはどのような行動がとられるべきか)
(5) インシデント後 (インシデント後の教訓は何か)
 
(6) 行政的なインシデントへの対応

この章では、以降、上記の重要な論点のそれぞれに関連した論点を掘り下げ、インシデントに対応するサイトのポリシーに何が含まれるべきか、についてのガイダンスを提供いたします。

5.1 インシデントに対応するための準備と計画立案 English

インシデントへの対応の一部として、まず、インシデントが起きる前にインシデントに対応する準備をしていること、があげられます。これには、各章で説明したように、適当なレベルの防御を築くことが含まれます。こうすることによって、インシデントが実際に起きたときのダメージを限定するとともに、あなたのサイトがインシデントに備えるのに役立ちます。防御には、インシデントへ対応する、あなたの組織体もしくはサイトのための緊急時対応計画(コンティンジェンシープラン)の一部としてのガイドラインの準備も含まれます。文書化された計画を用意することによって、インシデントの過程で起きる多くの曖昧さをなくし、より適切で周到な対応ができるようになります。インシデントが起きる前に提案された計画を「予行演習」でテストすることが特に重要です。 チームによっては、予行演習と同時に働くタイガー チームを雇うことさえ検討するかもしれません。 (注: タイガーチームとは、システムのセキュリティの突破を試みる専門家のチームです。)

インシデントへの効率的な対応を学ぶことは、多くの理由で重要です。:

(1) 侵される可能性のある資産の保護。
(2) インシデントがこれらのサービスを必要としなかったらもっと 効果的に使用できた資源の保護。
(3) (政府もしくは他の)規制に従うこと。
(4) あなたのシステムが他のシステムに対する攻撃に使用されることを予防する。 (これによってあなたは法的に不利な立場に陥る可能性があります。)
(5) ネガティブな面の暴露の可能性を最小限にする。

いかなる事前に計画された手続きに際しても、インシデントへの対応の目的に注意が払われる必要があります。これらの目的は、サイトごとに優先順位がつけられます。インシデントへの対応のための一定の目標事項を書き出すことができます。:

(1) どのようにそれは起きたのかを書き出す。
(2) 以降、どのようにして同じ脆弱性ををついた攻撃を避けるかを見つける。
(3) 拡大と以降のインシデントを避ける。
(4) インシデントの影響とダメージを評価する。
(5) インシデントから復旧させる。
(6) ポリシーと手続きを必要に応じて更新する。
(7) 誰がそれを行ったのかを見つける。(適切で可能な場合)

インシデントの性質に起因して、その問題に起点の分析をとるか、システムや サービスの復元をとるかの間に、コンフリクトが生ずる可能性があります。 (最重要システムの一貫性の確認のように、)全体の目的は、インシデントを 分析することとは違う理由によるかもしれません。 当然ながら、これは重要な経営管理の意思決定です。; しかしすべての関連主体は、分析しないと、同様のインシデントが再発する可能性があることを認識する必要があります。

インシデントに際してうまく行動できるように、事前に行動の優先順位をつけておくことも重要です。しばしば、インシデントは複雑で、一度にすべてを対応することができない場合があります。; そこで優先順位が重要となります。優先順位は、団体ごとに異なるでしょうが、下に示した優先順位が、あなたの組織体の対応を定めるための出発点を提供します。:

(1) 優先順位 1 -- 人命と人々の安全を守る。; 人命は常に他のすべての考慮事項に優先します。
(2) 優先順位 2 -- 機密扱いのデータや慎重を要するデータを守る。機密扱いや慎重を要するシステム、ネットワーク、サイトが攻撃されるのを 予防する。 被害を受けた、機密扱いのシステムや慎重を要するシステム、ネットワーク、 サイトに、すでに起きた突破について通知する。 (あなたのサイトまたば政府による規制を認識してください。)
(3) 優先順位 3 -- 他のデータを守る。 知的財産権のあるデータ、科学的データ、経営管理のデータ、 その他のデータを含みます。なぜならば、データの喪失は、資源のコストがかかるからです。他のシステム、ネットワーク、サイトの攻撃を予防し、すでに被害を受けたシステム、ネットワーク、サイトに突破について通知します。
(4) 優先順位 4 -- システムへのダメージを予防する。 (つまり、システム ファイルの消失または更新、ディスク ドライブへのダメージ等) システムへのダメージは、費用のかかるダウンの時間と復旧の結果を招く 可能性があります。
(5) 優先順位 5 -- (プロセスを含む)コンピューティング資源の崩壊を最小限にする。多くの場合、システムをシャットダウンするか、ネットワークから切断する方が、データもしくはシステムのダメージのリスクにさらすよりもよいといえます。サイトは、シャットダウンや切断と、維持することの間のトレードオフを 評価する必要があるでしょう。たとえ、さらなるダメージが起きても、システムを維持することを 要求するサービス契約がある場合もあるでしょう。 しかし、ダメージとインシデントの範囲が広い場合には、サービス契約は破られねばならないでしょう。

優先順位を決定するのに重要な教訓は、ひとたび人命と国家のセキュリティの考慮事項が対応されたら、通常、データを保存することの方がシステムのソフトウエアやハードウエアよりも重要です。インシデントにおいては、ダメージや損失は全く望まないのですが、システムが 変更されてしまうこともありえます。 しかし、その損失もしくはデータ(特に、機密扱いのデータや知的財産権のあるデータ) の変更は、通常、いかなる環境においても受け入れ難いものです。

他の重要な関心事は、インシデントが起きたシステムやネットワーク以外の他者の被害です。政府規制の範囲内で、できるだけ早く被害を受けた主体に通知することは、常に重要です。この論点の法的な教訓として、これ以上の遅れや、管理者にとっての不確実性を避けるために、これは計画された手続きに含まれている必要があります。

セキュリティ インシデントに対応するすべての計画は、ローカルのポリシーと規制に従ったものである必要があります。 機密扱いの情報を扱う政府や民間のサイトは、遵守すべき固有のルールをもっています。

あなたのサイトで選択された、インシデントにどのように対応するかについてのポリシーが、あなたの対応を形成します。例えば、もしあなたのサイトが侵入者が捕まえられたときに対抗手段をとることを計画していなければ、侵入者を監視、追跡するメカニズムをつくることは、 あまり意味をもちません。他の組織体では、あなたの計画に影響を与えるポリシーをもっているかもしれません。しばしば、電話会社は、電話の追跡情報を法執行機関にだけ発表します。

インシデントに対応することは、 退屈で、多くのルーティン(定型的)業務を必要とします。これらは、サポートする人材で対応することができます。 技術者を解放するためには、次のような仕事を補助するスタッフを任命すること が有用です。: コピー 、FAX 等。

 

5.2 通知と連絡先 English

実際にインシデントが起きる前に、様々な人々と連絡をとれるようにすることが重要です。多くの場合インシデントは、緊急事態ではありません。 確かに、あなたがその行為を内部的に扱うことができる場合もあるでしょう。 しかし、他の外部の部門がインシデントへの対応に参加する必要がある場合も 多くあります。 これらの追加的な連絡先には、現場のマネージャーやシステム管理者、 インターネット上の他のサイトの運営に関する連絡先や、様々な捜査機関が 含まれます。インシデントが起きる前にこうした連絡先を知っておくことは、 あなたのインシデントへの対応のプロセスを、より有効にするのに有用です。

各種の連絡先のために、特定の「連絡窓口(POC:Points of Contact)」が定められる必要があります。これらは、技術的もしくは運用的な性格をもっており、サービスプロバイダーやベンダーとともに、法的機関もしくは捜査機関が含まれます。このような連絡を確立する際には、各連絡先ごとにどれだけの量の情報が共有されるかを決定することが重要です。あらかじめ、どの情報がサイトのユーザに共有されるか、(プレス(報道関係者)を含む)公衆に共有されるか、他のサイ トと共有されるかを定めることが特に重要です。

これらの論点を、インシデントへの対応に責任ある現地の人に提示することが 特に重要です。なぜならば、その人は実際に他へ通知する責任があるからです。これらのカテゴリーごとの連絡先のリストは、インシデントにおいては、 この人にとって時間を節約する重要なものです。適当な人物を、多くの急ぎのイベントが進行するインシデントの最中に 見つけるのは極めて困難です。すべての関連の電話番号を(電子メール アドレスと FAX 番号も) サイトのセキュリティ ポリシーに含めることが強く推奨されます。インシデントの対応に直接関与するすべての人々の名前と連絡先情報は、このリストの先頭にあるべきです。

5.2.1 現場のマネージャと担当者 English

インシデントが進行中の際の主要な論点は、誰が複数の当事者の調整を行う責任者であるかを決定することです。 よくある失敗は、多くの人が、個々に独自に働き、協調しないことです。これではそのイベントの混乱を増すだけであり、おそらく時間の浪費または徒労に終わるでしょう。

唯一の連絡窓口は、インシデントへの対応に責任のある人かもしれませんし、そうでない場合もあります。誰が連絡窓口となるかと、誰がそのインシデントの責任者となるか を決定する際には、2つの対照的な役割の要件があります。そのインシデントの責任者は、そのイベントに対応したポリシーの実践として、意思決定を行います。対照的に、連絡窓口は、そのイベントへの対応に参画しているすべての主体の労力を調整する必要があります。

連絡窓口は、監視やその攻撃への対抗に参画しているシステムマネージャーやユーザの労力をうまく調整するために、技術的な経験をもった人とすべきです。誰がこの任にあたるかを決定する際には、注意が必要です。 それは、必ずしもその被害を受けたシステムの管理的な責任を負う人である 必要はありません。 それは、しばしばそのような管理者は、日々のコンピュータの使用に十分な知識しか持たず、深い技術的な経験を欠いているからです。

連絡窓口の他の重要な機能は、複数機関が参画する事態でも対応できるように、法執行機関や他の外部機関との連絡を維持することです。参画の程度は、法的な強制と、経営管理者の意思決定によって判断されます。

唯一の連絡窓口はまた、証拠収集の責任を負う唯一の主体である必要があります。それは、大雑把なやり方では、より多くの人が証拠に触れるほど、法廷で採用されない可能性が高くなるからです。証拠が法曹界で採用されることを確保するためには、証拠収集は、現地の適用法や法的な規制に則ってあらかじめ定められた手続きに従ってなされる必要があります。

連絡窓口の最もクリティカルな仕事のひとつは、すべての関連プロセスを調整することです。責任範囲はサイト全体におよび、複数の独立の部門もしくはグループが関与します。全体の成功を達成するためには、うまく調整された労力が要求されます。 この状況は、複数のサイトが参画しているときには、より複雑になります。 この場合、サイトごとのひとつしかない連絡窓口では、インシデント全体の対応を適切に調整することは、ほとんど不可能です。その代わりに、適当なインシデント対応チームが参画すべきです。

インシデントへの対応のプロセスは、場合によっては規模拡大のメカニズムも提供すべきです。そのようなメカニズムを定めるために、サイトは、インシデントのための内部的な機密スキームを築く必要があります。各レベルのインシデントに関連させるのが適当な連絡窓口と手続きであるといえるでしょう。 インシデントが拡大すれば、インシデントへの対応に参画しているすべての主体と コミュニケーションをとる必要のある連絡窓口は変更されることがあるでしょう。 連絡窓口の変更があった場合、旧連絡窓口はすべての提供元情報の中で新しい連絡窓口を知らせる必要があります。

最後にユーザは、気づいたインシデントの報告のし方を知っておく必要があります。 サイトでは、業務時間内でも時間外でも機能する報告手続きを確立する必要が あります。こうした報告を通常の業務時間内に受け付けるのには、しばしばヘルプ デスクが活用され、時間外の報告にはポケット ベルや電話を使用することができます。

5.2.2 法執行機関と捜査機関 English

法的な決着をはかるようなインシデントが起きたときには、できるだけ早く 捜査機関(例 アメリカ合衆国における FBI とシークレット サービス) と連絡をとることが重要です。現地の法執行機関、現地のセキュリティ事務所、学内の警備部門にも、適切に知らさせる必要があります。この節では、直面する多くの論点を記述しますが、各組織体には、どのように 法執行機関や捜査機関とやり取りをするかに影響を与えるそれぞれの(ローカルと) 政府の法や規制があることは、周知のとおりです。最も重要な点は、各サイトはこれらの論点について検討しておく必要があるということです。

インシデントの前に、このような連絡窓口をきちんと定めておく主な理由は、ひとたび攻撃が進行中となると、これらの機関を、誰が正しい連絡窓口とするか を決定するために呼ぶ時間はほとんどないからです。他の理由としては、よい協力関係を育てるように、これらの機関と協力することが 重要で、それはこれらの機関の働きの結果、得られるものといえるでしょう。 作業手順をあらかじめ知っておくことと、あなたの連絡先を予定しておくことは、この方向への大きな一歩です。 例えば、以降の法的な進行において採用される証拠を集めることが重要であり、どのように、そのような証拠を集めるかについての予備知識が要求されます。 できるだけ早く連絡をとれるようにする最後の理由は、あらゆるインシデント について 司法権を引き受ける特定の機関を知ることが不可能であることです。 連絡をとって、早期に正しいチャネルを見つけることによって、インシデントへの 対応は、かなりスムースになることでしょう。

あなたの組織体もしくはサイトに法律顧問がいれば、あなたはインシデントが進行中であることを知り次第、この事務所に知らせる必要があります。 最低限、あなたの法律顧問は、あなたのサイトもしくは組織体の法的、財務的な 利益を守るために参画する必要があります。法的、実際的な論点は多くありますが、それらの一部を示します。:

(1) あなたのサイトもしくは組織体が、ネガティブな報道のリスクを犯すことと、法的な訴訟に協力することによる開示のどちらを望むか?
(2) 下流への責務 -- あなたが被害を受けたシステムを監視できるようにそのままにして、 他のコンピュータがあなたのシステムを起点とする攻撃によってダメージを受けた場合、あなたのサイトもしくは組織体は、受けたダメージに責務を 負うことになります。
(3) 情報の配信 -- あなたのサイトもしくは組織体が、他のサイトもしくは組織体が参画しているか、 もしくは、その製品の販売可能性に影響を与える脆弱性についての攻撃についての情報を配信している場合、あなたのサイトもしくは組織体は、再度、 (評判のダメージを含む)すべてのダメージに責務を負うことになります。
(4) 監視に伴う責務 -- もし、あなたのサイトあるいはどこかのユーザが、ユーザに 通知せずにアカウンティングを監視していることを発見した場合には、 あなたのサイトもしくは組織体は訴えられるでしょう。

残念ながら、セキュリティインシデントに参画している組織体の責務もしくは責任について、または、捜査活動を支援するのに誰が参画すべきかについての明確な先例は 、まだありません。捜査官は、しばしば組織体に、追跡を助け、侵入者を監視することを強く薦めます。大部分の捜査官は、参画している組織体からの追加サポートなしには、コンピュータへの侵入を追跡することはできないのは確かです。しかし、捜査官は、責務の訴えからの防御を提供することはできず、この種の労力は、何ヶ月もかかり、多大な労力を要します。

他方で、組織体の法律顧問は、極端な警告をアドバイスし、追跡行為を止めて、侵入者をシステムから締め出すことを示唆することでしょう。これ自体は、責務の防御を提供するものではなく、捜査官が犯人を識別することを妨げることになります。

捜査活動の支援と、可用性の制限の間のバランスは、微妙です。あなたは、いかなるインシデントにおいても何をすべきかについての意思決定を するときには、あなたの法律顧問のアドバイスと、その侵入者が 引き起こしているダメージ(ある場合には)を考慮する必要があります。

あなたの法律顧問は、また、インシデントがあなたのサイトで起きた場合、捜査機関と連絡をとるすべての意思決定に参画すべきです。捜査機関との労力の調整のための意思決定は、おおむねあなたのサイトもしくは 組織体の意思決定となります。 あなたの法律顧問も、あなたのサイトと関連の特定の捜査機関との間の、複数レベルの 調整を育て、これによって有効な労働配分ができます。 また、あなたは将来の法的な過ちを避ける助けをするガイダンスを入手する ことでしょう。

最後に、あなたの法律顧問は、あなたのサイトのインシデントに対応するために記述された手続きを試す必要があります。あなたが実際にこれらの手続きを実行する前に、法的な見通しをもって「問題のない健康診断書」を入手することが重要です。

情報を求めて問い合わせてくる人が、その機関の正規の代表として質問していることを検証するために捜査機関を扱うことが決定的に重要です。残念ながら、多くの担当者も、コール元が政府機関の代表者を名乗っていたために、知らずにインシデントについての慎重を要する詳細を漏らしてしまって、認可されていない人を彼らのシステムなどへの侵入を許してしまっています。(注意: この注意書きは、実際にすべての外部との連絡についていえます。)

同様の配慮として、安全なコミュニケーションの手段を使用することがあげられます。なぜならば、多くのネットワーク攻撃者は簡単に電子メールの配信を変更できてしまうからです。(現在のインシデントを扱っている他の主体と同様に)他の機関との連絡においても、電子メールの使用を避けてください。安全対策の施されていない電話回線(通常ビジネスに使用されている電話)もまた、頻繁にネットワーク侵入者によって盗聴の標的となっているので、 気を付けてください!

州政府が参画した場合のインシデントに対応するためルールを作った人はいません。(アメリカ合衆国において)通常、法的な命令による以外に、あなたに監視することや ネットワークから切断すること、疑わしい攻撃者 との電話連絡を絶つことなどを 強要できる機関はありません。各組織体には、インシデントに対応するときに遵守しなければならない(ローカルと) 国の、法と規制があることでしょう。 各サイトは、インシデントに対応する前に、こうした法や規制に親しみ、識別し、司法機関の連絡先をよく知っておくことを薦めます。

5.2.3 コンピュータセキュリティインシデントに対応するチーム English

現在、数多くのコンピュータ セキュリティ インシデント対応チーム (CSIRT)があります。例えば、CERT/CC、ドイツの DFN-CERT があり、また世界中に他のチームが存在しています。多くの主要政府機関や大企業にはチームがあります。もし、このようなチームと連絡がとれるのでしたら、インシデントの初期段階で これを通知することは主要な考慮事項です。これらのチームは、ひとつのサイトを越えたコンピュータ セキュリティ インシデントの調整や、より大きな主体のものに責任を負います。たとえそのインシデントが、ひとつのサイト内に収まっていると信じられて いても、対応チームから得られる情報によって、そのインシデントの完全解決が助けられることはありえます。

システムのハードウエアもしくはソフトウエアの欠点によってその突破が起きたと判断されたときには、そのベンダー(ないし販売代理店)や コンピュータ セキュリティ インシデントへの対応を行うチームに、できるだけ早く通知する必要があります。 これは特に重要です。なぜならば、多くの他のシステムが脆弱性を持っており、これらのベンダーや対応チームの組織体は、他の被害を受けたサイトを助けることを広めることが できるようになるからです。

インシデントへの対応のためのサイトのポリシーを設ける際には、既に在るチームのようなサブグループが設けられることが望まれ、そのサブグループは、サイト(もしくは組織体の)コンピュータセキュリティインシデントへの対応に責任を負うことになります。そのようなチームが設けられたら、このチームと他のチームとの間にコミュニケーションが開かれることが肝要です。ひとたびインシデントが進行中の場合、事前になければ、他のチームとの間に信頼できる対話を始めることは困難です。

5.2.4 被害をうけた関連のサイト English

インシデントが他のサイトに影響をもつ場合には、彼らに知らせるのがよいとされています。最初から、そのインシデントは現地のサイトに限られないことが明らかである 場合もありますし、分析の結果ようやく分かる場合もあります。

各サイトは、他のサイトに直接連絡をとったり、適当なインシデント対応チームにその情報を渡したりすることができます。しばしば、遠隔のサイトの責任を負う連絡窓口を見つけることは非常に困難であり、そのインシデント対応チームは、既に在るチャネルを利用して連絡をとれるように なります。

セキュリティ インシデントによって引き起こされる法的債務性の論点はサイトごとに異なります。インシデントが起きる前に、他のサイトとの情報の共有や、ログを採ること のためのポリシーを定めることが重要です。

特定の個人についての情報 は、特に慎重を要するもので、プライバシーの法規との関係があります。この領域の問題を避けるために、関係のない情報は削除されるべきであり、残る情報の扱い方の表明が含められる必要があります。この情報がどのように使用されるかについての明確な表明が重要です。セキュリティ インシデントが起きたサイトを通知する人には、それについて公衆のプレス(報道)で読むようになることを望む人はいません。インシデント対応チームは、このことに関しては柔軟です。彼らが情報を責任を負う連絡窓口に渡すときには、情報源の匿名性を守ることができます。しかし、多くの場合、他のサイトのログと情報の分析は、あなたのサイトの所在を明らかにしてしまうことを認識してください。

上記で検討したすべての問題は、他のサイトを参画させない理由にしてはいけません。実際、既存のチームの経験では、セキュリティ問題について知らされた 大部分のサイトが、彼らのサイト自身が荒らされていたことにさえ気がついて いなかったことが分かっています。適時な情報がなければ、他のサイトは侵入者に対抗する行動をとることができません。

5.2.5 内部コミュニケーション English

大きなインシデントにおいて、なぜある行動がとられるのかや、どのようにユーザ(もしくは部門)がふるまうことが期待されているか についてコミュニケーションすることは決定的に重要です。 特に、(他の部門を含む)外界に何をしゃべることが許されているのか、(あるいはいけないか)をユーザに明確に示す必要があります。

例えば、もしユーザが顧客に「すみません。システムがダウンしています。我々は侵入を受けており、対応中です。」 といった具合に答えたら、組織体にとってはまずいでしょう。 「すみません。我々のシステムには脆弱性があり、よりよいサービスを提供できるように保守を行っているところです。」 のような準備された言葉で対応するように訓練されていた方が、はるかに望ましいといえます。

顧客や連絡先とのコミュニケーションは、気をきかせ、かつ慎重に対応する必要があります。チェックリストを用意することによって、主な論点に備えることができます。そのチェックリストは、インシデントが起きたら、その固有の状況に合わせて、ひとつかふたつの項目を追加することで使用できます。

広報部門は、インシデントにおいて非常に役に立ちます。 この部門はすべての計画に参画すべきであり、外部の部門や組織体との連絡が 必要なときには、統率のとれた対応を提供することができます。

5.2.6 広報(パブリックリレーションズ)- プレスリリース English

アメリカ合衆国においては、メディアにおけるコンピュータセキュリティインシデントの占める量がすさまじく伸びてきています。 このようなプレス(報道)のし方は、今、諸外国に拡大しようとしています。それはインターネットが成長を続け、国際的に拡大しているからです。そのようなメディアの注目がまだ起きていない国の読者は、 アメリカ合衆国の経験から学ぶことができ、警戒して準備しておく必要があります。

検討すべき最も重要な論点のひとつは、いつ、誰が、どの程度、プレスを通じて一般大衆に発表するか、です。この特別な論点について決定する際には、検討すべき多くの論点があります。まず最も重要なこととして、サイトに広報室がある場合には、この部署を プレスへの連絡機構として使用することが重要です。広報室は、発表情報の記述や話術の訓練を受けており、インシデントの最中とその後において(可能な限り)サイトのイメージが守られるようにするのに有用です。広報室には、あなたが率直に彼らとコミュニケーションできる利点があり、 継続的なプレスの注目と、インシデントのコントロールを維持する連絡窓口の役割 の間の緩衝材として機能します。

広報室がない場合、プレスに発表される情報は、慎重に検討される必要があります。情報が、慎重を要する場合、プレスには最低限の情報もしくは概要だけを提供するのがよいでしょう。プレスに提供されるすべての情報が、ただちにそのインシデントの犯人によってレビューされる可能性は極めて高いといえます。また、プレスを誤誘導することは、しばしば裏目に出て、慎重を要する情報を 発表するよりも大きなダメージを引き起こす可能性があることを銘記してください。どの程度、詳細をプレスに提供するかをあらかじめ決定することは困難ですが、気をつけるべきガイドラインをいくつか示します。:

(1) 詳細についての技術的なレベルは低くしておいてください。インシデントについての詳細な情報は、第三者が他のサイトに同様の攻撃を 仕掛けるのに十分な情報を提供してしまうかもしれません。そうしなければ、そのイベントが終結した後に、サイトがその有罪な主体を起訴することの妨げになるかもしれません。
 
(2) プレスの文言に推測を含めないようにしてください。誰がインシデントを起こしているか、ないし、その動機の推測は 誤る可能性が非常に高く、インシデントについての過剰な見通しを引き起こすことでしょう。
 
(3) 証拠が守られるように、法執行の専門家と協働してください。検察当局が関与している場合、収集された証拠はプレスに漏らさないように してください。
 
(4) あなたの準備が整う前に、プレスの取材に巻き込まれないように してください。某有名なプレスは、「午前 2時」の取材で有名で、 取材対象者がガードしていないところを捕まえて、そうでなければ得られない情報を入手しようとするのです。
 
(5) プレスの関心をそのイベントの対応からそらしてはいけません。上手なインシデントの終結が最重要であることを片時も忘れてはいけません。

 

5.3 インシデントの識別 English

5.3.1 本当にインシデントか? English

この段階には、本当に問題が存在するかを判定することが含まれます。当然、大部分とはいえなくとも多くの症状は、ウイルスの感染と関連があります。システム侵入、悪意のユーザなどは、ハードウエアの欠陥、またはシステムあるいはユーザの疑わしい行為などの例外的なものです。本当にインシデントであるのか を識別するのを補助するために、通常、入手可能な検知ソフトウエアを入手し、利用することは有益です。監査情報もまた極めて有用で、特にネットワーク攻撃の有無の判定に有用です。誰かが何かがおかしいと疑ったらすぐに、システムのスナップショットをとることが極めて重要です。多くのインシデントは、イベントの連鎖的発生を引き起こすので、最初のシステムのスナップショットが、その問題と攻撃元を識別するために最も価値のあるツール(道具)なのです。とにかく、ログ日誌をつけ始めることが重要です。システム イベント、電話での会話、タイムスタンプ等を記録することによって、その問題をより早く、体系的に識別することができ、以降のインシデントへの対応の段階の基礎となります。

インシデントには特別な注意を払うべき、ある種の症状もしくは「兆候」があります。:

(1) システム クラッシュ
(2) 新しいユーザ アカウント ( RUMPLESTILTSKIN アカウントが予期せず作成されていたり、権限が低かった アカウントが高い権限を要求する行為を行います。)
(3) 新しいファイル (通常、data.xx、k、.xx のように、新しく、妙なファイル名をもっています。)
(4) アカウンティングの食い違い ( UNIX システムでは、/usr/admin/lastlog というアカゥンティング ファイルの 変化を検知することができ、侵入者の可能性を強く疑うこともあるでしょう。)
(5) ファイル長または日付の変化 (ユーザは、もし MS DOS コンピュータの.EXE ファイルが予期せず 1800バイト増加していたりしたら、疑う必要があります。)
(6) システムに書き込みを行おうとした試み (システム マネージャーは、VMS システムの特権ユーザが RIGHTSLIST.DAT を 変更しようとしていることを検知します。)
(7) データの改ざんまたは消去 (ファイルが消えてしまいます。)
(8) サービス妨害 (システム管理者と他のすべてのユーザが UNIX システムから締め出され、 シングル ユーザ モードとなってしまいます。)
(9) 予期していなかったシステム パフォーマンス(性能)の低下
(10) 異例事項 (「GOTCHA」がコンソールに表示されたり、予期しない「ビープ」音が頻繁に鳴ります。)
(11) 疑わしい探索 (他のノードからのログインの失敗は数限りなくあります。)
(12) 覗き見 (誰かが UNIXシステムのルート ユーザとなり、多くのユーザ アカウントの ファイルを次々にアクセスします。)
(13) アカウントが変更されてしまってユーザがログインできないこと

このリストがすべてを網羅しているわけではありません。; 我々は、数多くのよく知られた症状を列挙しただけです。インシデントが起きているのか否かについて、他の技術者や、コンピュータ セキュリティ専門家と共同でグループとしての意思決定を行うのがベストです。

5.3.2 インシデントの種類と持つべき視野 English

インシデントを識別するということは、その問題の視野と影響を評価するということです。効果的にインシデントを扱うためと対応の優先順位をつけるためには、その周辺事項を 正しく識別することが重要です。

持つべき視野と影響を識別するために、そのサイトに適切で、接続形式に適切な 基準が定められる必要があります。それらの論点には以下のものが含まれます。:

(1)  これは複数のサイトのインシデントか?
(2)  あなたのサイトの多くのコンピュータが、このインシデントによって被害を 受けたのか?
(3)  慎重を要する情報が含まれているか?
(4) そのインシデントの侵入経路はどこか? (ネットワーク、電話回線、ローカル端末等)
(5) プレス(報道関係者)が参画しているか?
(6) そのインシデントの潜在的なダメージは何か?
(7) そのインシデントを終結させるのに要する時間の見積もりは?
(8) そのインシデントに対応するのに必要とされる可能性のある資源は何か?
(9) 法執行機関が参画するか?

5.3.3 ダメージと影響範囲の評価 English

ダメージとインシデントの影響範囲の分析には、かなりの時間がかかりますが、インシデントの性質を理解することができ、捜査や訴訟に役立ちます。 その突破が起きたらすぐに、システム全体とそのコンポーネントはすべて、 疑わしいとみなす必要があります。 システム ソフトイエアは、最も狙われやすい標的です。狙われる可能性のあるシステムの、あらゆる変更を検知できるようにする鍵は、 準備です。 これには変更に備えてアルゴリズムを使って、ベンダーからきたすべてのメディアの チェックサムを採ることが含まれます。( 4.3 の項をご覧ください。)

オリジナルのベンダー配布メディアが入手可能であれば、すべてのシステムファイルの分析を開始し、すべての異常事項は注目される必要があり、インシデントの対応に 参画しているすべての主体に問い合わせる必要があります。 場合によっては、どのバックアップ メディアがシステムの正しい状態であるのか を判定するのが非常に困難であるかもしれません。例えば、インシデントは発見するまでに何ヶ月もあるいは何年も経過しているかも しれませんし、サイトの従業員が疑わしいかもしれませんし、または、 そのシステム固有の知識かアクセスを持っている人かもしれないことを考慮してください。すべての場合、インシデント前の準備が、どの復旧が可能であるかを決定します。

システムが集中的なログ管理をサポートしている場合、(すべきですが、) ログを見直して、異常なことを探してください。 もしプロセスのアカゥンティングと接続時間のアカゥンティングが可能に なっている場合には、システム使用のパターンを探してください。 その次に、ディスクの使用状況が、そのインシデントの光明となるかもしれません。 アカウンティングは、インシデントの分析と後の訴訟に、大変有益な情報を 提供することができます。 あなたが、特定のインシデントについてのすべての観点に対応できるかは、この分析の成功にかかっています。

 

5.4 インシデントへの対応 English

インシデントへの対処においては、一定の手続きを踏むことが必要不可欠です。すべてのセキュリティ関連活動で最も重要なことは、すべてのサイトが現にポリシーを持っていることです。ポリシーと目的を定めない場合にとられる行動は、方向性のないままとなります。その目的はあらかじめ、経営管理者と法律顧問によって定められる必要があります。

最も基本的な目標事項として、被害を受けたシステムのコントロールを復元することと、影響およびダメージを限定することがあげられます。最悪のシナリオでは実際の解決策は、システムをシャットダウンするか、システムをネットワークから切断するしかない場合があります。

関連の行動は複雑なので、できるだけ多くの助けを得るように努めてください。その問題を独りで解決しようとしている間に、遅れや情報がないことによって、深刻なダメージを受ける可能性があります。大部分の管理者は、侵入者の発見を個人的な挑戦として扱っています。このように進行すると、現地のポリシーで定められた他の目標事項が、常に考慮されるとは限りません。システムの 完全性に比べて、侵入者を追跡することが非常に優先順位の低いものとされているかもしれません。例えば、ハッカーの行動を監視することは有用ですが、アクセスし続けることを許すリスクに値しない、とみなされるかもしれません。

5.4.1 通知の種類と情報交換 English

あなたがインシデントの発生を確認したら、適当な人に通知する必要があります。どのようにこの通知がなされるかは、技術的な観点と、感情的な観点の両方からイベントを管理下におくために、非常に重要です。その状況は、その問題の通知と理解を助けるためにできるだけ詳細に記述される必要があります。その通知において、どの主体に詳細な技術情報を提供するかを決定する際には、十分に注意する必要があります。例えば、この種の情報をインシデントに対応するチームに回すことは有用です。それは、彼らはインシデントに関連する脆弱性を根絶するための有用なヒントを提供することによって、あなたを助けることができるからです。また一方で、極めて重要な知識を公衆に共有させることは、(例 : USENET の ニュースグループもしくはメーリングリスト経由)膨大な数のシステムを侵入のリスク(危険)にさらす可能性があります。あるニュースグループを読んでいるすべての管理者が、オペレーティングシステムのソース コードにアクセスできると想定したり、さらには、彼らすべてがアドバイザリーについて適切な手続きをとるのに十分な理解ができる、と想定することは不適切です。

まず最初に、現地の人宛てと、サイト外の人宛てのどちらのいかなる通知も、明瞭である必要があります。 このことは、すべての文章が(電子メールのメッセージ、電話、FAX、ポケットベル、信号機であれ)インシデントについて提供する情報は、明確で、簡潔で、許可を得たものであることを要求します。 あなたが、イベントに対応するのを助けてくれる人に通知するときに、「煙幕」は、 労力を分断するだけで、混乱をもたらします。 もし、労力の分断があるようでしたら、各参加者に、他ではどのような努力がなされているか、についての情報を提供することが有益です。これは労力の重複を減らすばかりでなく、その問題に参画して働いている人々に、そのインシデントの担当個所についての情報をどこで入手できるかを知ることを許容します。

インシデントについてコミュニケーションをとる際の他の重要な考慮事項として、事実関係を語ることがあげられます。誤った、もしくは不十分な情報を提供することによって、そのインシデントの ある側面を隠そうとする試みは、そのインシデントに対する上手な解決ができないばかりでなく、状況をより悪くしてしまいます。

そのインシデントについて人々に通知する際に使用される言葉の選択は、その情報の受け取られ方に重大な影響があります。あなたが感情的または挑発的な用語を使用すれば、インシデントのダメージと ネガティブな結果を引き起こしかねません。 書面による場合も、口頭による場合もコミュニケーションは冷静に保つことが重要です。

他の考慮事項として、必ずしもすべての人々が同じ言葉を話すわけではないことがあげられます。 このことによって、特にこれが複数の国にまたがるインシデントの場合、誤解と遅延が起きます。他の国際的な論点には、異なる法的なセキュリティ インシデントの実践と、文化的な相違があります。しかし、文化的な相違は国家間でのみ存在しているわけではありません。それらは一国の中にも、異なる社会やユーザの間にあります。 例えば、大学のシステムの管理者は気軽に telnet でシステムに接続しようと しますが、軍事システムの管理者は、同じ行為を攻撃の可能性とみなすことでしょう。

言葉の選択と関連のある他の論点は、技術者でない人、もしくはサイト以外の人への通知です。不要な警告もしくは混乱を生むことなく、正確にインシデントを記述することが重要です。技術者でない読者のためにインシデントを記述することはもっと困難ですが、技術的でない記述は、経営上層部、プレス、または法執行機関から求められること の方がより重要です。これらのコミュニケーションの重要性を軽視してはいけませんし、インシデントを正しく解決できるか、ダメージをさらに拡大してしまうか、の分かれ目となることでしょう。

もし、インシデント対応チームが参画した場合、情報交換のために雛形(報告様式)の項目を埋めることが必要となります。これは追加負担、ないしさらに遅らせることのように思われるかもしれませんが、 これはそのチームが、この最小限の情報に基づいて行動するのを助けます。その対応チームは、現場の管理者が気づいていない、そのインシデントの側面に 対応することができます。 もし、情報が第3者に渡るのでしたら、下記の最低限の情報だけが提供されるべきです。:

(1) ログのタイムゾーン 世界標準時間(GMT)または現地時間で。
(2) リモート システムについての情報 ホスト名、IP アドレス(とユーザ ID)を含む。
(3) そのリモート サイトに関連したすべてのログ エントリ
(4) インシデントの種類 (何が起きたのか、なぜ問題とする必要があるのか。)

もし ローカル情報(つまり、ローカルのユーザ ID)がログ エントリに含まれている場合には、プライバシーの論点を避けるために、エントリをあらかじめ 消去しておくことが必要です。一般に、現地のポリシーがこれを禁止していない限り、インシデントを解決する 際には、リモート サイトを補助するすべての情報が提供されるべきです。

5.4.2 証拠とアクティビティ ログの保護 English

あなたがインシデントに対応するときには、そのインシデントに関連するすべての詳細を文書化してください。これによって、あなたがイベント経緯を解明しようとする際には、あなた自身と他者にとって価値のある情報が得られます。すべての詳細を文書化することによって、最終的には時間の節約になります。例えば、もしあなたが関連するすべての電話を文書化していないとしたら、あなたが入手した情報の重要な部分を忘れ、情報元に再度連絡することが 必要となります。 同時に、詳細を記録することは、仮に訴訟の方向に進んだ場合、そのための証拠を提供することになります。インシデントを文書化することは、あなたが(あなたの経営管理者や法執行事務員が 知りたがる)最終的なダメージの評価を行うことにも役立ちますし、その対応プロセスの後のフェイズ(根絶、復旧、フォローアップ、「教訓」)のための基礎となります。

インシデントの最初の段階においては、訴訟が可能であるかを判断するのは、しばしば不可能なので、あなたは法廷のための証拠を集めているかのように 文書化する必要があります。 最低限、あなたは下記の事項を記録する必要があります。:

(1) すべてのシステムイベント(監査記録)
(2) あなたがとったすべての行動(時間を付して)
(3) すべての外部との会話(誰と話したか、日付と時間、会話のないようを含む)

文書化する最も率直なやり方は、ログ日誌をつけることです。これによってあなたは、個々に紙をめくりかえすことなく、必要な時に集中管理された時系列順の情報元にあたることができます。この情報の多くは、法廷で証拠能力があります。それゆえ、法的なフォローアップが可能である場合、準備されている手続きに従って、証拠の誤った対応によって、その法的なフォローアップを危機に陥れることを避ける必要があります。

下記の手続きが、適当な場合にはとられます。

(1) 定期的に(つまり毎日)、あなたのログ日誌のコピーをとり、サインされたコピーを(システム イベントを記録するのに使用されるメディアとあわせて) 文書の保管人に渡す。
(2) 保管人は、これらのコピーされたページを安全な場所(つまり金庫)に 保存する必要がある。
(3) 情報を蓄積するために実施するとき、あなたは署名と日付の付された受領書を文書の保管人から入手する必要がある。

これらの手続きを監視することの失敗は、あなたが入手したすべての証拠の法廷での却下につながりかねません。

5.4.3 包囲 English

包囲の目的は、攻撃の拡大を限定することです。包囲で肝要なのは、意思決定です。 (つまり、システムをシャットダウンすべきか、ネットワークから切断すべきか、システムもしくはネットワークのアクティビティを監視するか、罠を仕掛けるべきか、遠隔のファイル転送のような機能を使用不能とするか、等を判断することです。)

しばしば、この意思決定は取るに足らないものです。; もし、その情報が機密情報や、慎重を要するもの、もしくは知的財産権のあるものの場合、システムをシャットダウンします。インシデントが進行中にすべてのアクセスを不能にすることは、管理者が問題を 認識していることを、その容疑のあるユーザを含むすべてのユーザに明らかにすることになることを銘記しておいて下さい。; このことは捜査において有害な影響があるはずです。すべてのアクセスもしくは機能をできるだけ早くなくして、それから限定的に通常の運用を復元するのが賢明である場合があります。また、システムを運用し続けることによって、侵入者を識別することができるのであれば、ある程度のシステムへのダメージのリスク(危険)をおかす価値がある場合もあります。

この段階には、あらかじめ定められた手続きを実行することが含まれている必要があります。あなたの組織体ないしサイトは、例えば、インシデントに対応する際に、許容可能なリスクを定義する必要があり、とるべき行動と戦略もあらかじめ記述しておく必要が あります。これは、迅速な意思決定が必要で、決定するための検討を行うために、すべての参画している主体と連絡をとることが不可能なときには特に重要です。 あらかじめ定められた手続きがないとき、そのインシデントについて責任ある人 (システムをシャットダウンすることによって、費用がかかっている実験の結果を 失う可能性が高い人など)は、困難な経営管理の意思決定を行う力を持っていないことが多いといえます。インシデントへの対応のこの段階において行う最期の行動は、適切な専門家への通知です。

5.4.4 根絶する English

ひとたびインシデントが包囲されたら、今度はその起源を根絶する番です。ただしその起源を根絶する前に、被害を受けたシステムと、そのインシデントの起源 についての、必要なすべての情報を収集することは、システムをクリーンにする際にそれらは失われがちなので、十分注意する必要があります。

根絶のプロセスにおいて、ウイルス対策ソフトウエアのような、それを助けてくれる ソフトウエアが入手可能です。 もし、何らかの偽造ファイルが作成されていたら、それらを削除する前に アーカイブにして下さい。 ウイルス感染の場合、感染したファイルを含むすべてのメディアについて駆除や 再フォーマットを行うことが重要です。 最後に、すべてのバックアップがクリーンであることを確認してください。 ウイルスに感染した多くのシステムが、周期的に再度感染するのは、単に体系的に ウイルスをバックアップから撲滅していないからです。根絶した後、新たにバックアップが採られる必要があります。

ひとたびインシデントが起きると、すべての脆弱性をなくすことは困難です。脆弱性を除去する鍵は、その突破の知識と理解です。 当初の版のメディアを再度使用して、再度システムをカスタマイズすることが必要不可欠となります。

この最悪の事態のシナリオを回避するために、当初のシステムの設定記録と、各カスタマイズのための変更が、保持されている必要があります。ネットワークに基づいた攻撃の場合、攻撃された各オペレーティング システムの 脆弱性のためパッチをインストールすること重要です。

5.4.2 で検討したようにセキュリティログは、脆弱性を除去するこのフェイズに おいて、最も価値があるかもしれません。どのようにしてそのインシデントが発見され、包囲されたかを示すログは、後でインシデントによるダメージの拡大範囲の判断に役立てるために使用することができます。この手続きは、将来、その問題が再発しないようにするのに使用することができます。理想的には、自動化されて、定期的に、セキュリティインシデントの検知に使用されたのと同じテストを適用する必要があります。

攻略されていた特定の脆弱性が隔離されたら、次のステップは、あなたのシステムを守るためのメカニズムを見つけることです。セキュリティメーリングリストや掲示板は、この情報を探すのによい場所で、 インシデント対応チームからアドバイスを得ることができます。

5.4.5 復旧 English

ひとたびインシデントの原因が根絶されたら、復旧のフェーズでは、次の段階の行動を定めます。 復旧の目的は、システムを通常に戻すことです。 一般に、ユーザに与える不便を最低限にする要求に従って、サービスを継続するのが最善であると言われています。システムの正しい復旧手続きを理解することは極めて重要で、サイトに固有なものです。

5.4.6 フォローアップ English

ひとたび、あなたがシステムは「安全な」状態に復元されたと信じてもなお、 ホール(穴)や罠さえ、そのシステムにある可能性があります。インシデントへの対応において最も重要な段階のひとつは、とかく省略されがちな段階でもある、フォローアップの段階です。フォローアップの段階においてシステムは、クリーンアップの段階において 失われている可能性がある要素について監視される必要があります。 とりあえず、第7章に紹介するツールのいずれかを使用するのが賢明といえます。これらのツールは、継続的なシステム監視と、よいシステム管理の実践を不要にするものではないことを銘記してください。

フォローアップの段階で最も重要な要素は、事後の分析を行うことです。正確に何が、いつ起きたのか? インシデントに関与したスタッフはどれだけよくやったか? どんな情報をスタッフはすぐに必要とし、どのようにしたら彼らはその情報を できるだけ早く入手することができたか?次回、スタッフはどう違った行動をとるか?

インシデントの後、実際のイベントの発生順の記録を記述した報告書を書くのが 賢明です。: その発見方法、収集手続き、監視手続き、教訓の要約が書かれます。 このことによって、その問題を明確に理解することができます。 (タイム スタンプを含む)公式なイベントの時系列を作成することもまた、 法的な理由で重要です。

フォローアップ報告は多くの理由で意義があります。これは、他の同様のインシデントが起きたときに参照することができます。また、できるだけ早くそのインシデントが引き起こしたダメージの金額的な 見積もりを入手することも重要です。この計算には、すべてのソフトウエアやファイルの損失に関連した費用、 (特に、すでに開示されている知的財産権のあるデータの価値)ハードウエアのダメージ、変更されたファイルを復元する人件費、 被害を受けたシステムの再設定などが含まれる必要があります。この計算は、その後の訴訟のための基礎となります。この報告はまた、組識体のコンピュータセキュリティを管理する努力の 正当性を主張することを助けます。

 

5.5 インシデント後 English

インシデントの後、いくつかの行動をしなければなりません。 これらの行動は、下記のようにまとめることができます。:

(1) そのシステムの資産の目録を作る必要があります。 (つまり、慎重な検査によって、そのインシデントによって、どのように システムが影響を受けたかを判断する必要があります。)
(2) そのインシデントの結果として学んだ教訓は、インシデントの再発を防止する ために、改訂されたセキュリティ計画に含められている必要があります。
(3) インシデントを前提に、新たにリスク分析がなされる必要があります。
(4) もし必要と判断されれば、そのインシデントを引き起こした人間の、 捜査と訴訟を始める必要があります。

もしインシデントが、貧弱なポリシー、そしてそのポリシーが変更されなかった ことに起因するものである場合、過去を繰り返すことになっています。 ひとたびサイトがインシデントから復旧したら、サイトのポリシーと手続きは、 同様のインシデントを防止するための変更を絞り込むために、レビュー(見直し) される必要があります。 たとえインシデントが起きなくても、ポリシーと手続きを定期的にレビュー(見直し) するのが賢明です。 レビューは、今日の変化するコンピューティング環境においては避けられないものです。

この事後のプロセスの全体の目的は、将来の攻撃に対抗してサイトを守るためのすべてのセキュリティ手段を改善することにあります。 インシデントの結果として、サイトもしくは組識体は、実践的な知識を経験から得ることになります。事後のプロセスの具体的な目的は、新しい進んだ手段を開発することです。他の重要な事後のプロセスの側面は、セキュリティ問題の再発を防止するためのエンドユーザと管理者の教育でしょう。

 

5.6 責任事項 English

5.6.1 一線を踏み越えてはいけません English

「自分のネットワークを守ること」と「他人のネットワークまで守る必要があると考えること」は、全く別のことです。インシデントへの対応において、自分のシステムと他人のシステムについて特定の脆弱性が明らかになります。侵入者を追跡することは簡単で、足跡をたどってその侵入者を追跡してみたくなることさえあるでしょう。よい意図であっても、ある時点で「一線を踏み越えて」しまう可能性があり、侵入者以外の何者でもないことになることを銘記しておいてください。

妥当な線をはかるならば、最善のルールは、公的なものではないリモート(遠隔) のサイトの、いかなる機能も使用しないことです。このルールは、明示的に許可されていない(リモート シェルもしくはログインセッションのような)いかなるシステムへの入り口の使用を明確に排除します。これは、やってみたくなることですが、セキュリティの突破が検知された後、システム管理者は、どのようなダメージがそのリモートのサイトで起きたか、を確定する「フォーローアップ」の手段を持ちます。これをやってはいけません!その代わりに、その被害を受けたサイトの適当な連絡先と連絡をとるようにしてください。

5.6.2 よきインターネットの市民として English

セキュリティインシデントにおいては、2つの選択肢があります。まず、サイトは、その侵入者を捕らえることができることを期待して監視することを選択することができます。; また、サイトは、そのインシデント後にクリーンアップして、侵入者をそのシステムから締め出すことができます。これは、非常に思慮深くなされる必要がある意思決定です。それは 、もし、侵入者が他のサイトへの踏み台としてあなたのサイトを利用していることを知りながら、あなたがサイトを開いたままにすることを選択した場合、法的な責務があるからです。よきインターネット市民であることは、あなたは他のサイトに、彼らが侵入者に よって影響を受けているかもしれない、と警告するようにすべきであることを意味します。これらの被害を受けたサイトは、あなたのログファイルの徹底的なレビュー後には明らかとなっているはずです。

5.6.3 インシデントへの管理的な対応 English

セキュリティインシデントにユーザが関係している場合、そのサイトのセキュリティポリシーは、どのような行動がとられるべきかを記述する必要があります。違反については、深刻に受け止める必要があります。ただし、そのユーザが果たした役割を確認することが非常に重要です。そのユーザは、現地の人だったのでしょうか?セキュリティの突破をユーザのせいにすることにミスはなかったのでしょうか?そのユーザが意図的にそのインシデントを引き起こしたとみなす管理上の措置を適用することは、単にミスを犯したユーザには適切とはいえないでしょう。意図的な侵入行為やシステムの場合には、このようなより厳格な手段に加えて、よりあなたのポリシーに適合する(例えば、ユーザの教育もしくは再教育のような) 制裁を含めるのが適切であるといえるでしょう。


->6