アーキテクチャ分析

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

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

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

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

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

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

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

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

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

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

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

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

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

[AA2.2: 14] アーキテクチャ記述の標準化。

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

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

[AA3.1: 7] エンジニアリング・チームがアーキテクチャ分析プロセスをリードする。

ほとんどの場合、エンジニアリング・チームがアーキテクチャ分析プロセスをリードします。SSGがアドバイスを与えたり、あるいは特殊な状況では、アーキテクチャ分析に貢献できる場合もありますが、この活動には、よく理解され、詳細に文書化されたプロセスが必要になります([AA2.1 AAプロセスの定義と使用]を参照)。優れたプロセスが用意されていても、アーキテクチャの分解には多くの経験が必要なため、一貫性を維持することは難しくなります。新しい問題については、アーキテクトがSSGまたは外部の専門知識を利用できるようにする必要があります。

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

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

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

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