req_id

作業グループに関するフィードバック

8.1.6

この要件は、より実用的なものに見直します（たとえば、バックアップの保持期間は X 回にするべきです。バックアップは盗難/破損がないかモニタリングする必要があります）。バックアップは、監査して本番環境に戻すことができるか定期的に確認する必要があります。現在の前提条件は広すぎて、さらに定義が必要です。

5.1.4

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

7.3.3

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

1.2.2

他の要件（4.1.1 など）に該当しているため削除

2.2.4

4.3.1 の対象となる Req を削除する

（4.3.1 管理インターフェースが適切な多要素認証を使用して

不正使用を防止します）。

2.2.5

mTLS はほとんどの CSP でサポートされていないため、削除します。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 は一般的なユースケースではありません。このインターフェースは、管理インターフェースに必要です。ただし、req 4.3.1（管理インターフェースが不正使用を防ぐために適切な多要素認証を使用していることを確認する）は、管理インターフェースの MFA をカバーし、このリスクをカバーします

2.9.1

この要件は、ASVS に基づく実機（暗号セキュリティ キーはスマートカードまたは FIDO キー）に対応し、ユーザーはスマートプラグまたは

認証を完了するためにコンピュータに必要です。検証者がチャレンジノンスを

暗号デバイスまたはソフトウェアには暗号化されず、デバイスやソフトウェアは安全に、

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

2.9.3

この要件は、ASVS に基づく実機（暗号セキュリティ キーはスマートカードまたは FIDO キー）に対応し、ユーザーはスマートプラグまたは

認証を完了するためにコンピュータに必要です。検証者がチャレンジノンスを

暗号デバイスまたはソフトウェアには暗号化されず、デバイスやソフトウェアは安全に、

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

2.10.1

要件は 2.10.2 と矛盾する

2.10.3

2.4.1 で規定されている（ユーザーのパスワードを保存する際にパスワード ハッシュ関数（argon2id、scrypt、bcrypt、または PBKDF2）のいずれかが使用されていることを確認します）。

2.10.4

6.4.2 でカバー

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 と、アプリケーションのポリシー ポリシー レビューの対象です。

2011 年 10 月 1 日

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

10.2.3

妥当な時間内はできない。奇妙なコードはドキュメントとレビューする必要がありますが、バックドアが存在しないように特定のタスクを設定すると、行ごとのコードレビューが必要になります。バックドアが存在しないことを保証するものではありません。

適切に設計された悪意のある関数のテストが困難

2022 年 10 月 2 日

テストする方法はない妥当な時間内は不可能です。奇妙なコードはドキュメント化してレビューする必要がありますが、バックドアが存在しないように特定のタスクを設定すると、行ごとのコードレビューを行う必要があります。また、バックドアが存在しないことが保証されません。

適切に設計された悪意のある関数のテストが困難

2012 年 10 月 2 日

テストする方法はない妥当な時間内は不可能です。奇妙なコードはドキュメント化してレビューする必要がありますが、バックドアが存在しないように特定のタスクを設定すると、行ごとのコードレビューを行う必要があります。また、バックドアが存在しないことが保証されません。

適切に設計された悪意のある関数のテストが困難

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

これは、ステートレスな認証/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 アプレットです。