- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2020-07-17T10:43:04+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン（案）]]
#freeze
#author("2020-12-22T14:34:36+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン]]
*はじめに [#c252218c]
本項では、セキュアコーディングを確立するため、OWASP Application Security Verification Standard をベースに具体的な対策を国防総省 STIGs 及び本ガイドラインの設定対策に紐づけ解説します。
本項では、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 Application Security Verification Standard とは [#s39ef6e8]
ASVS プロジェクトは、アプリケーションの設計、開発、脆弱性診断などにおけるセキュリティ要件の標準を開発するプロジェクトです。ASVS v4.0.1 では、以下のセキュリティ要件を総計14のカテゴリに分類してまとめリスト化しています。~
また、ASVSはアプリケーションの性質、特性に応じてセキュリティレベルを3段階に分けています。これによって最低限設定すべき項目から、高い信頼性を求められるシステムでの実装すべきセキュリティ項目を洗い出すことが可能となっています。
&br;
-レベル1: 全てのアプリケーションが満たすべきもの
-レベル2: 機微なデータを扱うアプリケーションが満たすべきもの
-レベル3: さらに高度な信頼性が求められるアプリケーションが満たすべきもの
ASVSはクリエイティブコモンズ CC BY-SA（表示ｰ継承）でライセンスされるため、変更点を明示し、同様のライセンスを付与することで、商用利用、再頒布が可能です。~
ASVS を要件定義段階でセキュリティ標準として定めることで、設計、コーディング段階での具体的な仕様を提示することが可能となります。また、ASVS は共通脆弱性タイプ一覧 （Common Weakness Enumeration：https://cwe.mitre.org/）に紐づいていることから、脅威に基づく対策を設定やコーディングレベルで保証でき、脆弱性管理の監査が容易になります。
&br;
設計段階で各対策の該当・非該当を示し、コーディングレベルでのコンポーネントの使用方法を具体的に示すことで、サプライチェーンでのコーディング規約が確立でき、また、単体テスト、結合テスト、出荷テストなど各段階での脆弱性検査や、脆弱性スキャナーなどのツールを使用する際の具体的なテスト項目の洗い出しにも活用できます。
**ASVS v4.0.1 [#q10c69c5]
*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の基準でもリスク受容できると判断された場合は、その理由を文書化し、ダウングレードすることをお勧めします。
