01主な
調査結果
■ アーキテクチャ フレームワークは、集合的な洞察を使用して、組織のリスクとビジネス コンテキストを考慮する際にユーザーを導くベスト プラクティスを作成します。これらの方法を適応およびカスタマイズすることは、組織がそれらの方法から最大の価値を引き出すのに役立ちます。
■ この方法論は、ビジネス入力と期待を使用して、反復可能で追跡可能な (ボトムアップおよびトップダウン) セキュリティ アーキテクチャ定義を作成するシステム エンジニアリング アプローチを提供します。
■ アーキテクチャ フレームワークをセキュリティ アーキテクチャ手法と組み合わせて使用すると、フレームワークに関連するビジネス セキュリティ コンテキストおよびニーズ (コンプライアンス義務など) に対処できます。
■ 戦略的アーキテクチャ、論理的アーキテクチャ、技術的アーキテクチャは異なる速度で変化し、結果も異なります。提供方法によってテクノロジー コンポーネントがどのように構築されるかが決まるため、プログラムによる実装方法は、変更の際に厳密さを実現するのに役立ちます。
02主な
ご提案
セキュリティ アーキテクチャにおけるテクノロジー、情報、復元力のリスクに対処する技術専門家として、次のことを行う必要があります。
■ ビジネス コンテキストを構築し、セキュリティ アーキテクチャの利点を促進するために、組織の上級関係者との対話を計画します。
■ NIST CSF などのフレームワーク手法を使用して、セキュリティ アーキテクチャの構築を高速化します。明確に定義されたビジネス目標と戦略目標に合わせてカスタマイズする計画を立てる必要があります。
■ SABSA などのセキュリティ手法を使用してビジネス コンテキストを定義し、システム エンジニアリング レベルのトレーサビリティとアーキテクチャ レイヤ間の厳密性を提供します。
■ フレームワークと方法論 (この 2 つは相互に排他的ではありません) を組み合わせて、「両方の長所」をどのように活用できるかを評価します。
03問題
提起
セキュリティ アーキテクチャの方法論とフレームワークのアプローチは、その価値を最大限に実現するために実行が複雑になる場合があります。よく考えられたセキュリティ アーキテクチャが存在しないと、効果のないセキュリティ機能が導入されることになります (過剰に導入されたり、ギャップがあったりします)。クライアントは、組織により良いサービスを提供するためにセキュリティ アーキテクチャ機能を実装する方法を理解しようとしています。方法論やフレームワークなど、さまざまな戦略があり、それぞれに長所と短所があります。
セキュリティ アーキテクチャのアクティビティに対する批判の 1 つは、セキュリティ アーキテクチャのアクティビティが、高価な 1 回限りのアクティビティであるか、アジャイルな配信を妨げ、実行時にすぐに現実を反映できなくなるアクティビティとみなされていることが多いということです。このガイドでは、セキュリティ アーキテクチャを配信実践に組み込む方法を含め、組織に焦点を当てた独自のカスタム セキュリティ アーキテクチャ アプローチを構築するプロセスを開始する方法について説明します。組織内の継続的な活動としてセキュリティ アーキテクチャを実装する準備を整える方法についてのガイダンスを提供します。
04
ガートナー法
セキュリティ アーキテクチャは、方法論を使用して第一原則に基づいて開発されるか、アーキテクチャ フレームワークをカスタマイズするかにかかわらず、高度に構造化されています。導入を成功させるには、選択、設計、既存のビジネス慣行への統合のプロセス全体にわたって慎重な管理が必要です。ビジネス目標を達成するには、アプローチを選択し、場合によっては組み合わせて、最適なセキュリティ アーキテクチャ プロセスを提供することが必要です。わかりやすくするために、このガイドは、ユーザーが組織に最適なパスを準備して選択するのに役立ちます。
このガイドでは、セキュリティ アーキテクチャ アプローチの実装をサポートするために計画する必要があるアクティビティについて説明します。フェーズは戦略的ニーズに基づいて、論理的なセキュリティの形成に役立つ特定のステップを経て進みます。必要なセキュリティ コンポーネントと技術の実装に役立つ、スムーズな設計プロセスの準備を推奨します。戦略的なテクノロジー目標を達成するには、セキュリティ アーキテクチャが 1 回限りのイベントではなく、継続的なプロセスである必要があります。この方法論は、セキュリティ アーキテクチャをビジネスや ITT の実践に組み込んで確実に受け入れられ、統合されるようにするためのガイダンスを提供します。
05リスク
と落とし穴
セキュリティ アーキテクチャ プロジェクトに対する一般的なリスクは次のとおりです。
■ よく考えられたセキュリティ アーキテクチャが欠如していると、効果のないセキュリティ機能が導入されることになります (過剰に導入されたり、ギャップが生じたりする)。セキュリティ機能が誤って展開されないように、セキュリティ アーキテクチャの実装のすべての段階にすべての関係者を含めて徹底的に行います。
■ セキュリティ アーキテクチャ プロセスを実装する場合、スコープの定義に失敗すると、セキュリティ アーキテクチャが誤って定義されます。不完全なスコープ境界は、スコープ境界がない、または単なる仮想的なスコープ境界と同じくらい問題です。したがって、対象範囲と完全性を確保するためにあらゆる努力を払う必要があります。IT リーダーと協力して、セキュリティ アーキテクチャ プロセスの正しい範囲を特定し、確実に定義します。
■ リスクを理解せずにセキュリティ アーキテクチャを開発することにより、組織は本質的にコンテキストフリーの汎用制御テンプレートを開発することになります。これでは焦点が合わなくなり、組織が直面する本当のリスクに対処できなくなります。すべてのセキュリティ アーキテクチャのアクティビティは、リスクの管理に特化する必要があります。
■ 既存のセキュリティおよび制御フレームワークを特定します。このステップが無視されたり軽視されたりすると、必要な制御フレームワーク要件とセキュリティ アーキテクチャ設計の間に不一致が生じる可能性があります。ガバナンスと設計の整合性が欠如していると、管理が不十分または欠落し、監査の不合格につながる可能性があります。すべてのセキュリティ ガバナンスおよびリスク チームと協力し、組織のセキュリティ ポリシーと標準を使用してセキュリティ アーキテクチャの形成を支援します。
■ 効果的なコミュニケーション計画がなければ、重大なリスクがセキュリティ アーキテクチャ アクティビティ全体の成功に影響を及ぼします。関係者、特に上級スタッフを巻き込むつもりがない場合、必要なときにすぐに来てくれない可能性があります。利害関係者の関与計画を策定します。
■ この段階のリスクに対して慎重に計画し準備をしないと、効果的なセキュリティ アーキテクチャを定義できなくなります。主なリスクは、必要な論理セキュリティ サービスを決定するための組織およびビジネス プロセスの詳細情報が十分にないことです。これらの問題は、そのような文書にアクセスし、ガイダンスを提供できる組織全体の関係者とつながることで軽減できます。
■ 多層防御を常にチェックする。セキュリティ アーキテクチャの高度化に関連する潜在的なリスクが生じるため、スキップしないでください。紙の上では、すべての要件が満たされているように見えます。ただし、補償制御が要件を適切に満たしているかどうかを検証する必要があります。
■ セキュリティ アーキテクトに既存のセキュリティ アーキテクチャを新しいプロジェクトに適用するよう促すために、十分なトリガーを定義する必要があります。
■ アーキテクトは、ビジネス目標の変化に応じて、論理的および技術的なセキュリティ アーキテクチャが確実に更新されるように取り組む必要があります。DevOps 用に作成されたリファレンス アーキテクチャやプログラミング コンポーネントなどの成果物も維持し、更新する必要があります。
2. 指導体制
このガイド フレームワークは、実装の重点分野に合わせた 5 つのフェーズで構成されるセキュリティ アーキテクチャへのアプローチを定義するのに役立ちます。ステージには次のものが含まれます。
-
範囲を定義し、環境を理解します。
-
戦略レベルのセキュリティに関する洞察を取得します。
-
論理的なセキュリティ アーキテクチャの開発をサポートします。
-
技術的なセキュリティ アーキテクチャの設計を促進します。
-
セキュリティ アーキテクチャを動的かつアクティブなプロセスにします。
図 1 はこれらのフェーズを要約し、サブフェーズのアクティビティと各フェーズで考えられる結果を示しています。
