- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2020-08-10T15:19:39+09:00","","")
#freeze
#author("2020-08-20T15:07:42+09:00","","")
[[OWASP ASVS 4.0]]
アプリケーションセキュリティ検証標準 (ASVS) バージョン 4.0 へようこそ。ASVS は現代の Webアプリケーションおよび Webサービスを設計、開発、テストする際に必要となる、機能的および非機能的なセキュリティ管理策の定義に焦点を当てた、セキュリティ要件および管理策のフレームワークを確立するコミュニティ主導の取り組みです。
ASVS v4.0 は長年にわたるコミュニティの取り組みと業界のフィードバックの集大成です。セキュアなソフトウェア開発ライフサイクルを通して、さまざまなユースケースに ASVS をより簡単に採用できるようにしました。&br;
アプリケーションセキュリティ検証標準 (ASVS) バージョン 4.0 へようこそ。ASVS は現代の Webアプリケーションおよび Webサービスを設計、開発、テストする際に必要となる、機能的および非機能的なセキュリティ管理策の定義に焦点を当てた、セキュリティ要件および管理策のフレームワークを確立するコミュニティ主導の取り組みです。&br;
&br;
ASVS v4.0 は長年にわたるコミュニティの取り組みと業界のフィードバックの集大成です。セキュアなソフトウェア開発ライフサイクルを通して、さまざまなユースケースに ASVS をより簡単に採用できるようにしました。&br;&br;
ASVS を含むあらゆる Webアプリケーション標準の内容に 100% 合意できるとは考えていません。リスク分析は常にある程度主観的なものであり、さまざまな場面に対応する規格で一般化しようとすることは困難が伴います。しかし、このバージョンで行われた最新の更新が正しい方向への一歩であり、この重要な業界標準に導入されたコンセプトの強化を願っています。
*4.0 の更新内容 [#yed9d963]
このバージョンでの最も重要な変更は NIST 800-63-3 デジタルアイデンティティガイドラインの導入であり、最新で、エビデンスをベースとする、高度な認証管理を紹介しています。高度な認証規格との整合については多少の相違が考えられますが、主に他のよく知られているアプリケーションセキュリティ標準規格がエビデンスベースの場合には、標準規格との調整が不可欠と考えています。&br;
準拠する組織が競合する管理策や相反する管理策を決定する必要がないように、情報セキュリティ標準は固有の要件の数を最小限に抑えるように努めるべきです。OWASP Top 10 2017 と現在の OWASP アプリケーションセキュリティ検証標準は認証とセッション管理に関して NIST 800-63 に準拠しています。セキュリティを最大化しコンプライアンスコストを最小化するために、他の標準化団体が私たち、NIST、および他の人たちと協力して、一般に認められている一連のアプリケーションセキュリティ管理策に取り組むことを歓迎します。&br;
ASVS 4.0 は最初から最後まで全面的に番号が付け替えられました。新しい採番スキームにより長期間消えていた章からのギャップを埋めることができ、開発者やチームが順守しなければならない管理策の数を最小限に抑えるために長い章をセグメント化できました。たとえば、アプリケーションが JWT を使用しない場合、セッション管理における JWT のセクション全体が適用されません。&br;
4.0 での新規項目は、近年長期にわたり最もよく求められていた機能要求のひとつです、Common Weakness Enumeration (CWE) への包括的なマッピングです。CWE マッピングにより、ツール開発業者と脆弱性管理ソフトウェアを使用しているユーザは、他のツールおよび以前の ASVS バージョンの結果を 4.0 およびそれ以降に一致させることができます。CWE エントリのためのスペースを確保するために、「導入バージョン」列を廃止しなければなりませんでした。「導入バージョン」列は完全に番号を付け替えたため、以前のバージョンの ASVS のものより意味がありません。ASVS のすべての項目に関連する CWE があるわけではありませんし、CWE には多くの重複があるため、必ずしも近いものではなく最も一般的に使用されているものを使用しようとしています。検証管理は常に同等の脆弱性にマップできるわけではありません。私たちはこのギャップをより一般的なものに埋めることに関して CWE コミュニティおよび情報セキュリティ分野との継続的な議論を歓迎します。&br;
私たちはOWASP Top 10 2017およびOWASP Proactive Controls 2018に対応する要件を包括的に満たし、上回るように努めてきました。OWASP Top 10 2017 は過失を回避するための最低限のもののため、特定のログ記録を除き意図的にすべての Top 10 要件をレベル 1 管理策とし、OWASP Top 10 の採用者が具体的なセキュリティ標準に容易にステップアップできるようにしています。&br;
このバージョンでの最も重要な変更は NIST 800-63-3 デジタルアイデンティティガイドラインの導入であり、最新で、エビデンスをベースとする、高度な認証管理を紹介しています。高度な認証規格との整合については多少の相違が考えられますが、主に他のよく知られているアプリケーションセキュリティ標準規格がエビデンスベースの場合には、標準規格との調整が不可欠と考えています。&br;&br;
準拠する組織が競合する管理策や相反する管理策を決定する必要がないように、情報セキュリティ標準は固有の要件の数を最小限に抑えるように努めるべきです。OWASP Top 10 2017 と現在の OWASP アプリケーションセキュリティ検証標準は認証とセッション管理に関して NIST 800-63 に準拠しています。セキュリティを最大化しコンプライアンスコストを最小化するために、他の標準化団体が私たち、NIST、および他の人たちと協力して、一般に認められている一連のアプリケーションセキュリティ管理策に取り組むことを歓迎します。&br;&br;
ASVS 4.0 は最初から最後まで全面的に番号が付け替えられました。新しい採番スキームにより長期間消えていた章からのギャップを埋めることができ、開発者やチームが順守しなければならない管理策の数を最小限に抑えるために長い章をセグメント化できました。たとえば、アプリケーションが JWT を使用しない場合、セッション管理における JWT のセクション全体が適用されません。&br;&br;
4.0 での新規項目は、近年長期にわたり最もよく求められていた機能要求のひとつです、Common Weakness Enumeration (CWE) への包括的なマッピングです。CWE マッピングにより、ツール開発業者と脆弱性管理ソフトウェアを使用しているユーザは、他のツールおよび以前の ASVS バージョンの結果を 4.0 およびそれ以降に一致させることができます。CWE エントリのためのスペースを確保するために、「導入バージョン」列を廃止しなければなりませんでした。「導入バージョン」列は完全に番号を付け替えたため、以前のバージョンの ASVS のものより意味がありません。ASVS のすべての項目に関連する CWE があるわけではありませんし、CWE には多くの重複があるため、必ずしも近いものではなく最も一般的に使用されているものを使用しようとしています。検証管理は常に同等の脆弱性にマップできるわけではありません。私たちはこのギャップをより一般的なものに埋めることに関して CWE コミュニティおよび情報セキュリティ分野との継続的な議論を歓迎します。&br;&br;
私たちはOWASP Top 10 2017およびOWASP Proactive Controls 2018に対応する要件を包括的に満たし、上回るように努めてきました。OWASP Top 10 2017 は過失を回避するための最低限のもののため、特定のログ記録を除き意図的にすべての Top 10 要件をレベル 1 管理策とし、OWASP Top 10 の採用者が具体的なセキュリティ標準に容易にステップアップできるようにしています。&br;&br;
ASVS 4.0 レベル 1 は、アプリケーション設計、コーディング、テスト、セキュアコードレビュー、ペネトレーションテストのための PCI DSS 3.2.1 セクション 6.5 の包括的なスーパーセットであることを確認することに着手しました。これには、既存の業界をリードするアプリケーションおよびWebサービスの検証要件に加えて、V5 ではバッファオーバーフローと危険なメモリ操作、V14 では危険なメモリ関連のコンパイラフラグを含める必要がありました。&br;
ASVS はモノリシックなサーバサイドのみの管理策から、現代のすべてのアプリケーションおよび API に対するセキュリティ管理策を提供することへの移行を完了しました。関数型プログラミング、サーバレス API 、モバイル、クラウド、コンテナ、CI/CD および DevSecOps 、フェデレーションなどの時代には、現代のアプリケーションアーキテクチャを無視し続けることはできません。現代のアプリケーションはオリジナルの ASVS が 2009 年にリリースされたときに構築されたものとは全く異なるように設計されています。私たちの主要なオーディエンスである開発者に適切なアドバイスを提供するために、ASVS は常に遠い将来を見据えたものでなければなりません。アプリケーションが単一の組織により所有されているシステム上で実行されることを前提としている要件を明確化または廃止しました。&br;
ASVS 4.0 のサイズ、および他のすべての ASVS の取り組みのためのベースライン ASVS になりたいという私たちの願いのために、OWASP モバイルアプリケーションセキュリティ検証標準(MASVS) に賛同し、モバイルの章を削除しました。Internet of Things の付録は OWASP Internet of Things Project のもとで将来 IoT ASVS として現れるでしょう。付録 C に IoT ASVS の早期プレビューがあります。これらの ASVS をサポートしてくれた OWASP Mobile Team と OWASP IoT Project Team の双方に感謝し、将来彼らが補完的な標準を提供することを楽しみにしています。&br;
ASVS はモノリシックなサーバサイドのみの管理策から、現代のすべてのアプリケーションおよび API に対するセキュリティ管理策を提供することへの移行を完了しました。関数型プログラミング、サーバレス API 、モバイル、クラウド、コンテナ、CI/CD および DevSecOps 、フェデレーションなどの時代には、現代のアプリケーションアーキテクチャを無視し続けることはできません。現代のアプリケーションはオリジナルの ASVS が 2009 年にリリースされたときに構築されたものとは全く異なるように設計されています。私たちの主要なオーディエンスである開発者に適切なアドバイスを提供するために、ASVS は常に遠い将来を見据えたものでなければなりません。アプリケーションが単一の組織により所有されているシステム上で実行されることを前提としている要件を明確化または廃止しました。&br;&br;
ASVS 4.0 のサイズ、および他のすべての ASVS の取り組みのためのベースライン ASVS になりたいという私たちの願いのために、OWASP モバイルアプリケーションセキュリティ検証標準(MASVS) に賛同し、モバイルの章を削除しました。Internet of Things の付録は OWASP Internet of Things Project のもとで将来 IoT ASVS として現れるでしょう。付録 C に IoT ASVS の早期プレビューがあります。これらの ASVS をサポートしてくれた OWASP Mobile Team と OWASP IoT Project Team の双方に感謝し、将来彼らが補完的な標準を提供することを楽しみにしています。&br;&br;
最後に、影響の少ない管理策を重複削減および廃止しました。時間とともに、ASVS は包括的な管理策のセットになり始めましたが、すべての管理策がセキュアなソフトウェアを生み出すうえで同等というわけではありません。影響の少ない項目を排除するこの取り組みはさらに進むかもしれません。ASVS の将来のエディションでは、Common Vulnerability Scoring System (CVSS) が真に重要な管理策と廃止すべき管理策の優先順位付けに役立つでしょう。
バージョン 4.0 では、ASVS は従来および現在のアプリケーションアーキテクチャ、アジャイルセキュリティプラクティス、DevSecOps カルチャーをカバーする、主要な Webアプリおよびサービス標準であることにのみフォーカスしています。
