インタビュー手法
フェーズ4、タスク1：セキュリティ制御評価計画
セキュリティ制御評価者は独立セキュリティ制御評価を行うための地図として使用する詳細評価計画を策定します。 この計画は、システムのどの構成要素が評価されるか、どのような自動化ツールまたは手動プロセスが使用されるか、および、テストの境界線が何であるかを指定します。 また、テスト計画には、情報システム所有者と権限付与者により承認された、合意された関与の規則（ROE）が含まれる べきです。 これらのROEは、セキュリティ評価の範囲と深さ、テストイベント中に発生するイベントまたはインシデントの連絡先（POC）、評価を実施するために承認された許容可能なツールと技術、評価またはテストイベントを成功させるために必要なアクセスレベルを定義する必要があります。 テスト計画は、情報システム所有者がセキュリティ管理評価者に提示する、システムセキュリティ計画（SSP）、エンジニアリング、アーキテクチャおよびポリシー文書、ユーザおよび管理者ガイド、以前のテスト計画およびテスト結果など、情報システムの既存の証拠書類（BOE）から作成される。 この時点での完全なBOEは、SCAがシステムのセキュリティ態勢および要求されるセキュリティ制御のシステム実装を適切にテストするテスト計画を策定できるよう、評価者が情報システムを構築されたとおりに必要な詳細さで理解することを保証するものである。 システムまたは共通コントロールプロバイダに十分な保護とコンプライアンスを提供していると、（RMFの以前のステップで）権限を持つ当局によって独立したとみなされた評価者によって評価および検証されたコントロールは、再評価する必要はありません。 評価者が独立した評価者でないと判断された場合、前回のテスト計画が適切であれば、独立したコントロール評価者は評価計画と結果を使用して、情報システムのコンプライアンスのベースラインを形成し、評価のスピードアップを図ることができる。 以前の計画が適切でない場合、独立したコントロール評価者によって強化、書き直し、またはゼロから開発する必要があります。
評価計画は、独立したセキュリティコントロール評価者のテストイベントの目標を提供します。 このコントロール評価の青写真は、誰がテストイベントを実施し、セキュリティコントロールがセキュリティとコンプライアンスを提供するために設置され、設計どおりに機能していることを検証するために使用される手順を特定します。 完全に整備された計画は、組織にとって 2 つの目的を果たす。 まず、システムまたはコントロールの提供者を評価するために使用する手順、および、テストの境界と範囲を定義することによって、セキュリティコントロールの評価に対する適切な期待値を確立することです。 次に、評価者を定義された労力レベルで拘束し、過度に複雑なテストでリソースが浪費されないようにし、セキュリティ対策の要求事項の正しい評価につなげることができるようにします。 場合によっては、システムの重要度や含まれている情報に基づいて、複雑なテスト戦略が必要になることがあります。 すべての場合において、セキュリティ統制の評価における複雑さと詳細さのレベルは、システムまたは共通統制セットの重要性に見合うものでなければならない。
システムに実装することが要求されるセキュリティ統制をテストするために使用される評価には、大きく分けて3つのタイプがある：開発テストと評価の評価、独立検証および妥当性確認（IV&V）、そして3番目のタイプ、認可または再認可を裏付ける評価、継続モニタリング評価および修正または回帰評価など、いずれかを裏付ける評価。 認可または再認可の評価には、認可担当者によって定義された独立した評価チームが必要である。 このレベルの独立性はIV&Vのアセスメントにも必要であり、これにはIV&Vまたはアセスメント／再評価テスト（システム開発の初期に実施されるテストなど）でその知見が使用されるように設計されたアセスメントも含まれる。 多くの場合、結果がIV&Vと同様に認可及び再認可イベントのサポートに使用できることを保証するために、これらのタイプの評価のすべてを実施するために割り当てられた独立した査定者の専門チームを持つことがより有利である。 独立性とは、評価者がシステムのセキュリティ制御の設計及び開発に関して、実際のまたは認識される利害の対立から自由であることを意味する。 このレベルの独立性を達成するために、認可当局は、他の組織または契約されたチームを含む、設計及び開発チームから分離された組織に、独立したセキュリティ対策の評価を求めてもよい。 契約されたリソースが使用される場合、コントロール評価者の独立性を確保するために、システム所有者が契約プロセスに直接関与しないことが重要である。
セキュリティテスト計画では、テストイベントで使用される手動および自動ツールの種類を定義すべきである。セキュリティコントロール評価を行う場合、可能な限り自動テストおよびテスト手順を利用することにより、最大の有効性を得ることができる。 自動化された評価ツールまたはテストアプリケーションを使用してコントロールを検証する場合、テスト計画では、使用する自動化ツールの設定、プロファイル、プラグイン、およびその他の構成設定を示す必要があります。 自動化ツールではセキュリティ対策を評価できない場合や、手動のプロセスや手順で補強する必要がある場合が多くあります。 このような場合、手動による手順は、実行した手順、入力したコマンド、選択したメニュー項目を含めて、完全に文書化する必要がある。 詳細な文書化により、テストが正確に繰り返されることが保証され、また、互恵主義の場合、証拠資料の一部としてテスト計画を検査する個人が、各コントロールがどのように評価されたかを理解することができます。 これは通常、各コントロールのテストされたイベントの一部として、通常、詳細なテスト手順の後に記載される。 この文書により、SCA および他の関係者は、その特定のテストイベントを成功裏に通過する結果となる、システムまたはデバイスからの期待される出力を知ることができます。 場合によっては、許容できる複数の結果があります。これらの事象については、テスト事象に不合格となる結果を列挙することがより賢明かもしれません。その後、テスト計画では、列挙した結果以外は、コントロールが正しく実装されていることを示すべきです。 これらの3種類のコントロールは、システムが開発され設計された方法に基づいて、共通のコントロールとして実装されるか、システム固有のコントロールとして実装されるか、またはハイブリッドコントロールとして実装されます。 このため、評価者は、多くの異なる環境および技術における広範な統制の実装を評価する経験を持っていなければなりません。
セキュリティ統制のテスト計画を策定するとき、SCAは、この文書が統制を評価しなければならない方法を定義しているので、NIST SP 800-53Aをしばしば参照すべきです。 SP 800-53A は、しばしばギリシャ語の A の文字、”アルファ” で参照されます。 アルファは、セキュリティ制御を評価する3つの異なる方法、すなわち、検査、インタビュー、およびテストを定義しています。 NISTはSP800-53Aでこの3つの事象を次のように定義しています：
検査方法は、1つまたは複数の評価対象（すなわち、仕様、メカニズム、または活動）をレビュー、検査、観察、研究、または分析するプロセスである。 検査方法の目的は、評価者の理解を促進すること、明確化を図ること、または証拠を得ることです。 インタビュー法とは、組織内の個人またはグループと議論を行うプロセスであり、ここでもまた、アセッサー の理解を促進し、明確化を図り、または証拠を入手することを目的としている。 テスト方法は、1つ以上の評価対象（すなわち、活動またはメカニズム）を指定された条件下で実施し、実際の動作と期待される動作を比較するプロセスである。 公式な定義ではありませんが、一般的なルールとして、試験イベントは文書またはシステム出力のレビューに焦点を当て、インタビューイベントは異なる個人との会話に焦点を当て、そしてテストイベントは技術的な評価であるとされています。 SCA はこれらの要求事項を用いて、開発中のテスト計画が、コントロールが評価されるべき特定の方法に対応していることを確認します。 また、このαには、この時点で役に立つかもしれない3つの付録が含まれている。 付録Dは、評価方法、適用可能なオブジェクト、および属性を定義し、付録Gは、SARおよびSARテンプレートの作成方法を説明し、付録Gは、テスト計画用の評価ケースの作成方法、およびテンプレートとして使用できる評価ケースの例を詳述する。
テストの深さと範囲を決めることは、セキュリティ対策の評価またはテスト計画を開発する際に重要であり、評価または計画は各コントロールのテストのために用いられる努力レベルを設定するものである。 これらの要素は、特定のコントロールごとに必要なテストの厳密さと範囲を定義し、階層化されており、一部の情報システムに必要な保証を増やすために、評価要件を増やしたものを提供します。 評価の深さは、セキュリティ管理策の完全なテストに必要な詳細さのレベルを決定し、基本、重点、包括の3つの属性値のいずれかにすることができる。 対象範囲」は、評価の範囲または幅を定義し、「基本」、「重点」、「包括」の3つの属性のいずれかを含む。 これらの深さと範囲の属性は、RMF をサポートする組織全体のリスクマネジメントプログラ ムを定義するときに、組織が割り当てる。 通常、情報システムの保証要件が高まるにつれて、セキュリティ管理アセスメントの範囲と厳密さに関する要件も高まる。 NIST SP 800-53A の付録 D では、検査、インタビュー、テストの各評価方法に対する深さと範囲の要件が定義されています。 この文書の一部は、便宜上、付録Dに再現されています。しかし、評価計画の開発を完了する前に、セキュリティ対策評価者は、この情報が最新であることを確認する必要があります。 SP 800-53A を使用して、SCA は、各コントロールの各テストイベントで使用される評価方法を特定することができます。 例として、SP800-53Aに記載されているAC-3(6)「Access Enforcement」の評価目的を以下に引用します：
ASSESSMENT OBJECTIVE: Determine if:
(i)
組織は、暗号化する、または安全な場所にオフラインで保存するユーザーおよび/またはシステム情報を定義する。
(ii)
組織は、暗号化する、または安全な場所にオフラインで保存する、組織定義のユーザーおよび/またはシステム情報。
考えられる評価方法と対象：
Examine: .
Interview。 .
テスト：.
これは主なセキュリティコントロールAC-3の強化である。 このコントロールが義務付けられているシステムで実装されなければならない2つの重要な拡張機能を検証します。 評価目的（i）で示されるように、この強化は、組織が暗号化されるかオフラインで保存されるシステム情報を特定したこと、およびパート（ii）で示されるように、組織が実際にこの情報をオフラインで暗号化または保存していることを検証するものである。 評価方法と評価対象は、これら2つの構成要素を評価するために必要なものを定義しています。 この場合、強化の完全な評価には、3つの方法-検査、インタビュー、テスト-がすべて必要である。
セキュリティコントロール評価計画を策定する際、セキュリティコントロール評価者はまずシステムを検査する方法を策定する。 SCAは、検査方法の「から選択」セクションで評価する。 SCAは、アクセス制御方針、アクセス強制に対処する手順、情報システム設計文書、情報システム構成設定と関連文書、情報システム監査記録、その他の関連文書または記録のいずれかまたはすべてを検査することが可能である。 評価者は、この機能強化のために定義されたテスト方法を評価し、次に、アクセス強制機能を実装した自動化されたメカニズムを評価するためのテスト計画を構築する。 次に、評価者は、システムの提出された BOE をレビューし、必要な情報タイプに対して暗号化または オフラインストレージのいずれかを実装するために使用される技術（テスト手順の出力または期待 される評価結果を含む）を判断する。 最後に、評価者は、このエンハンスメントには面接要件があるため、評価中に面接部分が実施されることに留意する。 必須ではありませんが、インタビューを実施するためのスクリプトを作成する評価者もいれば、評価の他の方法（検査とテスト）の結果のみを使用して、テスト中にインタビューの質問をその場しのぎで決定する評価者もいます。 これにより、システムをサポートするスタッフが、組織とシステム所有者によって定義されたこの機能強化の要件を理解していることが確認される。
このタスクの出力は、セキュリティコントロールの評価者、評価プロセス、および評価の境界を定義し、承認されたROEを含む、完全に開発、レビュー、および承認されたテストプランである。 評価チームの独立性が定義され、場合によっては、権限のある当局によって決定された独立した評価者の使用が要求される。 テスト計画は、作成されレビューされた後、AO により承認される。
セキュリティコントロールの評価計画の例の一部を付録G
に掲載しました。