v4.x と比較した変更点

はじめに

バージョン 4.x の標準に慣れ親しんだユーザは、コンテンツ、スコープ、基本理念の更新など、バージョン 5.0 で導入された主な変更点を確認することが役立つかもしれません。

バージョン 4.0.3 の 286 の要件のうち、変更されていないのは 11 件のみであり、15 件はその意味を変えずに文法上の軽微な調整を行いました。計 109 件 (38%) の要件がバージョン 5.0 では独立した要件ではなくなりました。そのうち 50 件は単純に削除され、28 件は重複として削除され、31 件は他の要件に統合されました。残りは何らかの形で改訂されています。実質的に変更されていない要件であっても、順序変更や構造変更により識別子が異なります。

バージョン 5.0 の採用を促進するために、バージョン 4.x の要件がバージョン 5.0 の要件とどのように対応しているかをユーザが追跡できるように、マッピングドキュメントが提供されています。これらのマッピングはリリースのバージョン管理に縛られるものではなく、必要に応じて更新または明確化される可能性があります。

要件の理念

スコープとフォーカス

バージョン 4.x では標準の意図するスコープに合致しない要件を含みましたが、これらは削除されました。また、5.0 のスコープ基準を満たしていない要件や検証不可能な要件も除外されました。

メカニズムよりもセキュリティ目標を重視

バージョン 4.x では、多くの要件が基盤となるセキュリティ目標ではなく、特定のメカニズムに重点を置いていました。バージョン 5.0 では、セキュリティ目標を中心に据えて、特定のメカニズムについてはそれが唯一の現実的な解決策である場合にのみ言及するか、例や補足的なガイダンスとして提供します。

このアプローチは、特定のセキュリティ目標を達成するために複数の方法が存在しうることを認識し、組織の柔軟性を制限しかねない不必要な規範性を回避するものです。

さらに、同じセキュリティ上の懸念に対処する要件は、必要に応じて統合されています。

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

セキュリティ上の決定事項の文書化という概念はバージョン 5.0 での新たなもののように見えるかもしれませんが、これは以前のバージョン 4.0 におけるポリシー適用と脅威モデリングに関する要件の進化形です。以前は、許可されるネットワーク接続の決定など、セキュリティコントロールの実装に必要な分析を暗黙的に要求する要件もありました。

実装と検証に必要な情報が利用できるようにするため、これらの期待事項はドキュメント要件として明示的に定義され、明確で実行可能かつ検証可能になりました。

構造変更と新章

バージョン 5.0 では、いくつかの章に全く新しいコンテンツを導入しています。

• OAuth と OIDC – アクセス委譲やシングルサインオンのためにこれらのプロトコルが広く採用されていることから、開発者が遭遇する可能性のある多様なシナリオに対応するために専用の要件が追加されました。この分野は以前のバージョンにおけるモバイルおよび IoT の要件の扱いと同様に、最終的には独立した標準へと進化する可能性があります。

• WebRTC – このテクノロジが普及するにつれて、その固有のセキュリティ上の考慮事項と課題は専用のセクションで取り上げるようにしました。

また、各章と各セクションは、関連する要件の一貫したセットとして構成されるように、努力してきました。

この構造変更により、追加の章が設けられました。

• 自己完結型トークン – 以前はセッション管理に分類されていた自己完結型トークンは、現在では独立したメカニズムとして認識され、ステートレス通信 (OAuth や OIDC など) の基盤要素となっています。その固有のセキュリティ上の意味合いから、バージョン 5.x で導入されたいくつかの新しい要件とともに、専用の章で扱われます。

• Web フロントエンドセキュリティ – ブラウザベースのアプリケーションの複雑さが増したことと、API のみのアーキテクチャの台頭により、フロントエンドのセキュリティ要件は専用の章に分割されました。

• セキュアコーディングとアーキテクチャ – 既存の章に収まらない一般的なセキュリティプラクティスに対処する新しい要件がここにまとめられています。

バージョン 5.0 では意図を明確にするためにその他の構成変更も行われました。たとえば、入力バリデーション要件は、サニタイゼーションやエンコーディングと一緒に分類されるのではなく、ビジネスルールを強制する役割を反映して、ビジネスロジックと一緒とするように移動されました。

以前の V1 アーキテクチャの章は削除されました。その最初のセクションにはスコープ外の要件を含みましたが、後続のセクションは関連する章に再配置され、必要に応じて重複を排除し、明確化しました。

他の標準への直接マッピングの削除

他の標準への直接マッピングは、この標準の本体から削除されました。その目的は OWASP Common Requirement Enumeration (CRE) プロジェクトでマッピングを準備することであり、ASVS をさまざまな OWASP プロジェクトや外部標準とリンクします。

以下で説明するように、CWE と NIST への直接マッピングは維持されなくなりました。

NIST Digital Identity Guidelines との結びつきの低減

NIST Digital Identity Guidelines (SP 800-63) は長年にわたり認証と認可コントロールのリファレンスとして使用されてきました。バージョン 4.x では、一部の章が NIST の構成と用語に密接に整合していました。

これらのガイドラインが重要なリファレンスであることに変わりはありませんが、厳密な整合はあまり広く認識されていない用語、類似した要件の重複、不完全なマッピングなどの課題をもたらしました。バージョン 5.0 ではこのアプローチから脱却し、明確性と関連性を向上します。

共通脆弱性タイプ一覧 (Common Weakness Enumeration, CWE) からの脱却

Common Weakness Enumeration (CWE) はソフトウェアのセキュリティ脆弱性の有用な分類法を提供します。しかし、カテゴリのみの CWE、要件を単一の CWE にマッピングすることの難しさ、バージョン 4.x での不正確なマッピングの存在などの課題から、バージョン 5.0 では CWE への直接マッピングを廃止することを決定しました。

レベル定義の再考

バージョン 4.x では、レベルを L1 (「最小 (Minimum)」)、L2 (「標準 (Standard)」)、L3 (「上級 (Advanced)」) と定義し、機密データを扱うすべてのアプリケーションは少なくとも L2 を満たす必要があると示唆していました。

バージョン 5.0 では、このアプローチにおけるいくつかの問題に対処しています。以下で説明します。

実際問題として、バージョン 4.x ではレベル指標にチェックマークを使用していましたが、5.x ではマークダウン、PDF、DOCX、CSV、JSON、XML を含む標準のすべての形式で単純な数字を使用しています。後方互換性のため、引き続きチェックマークを使用する CSV、JSON、XML 出力のレガシーバージョンも生成しています。

より容易なエントリレベル

フィードバックによると、レベル 1 の要件数の多さ (約 120) に加え、ほとんどのアプリケーションには不十分な「最小 (Minimum)」レベルという指定が、採用を阻害していることが示されました。バージョン 5.0 では、レベル 1 を主に第一層の防御要件を中心に定義することで、この障壁を低くし、このレベルの要件をより明確で少なくすることを目指しています。これを数値で表すと、v4.0.3 では、計 278 件の要件のうち L1 要件は 128 件あり、46% を占めていました。5.0.0 では、計 345 件の要件のうち L1 要件は 70 件あり、20% を占めています。

試験性の誤り

バージョン 4.x でレベル 1 のコントロールを選定する際の重要な要素は、「ブラックボックス」外部ペネトレーションテストによる評価に適しているかどうかでした。しかし、このアプローチはセキュリティコントロールの最小セットとしてのレベル 1 の意図と完全には合致していませんでした。レベル 1 はアプリケーションを保護するには不十分であると主張するユーザもいれば、テストが難しすぎるというユーザもいました。

試験性を基準として頼ることは、相対的であり、時には誤解を招きます。要件がテスト可能であるという事実は、それが自動化された方法や簡単な方法でテストできることを保証するものではありません。さらに、最も簡単にテスト可能な要件が、必ずしもセキュリティへの影響が最も大きい要件や実装が最も簡単な要件とは限りません。

そのため、バージョン 5.0 では、レベルの決定は主にリスクの軽減に基づいて行われ、実装の労力も考慮しました。

リスクだけではない

特定のアプリケーションに対して特定のレベルを義務付ける、規範的なリスクベースのレベルの使用は、過度に厳格であることが判明しています。実際には、セキュリティコントロールの優先順位付けと実装は、リスク軽減と実装に必要な労力など、複数の要因に依存します。

したがって、組織はその成熟度とユーザに送りたいメッセージに基づいて、達成すべきと思われるレベルを達成することが推奨されます。