監査と認証

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

OWASP はベンダ中立の非営利組織であり、現在、ベンダ、検証者、ソフトウェアの認証は行っていません。

そのような保証の表明、認証マーク、認証はいずれも OWASP によって公式に検査、登録、認証されたものではありません。そのような見解に依存している組織は ASVS 認証を主張する第三者や認証マークについて、その信頼性に注意する必要があります。

これは、OWASP の公式な認証であると主張しない限り、組織がこのような保証サービスを提供することを妨げるものではありません。

認証機関のためのガイダンス

アプリケーションセキュリティ検証標準はアプリケーションのオープンブック検証として使用できます。特にレベル 2 とレベル 3 の検証には、設計者や開発者、プロジェクト文書、ソースコード、(役割ごとにひとつ以上のアカウントへのアクセスを含む) テストシステムへの認証されたアクセスといった、主要リソースへのオープンで自由なアクセスを含みます。

歴史上、ペネトレーションテストとソースコードレビューは「例外による」問題を含んでいました。つまり、不合格のテストのみが最終レポートに示されます。認証機関は (特に SSO 認証などの主要コンポーネントがスコープ外の場合) 検証のスコープ、合格および不合格のテストを含む検証結果の要約、不合格のテストへの解決法の明確な指示をレポートに含める必要があります。

特定の検証要件はテスト中のアプリケーションに適用されない場合があります。例えば、クライアント実装なしで顧客にステートレスサービス層 API を提供する場合、V3 セッション管理の要件の多くは直接適用されません。そのような場合、認証機関は依然として ASVS の完全な順守を主張することができますが、そのような除外された検証要件が適用されない理由を明確にレポートに示さなければなりません。

詳細な調書、スクリーンショットやムービー、問題を確実かつ繰り返し利用するためのスクリプト、傍受したプロキシログなどのテストの電子記録、クリーンアップリストなどの関連メモを保持することは標準的な業界の慣行と考えられます。そして、最も疑わしい開発者の発見の証拠として本当に役に立ちます。単にツールを実行して不合格を報告するだけでは十分ではありません。認証レベルのすべての問題がテストされ、余すところなくテストされている十分な証跡を (まったく) 提供していません。異議申し立てがあった場合に備えて、それぞれすべての検証要件が実際にテストされたことを実証するのに十分な証跡が必要となります。

テスト手法

認証機関は適切なテスト手法を自由に選択できますが、レポートに記載する必要があります。

テスト対象のアプリケーションと検証要件に応じて、結果に均一な信頼性を得るためにさまざまなテスト手法を使用できます。例えば、アプリケーションの入力検証メカニズムの有効性を妥当性確認するには、手動ペネトレーションテストで分析するかソースコード解析を用います。

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

自動ペネトレーションテストツールの使用は、できるだけ多くの範囲をカバーするために推奨されています。

自動ペネトレーションテストツールだけを使用して ASVS 検証を完全に完了することはできません。レベル 1 の要件の大部分は自動テストを使用して実行できますが、要件全体の大半は自動ペネトレーションテストには適していません。

アプリケーションセキュリティ業界が成熟するにつれて、自動テストと手動テストの境界があいまいになっていることに注意してください。自動ツールは専門家により手動で調整されることが多く、手動テスト担当者はさまざまな自動テストツールを活用することがよくあります。

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

バージョン 4.0 では、ソースコード、ドキュメント、開発者にアクセスすることなくレベル 1 を完全にペネトレーションテストできるようにしました。OWASP Top 10 2017 A10 に準拠するための必要な二つのログ記録の項目は、OWASP Top 10 2017 の場合と同様に、インタビュー、スクリーンショット、その他の証跡収集が必要になります。しかし、必要な情報にアクセスせずにテストすることは、ソースのレビュー、脅威の特定、管理策の欠如、そしてより短期間での十分なテスト実行の可能性を見逃すため、セキュリティ検証の理想的な方法ではありません。

可能であれば、開発者、ドキュメント、コードへのアクセス、および本番用ではないデータでのテストアプリケーションへのアクセスが、レベル 2 またはレベル 3 アセスメントを実行する際に必要です。これらのレベルで行われるペネトレーションテストには、「ハイブリッドレビュー」や「ハイブリッドペネトレーションテスト」と呼ぶ、このレベルのアクセスが必要です。

ASVS のその他の用途

アプリケーションのセキュリティを評価するために使用される以外に、ASVS のその他の潜在的な用途がいくつか考えられています。

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

アプリケーションセキュリティ検証標準のより一般的な用途の一つはセキュリティアーキテクトのためのリソースです。Sherwood Applied Business Security Architecture (SABSA) にはアプリケーションセキュリティアーキテクチャの十分なレビューを完了するために必要な多くの情報が欠けています。ASVS を使用して、セキュリティアーキテクトがデータ保護パターンや入力バリデーション戦略などの一般的な問題に対してより適切な管理策を選択できるようにすることで、これらのギャップを埋めることができます。

画一的なセキュアコーディングチェックリストの代わりとして

多くの組織は ASVS を採用することでメリットがあります。三つのレベルのいずれかを選択するか、ASVS をフォークし、各アプリケーションのリスクレベルに必要なものをドメイン固有の方法で変更します。トレーサビリティが維持されている限りこのタイプのフォークをお勧めします。アプリが要件 4.1 をパスした場合、これはフォークされたコピーについても標準としてそれが進化したものとして同じことを意味します。

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

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

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

ASVS はセキュアソフトウェアの特性を定義するためにも使用できます。多くの「セキュアコーディング」コースはコーディングのヒントがわずかにあるだけの単なる倫理的ハッキングコースです。これは開発者がよりセキュアなコードを書くのに必ずしも役に立つとは限りません。代わりに、セキュア開発コースでは、してはいけないことの Top 10 ネガティブ項目ではなく、ASVS にある予防的管理策に重点を置いて ASVS を使用できます。

アジャイルアプリケーションセキュリティの牽引役として

ASVS は、セキュアな製品を開発するためにチームが実装する必要がある特定のタスクを定義するためのフレームワークとして、アジャイル開発プロセスで使用できます。一つのアプローチとして、レベル 1 から始めて、指定されたレベルの ASVS 要件に従い特定のアプリケーションやシステムを検証し、どの管理策が欠けているかを見つけ、バックログに特定のチケットやタスクを上げます。これは特定のタスクの優先度付け (または調整) に役立ち、アジャイルプロセスでセキュリティを可視化します。これはまた、特定の ASVS 要件が特定のチームメンバーのレビュー、リファクタリング、監査の牽引役となり、バックログでいずれ行う必要がある「負債」として可視化され、組織内の監査タスクおよびレビュータスクの優先度付けにも使用できます。

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

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