req_id

بازخورد گروه کاری

8.1.6

آیا این الزام را به عنوان چیزی عملی تر در نظر می گیریم (مثلاً نسخه های پشتیبان باید فقط برای مدت X نگهداری شوند، پشتیبان ها باید از نظر سرقت/فساد نظارت شوند، نسخه های پشتیبان باید به طور منظم ممیزی شوند تا توانایی آنها برای بازگرداندن به تولید تأیید شود). فرض فعلی بسیار گسترده است و نیاز به تعریف بیشتری دارد.

5.1.4

کپی از سایر موارد تست. این یک مورد آزمایشی با ارزش کم با تلاش زیاد است. توصیه می شود حذف شود.

7.3.3

کپی از سایر موارد تست. این یک مورد آزمایشی با ارزش کم با تلاش زیاد است. توصیه می شود حذف شود.

1.2.2

حذف به دلیل پوشش در شرایط دیگر مانند 4.1.1

2.2.4

Req را همانطور که در 4.3.1 پوشش داده شده است حذف کنید

(4.3.1 بررسی کنید که رابط های اداری از احراز هویت چند عاملی مناسب استفاده کنند

جلوگیری از استفاده غیرمجاز.) که مقاومت جعل هویت در برابر فیشینگ در رابط های مدیریت و سایر مسیرهای دسترسی داخلی را پوشش می دهد.

2.2.5

حذف از آنجایی که mTLS توسط اکثر CSP ها پشتیبانی نمی شود، همچنین اکثر توسعه دهندگان آزمایش شده برای CASA از احراز هویت مبتنی بر رمز عبور استفاده می کنند.

2.4.3

استانداردی که نوشته شده به اندازه کافی مشخص نیست که قابل اجرا باشد

2.4.5

نیاز حذف شده در V5 ASVS و الگوریتم های هش توصیه شده در 2.4.1 نمی تواند این نیاز را برآورده کند.

2.7.5

آزمایش غیرممکن است زیرا ممکن است نیاز به تجزیه و تحلیل ارائه دهندگان OOB شخص ثالث داشته باشد، خطر در اینجا کم است زیرا کد احراز هویت کوتاه مدت است.

2.8.2

الزامات فقط مربوط به راه حل های سفارشی MFA است که توسط 6.4.2 و 6.4.1 نیز پوشش داده شده است.

2.8.5

نیاز را حذف کنید زیرا توسط 2.7.6 پوشش داده شده است.

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 بررسی کنید که مواد کلیدی در معرض برنامه کاربردی قرار نگرفته باشد، اما در عوض از یک ماژول امنیتی ایزوله مانند یک طاق برای عملیات رمزنگاری استفاده می کند.

3.2.3

تحت پوشش 3.4.1، 3.4.2 و 3.4.3

3.5.1

کاربر می تواند توکن ها را از طریق ارائه دهنده OAuth باطل کند

4.3.3

Req برای رابط های مدیریت و دسترسی ممتاز توسط MFA پوشش داده شده است

5.1.3

این درخواست توسط سایر الزامات اعتبار سنجی ورودی پوشش داده می شود و اگر عدم اعتبار سنجی آسیب پذیری منطقی تجاری واقعی را معرفی نکند، آنگاه می تواند شدت کمتری داشته باشد. به عنوان مثال، اعتبارسنجی نکردن شماره تلفن به درستی منجر به نمایش نامناسب شماره تلفن در صفحه اطلاعات می شود، که پیامدهای امنیتی مستقیمی ندارد.

5.1.4

این درخواست توسط سایر الزامات اعتبار سنجی ورودی پوشش داده می شود و اگر عدم اعتبار سنجی آسیب پذیری منطقی تجاری واقعی را معرفی نکند، آنگاه می تواند شدت کمتری داشته باشد. به عنوان مثال، اعتبارسنجی نکردن شماره تلفن به درستی منجر به نمایش نامناسب شماره تلفن در صفحه اطلاعات می شود، که پیامدهای امنیتی مستقیمی ندارد.

5.3.2

بخشی از این شرط که مشخص می کند هر کاراکتر یونیکد معتبر است، می تواند آزمایش آن را چالش برانگیز کند. هر برنامه ای شامل یک فرم متنی به اندازه کافی بزرگ نیست که هر کاراکتر یونیکد را در آن قرار دهد. همچنین عدم پشتیبانی از سیستم عامل های خاص و ابزارهای هک برای کل فضای یونیکد وجود دارد که باعث می شود حتی اگر سرور از آن پشتیبانی کند، نتوانید آن را آزمایش کنید. ارزش امنیتی مشکوک به طور کلی. در ابتدا در نسخه بتا قرار گرفت اما به دلیل مشکلاتی در آزمایش حذف شد.

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

کنترل مختص سیستم (نوع ویندوز/لینوکس) و دستگاه خاص است و در بیشتر موارد کنترل برنامه نیست.

8.3.8

تحت پوشش 1.8.1، 1.8.2، و 1.1.4

9.2.5

تحت پوشش 8.3.5 و بررسی سیاست های ورود به سیستم از برنامه.

10.1.1

تحت بررسی معماری قرار گرفته و بهترین روش توصیه شده است. نیاز قابل آزمایش نیست

10.2.3

انجام در مدت زمان معقول امکان پذیر نیست. هر کد عجیب و غریب باید مستند و بررسی شود، با این حال تنظیم یک وظیفه خاص برای اطمینان از عدم وجود درهای پشتی به بررسی عمیق کد خط به خط نیاز دارد و تضمینی برای عدم وجود درب پشتی نیست.

آزمایش عملکردهای مخرب خوب طراحی شده دشوار است

10.2.4

هیچ راهی برای تست وجود ندارد. انجام در مدت زمان معقول امکان پذیر نیست. هر کد عجیب و غریب باید مستند و بررسی شود، با این حال تنظیم یک وظیفه خاص برای اطمینان از عدم وجود درهای پشتی به بررسی عمیق کد خط به خط نیاز دارد و تضمینی برای عدم وجود درب پشتی نیست.

آزمایش عملکردهای مخرب خوب طراحی شده دشوار است

10.2.5

هیچ راهی برای تست وجود ندارد. انجام در مدت زمان معقول امکان پذیر نیست. هر کد عجیب و غریب باید مستند و بررسی شود، با این حال تنظیم یک وظیفه خاص برای اطمینان از عدم وجود درهای پشتی به بررسی عمیق کد خط به خط نیاز دارد و تضمینی برای عدم وجود درب پشتی نیست.

آزمایش عملکردهای مخرب خوب طراحی شده دشوار است

13.1.1

تحت پوشش 5.2.6 و 5.3.9

12.3.1

ریسک پیمایش مسیر توسط سایر الزامات موجود از فصل 5 (اعتبارسازی، پاکسازی و رمزگذاری) ASVS و CASA پوشش داده شده است.

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ها در برابر حملات Insecure Direct Object Reference (IDOR) محافظت می‌شوند که هدفشان ایجاد، خواندن، به‌روزرسانی و حذف رکوردها است، مانند ایجاد یا به‌روزرسانی رکورد شخص دیگری، مشاهده سوابق همه یا حذف همه رکوردها.

1.14.6

بررسی کنید که برنامه از پشتیبانی نشده، ناامن یا منسوخ استفاده نمی کند

فناوری های سمت مشتری مانند پلاگین های NSAPI، Flash، Shockwave، ActiveX،

سیلورلایت، NACL یا اپلت های جاوا سمت کلاینت.