ASVS の使い方
序文で述べたように、ASVS は現代の Web アプリケーションおよび Web サービスで考慮すべき、機能的および非機能的なセキュリティ要件を定義する標準です。
したがって、アプリケーションを開発するためのセキュアプロセスではなく、アプリケーションのコンテンツに焦点を当てています。セキュア開発プロセスは OWASP SAMM プロジェクトでより適切にカバーされており、ASVS の主要なスコープではありません。
セキュア要件のコンテキストにおいて、ASVS は以下のことを行おうとする人に役立つでしょう。
セキュアアプリケーションの開発と保守。
アプリケーションのセキュリティの評価。
この章ではレベルを使用したリスクベースのアプローチを採用することや標準のさまざまなユースケースなど、ASVS を使用する際の重要な側面について説明します。
アプリケーションセキュリティ検証レベル
アプリケーションセキュリティ検証標準では三つのセキュリティ検証レベルを定義しており、レベルごとに深さを増していきます。
ASVS レベル 1 は低保証レベル向けであり、すべてがペネトレーションテストを通じて検証可能です。
ASVS レベル 2 は機密データを含むアプリケーション向けであり、保護を必要とし、ほとんどのアプリに推奨されるレベルです。
ASVS レベル 3 は極めて重要なアプリケーション向けであり、高額取引を行うアプリケーション、機密性の高い医療データを持つアプリケーション、最高レベルの信頼性を要求するアプリケーションなどを対象としています。
各 ASVS レベルはセキュリティ要件のリストを含みます。これらの各要件はセキュリティ固有の機能や開発者がソフトウェアに組み込む必要のある機能にもマップできます。
レベル 1 は人間によりすべてがペネトレーションテスト可能な唯一のレベルです。それ以外のものはすべてドキュメント、ソースコード、設定、開発プロセスに携わる人々へのアクセスを必要とします。但し、たとえレベル 1 が「ブラックボックス」 (ドキュメントなし、ソースなし) テストを行うことができたとしても、それは有効な保証活動ではなく積極的に阻止すべきです。悪意のある攻撃者にはかなりの時間があり、ほとんどのペネトレーションテストは数週間以内に終了します。防御する者はセキュリティ管理策を組み入れ、すべての弱点を保護、発見、解決し、悪意のある行為を行う者を妥当な時間内に検出および対応する必要があります。悪意のある行為を行う者は本質的に無限の時間があり、成功するためにはひとつの侵入しやすい防御、ひとつの弱点、または見逃した検出のみで足ります。ブラックボックステストは開発の最後に行われることが多く、あわただしく行われるか、全く行われず、このような不均衡に完全に対処することはできません。
過去 30 年以上にわたり、ブラックボックステストはさらに深刻な侵害に直接つながる重大なセキュリティ問題を見逃していることが何度も繰り返し証明されてきました。開発プロセス全体を通して開発者とドキュメントへのフルアクセスを伴い、レベル 1 でのペネトレーションテストをソースコード主導 (ハイブリッド) ペネトレーションテストに置き換えるなど、幅広いセキュリティ保証と検証の使用を強く推奨します。金融規制当局は財務記録、サンプル取引、管理を実行する人々にアクセスできない外部の財務監査を認めません。産業界および政府機関はソフトウェア工学の領域で同じ標準の透明性を要求しなければなりません。
開発プロセス自体の中でセキュリティツールを使用することを強く推奨します。DAST および SAST ツールをビルドパイプラインに継続的に導入すると、存在してはならない単純なセキュリティ問題を効果的に特定して対処できます。
自動ツールとオンラインスキャンは人間による支援なしでは ASVS の半分以上を完了することができません。ビルドごとに包括的なテスト自動化が必要な場合には、カスタムの単体テストと統合テストの組み合わせをビルド開始時のオンラインスキャンとともに使用します。ビジネスロジックの欠陥とアクセス制御のテストは人間による支援でのみ可能です。これらは単体テストと統合テストに変えるべきです。
この標準の使い方
アプリケーションセキュリティ検証標準を使用する最善の方法の一つは、アプリケーション、プラットフォーム、組織に固有のセキュアコーディングチェックリストを作成するための青写真として使用することです。ユースケースに合わせて ASVS を仕立て直すことで、プロジェクトや環境にとって最も重要なセキュリティ要件に焦点を当てるでしょう。
レベル 1 - ファーストステップ、自動化、ポートフォリオビュー全体
検出が容易で、OWASP Top 10 や他の同様のチェックリストに含まれているアプリケーションセキュリティ脆弱性に対して適切に防御されていれば、アプリケーションは ASVS レベル 1 を達成します。
レベル 1 はすべてのアプリケーションが目指すべき必要最低限のレベルです。複数フェーズの作業での最初のステップとして、またはアプリケーションが機密データを格納や処理しないためレベル 2 や 3 のより厳しい管理策を必要としない場合にも役立ちます。レベル 1 管理策はツールにより自動的にチェックすることも、ソースコードにアクセスすることなく手動でチェックすることもできます。私たちはレベル 1 をすべてのアプリケーションに最低限必要なものと考えています。
アプリケーションに対する脅威は、発見が容易で悪用が容易な脆弱性を特定するために簡単で手間のかからない技法を使用している攻撃者からのものがほとんどです。これはアプリケーションを明確にターゲットとすることに集中的にエネルギーを費やす、確固たる攻撃者とは対照的です。アプリケーションが高い価値を持つデータを処理する場合には、レベル 1 レビューで止めたくないでしょう。
レベル 2 - 大半のアプリケーション
今日のソフトウェアに関連するリスクのほとんどを適切に防御できれば、アプリケーションは ASVS レベル 2 (または Standard) を達成します。
レベル 2 ではセキュリティ管理策が適用され、効果的であり、アプリケーション内で使用されていることを確認します。ヘルスケア情報の処理、ビジネスに不可欠なまたは機密性の高い機能の実装、他の機密性の高い資産の処理などを含む、重要な企業間取引を処理するアプリケーションや、チートやゲームハックを阻止するゲーム業界などの、ビジネスを保護するために完全性が重要な要素となる業界に対して、通常、レベル 2 が適用されます。
レベル 2 アプリケーションの脅威は、通常、アプリケーション内の弱点を発見および悪用するために高度に実践され効果的なツールや技法を用いて特定のターゲットに集中する、熟練した動機のある攻撃者です。
レベル 3 - 高い価値、高い保証、高い安全性
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.2 での1.11.3は以下のとおりです。
認証、セッション管理、アクセス制御など、価値の高いビジネスロジックフローのすべてがスレッドセーフであり、time-of-check time-of-use 競合状態に耐えられる。
識別子は標準のバージョン間で変更となる可能性があるため、他のドキュメント、レポート、ツールでは v<version>-<chapter>.<section>.<requirement> という形式を使用することを推奨します。ここでは 'version' は ASVS バージョンタグです。例: v4.0.2-1.11.3 はバージョン 4.0.2 の 'アーキテクチャ' の章の 'ビジネスロジックアーキテクチャ要件' セクションの 3 番目にある要件を意味すると理解できます。 (これは v<version>-<requirement_identifier> と要約できます。)
注: この形式でバージョン番号の前にある v は常に小文字にする必要があります。
v<version> 要素を含めずに識別子を使用する場合には、最新のアプリケーションセキュリティ検証標準コンテンツを参照していると想定すべきです。標準の進化や変更に伴いこれが問題になるため、執筆者や開発者はバージョン要素を含める必要があります。
ASVS 要件リストは CSV, JSON, および参照またはプログラムでの使用に役立つ可能性があるその他の形式で提供されています。
ASVS のフォーク
多くの組織は ASVS を採用することでメリットがあります。三つのレベルのいずれかを選択するか、ASVS をフォークして各アプリケーションのリスクレベルに必要なものをドメイン固有の方法で変更します。トレーサビリティが維持されている限りこのタイプのフォークをお勧めします。アプリが要件 4.1.1 にパスする場合にはフォークされたコピーが本標準の進化したものとして同じことを意味するようにします。
理想的には、すべての組織が独自のフォークした ASVS を持ち、組織にあった要件を選択すべきです。したがって、もし組織が GraphQL, Websockets, もしくは SOAP Web サービスを使用しないのであれば、フォークした ASVS からこれらのセクションを削除すべきです。フォークプロセスではまず組織のベースラインとして ASVS レベル 1 要件を確認することから始めて、アプリケーションのリスクレベルに基づいて ASVS レベル 2 や 3 に段階的に移行していきます。
ASVS の用途
ASVS はアプリケーションのセキュリティを評価するために使用できます。これについては次の章で詳しく説明しますが、ASVS (もしくはフォーク版) のその他の潜在的な用途がいくつか考えられています。
詳細なセキュリティアーキテクチャガイダンスとして
アプリケーションセキュリティ検証標準のより一般的な用途の一つはセキュリティアーキテクトのためのリソースです。Sherwood Applied Business Security Architecture (SABSA) にはアプリケーションセキュリティアーキテクチャの十分なレビューを完了するために必要な多くの情報が欠けています。ASVS を使用して、セキュリティアーキテクトがデータ保護パターンや入力バリデーション戦略などの一般的な問題に対してより適切な管理策を選択できるようにすることで、これらのギャップを埋めることができます。
専用のセキュアコーディングチェックリストとして
ASVS はセキュアアプリケーション開発のためのセキュアコーディングチェックリストとして使用でき、開発者がソフトウェアを構築する際にセキュリティを考慮するよう支援します。セキュアコーディングチェックリストは統一され、明確で、すべての開発チームに適用可能であるべきです。理想的にはセキュリティエンジニアやセキュリティアーキテクトの指導に基づいて作成されるべきです。
自動ユニットテストおよび自動統合テストのガイドとして
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 と組み合わせると効果的です。
実際に ASVS を適用する
脅威が異なれば動機も異なります。一部の業界では独自の情報資産と技術資産があり、ドメイン固有の規制順守要件があります。
組織はそのビジネスの性質に基づく独自のリスク特性を詳細に検討し、そのリスクとビジネス要件に基づいて適切な ASVS レベルを決定することを強く推奨します。
コミュニティのさまざまなメンバーから、実際にどのように標準を導入しているかについてフィードバックを受け取りました。
個人的なケーススタディ
Matthew Hackling
ペンテストスコープとテストケースを駆動します。
デザインヘルプのためのセキュリティ要件を駆動します。
ISO27034 組織的規範フレームワーク (要件ライブラリ) を推進します。
Dominique Righetto
コードレビューや Web アプリケーションの脆弱性評価を行う際のチェックリストとして使用されます。
Giovanni Cruz
前回の OWASP Latam Tour Bogotá 2019 では、完全に ASVS に基づいたトレーニングコースが準備されました。すべてのコンテンツは開発者を支援するトレーニング用の脆弱なプラットフォームで作成されました。使い方や、ある基準に基づいて達成したいと思うセキュリティレベルを示したため、大きな反響がありました。
Sebastien Gioria
一部の顧客では、セキュアな設計とコーディングを実施するための必須要件の基礎として使用されています。
Riotaro Okada
近年、日本の一部の銀行ではセキュリティテストサービスの RFP に必須要件として ASVS を盛り込んでいるところが見受けられます。 ASVS レベルに適合するセキュリティベンダの提案を求めていました。
日本で SFA 関連パッケージを販売しているあるソフトウェアベンダは、自社の製品が ASVS に適合するかどうか、どのレベルに適合するかを顧客基準で確認していました。 (これをきっかけにベンダは自社のチームにセキュアな開発と検証を導入することになりました)
John Patrick Lita
これを使用し、 CI/CD アクティビティにこれを統合しています。
他のプロジェクトやツールでの使用
OWASP Defectdojo には ASVS サポートが組み込まれています https://www.defectdojo.org/
ASVS 4 のリリースから数週間後、 RIPS は ASVS のサポートを追加しました: https://blog.ripstech.com/2019/rips-3.1-adds-teamcity-ldap-jsp-support/
Last updated