アーキテクチャ分析

アーキテクチャ分析では、ソフトウェア・アーキテクチャを簡潔な図にとらえたり、リスクや脅威のリストを適用したり、レビューにプロセス(STRIDEまたはアーキテクチャ・リスク分析など)を採用したり、組織のための評価および修正計画を策定します。

アーキテクチャ分析レベル1

[AA1.1: 101] セキュリティ機能レビューの実行。

アーキテクチャ分析を開始するには、セキュリティ機能のレビューをプロセスの中心に設定します。セキュリティの意識が高いレビューアは、アプリケーションのセキュリティ機能(認証、アクセス・コントロール、暗号化の使用など)を特定し、次にこれらの機能の実行が失敗する原因となる問題、あるいは目的の達成に不十分だと証明された機能が設計にないか調査します。たとえば、アクセス・コントロールが壊れているため権限攻撃を激しく受けるようになったシステム、あるいはPIIをローカル・ストレージに保存しているモバイル・アプリケーションはいずれもこの種のレビューで特定されます。より高いレベルの成熟度では、より包括的なアーキテクチャ分析手法の方が、機能をレビューするアクティビティに勝ります。場合によっては、セキュリティが設計に組み込まれた企業のコンポーネントを使用することで、このプロセスを効率化できます。

[AA1.2: 33] 高リスク・アプリケーションの設計レビューを実行する。

数個の高リスクの重要なアプリケーションのレビュー結果を見せれば、アーキテクチャ分析の利点を組織に説得できます。レビューアには、詳細な設計レビューを実行し、対象のアーキテクチャ、特に新しいプラットフォームか環境を分解した経験がある必要があります。すべての場合で、アーキテクチャ上の欠陥が特定でき、それを軽減する計画が策定できます。SSGにまだ詳細なアーキテクチャ分析を行った経験がない場合は、コンサルタントを使ってこの作業を実行します。ここでは、多くの専門知識を必要とする臨時のレビュー範例を使用できますが、長期的には拡張できません。ソフトウェア・プロジェクトが適切なプロセス段階を実行したかどうかのみに注目したレビューでは、期待される結果は得られません。堅牢性の十分な設計レビュー・プロセスはCI/CDの速度で実行することはできません。

[AA1.3: 27] SSGが設計レビューを先導している。

SSGは、設計上の欠陥を特定するために設計レビューを行って、アーキテクチャ分析のリーダーを務めます。このために、SSGは、アーキテクチャを分解しますが、その後作業をアーキテクトに引き渡せるよう、この作業に熟練している必要があり、熟練するには練習が必要です。多くの場合、SSGは、設計を理解するためにアーキテクトや実装者からの協力が必要で、単独では成功できません。設計が明確になったら、SSGは、プロジェクト・チームとそれほど連絡を密に取らなくても詳細なレビューを実行できます。より高いレベルの成熟度では、レビューのリーダー役はソフトウェア・アーキテクチャに移行します。アーキテクチャ分析(および脅威モデリング)は、長期間にわたって変化します。一旦決定した同じプロセスをいつまでも使用できないことに留意してください。

[AA1.4: 57] リスク質問票を使用してアプリケーションを格付けしている。

セキュリティ機能と設計レビュー・プロセスを円滑に実行するために、SSGは、リスク質問票を使用して各アプリケーションの情報を収集し、リスク別に分類し、スキーマの優先順位を決定します。質問には、「アプリケーション開発に使用しているプログラミング言語は?」、「アプリケーションのユーザーは誰ですか?」、「アプリケーションはコンテナで導入していますか?」といった内容を含めることができます。アプリケーション・チームの資格のあるメンバーが質問票に回答します。質問票は、数時間で回答できるよう、短めにします。SSGは、回答を使用してアプリケーションを「高」、「中」、「低」リスクに分類します。リスク質問票は、正確に回答されないことも多いため、信頼性と正確性を確認する抜き取り検査を実施することが重要です。自己申告制や自動化を過信すると、このアクティビティの効果がなくなります。

アーキテクチャ分析レベル2

[AA2.1: 15] AAプロセスの定義と使用。

SSGは、アーキテクチャ分析プロセスを定義し文書化して、欠陥を特定するための設計レビューに適用します。このプロセスには、攻撃に対する考え方、セキュリティ属性、関連リスクに関する標準化された手法が含まれます。このプロセスは、SSG以外の従業員が教育を受けて実行できるよう、厳密に規定されます。特に、レビュー対象のアーキテクチャと、特定されたセキュリティ上の欠陥の両方を慎重に文書化します。仲間内だけで通用する知識は、定義されたプロセスとはみなせません。マイクロソフトのSTRIDEやSynopsysのアーキテクチャ・リスク分析は、このプロセスの例です。これらの2つのアーキテクチャ・メソドロジーですら、長期的には大きく変わってきました。

[AA2.2: 14] アーキテクチャ記述(データ・フローを含む)の標準化。

定義されたAAプロセス([AA2.1 AAプロセスの定義と使用]を参照)では、データ・フローの表現方法など、合意されたアーキテクチャの記述形式が使用されます。この形式をアーキテクチャ分析プロセスと組み合わせることで、セキュリティの知識が少ない従業員でもアーキテクチャ分析に取り組むことができるようになります。クラウド・アプリケーションの場合は、データはインターネット上を移動する可能性が高くなります。この場合、ネットワーク図が有効ですが、ソフトウェアそのものの構造について詳細に記述されている必要があります。標準のアーキテクチャ記述に、保護が必要な情報資産の明示的な概要を追加することで、これを強化できます。また、UML図で一貫して使用されている標準化されたアイコン、Visioテンプレート、ホワイトボードを使った記述は特に効果的です。 

アーキテクチャ分析レベル3

[AA3.1: 4] ソフトウェア・アーキテクトが設計レビューを先導している。

ほとんどの場合、組織の各部門からのソフトウェア・アーキテクトを中心にアーキテクチャ分析プロセスが実行されます。SSGは、アドバイスを与えたり、あるいは特殊な状況では、アーキテクチャ分析に貢献できる場合もありますが、このアクティビティには、よく理解され、詳細に文書化されたアーキテクチャ分析プロセスが必要になります([AA2.1 AAプロセスの定義と使用]を参照)。この場合でも、アーキテクチャの分解には経験が必要なため、一貫性を維持することは難しくなります。

[AA3.2: 2] 分析結果を標準のアーキテクチャ・パターンに適用する。

アーキテクチャ分析で特定された欠陥は、改善された設計パターンで、同様の欠陥が今後発生しないよう、セキュリティ設計委員会にフィードバックとして返されます([SFD3.1 セキュリティ上安全な設計パターンを承認し維持する審査委員会または中央委員会を設立する]を参照)。セキュリティ設計パターンは、セキュリティを分解する方法に意外な形で関係している場合があります。審査対象の設計パターンが標準的に使用されている場合でも、アーキテクチャ分析プロセスは、適用される必要があります。

[AA3.3: 3] SSGがAAリソースまたは指導者の役割を果たしている。

SSG以外の従業員のアーキテクチャ分析能力を養成するため、SSGは、AAプロセスを使用して自分たちで独自に設計レビューを行おうとするチームが使用できるリソースまたは指導者として、SSGを活用するよう奨励します([ AA2.1 AAプロセスの定義と使用]を参照)。SSGは、運営時間中、アーキテクチャ分析に関する質問に回答し、分析中にアーキテクトと同席する従業員を任命する場合もあります。リスクの高いソフトウェアの場合は、SSGは、AAプロセスの適用に関する指導者として、より積極的な役割を果たします。