監査と認証

ASVS 認証と認証マークに対する OWASP の見解

OWASP はベンダ中立の非営利組織であり、ベンダ、検証者、ソフトウェアの認証は行っていません。ASVS 準拠を主張する保証、認証マーク、認証はいずれも OWASP によって公式に承認されたものではないため、組織は第三者が主張する ASVS 認証に注意する必要があります。

OWASP の公式な認証であると主張しない限り、組織は保証サービスを提供できます。

ASVS コンプライアンスの検証方法

ASVS はテストガイドのレベルでのコンプライアンスを検証する厳密な方法について意図的に明確にしていません。しかし、いくつかの重要なポイントを強調しておくことは重要です。

検証レポート

従来のペネトレーションテストは「例外による」問題を報告し、不合格のみをリストします。しかし、ASVS 認証レポートには、スコープ、チェックしたすべての要件の要約、例外が記録された要件、問題解決のガイダンスを含めるべきです。要件の中には適用できないもの (ステートレス API でのセッション管理など) もあり、その旨をレポートに記載しなければなりません。

検証のスコープ

一部の要件はアプリケーションの機能にとって無関係またはそれほど重要ではないため、アプリケーションを開発する組織は一般的にすべての要件を実装するわけではありません。検証者は、組織が達成しようとしているレベルや含まれている要件など、検証のスコープを明確に定義する必要があります。これは、含まれていないものではなく、含んでいるものの観点で行う必要があります。また、実施されていない要件を除外する根拠についての意見を示す必要もあります。

これにより、検証報告書の利用者は検証の背景を理解し、アプリケーションにおける信頼レベルについて十分に理解した上で判断できるようになります。

認証機関は適切なテスト手法を選択できますが、レポートでそれを開示する必要があり、理想的には再現できる必要があります。アプリケーションや要件に応じて、手動ペネトレーションテストやソースコード解析などのさまざまな手法を使用して、入力バリデーションなどの側面を検証できます。

検証メカニズム

特定の ASVS 要件を検証するには、さまざまな技法が必要になることがあります。ペネトレーションテスト (アプリケーションを完全にカバーするために有効なクレデンシャルを使用する) 以外にも、ASVS 要件を検証するには、ドキュメント、ソースコード、構成、および開発プロセスに関与する人々へのアクセスが必要となることがあります。特に L2 および L3 の要件を検証する場合、作業書類、スクリーンショット、スクリプト、テストログなどの詳細なドキュメントで、調査結果の堅実な証跡を提供することは標準的な慣行です。各要件は検証可能な形でテストしていなければならないため、徹底的なテストを行わずに自動化ツールを実行するだけでは認証には不十分です。

ASVS 要件の検証における自動化の使用は、常に関心を集めるトピックです。したがって、自動テストとブラックボックステストに関連するいくつかのポイントを明確にすることが重要です。

自動セキュリティテストツールの役割

動的および静的アプリケーションセキュリティテストツール (DAST や SAST) などの自動セキュリティテストツールは、ビルドパイプラインに適切に実装されると、存在してはいけないセキュリティ問題を効果的に特定できるかもしれません。ただし、慎重な設定とチューニングを行わないと、必要なカバレッジが得られず、ノイズのレベルによって実際のセキュリティ問題を特定および緩和できなくなります。

これによって、出力エンコーディングやサニタイゼーションに関連するものなどの、より基本的で簡単な技術要件をカバーできるかもしれませんが、これらのツールではより複雑な ASVS 要件や、ビジネスロジックやアクセス制御に関連する要件の多くを完全には検証できないことに注意することが重要です。

それほど単純ではない要件では、自動化を利用できる可能性はありますが、これを実現するにはアプリケーション固有の検証を記述する必要があるでしょう。これらは組織がすでに使用している単体テストや統合テストに似ているかもしれません。そのため、この既存のテスト自動化インフラストラクチャを使用して、ASVS 固有のテストを記述することが可能かもしれません。これを行うには短期的な投資が必要ですが、これらの ASVS 要件を継続的に検証できるようになるという長期的な恩恵が大きくなるでしょう。

要約すると、自動化ツールを使用してテスト可能であることは、既製ツールを実行することではありません。

ペネトレーションテストの役割

バージョン 4.0 の L1 は「ブラックボックス」(ドキュメントもソースもない) テストを実行するように最適化されていましたが、それでも、これは効果的な保証活動ではなく、積極的に推奨すべきではないことは明らかでした。

必要な追加情報にアクセスできない状態でテストを行うことは、セキュリティ検証のメカニズムとしては非効率的で非効果的です。それは、ソースをレビューし、脅威や対策漏れを特定し、より短い時間枠でのはるかに徹底的なテストを実施する可能性を逃すことになるためです。

従来のペネトレーションテストを、アプリケーション開発者とアプリケーションのドキュメントに完全にアクセスできる、ドキュメントやソースコード主導 (ハイブリッド) のペネトレーションテストに置き換えることを強くお勧めします。これは、多くの ASVS 要件を検証するために必要になるでしょう。