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

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

2.9.1

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

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

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

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

2.9.3

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

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

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

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

הדרישה מכוסה על ידי אימות דו-שלבי לממשקי אדמין ולגישה עם הרשאות

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

קשה לתאר מהו פרמטר קביל או נחוץ. המקרה לא ניתן לבדיקה. מה נחשב לנדרש? איך נקבע אם חריגה היא תקפה? Considered out of scope for 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

covered by 1.1.4, 1.8.4 and 1.8.2

1.4.4

covered by 1.1.4, 1.8.4 and 1.8.2

1.5.2

covered by 1.1.4, 1.8.4 and 1.8.2

1.5.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.5.4

covered by 1.1.4, 1.8.4 and 1.8.2

1.9.1

covered by 1.1.4, 1.8.4 and 1.8.2

1.11.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.1

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.2

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.4

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.5

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.6

covered by 1.1.4, 1.8.4 and 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

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