ASVS とは何か？

アプリケーションセキュリティ検証標準 (ASVS) はウェブアプリケーションとサービスのセキュリティ要件を定義しており、安全なアプリケーションを設計、開発、保守、またはそれらのセキュリティを評価することを目的とするすべての人にとって貴重なリソースとなります。

この章では ASVS のスコープ、優先度ベースのレベルの構造、標準の主な使用例など、ASVS を使用する上での不可欠な側面について概説します。

ASVS のスコープ

ASVS のスコープは、アプリケーション (Application)、セキュリティ (Security)、検証 (Verification)、標準 (Standard) という名称で定義されます。これは、達成する必要があるセキュリティ原則を特定するという包括的な目標を掲げ、どの要件を含めるか、または除外するかを定めます。このスコープでは、実装要件の基盤となるドキュメント要件も考慮します。

攻撃者にとってスコープというようなものは存在しません。したがって、ASVS 要件は、CI/CD プロセス、ホスティング、運用アクティビティなど、アプリケーションライフサイクルの他の側面に関するガイダンスと併せて評価する必要があります。

アプリケーション (Application)

ASVS では「アプリケーション」を、セキュリティコントロールを統合する必要がある、開発中のソフトウェア製品と定義しています。ASVS は、開発ライフサイクルのアクティビティを規定したり、CI/CD パイプラインを介してアプリケーションを構築する方法を指示するのではなく、製品自体の中で達成する必要があるセキュリティ成果を指定します。

Web アプリケーションファイアウォール (WAF)、ロードバランサ、プロキシなど、HTTP トラフィックを提供、変更、検証するコンポーネントは、一部のセキュリティ制御がこれらに直接依存しているか、これらを介して実装できるため、特定の目的のためにアプリケーションの一部とみなされるかもしれません。これらのコンポーネントは、キャッシュされたレスポンス、レート制限、あるいは送信元と送信先に基づく送受信接続の制限に関連する要件について考慮する必要があります。

逆に、ASVS では通常、アプリケーションに直接関係しない要件や、構成がアプリケーションの責任範囲外となる要件を除外します。たとえば、DNS の問題は一般的に別のチームや機能によって管理されます。

同様に、アプリケーションが入力をどのように消費し、出力をどのように生成するかについて責任を負いますが、外部プロセスがアプリケーションやそのデータとやり取りする場合、ASVS のスコープ外とみなされます。たとえば、アプリケーションやそのデータのバックアップは、通常、外部プロセスの責任であり、アプリケーションやその開発者によって制御されるものではありません。

セキュリティ (Security)

すべての要件はセキュリティに明白な影響を与える必要があります。要件がない場合、アプリケーションは安全でなくなり、要件を実装することで、セキュリティリスクの発生可能性または影響のいずれかを軽減する必要があります。

機能的側面、コードスタイル、ポリシー要件など、その他の考慮事項はスコープ外です。

検証 (Verification)

要件は検証可能である必要があり、検証の結果は「不合格 (fail)」または「合格 (pass)」の判定になる必要があります。

標準 (Standard)

ASVS は標準に準拠するために実装されるセキュリティ要件の集合として設計されています。つまり、要件はそれを達成するためのセキュリティ目標を定義することに限定されます。その他の関連情報は ASVS 上に構築することも、マッピングを介してリンクすることもあります。

具体的には、OWASP には多くのプロジェクトがあり、ASVS は他のプロジェクトの内容との重複を意図的に避けています。たとえば、開発者は「特定の技術や環境で特定の要件を実装するにはどのようにすればよいか」という疑問を持つかもしれません。これは Cheat Sheet Series プロジェクトでカバーすべきです。検証者は「この環境でこの要件をテストするにはどのようにすればよいか」という疑問を持つかもしれません。これは Web Security Testing Guide プロジェクトでカバーすべきです。

ASVS はセキュリティ専門家だけが使用することを意図しているわけではありませんが、読者には内容を理解するための技術的知識や特定の概念を調査する能力が求められます。

要件 (Requirement)

特に ASVS では要件 (requirement) という用語が使用されており、これを満たすために何を達成する必要があるかを説明しています。ASVS には主な条件として要件 (must) のみを含み、推奨事項 (should) は含みません。

言い換えると、推奨事項は、それが問題を解決するための多くの可能な選択肢の一つにすぎない場合や、コードスタイルの考慮事項である場合など、要件である定義を満たしません。

ASVS の要件は、実装や技術に特化しすぎることなく、特定のセキュリティ原則に対応すること、と同時に、その存在理由が自明であることも意図しています。これはまた、要件が特定の検証方法や実装に基づいて構築されていないことも意味しています。

セキュリティ上の決定事項の文書化

ソフトウェアセキュリティでは、セキュリティ設計と使用するメカニズムを早い段階で計画することで、完成した製品や機能においてより一貫性と信頼性の高い実装につながります。

さらに、特定の要件については、実装が複雑になり、アプリケーションのニーズに非常に特化したものになります。よくある例としてはパーミッション、入力バリデーション、さまざまなレベルの機密データに関する保護コントロールなどがあります。

これを考慮して、「すべてのデータを暗号化する必要がある」というような包括的な記述や、要件であらゆるユースケースをカバーしようとするのではなく、アプリケーション開発者によるこの種のコントロールへのアプローチと構成を文書化することを義務付けるドキュメント要件を盛り込みました。そして、これが適切かどうかをレビューし、実際の実装をドキュメントと比較して、実装が期待通りかどうかを評価できます。

これらの要件は、アプリケーションを開発する組織が特定のセキュリティ要件を実装する方法に関する決定事項を文書化することを意図しています。

ドキュメント要件は、常に章の最初のセクションにあります (すべての章にあるわけではありません)。文書化された決定事項を実際に実施する必要がある箇所には、必ず関連する実装要件があります。ここでのポイントは、ドキュメントが整備されていることと、実際の実装が二つの別のアクティビティであることを検証することです。

これらの要件を盛り込む主な要因は二つあります。一つ目の要因は、セキュリティ要件には、アップロードできるファイルの種類、適用すべきビジネスコントロール、特定フィールドに許可される文字など、ルールが適用されることがよくあることです。これらのルールはアプリケーションごとに異なるため、ASVS では規範的に定義することはできず、チートシートやより詳しい回答もこの場合には役に立ちません。同様に、これらの決定事項が文書化されていなければ、これらの決定事項を実装する要件の検証を行うことはできないでしょう。

二つ目の要因は、特定の要件において、アプリケーション開発では特定のセキュリティ課題への対処方法に関する柔軟性を提供することが重要となることです。たとえば、以前の ASVS バージョンでは、セッションタイムアウトのルールは非常に規範的でした。現実的に言えば、多くのアプリケーション、特にコンシューマ向けのものでは、より穏やかなルールを持ち、代わりに他の緩和策を実装することを好みます。したがって、ドキュメント要件はこのあたりの柔軟性を明示的に許容します。

明らかに、個々の開発者がこれらの決定を下して文書化することは期待されていません。むしろ、組織全体がそのような決定を下し、それを開発者に確実に伝えて、開発者がそれに従うようにします。

開発者に新機能の仕様と設計を提供することは、ソフトウェア開発の標準的な手順です。同様に、開発者はその都度独自の判断を下すのではなく、共通のコンポーネントとユーザインタフェースメカニズムを使用することが期待されています。そのため、これをセキュリティに拡張することは、驚くべきことではなく、議論の余地もないでしょう。

これを実現する方法にも柔軟性があります。セキュリティに関する決定事項は、リテラルドキュメントに文書化され、開発者が参照することが求められるかもしれません。あるいは、セキュリティに関する決定事項を文書化し、共通のコードライブラリに実装して、すべての開発者が使用することを義務付けることもあります。いずれの場合でも、望ましい結果が得られます。

アプリケーションセキュリティ検証レベル

ASVS では三つのセキュリティ検証レベルを定義しており、レベルごとに深さと複雑さを増していきます。一般的な目標は、組織が最も重大なセキュリティ上の懸念に対処するために最初のレベルから始め、それから組織とアプリケーションのニーズに応じて上位レベルへ移行することです。レベルは文書および要件テキストにおいて L1, L2, L3 と表記することがあります。

各 ASVS レベルは、そのレベルで達成するために必要なセキュリティ要件を示し、残りの上位レベルの要件は推奨事項となります。

要件の重複や、上位レベルでは関係のない要件を避けるため、一部の要件は特定のレベルに適用されますが、上位レベルではより厳しい条件となっています。

レベル評価

レベルは、セキュリティ要件の実装とテストの経験に基づき、各要件の優先度ベースの評価によって定義されます。主な焦点はリスク軽減と要件実装の労力を比較することです。もう一つの重要な要素は参入障壁を低く抑えることです。

リスク軽減は、その要件がアプリケーション内のセキュリティリスクのレベルをどの程度軽減するかを考慮します。その際、従来の機密性、完全性、可用性の影響因子を考慮するとともに、その要件が防御の主要な層であるか、多層防御とみなされるかを考慮します。

基準とレベル分けの決定に関する厳密な議論の結果、あらゆる状況に 100% 適合するわけではないことを受け入れつつ、大半のケースに当てはまる割り当てを導き出しました。つまり、場合によっては、組織は独自のリスク考慮事項に基づいて、早い段階で上位レベルの要件を優先付けることが望ましいこともあります。

各レベルにおける要件の種類は以下のように特徴付けることができます。

レベル 1

このレベルはアプリケーションを保護にする際に考慮すべき最低限の要件を含み、重要な出発点となります。このレベルには ASVS 要件の約 20% を含みます。このレベルの目標は、可能な限り要件を少なくし、参入障壁を低く抑えることです。

これらの要件は通常、悪用可能な他の脆弱性や前提条件を必要としない一般的な攻撃を防ぐための、重要または基本的な第一層の防御要件です。

第一層の防御要件に加えて、パスワードに関連する要件など、上位レベルでは影響が少ない要件もあります。上位レベルでは多要素認証要件が重要になるため、これらはレベル 1 ではより重要です。

レベル 1 は、要件の数が少ないため検証は容易になるものの、ドキュメントやコードへの内部アクセスを持たない外部のテスト担当者によるペネトレーションテスト (「ブラックボックス」テストなど) が必ずしも可能であるとは限りません。

レベル 2

ほとんどはアプリケーションはこのレベルのセキュリティを達成するように努力すべきです。ASVS の要件の約 50% は L2 であるため、アプリケーションが L2 に準拠するには ASVS の要件の約 70% (L1 と L2 要件のすべて) を実装する必要があります。

これらの要件は通常、あまり一般的ではない攻撃、または一般的な攻撃に対するより複雑な防御のいずれかに関連します。これらは依然として防御の第一層であるかもしれませんし、攻撃が成功するには特定の前提条件を必要とするかもしれません。

レベル 3

このレベルは、最高レベルのセキュリティを実証しようとするアプリケーションの目標とすべきであり、準拠すべき要件の最後の約 30% を提供します。

このセクションの要件は通常、多層防御メカニズムまたはその他の有用だが実装が困難なコントロールのいずれかです。

どのレベルを達成するか

優先度ベースのレベルは、組織とアプリケーションのアプリケーションセキュリティ成熟度を反映することを意図しています。アプリケーションがどのレベルに到達すべきかを ASVS が規定するのではなく、組織はそのリスクを分析し、アプリケーションの機密性や、もちろんアプリケーションのユーザの期待に応じて、どのレベルに到達すべきかを決定する必要があります。

たとえば、限定的な機密データしか収集していないアーリーステージのスタートアップ企業は初期のセキュリティ目標としてレベル 1 に絞ることに決めるかもしれませんが、銀行はオンラインバンキングアプリケーションでレベル 3 未満のものを顧客に正当化するのは難しいかもしれません。

ASVS の使い方

ASVS の構成

ASVS は合計約 350 の要件で構成されており、17 の章に分かれています。各賞はさらにセクションに分かれています。

章とセクションを分ける目的は、アプリケーションに関連するものに基づいて、章とセクションの選択や除外を簡単にすることです。たとえば、マシン間 API の場合、Web フロントエンドに関連する V3 章の要件は関係ありません。OAuth や WebRTC を使用しないのであれば、それらの章も無視できます。

リリース戦略

ASVS リリースは "Major.Minor.Patch" というパターンに従い、番号はリリース内での変更内容に関する情報を示します。メジャーリリースでは最初の番号が変わり、マイナーリリースでは二番目の番号が変わり、パッチリリースでは三番目の番号が変わります。

• メジャーリリース - 全面的な再編成。要件番号を含め、ほぼすべてが変わっている可能性があります。準拠のための再評価が必要になります (例: 4.0.3 -> 5.0.0)。

• マイナーリリース - 要件が追加または削除されている可能性がありますが、全体的な番号付けは変わりません。準拠のための再評価が必要になりますが、より簡単になるはずです (例: 5.0.0 -> 5.1.0)。

• パッチリリース - 要件が削除されている (たとえば、重複していたり陳腐化した場合) または厳しさが緩和されている可能性がありますが、以前のリリースで準拠していたアプリケーションはパッチリリースでも準拠します (例: 5.0.0 -> 5.0.1)。

上記は特に ASVS の要件に関連しています。周囲のテキストや付録などのその他のコンテンツへの変更は、互換性を損なう変更とはみなされません。

ASVS の柔軟性

ドキュメント要件やレベルメカニズムなど、上述したいくつかの点により、ASVS をより柔軟かつ組織固有の方法で使用できるようになります。

さらに、組織には、アプリケーションの特定の特性とリスクレベルに基づいて要件を調整するために、組織またはドメイン固有のフォークを作成することを強く推奨します。ただし、要件 4.1.1 に合格することが、すべてのバージョンで同じ意味になるように、トレーサビリティを維持することが重要です。

理想的には、各組織が独自に調整した ASVS を作成して、関係のないセクション (GraphQL, WebSockets, SOAP など、不要な場合) を省略すべきです。組織固有の ASVS バージョンまたはサプリメントは、組織固有の実装ガイダンスを提供し、要件に準拠する際に使用するライブラリやリソースを詳述するのにも適しています。

ASVS 要件の見方

各要件には <chapter>.<section>.<requirement> という形式の識別子があります。各要素は数値です。例: 1.11.3

• <chapter> の値は要件の属する章に対応します。例: 1.#.# の要件はすべて エンコーディングとサニタイゼーション の章のものです。

• <section> の値は要件が現れる章内のセクションに対応します。例: 1.2.# の要件はすべて エンコーディングとサニタイゼーション の章の インジェクション防御 セクションにあります。

• <requirement> の値は章およびセクション内の特定の要件を識別します。例: この標準のバージョン 5.0.0 での 1.2.5 は以下のとおりです。

アプリケーションが OS コマンドインジェクションに対して保護していること、およびオペレーティングシステムコールがパラメータ化された OS クエリを使用するか、コンテキストに応じたコマンドライン出力エンコーディングを使用する。

識別子は標準のバージョン間で変更となる可能性があるため、他のドキュメント、レポート、ツールでは v<version>-<chapter>.<section>.<requirement> という形式を使用することを推奨します。ここでは 'version' は ASVS バージョンタグです。例: v5.0.0-1.2.5 はバージョン 5.0.0 の 'エンコーディングとサニタイゼーション' の章の 'インジェクション防御' セクションの 5 番目にある要件を意味すると理解できます。 (これは v<version>-<requirement_identifier> と要約できます。)

注: この形式でバージョン番号の前にある v は常に小文字にする必要があります。

v<version> 要素を含めずに識別子を使用する場合には、最新のアプリケーションセキュリティ検証標準コンテンツを参照していると想定すべきです。標準の進化や変更に伴いこれが問題になるため、執筆者や開発者はバージョン要素を含める必要があります。

ASVS 要件リストは CSV、JSON、および参照またはプログラムでの使用に役立つ可能性があるその他の形式で提供されています。

ASVS のフォーク

組織は ASVS を採用することでメリットがあります。三つのレベルのいずれかを選択するか、ドメイン固有のフォークを作成して、アプリケーションリスクレベルごとに要件を調整します。トレーサビリティが維持されている限りこのようなフォークを推奨します。要件 4.1.1 に合格することがすべてのバージョンで同じことを意味するようにします。

理想的には、各組織が独自に調整した ASVS を作成し、関係のないセクション (未使用の場合、GraphQL、Websockets、SOAP など) を省略すべきです。フォークは ASVS レベル 1 をベースラインとして始めて、アプリケーションのリスクに基づいてレベル 2 または 3 に進めるべきです。

ASVS のユースケース

ASVS はアプリケーションのセキュリティを評価するために使用できます。これについては次の章で詳しく説明しますが、ASVS (もしくはフォーク版) のその他の潜在的な用途がいくつか考えられています。

詳細なセキュリティアーキテクチャガイダンスとして

アプリケーションセキュリティ検証標準のより一般的な用途の一つはセキュリティアーキテクトのためのリソースです。特に最新のアプリケーションでは、安全なアプリケーションアーキテクチャの構築方法について利用できるリソースが限られています。ASVS を使用して、セキュリティアーキテクトがデータ保護パターンや入力バリデーション戦略などの一般的な問題に対してより適切なコントロールを選択できるようにすることで、これらのギャップを埋めることができます。アーキテクチャとドキュメントの要件は、特にこのために役立ちます。

専用のセキュアコーディングリファレンスとして

ASVS はアプリケーション開発時にセキュアコーディングリファレンスを作成するための基盤として使用でき、開発者がソフトウェアを構築する際にセキュリティを考慮するよう支援します。ASVS をベースとすることも可能ですが、組織は明確で統一された独自のガイダンスを作成すべきです。理想的にはセキュリティエンジニアやセキュリティアーキテクトの指導に基づいて作成します。この延長として、組織は可能な限り、ガイダンスの中で参照でき、開発者が使用できる承認済みセキュリティメカニズムとライブラリを準備することが推奨されます。

自動ユニットテストおよび自動統合テストのガイドとして

ASVS は高度にテスト可能なように設計されています。検証の一部は技術的なものですが、他の要件 (アーキテクチャ要件やドキュメント要件など) ではドキュメントやアーキテクチャのレビューが必要になることがあります。技術的な手段で検証可能な要件に関連する、特定の関連する悪用のケースをテストおよびファジングするユニットテストや統合テストやファジングを構築することにより、各ビルドでこれらのコントロールが正しく動作していることをチェックしやすくなります。例えば、ログインコントローラのテストスイートとして、一般的なデフォルトユーザ名、アカウント列挙、総当たり攻撃、LDAP と SQL インジェクション、XSS のユーザ名パラメータをテストする追加のテストを作成することができます。同様に、パスワードパラメータのテストには一般的なパスワード、パスワード長、null バイトインジェクション、パラメータの削除、XSS などを含める必要があります。

セキュア開発トレーニングのために

ASVS はセキュアソフトウェアの特性を定義するためにも使用できます。多くの「セキュアコーディング」コースはコーディングのヒントがわずかにあるだけの単なるエシカルハッキングコースです。これは開発者がよりセキュアなコードを書くのに必ずしも役に立つとは限りません。代わりに、セキュア開発コースでは、してはいけないことの Top 10 のような否定的なことではなく、ASVS にある肯定的なメカニズムに重点を置いて ASVS を使用できます。ASVS の構造は、アプリケーションを保護する際に、さまざまなトピックを順を追って説明するための論理的な構造も提供します。

セキュアなソフトウェアの調達をガイドするためのフレームワークとして

ASVS は、セキュアなソフトウェアの調達やカスタム開発サービスの調達を支援する優れたフレームワークです。調達者は単に入手したいソフトウェアを ASVS レベル X で開発しなければならないという要件を設定し、そのソフトウェアが ASVS レベル X を満たすことを販売者に証明するよう要求できます。

実際に ASVS を適用する

脅威が異なれば動機も異なります。一部の業界では独自の情報資産と技術資産があり、ドメイン固有の規制順守要件があります。

組織はそのビジネスの性質に基づく独自のリスク特性を詳細に検討し、そのリスクとビジネス要件に基づいて適切な ASVS レベルを決定することを強く推奨します。