ID_permintaan

Masukan Grup Kerja

8.1.6

Akan menganggap kembali Persyaratan ini sebagai sesuatu yang lebih dapat ditindaklanjuti (misalnya, Cadangan hanya boleh dipertahankan selama X waktu, Cadangan harus dipantau untuk pencurian/korupsi, Cadangan harus diaudit secara berkala untuk mengonfirmasi kemampuannya untuk dipindahkan kembali ke produksi). Asumsi saat ini terlalu luas dan memerlukan definisi lebih lanjut.

5.1.4

Duplikasi kasus pengujian lainnya. Ini adalah kasus pengujian bernilai rendah dengan upaya tinggi. Direkomendasikan untuk menghapus.

7.3.3

Duplikasi kasus pengujian lainnya. Ini adalah kasus pengujian bernilai rendah dengan upaya tinggi. Direkomendasikan untuk menghapus.

1.2.2

hapus karena cakupan dalam persyaratan lain seperti 4.1.1

2.2.4

Hapus Permintaan karena dicakup oleh 4.3.1

(4.3.1 Memverifikasi antarmuka administratif menggunakan autentikasi multi-faktor yang sesuai untuk

mencegah penggunaan yang tidak sah.) yang mencakup ketahanan terhadap peniruan identitas terhadap phishing di antarmuka admin dan jalur akses internal lainnya

2.2.5

Hapus karena mTLS tidak didukung oleh sebagian besar CSP, juga sebagian besar developer yang diuji untuk CASA akan menggunakan autentikasi berbasis sandi

2.4.3

Standar yang tertulis tidak cukup spesifik untuk dapat diterapkan

2.4.5

Persyaratan yang dihapus di V5 ASVS dan algoritme hashing yang direkomendasikan di versi 2.4.1 tidak dapat memenuhi persyaratan ini

2,7.5

Pengujian tidak memungkinkan karena mungkin memerlukan analisis penyedia OOB pihak ketiga, risikonya di sini rendah karena kode autentikasi hanya berumur pendek.

2.8.2

Persyaratan ini hanya relevan untuk solusi MFA kustom, yang juga dicakup oleh 6.4.2 dan 6.4.1

2.8.5

Menghapus persyaratan karena dicakup oleh 2.7.6. Selain itu, logging upaya yang gagal dicakup oleh persyaratan logging ASVS

2.8.6

OTP fisik pada tingkat aplikasi bukanlah kasus penggunaan umum, persyaratan ini diperlukan untuk antarmuka admin. Namun, persyaratan 4.3.1 (Verifikasi antarmuka administratif menggunakan autentikasi multi-faktor yang sesuai untuk mencegah penggunaan yang tidak sah.) mencakup MFA untuk antarmuka admin dan akan mencakup risiko ini

2.9.1

Persyaratan ini mencakup perangkat fisik sesuai dengan ASVS (Kunci keamanan kriptografi adalah kartu smart atau kunci FIDO, yang mengharuskan pengguna mencolokkan atau menyambungkan

perangkat kriptografis ke komputer untuk menyelesaikan autentikasi. Pemverifikasi mengirimkan nonce tantangan ke

perangkat atau software kriptografi, dan perangkat atau software menghitung respons berdasarkan

kunci kriptografis yang disimpan). membuat persyaratan ini di luar cakupan CASA karena risiko autentikasi perangkat fisik tercakup dalam 4.3.1 untuk tujuan MFA (Physical atau software)

2.9.3

Persyaratan ini mencakup perangkat fisik sesuai dengan ASVS (Kunci keamanan kriptografi adalah kartu smart atau kunci FIDO, yang mengharuskan pengguna mencolokkan atau menyambungkan

perangkat kriptografis ke komputer untuk menyelesaikan autentikasi. Pemverifikasi mengirimkan nonce tantangan ke

perangkat atau software kriptografi, dan perangkat atau software menghitung respons berdasarkan

kunci kriptografis yang disimpan). membuat persyaratan ini di luar cakupan CASA karena risiko autentikasi perangkat fisik tercakup dalam 4.3.1 untuk tujuan MFA (Physical atau software)

2.10.1

Persyaratannya adalah kontradiksi terhadap 2.10.2

2.10.3

Dicakup oleh 2.4.1 (Verifikasi bahwa salah satu fungsi hashing sandi berikut digunakan saat menyimpan sandi pengguna untuk aplikasi: argon2id, scrypt, bcrypt, atau PBKDF2) yang mencakup risiko serangan offline dan penyimpanan sandi.

2.10.4

Dicakup oleh 6.4.2, pastikan bahwa materi kunci tidak diekspos ke aplikasi, tetapi menggunakan modul keamanan terisolasi seperti vault untuk operasi kriptografi.

3.2.3

Dicakup oleh 3.4.1, 3.4.2, dan 3.4.3

3.5.1

Pengguna dapat mencabut token melalui penyedia OAuth

4.3.3

Permintaan dicakup oleh MFA untuk antarmuka admin dan akses istimewa

5.1.3

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

5.1.4

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

5.3.2

Bagian dari persyaratan ini yang menentukan setiap karakter unicode yang valid dapat membuatnya sulit untuk diuji. Tidak semua aplikasi akan menyertakan bentuk teks yang cukup besar untuk menampung setiap karakter unicode. Ada juga kurangnya dukungan untuk sistem operasi dan alat peretasan tertentu untuk seluruh ruang unicode yang membuat Anda tidak dapat mengujinya meskipun server mendukungnya. Nilai keamanan yang diragukan secara keseluruhan. Awalnya disertakan dalam versi beta, tetapi telah dihapus karena masalah saat pengujian.

6.2.5

dicakup oleh 6.2.4 dan 6.2.3

6.2.6

dicakup oleh 6.2.4 dan 6.2.3

6.3.1

dicakup oleh 6.2.4 dan 6.2.3

6.3.3

dicakup oleh persyaratan pembuatan nomor acak lainnya.

7.1.2

dicakup oleh 7.1.1

7.1.3

dicakup oleh 7.1.1

7.3.1

dicakup oleh 7.1.1

7.3.3

dicakup oleh 7.1.1

8.1.3

Sulit untuk menjelaskan parameter mana yang dapat diterima atau diperlukan. Bukan kasus yang dapat diuji. Apa yang dimaksud dengan hal yang diperlukan? Bagaimana cara kami menentukan apakah sebuah pengecualian valid? Dianggap di luar cakupan CASA

8.3.3

Bukan persyaratan yang dapat diuji, yang relevan dengan kebijakan privasi serta persyaratan layanan, bukan keamanan aplikasi. Peninjauan ini bersifat hukum dan kepatuhan serta berada di luar cakupan CASA

8.3.6

Kontrol bersifat khusus sistem (varian Windows/Linux) dan khusus perangkat, dan dalam kebanyakan kasus bukan kontrol aplikasi.

8.3.8

dicakup oleh 1.8.1, 1.8.2, dan 1.1.4

9,2.5

tercakup dalam 8.3.5 dan pemeriksaan kebijakan logging aplikasi.

10,1.1

Dicakup oleh tinjauan arsitektur dan merupakan praktik terbaik yang direkomendasikan. Persyaratan tidak dapat diuji

10.2.3

Tidak dapat dilakukan dalam jangka waktu yang wajar. Setiap kode yang aneh harus didokumentasikan dan ditinjau, tetapi menetapkan tugas tertentu untuk memastikan bahwa pintu belakang tidak ada akan memerlukan peninjauan kode baris demi baris yang mendalam dan tidak menjamin bahwa pintu belakang tidak ada.

Sulit untuk menguji fungsi berbahaya yang dirancang dengan baik

10.2.4

Tidak ada cara yang memungkinkan untuk melakukan pengujian. Tidak dapat dilakukan dalam jangka waktu yang wajar. Kode unik apa pun harus didokumentasikan dan ditinjau, tetapi menetapkan tugas tertentu untuk memastikan bahwa pintu belakang tidak ada akan memerlukan peninjauan kode baris demi baris yang mendalam dan tidak menjamin bahwa pintu belakang tidak ada.

Sulit untuk menguji fungsi berbahaya yang dirancang dengan baik

10.2.5

Tidak ada cara yang memungkinkan untuk melakukan pengujian. Tidak dapat dilakukan dalam jangka waktu yang wajar. Kode unik apa pun harus didokumentasikan dan ditinjau, tetapi menetapkan tugas tertentu untuk memastikan bahwa pintu belakang tidak ada akan memerlukan peninjauan kode baris demi baris yang mendalam dan tidak menjamin bahwa pintu belakang tidak ada.

Sulit untuk menguji fungsi berbahaya yang dirancang dengan baik

13.1.1

Dicakup oleh 5.2.6 dan 5.3.9

12.3.1

risiko traversal jalur yang dicakup oleh persyaratan lain yang ada dari Bab 5 (Validasi, Sanitasi, dan Encoding) ASVS dan CASA

12.3.3

Dicakup oleh 5.2.6 dan 5.3.9

12.3.6

tercakup dalam 10.3.2 12.4.1 dan 12.4.2

12.5.1

tercakup dalam 10.3.2 dan 12.4.2

12.5.2

tercakup dalam 10.3.2 12.4.1 dan 12.4.2

13.1.5

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

13.2.2

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

13.2.3

Dicakup oleh 4.2.2

13.2.5

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

13.3.1

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

14.4.1

dicakup oleh 5.3.1

14.4.2

Persyaratan ini dicakup oleh persyaratan validasi input lainnya dan jika kurangnya validasi tidak menyebabkan kerentanan logika bisnis yang sebenarnya, maka tingkat keparahan ini lebih rendah. Misalnya, tidak memvalidasi nomor telepon dengan benar hanya akan menyebabkan tampilan nomor telepon yang tidak tepat di halaman info, yang tidak memiliki implikasi keamanan langsung.

14.4.3

dicakup oleh 5.2.7 dan 5.3.3

14.4.5

dicakup oleh 6.2.1 dan 9.2.1

14.4.7

dicakup oleh 12.4.1

14.5.3

dicakup oleh 14.5.2

2.1.5

dicakup oleh 2.1.1

2.1.6

dicakup oleh 2.1.1

2.2.3

Tidak relevan dengan casa karena risiko tercakup dalam kontrol anti-otomatisasi lainnya

2.5.6

dilindungi oleh perlindungan sandi lainnya

3.1.1

Risiko rendah terpapar dan tercakup oleh kontrol ASVS lainnya

3.2.1

Risiko rendah terpapar dan tercakup oleh kontrol ASVS lainnya

3.4.4

Risiko rendah terpapar dan tercakup oleh kontrol ASVS lainnya

3.4.5

Risiko rendah terpapar dan tercakup oleh kontrol ASVS lainnya

4.2.1

dicakup oleh 13.1.4

5.2.8

dicakup oleh pemeriksaan validasi dan sanitasi input lainnya

5.3.5

dicakup oleh pemeriksaan validasi dan sanitasi input lainnya

7.4.1

tercakup dalam pemeriksaan logging

8.2.3

dicakup oleh 8.1.1

9.1.1

dicakup oleh 6.2.1 dan 9.2.1

1.2.3

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1,4.4

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1,5.2

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1,5.3

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1,5.4

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.9.1

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.11.3

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.14.1

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.14.2

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.14.3

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.14.4

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1,14,5

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

1.14.6

dicakup oleh 1.1.4, 1.8.4 dan 1.8.2

6.1.2

Dicakup oleh 6.1.1

6.1.3

Dicakup oleh 6.1.1

2.10.2

Dicakup oleh 2.5.4

2.2.1

Dicakup oleh 11.1.4

2.7.3

Dicakup oleh 2.7.2

2.7.4

Dicakup oleh 2.7.2

5.1.2

Dicakup oleh Kontrol Anti Otomatisasi

6.2.2

algoritme kriptografi yang disetujui tidak ditentukan

8.2.1

Dicakup oleh 8.1.1

9.1.2

Dicakup oleh 9.2.1

9.1.3

Dicakup oleh 9.2.1

5.5.1

Dicakup oleh 1.8.2

14.2.1

Dicakup oleh 1.14.6

3.3.4

Hal ini tidak berlaku untuk aplikasi yang menggunakan AuthN/Z stateless. Setuju dengan rekomendasi NCC Group untuk menghapus. Ini harus dibahas dalam 3.3.3

ID_permintaan

Deskripsi

1.1.4

Verifikasikan dokumentasi dan justifikasi dari semua batas kepercayaan, komponen, dan aliran data aplikasi yang signifikan.

1,8.1

Verifikasi bahwa semua data sensitif diidentifikasi dan diklasifikasikan ke dalam tingkat perlindungan

1,8.2

Verifikasi bahwa semua tingkat perlindungan memiliki serangkaian persyaratan perlindungan terkait, seperti persyaratan enkripsi, persyaratan integritas, retensi, privasi, dan persyaratan kerahasiaan lainnya, dan bahwa persyaratan ini merupakan

diterapkan dalam arsitektur.

2.1.1

Pastikan panjang sandi yang ditetapkan pengguna minimal 12 karakter

2.5.4

Pastikan akun bersama atau default tidak ada (misalnya, "root",

"admin", atau "sa").

4.2.1

Verifikasi bahwa data sensitif dan API dilindungi dari serangan Insecure Direct Object Reference (IDOR) yang menargetkan pembuatan, pembacaan, pembaruan, dan penghapusan catatan, seperti membuat atau memperbarui catatan orang lain, melihat catatan semua orang, atau menghapus semua catatan.

1.14.6

Pastikan aplikasi tidak menggunakan yang tidak didukung, tidak aman, atau tidak digunakan lagi

teknologi sisi klien seperti plugin NSAPI, Flash, Shockwave, ActiveX,

Silverlet, NACL, atau applet Java sisi klien.