מה זה PT
תקיפה יזומה נגד חלק מוגדר מהסביבה שלכם בדיוק כמו שתוקף אמיתי היה עושה: תחת אישור בכתב, בתוך כללים מוסכמים ובחלון זמן מוסכם. בסוף אתם מקבלים את ההוכחה, את הדרך שבה התקיפה בוצעה, ורשימת תיקונים מסודרת לפי השפעה עסקית אמיתית ולא לפי ציון CVSS גולמי.
מבדק חדירה הוא לא סריקת פגיעויות. סורק מייצר רשימה של אפשרויות; מבדק מייצר רשימה של עובדות. הערך נמצא במה שאדם עושה אחרי שהסורק עצר: בשרשור של שלושה ממצאים "בינוניים" לכדי הרשאות דומיין, או בהפיכת דליפת מידע "נמוכה" להשתלטות מלאה על חשבון.
מה אני בודק
שתי משפחות של מבדקים. שתיהן רצות על אותו שלד מתודולוגי. ההבדל הוא ביעד, והיכן מושקע העומק.
| סוג המבדק | מה הוא מכסה, ומול מה הוא נבדק | על איזו שאלה הוא עונה |
|---|---|---|
| מבדק חדירה לתשתית | רשתות, שרתים, תחנות קצה, זהויות ותצורת ענן: On-Premise, ענן (Azure / Microsoft 365 / AWS) או היברידי. מתבצע חיצונית (מהאינטרנט מול הפרימטר שלכם) או פנימית (בהנחת פריצה, מתוך הרשת). נבדק מול: PTES, NIST SP 800-115 ו-CIS Benchmarks, כשכל טכניקה שבה השתמשתי ממופה ל-MITRE ATT&CK. | אם מישהו מגיע לרשת שלכם, מבחוץ או ממחשב אחד שנפרץ, לאן הוא מגיע בסוף, וכמה מהר? |
| מבדק חדירה לאפליקציה | אפליקציות ווב וה-API שמאחוריהן. נבדקות קודם ללא הזדהות, ואחר כך מזוהות בכל רמת הרשאה שקיימת במוצר, כולל התפקידים שאף אחד לא חושב עליהם, כמו משתמש הניסיון והחשבון שהושבת. נבדק מול: OWASP Top 10, OWASP API Security Top 10 ומדריך הבדיקות המלא OWASP WSTG. כיסוי שהולך הרבה מעבר ל-Top 10, שהוא רשימת מודעות ולא תוכנית בדיקות. | האם משתמש אחד יכול להפוך למשתמש אחר, או למנהל? האם אפשר להגיע למידע, לשנות אותו או לייצא אותו בלי הרשאה? |
Black box, grey box, white box
הבחירה השנייה, אחרי היעד, היא כמה מידע אני מקבל לפני שאני מתחיל. בתעשייה מכנים את אלה סוגי המבדק לפי רמת הידע. זו החלטת תיחום ולא החלטת איכות: היא קובעת כמה מהתקציב הולך לגילוי, וכמה לעומק.
| גישה | מה אתם נותנים לי | מתי זה הכי מתאים |
|---|---|---|
| Black box | רשימת יעדים ותו לא | כשרוצים ריאליזם, או מבדק ראשון שמראה מה גורם חיצוני מוצא בכוחות עצמו |
| Grey box | משתמשים לכל תפקיד, מסמכי ארכיטקטורה, תיעוד API | ברירת המחדל, וגם מה שרוב התקנים מניחים. הכיסוי הטוב ביותר ליום עבודה: בלי לשרוף תקציב על גילוי מחדש של מה שכבר ידוע לכם |
| White box | כל מה שלמעלה, בתוספת קוד מקור, קבצי תצורה וגישת קריאה לענן | מערכות רגולטוריות או קריטיות לעסק, שבהן לפספס משהו זו התוצאה היקרה |
מתי אתם חייבים לבצע מבדק
| מקור החובה | מה נדרש |
|---|---|
| תקנות הגנת הפרטיות (אבטחת מידע), תשע"ז-2017, תקנה 18 | מאגר מידע ברמת אבטחה גבוהה חייב בסקר סיכונים ובמבדקי חדירות אחת ל-18 חודשים לפחות. שיני האכיפה התחדדו מאוד עם תיקון 13 לחוק הגנת הפרטיות. |
| ISO/IEC 27001:2022 | בקרות A.8.8 (ניהול פגיעויות טכניות) ו-A.8.29 (בדיקות אבטחה בפיתוח ובקבלה). אף סעיף לא כותב "מבדק חדירה", אבל זו הראיה שמבקרים מצפים לראות. |
| SOC 2 | אותו סיפור: אין סעיף מפורש, אבל דוח עדכני הוא מה שמבקרים ולקוחות ארגוניים מחפשים תחת קריטריוני הניטור וניהול השינויים. |
| בנק ישראל, הוראת ניהול בנקאי תקין 361 | מבדקי חדירה מבוקרים כחלק מתוכנית הערכת בקרות הגנת הסייבר, בשילוב עם סקרי פגיעויות ומנגנוני הערכה נוספים. ההוראה קובעת את החובה, לא תדירות קבועה. |
| רשות שוק ההון, ביטוח וחיסכון, חוזרי ניהול סיכוני סייבר | גופים מוסדיים ונותני שירותים פיננסיים נדרשים לכלול בדיקות תקופתיות בתוכנית הערכת הבקרות שלהם. |
| DORA (האיחוד האירופי), תקנה 2022/2554 | מבדקי חדירה לרשת אחת לשנה לפחות לכל הגופים הפיננסיים בתחולה (סעיפים 24–25), ומבדקי חדירה מבוססי מודיעין איומים (TLPT) אחת לשלוש שנים לפחות לגופים שהרגולטור הלאומי הגדיר (סעיפים 26–27). |
| NIS2 (האיחוד האירופי), דירקטיבה 2022/2555 | בדיקות אבטחה והערכת אפקטיביות כחלק מאמצעי ניהול הסיכונים המחייבים, לגופים חיוניים וחשובים. |
| PCI DSS v4.x, דרישה 11.4 | מבדק פנימי (11.4.2) וחיצוני (11.4.3) אחת ל-12 חודשים לפחות ולאחר כל שינוי משמעותי; תיקון הממצאים הניתנים לניצול ובדיקה חוזרת (11.4.4); בדיקת בקרות ההפרדה אחת ל-12 חודשים (11.4.5), ואחת לחצי שנה אצל ספקי שירות (11.4.6). |
| חוזים מול לקוחות, שאלוני אבטחה ומכרזים | לא רגולציה, אבל מחייב בדיוק באותה מידה. "מבדק חדירה שנתי על ידי צד שלישי בלתי תלוי, עם מכתב אישור לפי דרישה" הוא כיום נוסח סטנדרטי בחוזים ארגוניים ובמכרזים ציבוריים בישראל ובאירופה. |
מתי זה מומלץ, גם כשאף אחד לא מחייב אתכם
- מוצר חדש או פיצ'ר משמעותי עומדים לעלות לאוויר. הרגע הזול ביותר לגלות פגם בהרשאות הוא לפני שהלקוח הראשון מגלה אותו
- עברתם לענן, שיניתם ארכיטקטורה או החלפתם ספק אחסון. הבקרות שהגנו על התכנון הישן כמעט אף פעם לא מתורגמות נקי לחדש
- בדיוק יצאתם מאירוע סייבר. מבדק הוא הדרך לוודא שדרך הכניסה באמת נסגרה, ולא רק שמניחים שנסגרה
- בדיקת נאותות בדרך. גיוס הון או רכישה, שבהם דוח נקי מקצר משמעותית את שיחת האבטחה
- רכשתם חברה. ירשתם משטח תקיפה שאף אחד בצוות שלכם עוד לא הסתכל עליו
- קוד שנוצר בעזרת AI עלה לאוויר מהר יותר ממה שהביקורת הספיקה. קוד מיוצר נוטה להיכשל בתבניות, והתבניות האלה ניתנות לבדיקה
- לקוח ארגוני גדול עומד לשאול. עדיף לענות עם דוח מאשר עם הבטחה
- הרשת הפנימית שלכם מעולם לא נבדקה מבפנים. הקשחה חיצונית לא אומרת דבר על מה שמחשב אחד שנפל לפישינג מגיע אליו
- מעולם לא ביצעתם מבדק. המבדק הראשון תמיד מוצא הכי הרבה, והוא זה שאומר לכם איפה אתם באמת עומדים
- אחת לשנה, בסביבה יציבה. כהיגיינה שוטפת, לצד בדיקה חוזרת של ממצאי השנה שעברה
איך זה עובד
שבעה שלבים, זהים לשני סוגי המבדק. אלה שלבי PTES ומחזור ה-Discovery–Attack–Report של NIST SP 800-115: תהליך מוכר שאפשר להציג למבקר, ולא מתודולוגיה שהמצאתי. מה שמשתנה בין תשתית לאפליקציה הוא מה שקורה בתוך כל שלב, לא הסדר שלהם.
- 1 · תיחום ואישור
- 2 · גילוי
- 3 · מידול איומים וניתוח
- 4 · ניצול
- 5 · אחרי הניצול
- 6 · דיווח
- 7 · בדיקה חוזרת
| שלב | מה קורה בו |
|---|---|
| 1 · תיחום ואישור | רשימת יעדים, כללי התקשרות, חלון בדיקה, איש קשר לחירום, ותשובה מוסכמת לשאלה "מה אם משהו נשבר". אישור בכתב נחתם לפני כל דבר אחר. בלי יוצאים מן הכלל. |
| 2 · גילוי (Discovery): איסוף מודיעין, סריקה ומיפוי | שלב אחד, לא שלושה: מיפוי משטח התקיפה האמיתי, שכמעט אף פעם לא זהה לזה שבדיאגרמה. איסוף מודיעין פסיבי, סריקה אוטומטית ומיפוי ידני מזינים את אותה תמונה, וכל ממצא אוטומטי מאומת ידנית, כך שממצאי שווא לא מגיעים לדוח שלכם. תשתית: מארחים חיים, שירותים חשופים, טננטים בענן, זהויות, סביבות בדיקה שנשכחו. אפליקציה: נתיבים, פרמטרים, תפקידים, מחסנית הטכנולוגיה והרכיבים של צד שלישי שבתוכה. |
| 3 · מידול איומים וניתוח פגיעויות | הכרעה מה באמת ניתן לניצול בהקשר שלכם, מה תוקף היה באמת רוצה כאן, ואילו ממצאים ניתן לשרשר זה לזה. שלוש בעיות לא מרשימות שמצטרפות לפריצה מלאה גוברות על ממצא "חמור" רועש אחד שלא מוביל לשום מקום. |
| 4 · ניצול | להוכיח, לא לטעון. תשתית: השגת גישה, הסלמת הרשאות, תנועה רוחבית, ניצול זהויות ותצורת ענן שגויה. אפליקציה: עקיפת אימות והרשאות, הזרקות, גישה ישירה לאובייקטים (IDOR), ניהול סשנים וניצול לוגיקה עסקית. |
| 5 · פעולות לאחר הניצול | עד לאן הגישה באמת מגיעה: הדומיין, הטננט בענן, המידע. העומק מוסכם מראש ונעצר בדיוק איפה שאתם אומרים. שום דבר לא נשאר מאחור בסביבה שלכם. |
| 6 · דיווח | טיוטת דוח, סקירה מול הצוות הטכני, מפגש נפרד להנהלה, ואז הגרסה הסופית. ממצאים קריטיים לא נשמרים לדוח. עליהם אתם שומעים ביום שבו הם נמצאו. |
| 7 · בדיקה חוזרת | אימות שהתיקונים באמת תיקנו, ודוח מעודכן שמשקף מה באמת נסגר. זו הגרסה שמבקר, לקוח או רגולטור יבקשו לראות. |
מה מקבלים
- ממצאים מדורגים לפי השפעה עסקית. ולא לפי ציון CVSS גולמי, שבאופן קבוע מציב ממצא "חמור" בלתי נגיש מעל ה"בינוני" שסוגר לכם את העסק
- שלבי שחזור. מדויקים מספיק כדי שהמפתח או איש התשתיות שלכם ישחזר את הבעיה בלעדיי
- הוכחת ניצול. צילומי מסך, בקשות ותגובות, והנתיב שבו עברתי בפועל
- סיפור התקיפה. איך הממצאים הבודדים משתרשרים יחד לפריצה אמיתית
- הנחיות תיקון למחסנית שלכם. התיקון בפועל בפריימוורק, בענן או במוצר שלכם, ולא קישור למאמר כללי
- תקציר מנהלים. כתוב כך שדירקטוריון לא טכני או לקוח יוכלו לקרוא ולהחליט
- מכתב אישור (Attestation). לרכש, לשאלוני אבטחה ולמכרזים
- בדיקה חוזרת ודוח מעודכן. הגרסה שאפשר באמת להראות למישהו
מה לא נכלל (אבל בר ביצוע ע"י hodsec)
- מניעת שירות (DoS) ובדיקות עומסים
- הנדסה חברתית וסימולציות פישינג: התקשרות נפרדת, לא חלק מהמבדק הזה
- חדירה פיזית
- מערכות של צד שלישי שאינן בבעלותכם או שאינכם רשאים לאשר בדיקה שלהן
- תיקון הממצאים. אני אומר מה לתקן ואיך; התיקון עצמו הוא שלכם, או התקשרות נפרדת
מה אני צריך מכם
זה משתנה מלקוח ללקוח, אבל בפועל מדובר בשלושה דברים:
- תיחום וגישה. היעדים המדויקים בכתב (טווחי כתובות, דומיינים, כתובות אפליקציה), אישור חתום לבדוק אותם, והגישה שהמבדק דורש: משתמשי בדיקה בכל רמת הרשאה, הסביבה שמולה אני בודק, וכל VPN, שרת קפיצה או הסרת חסימה ב-WAF שנדרשים כדי להגיע אליה
- איש קשר טכני אחד מצדכם. מי שיכול לתת את הגישה הזו, לאשר את כללי ההתקשרות, ולהיות זמין בחלון הבדיקה אם משהו נשבר או אם ממצא קריטי דורש החלטה מיידית
- החלטה אם לעדכן את צוות הניטור. או שהם יודעים על המבדק מראש, או שבמכוון לא, ואז המבדק בודק גם את יכולת הזיהוי שלכם. שתי האפשרויות בסדר, צריך רק לסכם את זה מראש, כדי שאירוע אמיתי בזמן החלון לא ייחשב בטעות לי
מי מבצע את העבודה
אני מוביל את העבודה בעצמי. יש לכם איש קשר אחד מתחילת הדרך ועד סופה. כשהעבודה דורשת ידיים נוספות או התמחות ספציפית, אני מצרף אנשי מקצוע שעבדתי איתם, תחת אותם תנאי סודיות, ואתם תמיד יודעים מי נוגע במערכות שלכם.
סודיות
מה שתספרו לי, ומה שאמצא, נשאר בינינו. סודיות מלאה מובטחת לאורך כל העבודה וגם אחריה, ואפשר לחתום על הסכם סודיות עוד לפני שנכנסים לפרטים.
התקנים שלפיהם העבודה מתבצעת
- PTES. Penetration Testing Execution Standard, למתודולוגיה הכוללת
- NIST SP 800-115. מדריך טכני לבדיקות והערכות אבטחת מידע
- OWASP Top 10, API Security Top 10 ו-WSTG. הבסיס שכל גורם בארגון מכיר, ולצידו מדריך הבדיקות שנותן לכיסוי אפליקציות הווב את העומק האמיתי שלו
- MITRE ATT&CK. לתיאור הטכניקות שבהן השתמשתי, באותה שפה שבה המגנים שלכם עובדים
המשך עבודה
מחזור מבדקים שנתי עם בדיקה חוזרת מובנית; ייעוץ פיתוח מאובטח שמתקן את סוג הבאג ולא את המופע הבודד; הדרכת מפתחים על הבעיות שבאמת הופיעו בקוד שלכם; סקר חשד לפריצה (Compromise Assessment) אם המבדק מרמז שמישהו הגיע לשם לפניי; ותגובה לאירוע, אם מתברר שאכן כך. שום דבר מזה אינו תנאי למבדק.
מה קורה עכשיו
- שיחת תיחום. מה יש לכם, מה מדאיג אתכם, ולאיזה תאריך יעד אתם עובדים. ללא עלות וללא התחייבות.
- תיחום והצעת מחיר בכתב בהתאם לסקופ העבודה. יעדים, גישת בדיקה, עומק, ומה בדיוק תקבלו, בכתב, כדי שלא יישאר מה לפרש אחר כך.
- ניירת. NDA, אישור לביצוע הבדיקה, וכללי התקשרות.
- תאריכים ביומן. חלון הבדיקה, בתיאום עם לוח הגרסאות ושעות הפעילות שלכם.
- מתחילים.
אם אתם כבר יודעים מה צריך להיבדק, השיחה קצרה. אם לא, בדיוק בשביל זה היא קיימת.