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

הסרה כי mTLS לא נתמך על ידי רוב ה-CSP, ולכן רוב המפתחות שנבדקו ל-CASA ישתמשו באימות מבוסס סיסמה

2.4.3

התקן, כפי שהוא נכתב, אינו ספציפי מספיק כדי לאכוף אותו

2.4.5

הדרישות שהוסרו בגרסה 5 של ASVS והאלגוריתמים המומלצים לגיבוב בגרסה 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, כי סיכון האימות של מכשירים פיזיים נכלל ב-4.3.1 למטרת MFA (פיזי או תוכנה)

2.9.3

הדרישה הזו מכסה מכשירים פיזיים בהתאם ל-ASVS (מפתחות אבטחה קריפטוגרפיים הם כרטיסים חכמים או מפתחות FIDO, שבהם המשתמש צריך לחבר או להתאים את

למכשיר קריפטוגרפי למחשב כדי להשלים את האימות. מאמתים שולחים הודעה אל האתגר

מכשירים או תוכנות קריפטוגרפיים, והמכשיר או התוכנה מחשבים תגובה על סמך

מפתח קריפטוגרפי מאוחסן.) הדרישה הזו לא נכללת בהיקף של CASA, כי סיכון האימות של מכשירים פיזיים נכלל ב-4.3.1 למטרת MFA (פיזי או תוכנה)

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

לא ניתן לבצע את הפעולה בזמן סביר. חשוב לתעד כל קוד מוזר ולבדוק אותו. עם זאת, הגדרה של המשימה הספציפית כדי לוודא שהדלתות האחוריות לא קיימות מחייבת בדיקה מעמיקה של קוד השורה, והיא לא מבטיחה נוכחות של דלתות אחוריות.

קשה לבדוק פונקציות זדוניות שתוכננו היטב

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 רגישים מוגנים מפני מתקפות מסוג אובייקט לא ישיר של אובייקטים ישירים (IDOR) המטורגטות ליצירה, לקריאה, לעדכון ולמחיקה של רשומות, כמו יצירה או עדכון של רשומות של אנשים אחרים, צפייה ברשומות של כולם או מחיקה של כל הרשומות.

1.14.6

צריך לוודא שהאפליקציה לא משתמשת בגרסה לא נתמכת, לא מאובטחת או שהוצאה משימוש

טכנולוגיות בצד הלקוח כגון יישומי פלאגין של NSAPI, Flash, Shockwave, ActiveX,

יישומונים מסוג Silverlight, ב-NACL או ב-Java בצד הלקוח.