- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2020-07-16T15:51:33+09:00","","")
#author("2020-07-17T10:43:04+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン（案）]]
*はじめに [#c252218c]
本項では、セキュアコーディングを確立するため、OWASP Application Security Verification Standard をベースに具体的な対策を国防総省 STIGs 及び本ガイドラインの設定対策に紐づけ解説します。
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 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]
-[[V1 アーキテクチャ、設計、脅威モデリングの要件]]
-[[V2 認証検証の要件]]
-[[V3 セッション管理検証要件]]
-[[V4 アクセス制御検証の要件]]
-[[V5 検証、サニタイズ、エンコーディング検証の要件]]
-[[V6 保存された暗号検証の要件]]
-[[V7 エラー処理とロギング検証の要件]]
-[[V8 データ保護検証の要件]]
-[[V9 通信検証の要件]]
-[[V10 悪意のあるコードの検証要件]]
-[[V11 ビジネスロジック検証の要件]]
-[[V12 ファイルとリソースの検証要件]]
-[[V13 APIおよびWebサービス検証の要件]]
-[[V14 構成検証の要件]]
