ASVS の使い方
Last updated
Was this helpful?
Last updated
Was this helpful?
ASVS には主な目標が二つあります。
組織がセキュアなアプリケーションを開発および保守するのに役立つこと。
セキュリティサービスベンダ、セキュリティツールベンダ、利用者がそれぞれの要件とサービス・製品を調整できるようにすること。
アプリケーションセキュリティ検証標準では三つのセキュリティ検証レベルを定義しており、レベルごとに深さを増していきます。
ASVS レベル 1 は低保証レベル向けであり、すべてがペネトレーションテスト可能です。
ASVS レベル 2 は機密データを含むアプリケーション向けであり、保護を必要とし、ほとんどのアプリに推奨されるレベルです。
ASVS レベル 3 は極めて重要なアプリケーション向けであり、高額取引を行うアプリケーション、機密性の高い医療データを持つアプリケーション、最高レベルの信頼性を必要とするアプリケーションのためのものです。
各 ASVS レベルはセキュリティ要件のリストを含みます。これらの各要件はセキュリティ固有の機能や開発者がソフトウェアに組み込む必要のある機能にもマップできます。
図 1 - OWASP アプリケーションセキュリティ検証標準 4.0 レベル
レベル 1 は人間によりすべてがペネトレーションテスト可能な唯一のレベルです。それ以外のものはすべてドキュメント、ソースコード、設定、開発プロセスに携わる人々へのアクセスを必要とします。但し、たとえレベル 1 が「ブラックボックス」 (ドキュメントなし、ソースなし) テストを行うことができたとしても、それは有効な保証活動ではなく積極的に阻止すべきです。悪意のある攻撃者にはかなりの時間があり、ほとんどのペネトレーションテストは数週間以内に終了します。防御する者はセキュリティ管理策を組み入れ、すべての弱点を保護、発見、解決し、悪意のある行為を行う者を妥当な時間内に検出および対応する必要があります。悪意のある行為を行う者は本質的に無限の時間があり、成功するためにはひとつの侵入しやすい防御、ひとつの弱点、または見逃した検出のみで足ります。ブラックボックステストは開発の最後に行われることが多く、あわただしく行われるか、全く行われず、このような不均衡に完全に対処することはできません。
過去 30 年以上にわたり、ブラックボックステストはさらに深刻な侵害に直接つながる重大なセキュリティ問題を見逃していることが何度も繰り返し証明されてきました。開発プロセス全体を通して開発者とドキュメントへのフルアクセスを伴い、レベル 1 でのペネトレーションテストをソースコード主導 (ハイブリッド) ペネトレーションテストに置き換えるなど、幅広いセキュリティ保証と検証の使用を強く推奨します。金融規制当局は財務記録、サンプル取引、管理を実行する人々にアクセスできない外部の財務監査を認めません。産業界および政府機関はソフトウェア工学の領域で同じ標準の透明性を要求しなければなりません。
開発プロセス自体の中でセキュリティツールを使用することを強く推奨します。DAST および SAST ツールはビルドパイプラインで継続的に使用して、存在してはならないセキュリティ問題を簡単に見つけることができます。
自動ツールとオンラインスキャンは人間による支援なしでは ASVS の半分以上を完了することができません。ビルドごとに包括的なテスト自動化が必要な場合には、カスタムの単体テストと統合テストの組み合わせをビルド開始時のオンラインスキャンとともに使用します。ビジネスロジックの欠陥とアクセス制御のテストは人間による支援でのみ可能です。これらは単体テストと統合テストに変えるべきです。
アプリケーションセキュリティ検証標準を使用する最善の方法の一つは、アプリケーション、プラットフォーム、組織に固有のセキュアコーディングチェックリストを作成するための青写真として使用することです。ユースケースに合わせて ASVS を仕立て直すことで、プロジェクトや環境にとって最も重要なセキュリティ要件に焦点を当てるでしょう。
検出が容易で、OWASP Top 10 や他の同様のチェックリストに含まれているアプリケーションセキュリティ脆弱性に対して適切に防御されていれば、アプリケーションは ASVS レベル 1 を達成します。
レベル 1 はすべてのアプリケーションが目指すべき必要最低限のレベルです。複数フェーズの作業での最初のステップとして、またはアプリケーションが機密データを格納や処理しないためレベル 2 や 3 のより厳しい管理策を必要としない場合にも役立ちます。レベル 1 管理策はツールにより自動的にチェックすることも、ソースコードにアクセスすることなく手動でチェックすることもできます。私たちはレベル 1 をすべてのアプリケーションに最低限必要なものと考えています。
アプリケーションに対する脅威は、発見が容易で悪用が容易な脆弱性を特定するために簡単で手間のかからない技法を使用している攻撃者からのものがほとんどです。これはアプリケーションを明確にターゲットとすることに集中的にエネルギーを費やす、確固たる攻撃者とは対照的です。アプリケーションにより処理されたデータが高い価値を持つ場合には、レベル 1 レビューで止めたくないでしょう。
今日のソフトウェアに関連するリスクのほとんどを適切に防御できれば、アプリケーションは ASVS レベル 2 (または Standard) を達成します。
レベル 2 ではセキュリティ管理策が適用され、効果的であり、アプリケーション内で使用されていることを確認します。ヘルスケア情報の処理、ビジネスに不可欠なまたは機密性の高い機能の実装、他の機密性の高い資産の処理などを含む、重要な企業間取引を処理するアプリケーションや、チートやゲームハックを阻止するゲーム業界などの、ビジネスを保護するために完全性が重要な要素となる業界に対して、通常、レベル 2 が適用されます。
レベル 2 アプリケーションの脅威は、通常、アプリケーション内の弱点を発見および悪用するために高度に実践され効果的なツールや技法を用いて特定のターゲットに集中する、熟練した動機のある攻撃者です。
ASVS レベル 3 は ASVS 内での最高レベルの検証です。このレベルは通常、軍事、安全衛生、重要インフラなどの分野で見られるような、重大なレベルのセキュリティ検証を必要とするアプリケーションを想定しています。
故障が組織の業務に、またその存続可能性にさえ大きく影響する可能性のある、重要な機能を実行するアプリケーションに対して、組織は ASVS レベル 3 を要求する可能性があります。ASVS レベル 3 のアプリケーションに関するガイダンスの例を以下に示します。高度なアプリケーションセキュリティ脆弱性に対して適切に防御し、優れたセキュリティ設計の原則を実証している場合、そのアプリケーションは ASVS レベル 3 (または Advanced) を達成します。
ASVS レベル 3 のアプリケーションは他のすべてのレベルよりもアーキテクチャ、コーディング、テストの詳細な分析を必要とします。セキュアなアプリケーションは (耐性、スケーラビリティ、そして何よりもセキュリティの層を促進するために) 意味のある方法でモジュール化され、各モジュール (ネットワーク接続や物理インスタンスで分離されている) はそれ自身のセキュリティ責任 (多層防御) を管理し、適切に文書化される必要があります。責任には機密性 (暗号化など) 、完全性 (トランザクション、入力検証など) 、可用性 (負荷の適切な処理など) 、認証 (システム間を含む) 、認可、監査 (ログ記録) を確保するための管理策が含まれます。
脅威が異なれば動機も異なります。一部の業界では独自の情報資産と技術資産があり、ドメイン固有の規制順守要件があります。
組織はそのビジネスの性質に基づく独自のリスク特性を詳細に検討し、そのリスクとビジネス要件に基づいて適切な ASVS レベルを決定することを強く推奨します。
各要件には <chapter>.<section>.<requirement> という形式の識別子があります。各要素は数値です。例: 1.11.3
<chapter> の値は要件の属する章に対応します。例: 1.#.# の要件はすべて アーキテクチャ の章のものです。
<section> の値は要件が現れる章内のセクションに対応します。例: 1.11.# の要件はすべて アーキテクチャ の章の ビジネスロジックアーキテクチャ セクションにあります。
<requirement> の値は章およびセクション内の特定の要件を識別します。例: この標準のバージョン 4.0.3 での 1.11.3 は以下のとおりです。
認証、セッション管理、アクセス制御など、価値の高いビジネスロジックフローのすべてがスレッドセーフであり、time-of-check time-of-use 競合状態に耐えられる。
識別子は標準のバージョン間で変更となる可能性があるため、他のドキュメント、レポート、ツールでは v<version>-<chapter>.<section>.<requirement> という形式を使用することを推奨します。ここでは 'version' は ASVS バージョンタグです。例: v4.0.3-1.11.3 はバージョン 4.0.3 の 'アーキテクチャ' の章の 'ビジネスロジックアーキテクチャ' セクションの 3 番目にある要件を意味すると理解できます。 (これは v<version>-<requirement_identifier> と要約できます。)
注: バージョン部分の前にある v は小文字にします。
v<version> 要素を含めずに識別子を使用する場合には、最新のアプリケーションセキュリティ検証標準コンテンツを参照していると想定すべきです。標準の進化や変更に伴い問題が発生することは明らかです。これが記者や開発者がバージョン要素を含めるべき理由です。
ASVS 要件リストは CSV, JSON, および参照またはプログラムでの使用に役立つ可能性があるその他の形式で提供されています。