req_id

ワーキング グループのフィードバック

8.1.6

この要件を、より実用的なもの（バックアップは X 期間のみ保持されるべきである、バックアップは盗難や破損についてモニタリングされるべきである、バックアップは本番環境に戻すことができることを確認するために定期的に監査されるべきであるなど）に再検討します。現在の前提条件は広すぎるため、より詳細な定義が必要です。

5.1.4

他のテストケースの重複。これは、労力が大きく価値の低いテストケースです。削除することをおすすめします。

7.3.3

他のテストケースの重複。これは、労力が大きく価値の低いテストケースです。削除することをおすすめします。

1.2.2

4.1.1 などの他の要件でカバーされているため削除

2.2.4

4.3.1 でカバーされているため、要件を削除

（4.3.1 管理インターフェースが適切な多要素認証を使用していることを確認します。

（不正使用を防ぐ）には、管理インターフェースやその他の内部アクセス パスでのフィッシングに対するなりすまし防止が含まれます。

2.2.5

ほとんどの CSP で mTLS がサポートされておらず、CASA のテストを実施するデベロッパーのほとんどがパスワード ベースの認証を使用するため、削除します。

2.4.3

この基準は、施行するには具体性が不足しています。

2.4.5

ASVS の V5 で要件が削除され、2.4.1 で推奨されているハッシュ化アルゴリズムはこの要件を満たせない

2.7.5

サードパーティの OOB プロバイダの分析が必要になる可能性があるため、テストは実行できません。認証コードの有効期間が短いため、リスクは低くなります。

2.8.2

この要件はカスタム MFA ソリューションにのみ関連し、6.4.2 と 6.4.1 でも規定されています。

2.8.5

2.7.6 でカバーされているため、要件を削除します。さらに、失敗した試行のロギングは ASVS のロギング要件でカバーされています。

2.8.6

アプリケーション レベルでの物理 OTP は一般的なユースケースではありませんが、管理インターフェースにはこの要件が必要です。ただし、要件 4.3.1（管理者インターフェースが適切な多要素認証を使用して不正使用を防止していることを確認する）は、管理者インターフェースの MFA を対象としており、このリスクをカバーします。

2.9.1

この要件は、ASVS に準拠した物理デバイスを対象としています（暗号セキュリティ キーはスマートカードまたは FIDO キーであり、ユーザーはデバイスに差し込むか、ペア設定する必要があります）。

認証を完了するために、暗号デバイスをパソコンに接続します。検証ツールは、チャレンジ ノンスを

暗号デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアが安全に

（保存された暗号鍵）。この要件は CASA の範囲外です。物理デバイスの認証リスクは、MFA（物理またはソフトウェア）の目的で 4.3.1 でカバーされています。

2.9.3

この要件は、ASVS に準拠した物理デバイスを対象としています（暗号セキュリティ キーはスマートカードまたは FIDO キーであり、ユーザーはデバイスに差し込むか、ペア設定する必要があります）。

認証を完了するために、暗号デバイスをパソコンに接続します。検証ツールは、チャレンジ ノンスを

暗号デバイスまたはソフトウェアに送信し、デバイスまたはソフトウェアが安全に

（保存された暗号鍵）。この要件は CASA の範囲外です。物理デバイスの認証リスクは、MFA（物理またはソフトウェア）の目的で 4.3.1 でカバーされています。

2.10.1

要件は 2.10.2 と矛盾している

2.10.3

2.4.1（アプリケーションのユーザー パスワードを保存する際に、argon2id、scrypt、bcrypt、PBKDF2 のいずれかのパスワード ハッシュ関数が使用されていることを確認する）でカバーされています。これは、オフライン攻撃とパスワード保存のリスクをカバーしています。

2.10.4

6.4.2 鍵マテリアルがアプリケーションに公開されず、代わりに暗号オペレーションに Vault などの分離されたセキュリティ モジュールを使用していることを確認するでカバーされています。

3.2.3

3.4.1、3.4.2、3.4.3 でカバー

3.5.1

ユーザーは OAuth プロバイダ経由でトークンを取り消すことができます

4.3.3

管理インターフェースと特権アクセスに対する MFA で要件が満たされている

5.1.3

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

5.1.4

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

5.3.2

この要件のすべての Unicode 文字が有効であることを指定する部分は、テストを難しくする可能性があります。すべての Unicode 文字を収容できるほど大きなテキスト フォームを含むアプリケーションは、必ずしも存在するとは限りません。また、特定のオペレーティング システムやハッキング ツールでは、Unicode 空間全体がサポートされていないため、サーバーがサポートしていてもテストできません。全体的にセキュリティ上の価値が疑わしい。もともとベータ版に含まれていましたが、テストで問題が発生したため削除されました。

6.2.5

6.2.4 および 6.2.3 でカバーされる

6.2.6

6.2.4 および 6.2.3 でカバーされる

6.3.1

6.2.4 および 6.2.3 でカバーされる

6.3.3

他の乱数生成要件でカバーされます。

7.1.2

7.1.1 で対応

7.1.3

7.1.1 で対応

7.3.1

7.1.1 で対応

7.3.3

7.1.1 で対応

8.1.3

許容されるパラメータや必要なパラメータを説明することは困難です。テスト可能なケースではありません。何が「必要」と見なされますか？例外が有効かどうかはどのように判断されますか？CASA の対象範囲外と見なされる

8.3.3

テスト可能な要件ではなく、プライバシー ポリシーと利用規約に関連するもので、アプリケーション セキュリティに関連するものではありません。これは法務とコンプライアンスの審査であり、CASA の範囲外です。

8.3.6

制御はシステム固有（Windows/Linux バリアント）かつデバイス固有であり、ほとんどの場合、アプリケーション制御ではありません。

8.3.8

1.8.1、1.8.2、1.1.4 でカバー

9.2.5

8.3.5 およびアプリケーションのロギング ポリシーの審査でカバーされます。

10.1.1

アーキテクチャ レビューの対象であり、推奨されるベスト プラクティスです。要件がテスト可能ではない

10.2.3

妥当な時間内に実行できない。奇妙なコードはすべて文書化してレビューする必要がありますが、バックドアが存在しないことを確認する特定のタスクを設定するには、コードを 1 行ずつ詳細にレビューする必要があり、バックドアが存在しないことを保証するものではありません。

悪意のある関数が適切に設計されているかどうかをテストするのが難しい

10.2.4

テストする方法がありません。妥当な時間内に実行できない。奇妙なコードはすべて文書化してレビューする必要がありますが、バックドアが存在しないことを確認する特定のタスクを設定するには、コードを 1 行ずつ詳細にレビューする必要があり、バックドアが存在しないことを保証するものではありません。

悪意のある関数が適切に設計されているかどうかをテストするのが難しい

10.2.5

テストする方法がありません。妥当な時間内に実行できない。奇妙なコードはすべて文書化してレビューする必要がありますが、バックドアが存在しないことを確認する特定のタスクを設定するには、コードを 1 行ずつ詳細にレビューする必要があり、バックドアが存在しないことを保証するものではありません。

悪意のある関数が適切に設計されているかどうかをテストするのが難しい

13.1.1

5.2.6 と 5.3.9 でカバー

12.3.1

ASVS と CASA の第 5 章（検証、サニタイズ、エンコード）の既存の要件でカバーされているパス トラバーサルのリスク

12.3.3

5.2.6 と 5.3.9 でカバー

12.3.6

10.3.2、12.4.1、12.4.2 でカバー

12.5.1

10.3.2 と 12.4.2 でカバー

12.5.2

10.3.2、12.4.1、12.4.2 でカバー

13.1.5

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

13.2.2

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

13.2.3

4.2.2 でカバー

13.2.5

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

13.3.1

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

14.4.1

5.3.1 でカバーされる

14.4.2

この要件は他の入力検証要件でカバーされています。検証の欠如によって実際のビジネス ロジックの脆弱性が生じない場合は、重大度を下げることができます。たとえば、電話番号の検証が適切に行われていない場合、情報ページで電話番号が正しく表示されないだけで、セキュリティに直接的な影響はありません。

14.4.3

5.2.7 および 5.3.3 でカバー

14.4.5

6.2.1 および 9.2.1 でカバー

14.4.7

12.4.1 でカバー

14.5.3

14.5.2 でカバーされる

2.1.5

2.1.1 でカバーされる

2.1.6

2.1.1 でカバーされる

2.2.3

リスクは他の自動化防止コントロールでカバーされているため、casa には関連しません。

2.5.6

他のパスワード保護の対象

3.1.1

露出のリスクが低く、ASVS の他のコントロールでカバーされている

3.2.1

露出のリスクが低く、ASVS の他のコントロールでカバーされている

3.4.4

露出のリスクが低く、ASVS の他のコントロールでカバーされている

3.4.5

露出のリスクが低く、ASVS の他のコントロールでカバーされている

4.2.1

13.1.4 に該当します

5.2.8

他の入力検証とサニタイズ チェックでカバーされている

5.3.5

他の入力検証とサニタイズ チェックでカバーされている

7.4.1

ロギング チェックの対象

8.2.3

8.1.1 でカバーされる

9.1.1

6.2.1 および 9.2.1 でカバー

1.2.3

1.1.4、1.8.4、1.8.2 でカバー

1.4.4

1.1.4、1.8.4、1.8.2 でカバー

1.5.2

1.1.4、1.8.4、1.8.2 でカバー

1.5.3

1.1.4、1.8.4、1.8.2 でカバー

1.5.4

1.1.4、1.8.4、1.8.2 でカバー

1.9.1

1.1.4、1.8.4、1.8.2 でカバー

1.11.3

1.1.4、1.8.4、1.8.2 でカバー

1.14.1

1.1.4、1.8.4、1.8.2 でカバー

1.14.2

1.1.4、1.8.4、1.8.2 でカバー

1.14.3

1.1.4、1.8.4、1.8.2 でカバー

1.14.4

1.1.4、1.8.4、1.8.2 でカバー

1.14.5

1.1.4、1.8.4、1.8.2 でカバー

1.14.6

1.1.4、1.8.4、1.8.2 でカバー

6.1.2

6.1.1 でカバー

6.1.3

6.1.1 でカバー

2.10.2

2.5.4 でカバー

2.2.1

11.1.4 でカバー

2.7.3

2.7.2 で対応

2.7.4

2.7.2 で対応

5.1.2

自動化防止制御の対象

6.2.2

承認済みの暗号アルゴリズムが定義されていない

8.2.1

8.1.1 の対象

9.1.2

9.2.1 でカバー

9.1.3

9.2.1 でカバー

5.5.1

1.8.2 で対応済み

14.2.1

1.14.6 で対応

3.3.4

ステートレス AuthN/Z を使用するアプリケーションには当てはまりません。削除するという NCC Group の推奨事項に同意します。これは 3.3.3 でカバーされるはずです。

req_id

説明

1.1.4

アプリケーションの信頼境界、コンポーネント、重要なデータフローのすべてのドキュメントと正当性を確認します。

1.8.1

すべての機密データが特定され、保護レベルに分類されていることを確認します。

1.8.2

すべての保護レベルに、暗号化要件、完全性要件、保持、プライバシー、その他の機密性要件などの保護要件の関連セットがあり、これらが

アーキテクチャに適用されます。

2.1.1

ユーザーが設定したパスワードが 12 文字以上であることを確認する

2.5.4

共有アカウントまたはデフォルト アカウントが存在しないことを確認します（例: 「root」）。

「admin」、「sa」など）。

4.2.1

機密データと API が、レコードの作成、読み取り、更新、削除を対象とする安全でない直接オブジェクト参照（IDOR）攻撃から保護されていることを確認します。たとえば、他人のレコードの作成や更新、すべてのレコードの表示、すべてのレコードの削除などです。

1.14.6

アプリケーションがサポートされていない、安全でない、または非推奨の

NSAPI プラグイン、Flash、Shockwave、ActiveX などのクライアントサイド技術、

Silverlight、NACL、クライアントサイドの Java アプレット。