トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS

OWASP ASVS 4.0 のバックアップの現在との差分(No.3)


  • 追加された行はこの色です。
  • 削除された行はこの色です。
#author("2020-07-16T15:51:33+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン(案)]]
#freeze
#author("2020-12-22T14:34:36+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン]]

*はじめに [#c252218c]
本項では、Web アプリケーションのセキュアコーディングを確立するため、OWASP Application Security Verification Standard JA (公式日本語版、邦訳:Software 2020/8)を掲載し、推奨ガイドラインとします。~
OWSP ASVS は、[[序文]]や[[ASVSの使い方]] にもあるように、現代の Web アプリケーションおよび Webサービスを設計、開発、テストする際に必要となる、機能的および非機能的なセキュリティ管理策の定義に焦点を当てた、セキュリティ要件および管理策のフレームワークであり、①組織がセキュアなアプリケーションを開発および保守するのに役立つこと、②セキュリティサービスベンダ、セキュリティツールベンダ、および利用者が、各々の要件とプロダクトを調整できるようにすること、を目的に作られています。~
ASVSと活用することで、要件定義段階でのアプリケーションに対する非機能要件の洗い出しや、外部設計から詳細設計におけるセキュリティ開発標準として活用でき、また、結合テストや運用テストでのペネトレーションテストの項目の洗い出しに利用できます。~
また、ASVSをソフトウェアサプライチェーンでのセキュアコーディングガイドラインとして位置づけ、ベンダーに遵守を要求することで、各工程のセキュリティに関する品質の違いを、ある程度、均質にすることが可能となります。~
セキュリティに詳しくないユーザーにとって、ASVSはセキュリティ品質を確保するための優れた教科書として参考することができ、加えてベンダーとともにASVSの各項目が、作成するシステムに該当するか否か、該当する場合のセキュリティリスクの回避方法を具体的にを検討できます。~
リスクコミュニケーションのプラットフォームとして、ASVSを活用し、正しいセキュリティ品質要求、正しいセキュリティ実装、正しいセキュリティ品質テストを実現しましょう。~
https://github.com/OWASP/ASVS/tree/master/4.0 から、完全版PDF(邦訳 Software ISAC 2020年8月)を入手できます。

OWASP ASVS
*V1 アーキテクチャ、設計、脅威モデリング [#z97860f5]
**V1.1安全なソフトウェア開発ライフサイクル要件 [#r0ef66d8]
	
|1.1.1||開発のすべての段階でセキュリティに対処する安全なソフトウェア開発ライフサイクルの使用を確認します。(C1)
|1.1.2||脅威を特定し、対策を計画し、適切なリスク対応を促進し、セキュリティテストを導くために、すべての設計変更またはスプリント計画で脅威モデリングの使用を確認します。
|1.1.3||すべてのユーザーストーリーと機能に、「ユーザーは自分のプロファイルを表示および編集できるはずです。他のユーザーのプロファイルを表示または編集できないようにする」などの機能的なセキュリティ制約が含まれていることを確認します。
|1.1.4||すべてのアプリケーションの信頼境界、コンポーネント、および重要なデータフローのドキュメントと正当性を確認します。
|1.1.5||アプリケーションのハイレベルアーキテクチャと接続されているすべてのリモートサービスの定義とセキュリティ分析を確認します。(C1)
|1.1.6||集中化された、シンプルな(設計の経済性)、吟味された、安全な、再利用可能なセキュリティコントロールの実装を確認して、コントロールの重複、欠落、無効、または安全性を回避します。(C10)
|1.1.7||すべての開発者とテスターが安全なコーディングチェックリスト、セキュリティ要件、ガイドライン、またはポリシーを利用できることを確認します。
|1.2.1||すべてのアプリケーションコンポーネント、サービス、およびサーバーに対して、一意または特別な低特権オペレーティングシステムアカウントの使用を確認します。(C3)
|1.2.2||API、ミドルウェア、データレイヤーなどのアプリケーションコンポーネント間の通信が認証されていることを確認します。コンポーネントには、必要最小限の権限が必要です。(C3)
|1.2.3||アプリケーションが、安全であることがわかっている検証済みの単一の認証メカニズムを使用し、強力な認証を含めるように拡張でき、アカウントの悪用や違反を検出するための十分なログと監視があることを確認します。
|1.2.4||すべての認証経路とID管理APIが一貫した認証セキュリティ制御強度を実装していることを確認します。これにより、アプリケーションのリスクごとに弱い代替手段がないようになります。
|将来用の予約||
|1.4.1||アクセス制御ゲートウェイ、サーバー、サーバーレス機能などの信頼できる実施ポイントがアクセス制御を実施することを確認します。クライアントにアクセス制御を強制しないでください。
|1.4.2||選択したアクセス制御ソリューションが、アプリケーションのニーズを満たすのに十分な柔軟性を備えていることを確認してください。
|1.4.3||関数、データファイル、URL、コントローラー、サービス、およびその他のリソースにおける最小特権の原則の実施を確認します。これは、なりすましや特権の昇格に対する保護を意味します。
|1.4.4||アプリケーションが、保護されたデータとリソースにアクセスするために、十分に吟味された単一のアクセス制御メカニズムを使用していることを確認します。コピーと貼り付け、または安全でない代替パスを回避するには、すべてのリクエストがこの単一のメカニズムを通過する必要があります。(C7)
|1.4.5||属性または機能ベースのアクセス制御が使用されていることを確認します。これにより、コードは、役割だけでなく、機能/データ項目に対するユーザーの承認をチェックします。権限は引き続きロールを使用して割り当てる必要があります。(C7)
|1.5.1||入力と出力の要件が、タイプ、内容、適用される法律、規制、およびその他のポリシーのコンプライアンスに基づいてデータを処理および処理する方法を明確に定義していることを確認します。
|1.5.2||信頼できないクライアントと通信するときにシリアル化が使用されていないことを確認します。これが不可能な場合は、適切な整合性制御(および機密データが送信される場合は暗号化)が実施され、オブジェクトインジェクションなどの逆シリアル化攻撃が行われないようにします。
|1.5.3||信頼できるサービスレイヤーで入力検証が実施されていることを確認します。(C5)
|1.5.4||出力エンコーディングが、それが意図されているインタプリタの近くまたはそれによって発生することを確認します。(C4)
|1.6.1||暗号化キーの管理に関する明示的なポリシーがあり、暗号化キーのライフサイクルがNIST SP 800-57などのキー管理標準に従っていることを確認します。
|1.6.2||暗号化サービスの利用者が、鍵保管庫またはAPIベースの代替手段を使用して、鍵素材およびその他の秘密を保護することを確認します。
|1.6.3||すべてのキーとパスワードが置き換え可能であり、機密データを再暗号化するための明確に定義されたプロセスの一部であることを確認します。
|1.6.4||クライアントによって生成された、またはクライアントと共有された対称鍵、パスワード、またはAPIシークレットが、ローカルストレージの暗号化などの低リスクのシークレットの保護、またはパラメーター難読化などの一時的な一時的な使用でのみ使用されることを確認します。クライアントとシークレットを共有することは平文と同等であり、アーキテクチャ的にはそのように扱われるべきです。
|1.7.1||システム全体で共通のログ形式とアプローチが使用されていることを確認します。(C9)
|1.7.2||分析、検出、アラート、エスカレーションのために、ログが安全なリモートシステムに送信されることを確認します。(C9)
|1.8.1||すべての機密データが識別され、保護レベルに分類されていることを確認します。
|1.8.2||すべての保護レベルに、暗号化要件、整合性要件、保持、プライバシー、その他の機密性要件など、関連する一連の保護要件があり、これらがアーキテクチャに適用されていることを確認します。
|1.9.1||特にコンポーネントが異なるコンテナー、システム、サイト、またはクラウドプロバイダーにある場合、アプリケーションがコンポーネント間の通信を暗号化することを確認します。(C3)
|1.9.2||アプリケーションコンポーネントが通信リンクの両側の信頼性を検証し、中間者攻撃を防ぐことを確認します。たとえば、アプリケーションコンポーネントはTLS証明書とチェーンを検証する必要があります。
|1.10.1||チェックインに問題または変更チケットが伴うことを確認する手順を使用して、ソースコード管理システムが使用されていることを確認します。ソースコード管理システムには、変更を追跡できるように、アクセス制御と識別可能なユーザーが必要です。
|1.11.1||すべてのアプリケーションコンポーネントの定義とドキュメントを、それらが提供するビジネスまたはセキュリティ機能の観点から確認します。
|1.11.2||認証、セッション管理、アクセス制御を含むすべての重要なビジネスロジックフローが非同期状態を共有していないことを確認します。
|1.11.3||認証、セッション管理、アクセス制御を含むすべての高価値のビジネスロジックフローがスレッドセーフであり、チェック時間と使用時間の競合条件に対して耐性があることを確認します。
|1.12.1||ユーザーがアップロードしたファイルがWebルートの外部に保存されていることを確認します。
|1.12.2||ユーザーがアップロードしたファイル(アプリケーションから表示またはダウンロードする必要がある場合)が、オクテットストリームのダウンロード、またはクラウドファイルストレージバケットなどの関連のないドメインから提供されていることを確認します。適切なコンテンツセキュリティポリシーを実装して、アップロードされたファイルからのXSSベクトルまたはその他の攻撃によるリスクを軽減します。
|将来用の予約||
|1.14.1||明確に定義されたセキュリティ制御、ファイアウォールルール、APIゲートウェイ、リバースプロキシ、クラウドベースのセキュリティグループ、または同様のメカニズムを通じて、異なる信頼レベルのコンポーネントの分離を確認します。
|1.14.2||信頼できないデバイスにバイナリを展開する場合、バイナリ署名、信頼できる接続、および検証済みのエンドポイントを使用することを確認します。
|1.14.3||ビルドパイプラインが古いコンポーネントや安全でないコンポーネントについて警告し、適切なアクションを実行することを確認します。
|1.14.4||ビルドパイプラインに、アプリケーションの安全なデプロイメントを自動的にビルドおよび検証するビルドステップが含まれていることを確認します。特に、アプリケーションインフラストラクチャがソフトウェアで定義されている場合は、クラウド環境のビルドスクリプトなどです。
|1.14.5||特にデシリアライゼーションなどの機密または危険なアクションを実行している場合に、攻撃者が他のアプリケーションを攻撃するのを遅らせ、阻止するために、アプリケーションの展開がネットワークレベルで適切にサンドボックス化、コンテナ化、分離していることを確認します。(C5)
|1.14.6||アプリケーションが、NSAPIプラグイン、Flash、Shockwave、ActiveX、Silverlight、NACL、クライアント側Javaアプレットなど、サポートされていない、安全でない、または非推奨のクライアント側テクノロジーを使用していないことを確認します。


*OWASP アプリケーションセキュリティ検証標準 4.0 [#d756d6b8]
Application Security Verification Standard 4.0~
最終版~
2019年3月

-[[口絵]]
-[[序文]]
-[[ASVSの使い方]]
-[[監査と認証]]
-[[V1 アーキテクチャ、設計、脅威モデリングの要件]]
-[[V2 認証検証の要件]]
-[[V3 セッション管理検証要件]]
-[[V4 アクセス制御検証の要件]]
-[[V5 検証、サニタイズ、エンコーディング検証の要件]]
-[[V6 保存された暗号検証の要件]]
-[[V7 エラー処理とロギング検証の要件]]
-[[V8 データ保護検証の要件]]
-[[V9 通信検証の要件]]
-[[V10 悪意のあるコードの検証要件]]
-[[V11 ビジネスロジック検証の要件]]
-[[V12 ファイルとリソースの検証要件]]
-[[V13 APIおよびWebサービス検証の要件]]
-[[V14 構成検証の要件]]
-[[Appendix A 用語集]]
-[[Appendix B 参考情報]]
-[[Appendix C IoT検証要件]]
*ASVS利用にあたっての注意事項][#gab8d876]
ASVSはNIST SP800-63に準拠していますが、SP800-63 と全く同じとはいえません。例えば、パスワードの最低文字数は12文字であり、SP800-63 が規程した8文字とは異なり、厳しい設定値を推奨しています。また、パスワードハッシュの手法についても、SP800-63とは異なる見解をのべていますが、いずれも、SP800-63を最低限の基準とみなし、よりリスクを受容しない方向で規程していると考えられます。~
従って、仕様策定の際は、初めにASVSの規定値で標準仕様を検討し、ユーザービリティやシステム特性を加味した上で、SP800-63の基準でもリスク受容できると判断された場合は、その理由を文書化し、ダウングレードすることをお勧めします。