V1 アーキテクチャ、設計、脅威モデリングの要件の変更点

Top/V1 アーキテクチャ、設計、脅威モデリングの要件
#author("2020-08-10T12:45:52+09:00","","")
#author("2020-08-10T12:46:45+09:00","","")
[[OWASP ASVS 4.0]]


*管理目標 [#t15c74af]
セキュリティアーキテクチャは多くの組織で失われた技術となっています。エンタープライズアーキテクトの時代は DevSecOps で過去のものとなりました。アプリケーションセキュリティの分野では、最新のセキュリティアーキテクチャの原則をソフトウェア実務者に再導入しながら、アジャイルセキュリティの原則をキャッチアップし採用する必要があります。アーキテクチャは実装ではなく、潜在的に多くの異なる答えがある可能性があり、唯一の「正しい」答えがない問題について考える方法です。多くの場合、開発者がその問題を解決するはるかに優れた方法を知っている可能性がある場合には、セキュリティは柔軟性がなく、開発者が特定の方法でコードを修正することを要求するものとみなされます。アーキテクチャに対して唯一で単純な解決策はありません。そして、そうではないフリをすることはソフトウェアエンジニアリング分野への害となります。&br;
Web アプリケーションの特定の実装はそのライフタイムを通じて継続的に改訂される可能性がありますが、全体的なアーキテクチャはほとんど変更されず、ゆっくりと進化します。セキュリティアーキテクチャも同様です。私たちは今日認証が必要ですし、明日も認証が必要でしょうし、五年後にも必要でしょう。今日、妥当な判断を下して、アーキテクチャに準拠したソリューションを選択して再利用すれば、多くの労力、時間、費用を節約できます。例えば、一昔前には、多要素認証はほとんど実装されていませんでした。&br;
開発者が SAML フェデレーションアイデンティティなどの単一のセキュアなアイデンティティプロバイダモデルに注力した場合、元のアプリケーションのインタフェースを変更することなく、NIST 800-63 コンプライアンスなどの新しい要件を組み込むためにそのアイデンティティプロバイダを更新できることでしょう。多くのアプリケーションが同じセキュリティアーキテクチャ、つまり同じコンポーネントを共有している場合、すべてのアプリケーションが同時にこのアップグレードの利を得られます。但し、SAML は常に最良ないし最適な認証ソリューションとして残るわけではありません。要件変更に応じて他のソリューションと交換する必要があるかもしれません。このような変更は互いに入り組んでおり、完全な書き直しが必要になるほどコストがかかるか、セキュリティアーキテクチャなしではまったく不可能となります。&br;
本章では、ASVS は妥当なセキュリティアーキテクチャの主要な側面である可用性、機密性、処理の完全性、否認防止、プライバシーをカバーしています。これらの各セキュリティ原則はすべてのアプリケーションに組み込まれ、本質的に備わったものでなければなりません。「シフトレフト」が重要です。セキュアコーディングチェックリスト、メンタリングとトレーニング、コーディングとテスティング、構築、展開、構成、運用で開発者の強化を開始します。そして、すべてのセキュリティ管理策が存在し機能していることを保証するために、フォローアップの独立テストで終了します。かつては業界として私たちが行うすべての作業が最後のステップでしたが、開発者が一日に数十回または数百回コードをプロダクションにプッシュするようになると、それだけでは不十分です。アプリケーションセキュリティの専門家はアジャイル技法に遅れずついていく必要があります。つまり、開発者ツールを採用し、コードを学び、開発者と協力することを意味します。他の全員が異動してから何か月も後にプロジェクトを批判するのではありません。&br;
&br;
*V1.1安全なソフトウェア開発ライフサイクル要件 [#iefc3a92]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.1.1|開発すべての段階でセキュアソフトウェア開発ライフサイクルを用いている。 (C1)||✓|✓||||
|1.1.2|脅威を特定し、対策を計画し、適切なリスク対応を促進し、セキュリティテストを進めるため、すべての設計変更またはスプリントプランニングに対する脅威モデリングが用いている。||✓|✓|1053|設計に関するドキュメントの欠落 |製品には、どのように設計されているかを示すドキュメントがありません。|
|1.1.3|すべてのユーザストーリーおよび機能に、「ユーザが、自分のプロフィールを表示および編集できるようにする。他のユーザのプロフィールを表示または編集するができない」などのセキュリティ上の制限機能が含まれる。||✓|✓|1110|設計文書が不完全 |製品の設計文書には、制御フロー、データフロー、システムの初期化、タスク間の関係、コンポーネント、合理性、または設計のその他の重要な側面が適切に記述されていません。|
|1.1.4|すべてのアプリケーションの信頼境界線、コンポーネントおよび重要なデータフローの文書化と正当性がある。||✓|✓|1059|不完全な文書 |文書には、紙または電子形式を問わず、製品の使用方法、構造、インタフェース、設計、実装、構成、操作など、製品の関連するすべての要素についての説明が含まれていません。|
|1.1.5|アプリケーションの高レベルアーキテクチャおよびすべてのリモート接続サービスの定義とセキュリティ分析がなされている。 (C1)||✓|✓|1059|不完全な文書 |文書には、紙または電子形式を問わず、製品の使用方法、構造、インタフェース、設計、実装、構成、操作など、製品の関連するすべての要素についての説明が含まれていません。|
|1.1.6|重複や欠落がある、非効果的な、もしくはセキュアでない管理策を回避するために、集中管理され簡潔（エコデザイン）で徹底調査され、セキュアで、再利用可能なセキュリティ管理策が実装されている。 (C10)||✓|✓|637|保護機構の不必要な複雑さ（「機構の経済性」を利用していない） |ソフトウェアは必要以上に複雑な機構を使用しており、機構が正しく理解されていない、モデル化されていない、設定されていない、 実装されていない、または使用されていない場合、結果的に弱点になる可能性があります。|
|1.1.7|セキュアコーディングチェックリスト、セキュリティ要件、ガイドラインまたはポリシーを、すべての開発者およびテスターが利用可能。||✓|✓|637|保護機構の不必要な複雑さ（「機構の経済性」を利用していない） |ソフトウェアは必要以上に複雑な機構を使用しており、機構が正しく理解されていない、モデル化されていない、設定されていない、 実装されていない、または使用されていない場合、結果的に弱点になる可能性があります。|


&br;
*V1.2認証のアーキテクチャ要件 [#veb71a6c]
認証を設計する際、攻撃者がコールセンターを呼び出して一般的に知らせている質問に答えることでアカウントをリセットできる場合、強力なハードウェア対応の多要素認証があるかどうかは問題なりません。身元を証明するときは、すべての認証経路が同じ強度を持つ必要があります。
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.2.1|すべてのアプリケーションコンポーネント、サービスおよびサーバに対して一意の、または特別な低特権のOSアカウントが使用されている。 (C3)||✓|✓|250|不必要な特権での実行 |ソフトウェアが必要最低限の特権レベルよりも高い特権レベルで操作を実行すると、新たな弱点が発生したり、他の弱点の結果が増幅されたりします。|
|1.2.2|API、ミドルウェア、データ層などのアプリケーションコンポーネント間の通信が認証されている。 コンポーネントには必要最小限の権限が設定されている。(C3)||✓|✓|306|重要な機能の認証がない| ソフトウェアは、証明可能なユーザー ID を必要としたり、大量のリソースを消費したりする機能の認証を実行しません。|
|1.2.3|セキュアであることが知られており、強力な認証を含むよう拡張できる単一で徹底調査された認証機構をアプリケーションが使用していること、アカウントの悪用や侵害を検出するのに十分なログ記録と監視をアプリケーション実装している。||✓|✓|306|重要な機能の認証がない| ソフトウェアは、証明可能なユーザー ID を必要としたり、大量のリソースを消費したりする機能の認証を実行しません。|
|1.2.4|アプリケーションのリスクごとに、弱い代替の認証が存在しないように、すべての認証経路とID管理APIが一貫した認証セキュリティ制御強実装している。||✓|✓|306|重要な機能の認証がない| ソフトウェアは、証明可能なユーザー ID を必要としたり、大量のリソースを消費したりする機能の認証を実行しません。|
&br;
*V1.3 セッション管理アーキテクチャ要件 [#qfa28b49]
これは将来のアーキテクチャ要件のためのプレースホルダです
&br;


*V1.4 アクセス制御アーキテクチャ要件 [#tafdeae1]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.4.1|アクセス制御ゲートウェイ、サーバ、サーバレス機能などの信頼できる強制ポイントでアクセス制御が実施されている。クライアント上でアクセス制御を実施してはなりません。||✓|✓|602|クライアント側でのサーバ側セキュリティの実施 |ソフトウェアは、サーバを保護することを目的としたメカニズムを実装するためにクライアントに依存するサーバで構成されています。|
|1.4.2|選択したアクセス制御ソリューションがアプリケーションのニーズを満たすのに十分柔軟性がある。||✓|✓|284|不適切なアクセス制御 |このソフトウェアは、許可されていないアクターからのリソースへのアクセスを制限していないか、または誤って制限しています。|
|1.4.3|機能、データファイル、URL、コントローラ、サービス、およびその他のリソースにおける最小特権の原則が実施されている。これにより、なりすましや特権昇格に対する保護が可能となります。||✓|✓|272|最小特権違反|chroot() のような操作を実行するために必要な特権レベルの上昇は、操作を実行した直後に削除する必要があります。|
|1.4.4|保護されたデータやリソースにアクセスするために、アプリケーションが1つの十分に検証されたアクセス制御機構を使用している。コピー&ペーストまたは安全でない代替パスを回避するため、すべてのリクエストがこの単一の機構をパスする必要があります。 (C7)||✓|✓|284|不適切なアクセス制御 |このソフトウェアは、許可されていないアクターからのリソースへのアクセスを制限していないか、または誤って制限しています。|
|1.4.5|属性または機能ベースのアクセス制御が使用されており、コードは単にユーザのロールではなくむしろ、機能/データ項目に対するユーザの権限を確認します。それでも、権限はロールを利用して割り当てる必要があります。 (C7)||✓|✓|275|カテゴリ：パーミッションの問題|このカテゴリの弱点は、権限の不適切な割り当てまたは処理に関連しています。|
&br;
*V1.5 入力および出力アーキテクチャ要件 [#t6ffadbb]
4.0 では、意味のある信頼境界線の用語として「サーバサイド」という用語をなくしました。信頼境界線は依然として重要です。信頼できないブラウザやクライアントデバイスでの決定はバイパス可能です。しかし、今日の主流のアーキテクチャ展開では、信頼の実行点が劇的に変わりました。したがって、ASVS で「信頼できるサービスレイヤ」という用語が使用されている場合、マイクロサービス、サーバレス API、サーバサイド、セキュアブートを備えたクライアントデバイス上の信頼された API、パートナー API や外部 API など、場所に関係なく、信頼された実行点を意味します。
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.5.1|入出力要件が、データの種類や内容および適用法、規制、その他のポリシー準拠に基づいて、取り扱い手順を明確に定義している。||✓|✓|1029|カテゴリ：OWASP トップテン 2017|このカテゴリの弱点は、OWASPトップテン2017のA3カテゴリに関連しています。|
|1.5.2|信頼できないクライアントと通信するときにシリアライゼーションが使用されていない。これが不可能な場合は、オブジェクトインジェクションを含むデシリアライゼーション攻撃を防ぐために、適切な完全性制御（および機密データが送信される場合はできる限り暗号化）を実施する。||✓|✓|502|信頼されていないデータのデシリアライズ |アプリケーションは、結果として得られるデータが有効であることを十分に検証することなく、信頼されていないデータをデシリアライズします。|
|1.5.3|信頼できるサービスレイヤで入力の妥当性確認が実施されている。 (C5)||✓|✓|602|クライアント側でのサーバ側セキュリティの実施 |ソフトウェアは、サーバを保護することを目的としたメカニズムを実装するためにクライアントに依存するサーバで構成されています。|
|1.5.4|アウトプットエンコーディングが意図されているインタプリタもしくはその近くで生成される。(C4)||✓|✓|116|出力の不適切なエンコードまたはエスケープ|不適切なエンコーディングまたは出力のエスケープソフトウェアは、別のコンポーネントと通信するために構造化されたメッセージを準備しますが、データのエンコーディングまたはエスケープが欠落しているか、正しく行われていません。その結果、メッセージの意図した構造が保持されません。|
&br;
*V1.6 暗号アーキテクチャ要件 [#q0c5c8c1]
アプリケーションは分類に従ってデータ資産を保護するために、強力な暗号化アーキテクチャで設計する必要があります。すべてを暗号化することは無駄であり、なにも暗号化しないことは法的な過失となります。通常、アーキテクチャ設計や高レベル設計、デザインスプリントやアーキテクチャスパイクの際に、バランスをとる必要があります。暗号を自ら設計したり追加導入したりすることは、最初から単純に組み込むよりも、セキュアに実装するために必然的により多くのコストがかかります。
アーキテクチャ要件はコードベース全体に内在するため、単体テストや統合テストは困難です。アーキテクチャ要件はコーディングフェーズを通じてコーディング標準を考慮する必要があり、セキュリティアーキテクチャ、ピアレビューやコードレビュー、振り返りの際にレビューする必要があります。
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.6.1|暗号鍵の管理に関する明示的なポリシーがあり、暗号鍵のライフサイクルがNIST SP 800-57などの鍵管理標準に従っている。||✓|✓|320|カテゴリ：鍵管理エラー|このカテゴリの弱点は、暗号化キーの管理のエラーに関連しています。|
|1.6.2|暗号化サービスの利用者が、Key Vault またはAPIベースの代替手段を使用して、キーマテリアルおよびその他の秘密情報を保護している。||✓|✓|320|カテゴリ：鍵管理エラー|このカテゴリの弱点は、暗号化キーの管理のエラーに関連しています。|
|1.6.3|すべての鍵とパスワードが置き換え可能であり、機密データを再暗号化するため明確に定義されたプロセスの一部となっている。||✓|✓|320|カテゴリ：鍵管理エラー|このカテゴリの弱点は、暗号化キーの管理のエラーに関連しています。|
|1.6.4|クライアントによって生成されたまたはクライアントと共有された対称鍵やパスワードまたはAPI秘密情報が、ローカルストレージの暗号化などの低リスクの秘密情報の保護、またはパラメータ難読化などの一時的な用途にのみ使用される。クライアントと秘密情報を共有することは、平文と同等であり、アーキテクチャ的にはそのように扱われる必要があります。||✓|✓|320|カテゴリ：鍵管理エラー|このカテゴリの弱点は、暗号化キーの管理のエラーに関連しています。|
&br;
*V1.7 エラー、ロギング、監査アーキテクチャ要件 [#f3b09349]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.7.1|システム全体で共通のログ形式とアプローチが使用されている。 (C9)||✓|✓|1009|カテゴリ：監査|このカテゴリの弱点は、システムの監査ベースのコンポーネントの設計とアーキテクチャに関連しています。攻撃者やシステムへの変更を特定するために、これらは頻繁にユーザーアクティビティのログを処理します。このカテゴリの弱点は、安全なアーキテクチャを設計または実装するときに対処されない場合、監査機能の品質の低下につながる可能性があります。|
|1.7.2|分析、検出、警告、およびエスカレーションのために、できればリモートシステムにログがセキュアに送信されている。 (C9)||✓|✓||||
&br;
*V1.8 データ保護とプライバシーアーキテクチャ要件 [#lcf467a2]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.8.1|すべての機密データが識別され、保護レベルごとに分類されている。||✓|✓||||
|1.8.2|暗号化要件、完全性要件、保存期間、プライバシー、その他の機密保持要件などの関連する保護要件一式がすべての保護レベルにあり、それらがアーキテクチャに適用されている。||✓|✓||||
&br;
*V1.9 通信アーキテクチャ要件 [#m11f448a]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.9.1|特にコンポーネントが異なるコンテナ、システム、サイトまたはクラウドプロバイダにある場合は、アプリケーションがコンポーネント間の通信を暗号化している。 (C3)||✓|✓|319|機密情報のクリアテキスト送信 |ソフトウェアは、機密情報またはセキュリティ上重要なデータを、許可されていないアクターが盗聴できる通信チャネルでクリアテキストで送信します。|
|1.9.2|中間者攻撃を防ぐために、アプリケーションコンポーネントが通信リンクの両側の信頼性を検証している。例えば、アプリケーションコンポーネントはTLS証明書とチェーンを検証する必要があります。||✓|✓|295|不適切な証明書の検証 ソフトウェアが証明書を検証しないか、または誤って検証します。|証明書が無効または悪意のあるものである場合、攻撃者がホストとクライアント間の通信経路を妨害することで、信頼されたエンティティになりすますことができる可能性があります。ソフトウェアは、信頼されたホストであると信じて悪意のあるホストに接続したり、信頼されたホストから発信されているかのように見えるなりすましデータを受け入れるようにだまされたりする可能性があります。|
&br;
*V1.10 悪意あるソフトウェアのアーキテクチャ要件 [#a4641fda]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.10.1|チェックインが、イシューや変更チケットによることを保証するため、手続きを定めてソースコード管理システムが利用されている。ソースコード管理システムは、アクセス制御と識別可能なユーザのみ登録され、どんな変更もトレースできるようにする必要がある。||✓|✓|284|不適切なアクセス制御 |このソフトウェアは、許可されていないアクターからのリソースへのアクセスを制限していないか、または誤って制限しています。|
&br;
*V1.11 ビジネスロジックアーキテクチャ要件 [#k23aabdd]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.11.1|提供するビジネスまたはセキュリティ機能の観点で、すべてのアプリケーションコンポーネントの定義と文書化がされている。||✓|✓|1059|不完全な文書 |文書には、紙または電子形式を問わず、製品の使用方法、構造、インタフェース、設計、実装、構成、操作など、製品の関連するすべての要素についての説明が含まれていません。|
|1.11.2|認証、セッション管理、アクセス制御を含むすべての重要なビジネスロジックフローが非同期状態で共有しない。||✓|✓|362|不適切な同期を伴う共有リソースを用いた同時実行（レースコンディション）|プログラムには、他のコードと同時に実行可能なコードシーケンスが含まれており、コードシーケンスは共有リソースへの一時的な排他的アクセスを必要としますが、同時に動作している別のコードシーケンスによって共有リソースを変更できるタイミングウィンドウが存在します。|
|1.11.3|認証、セッション管理、アクセス制御などを含む重要度の高いすべてのビジネスロジックフローがスレッドセーフであり、チェック時間（TOC）や使用時間（TOU）の競合状態に対して耐性がある。|||✓|367|チェック時間使用時間(TOCTOU) レースコンディション |ソフトウェアはリソースを使用する前にリソースの状態をチェックしますが、チェックと使用の間にリソースの状態が変化し、チェックの結果が無効になる可能性があります。このため、リソースが予期せぬ状態にある場合に、ソフトウェアが無効なアクションを実行してしまうことがあります。|
&br;
*V1.12 セキュアファイルアップロードアーキテクチャ要件 [#la1bf7a9]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.12.1|ユーザがアップロードしたファイルがWebルートの外部に保存される。||✓|✓|552|外部の関係者がアクセス可能なファイルまたはディレクトリ |本製品を使用すると、ファイルまたはディレクトリは、本来はアクセスできないはずのものであっても、権限のないアクターがアクセスできるようになります。|
|1.12.2|ユーザがアップロードしたファイル（表示またはアプリケーションからダウンロードする必要がある場合）が、オクテットストリームによるダウンロード、またはクラウドファイルストレージバケットなどの無関係なドメインからダウンロードされる。XSSベクターまたはアップロードされたファイルによる他の攻撃リスクを軽減するため、適切なコンテンツセキュリティポリシー（Content Security Policy）が実装されている。||✓|✓|646|外部から提供されたファイルのファイル名または拡張子への依存 |このソフトウェアはファイルのアップロードを許可しますが、適切な動作を決定するためにファイルのファイル名または拡張子に依存します。これは、攻撃者によってファイルが誤って分類され、危険な方法で処理される原因として使用される可能性があります。|
&br;
*V1.13 APIアーキテクチャ要件 [#iebb580f]
これは将来のアーキテクチャ要件のためのプレースホルダです。
&br;
V1.14 コンフィギュレーションアーキテクチャ要件
*V1.14 コンフィギュレーションアーキテクチャ要件 [#u076854d]
|50|350||||60|150|250|c
|項番|説明|L1|L2|L3|CWE No|タイトル|概要|h
|1.14.1|すべてのアプリケーションコンポーネント、サービス、サーバに対して、一意または特別な低権限のオペレーティングシステムアカウントが使用されている。||✓|✓|923|目的のエンドポイントへの通信チャネルの不適切な制限 |ソフトウェアは、特権または保護された操作のためにエンドポイントへの（またはエンドポイントからの）通信チャネルを確立しますが、正しいエンドポイントと通信しているかどうかを適切に確認していません。|
|1.14.2|信頼できないデバイスにバイナリを展開する場合は、バイナリ署名、信頼できる接続および検証済みのエンドポイントを使用する。||✓|✓|494|完全性チェックなしのコードのダウンロード |本製品は、ソース コードまたは実行ファイルを遠隔地からダウンロードし、コードの出所と完全性を十分に検証せずにコードを実行します。|
|1.14.3|ビルドパイプラインが、古いまたはセキュアでないコンポーネントについて警告し、かつ適切な措置が取られる。||✓|✓|1104|メンテナンスされていないサードパーティ製コンポーネントの使用 |本製品は、元の開発者または元の開発者の信頼できる代理人が積極的にサポートまたはメンテナンスしていないサードパーティ製コンポーネントに依存しています。|
|1.14.4|特にクラウド環境のビルドスクリプトなどアプリケーションインフラストラクチャがソフトウェアで定義されている場合、ビルドパイプラインにアプリケーションの安全なデプロイを自動的に構成および検証するビルドステップが含まれている。||✓|✓||||
|1.14.5|特に機密性が高い、またはデシリアライゼーションなど危険な動作を実行している場合は、攻撃者が他のアプリケーションを攻撃するのを遅らせたり阻止したりするために、アプリケーションのデプロイがネットワークレベルで適切にサンドボックス化、コンテナ化および/または隔離されている。 (C5)||✓|✓|265|カテゴリ:特権問題|このカテゴリの弱点は、特権の不適切な取り扱い、割り当て、または管理によって発生します。特権とは、ユーザなどのエージェントのプロパティです。特権は、通常は許可されていないことをエージェントに可能にします。例えば、コンピュータの再起動などのメンテナンス機能をエージェントに実行させる特権があります。|
|1.14.6|NSAPIプラグイン、Flash、Shockwave、ActiveX、Silverlight、NACL、またはクライアントサイドのJavaアプレットなど、サポートがされておらずセキュアでない、または非推奨のクライアント側技術をアプリケーションが使用していない。||✓|✓|477|廃止された関数の使用 |コードが非推奨または廃止された関数を使用している場合、コードが積極的にレビューまたはメンテナンスされていないことを示唆しています。|
V1 アーキテクチャ、設計、脅威モデリングの要件 の変更点

V1 アーキテクチャ、設計、脅威モデリングの要件の変更点
