בואו נתכנן את הצעד הבא באבטחת הארגון
השאירו פרטים לשיחה
בדיקות חדירות: המדריך והשירות המרכזי / מבדק חדירות תשתיתי
מבדק חדירות תשתיתי בוחן שירותים, זהויות וקשרים ברשת הארגונית כדי להבין אילו נתיבי גישה עשויים להיות זמינים לתוקף. הוא יכול להתחיל מחוץ לארגון או מנקודה פנימית מוגדרת, בהתאם למטרה. הבדיקה מחברת בין חשיפה טכנית לבין נכסים עסקיים, ומסייעת להבחין בין חולשה נקודתית לבין מסלול שמאפשר להתקדם למערכות נוספות.
בדיקה חיצונית מול בדיקה פנימית
בדיקה חיצונית מתייחסת לשירותים שנגישים מנקודת התחלה מחוץ לרשת: מערכות חשופות, גישה מרחוק ונתיבי ניהול שנכללו בהיקף. בדיקה פנימית מתחילה מנקודה מוגדרת בתוך הסביבה, למשל חשבון בדיקה מוגבל או תחנה ייעודית. אין להסיק מתוצאה באחד ההיקפים על כל ההיקף האחר. כדי לתכנן עבודה מועילה, צריך להגדיר את נקודת ההתחלה, את רמת ההרשאה ואת היעדים. בדיקה פנימית אינה מחייבת לתת הרשאות מנהל, ובדיקה חיצונית אינה מסתכמת ברשימת כתובות. שתי הגישות יכולות להשלים זו את זו כאשר יש מטרות ברורות לכל חלק.
שירותים חשופים ותצורות גישה
מיפוי השירותים מסייע להבין מה נגיש ובאילו תנאים, אך עצם הופעת שירות אינה מוכיחה חולשה. בוחנים את התצורה, את מנגנון האימות, את הרגישות ואת האפשרות להשתמש בשירות מעבר לצורך העסקי. שירות ניהול שחשוף לאינטרנט, לדוגמה, עשוי להצריך הגבלת גישה ובקרה נוספת. ממצא צריך לתאר את הסיכון בפועל ולא להסתפק בשם מוצר או בגרסה שנצפתה. אימות של חולשה ידועה מבוצע רק בדרך שסוכמה ובלי לגרום נזק. אם לא ניתן לאמת את החשיפה, הדוח צריך להבחין בין חשד לבין ממצא שהודגם.
זהויות, Active Directory והרשאות ניהול
תשתיות ארגוניות נשענות לעיתים על מערכת זהויות מרכזית ועל חשבונות שירות. כאשר אלה נכללים בהיקף, נבחנים יחסי אמון, הרשאות רחבות וקשרים בין תחנות, שרתים ומשתמשים. חשוב להבין אילו זהויות משמשות לפעילות שוטפת ואילו לפעולות ניהול. הרשאת שירות שניתנה לפני שנים יכולה להיות רלוונטית למסלול תקיפה גם בלי חשיפה ישירה לאינטרנט. תרחישים כאלה מחייבים תיאום מפורט, משום שמערכת זהויות מרכזית משפיעה על הארגון כולו. המטרה היא להראות את נתיב הגישה ואת ההשפעה האפשרית באופן מבוקר, לא להפעיל שינוי גורף בחשבונות או במדיניות.
מבדקי חדירה לתשתיות תקשורת והפרדת רשתות
הפרדה בין רשתות צריכה להתאים לתפקידים ולזרימת העבודה. רשת עובדים, סביבת שרתים ונתיב ניהול אינם אמורים לקבל בהכרח אותה גישה. במסגרת הבדיקה בוחנים אם גבולות ההפרדה אוכפים את המדיניות שהארגון הגדיר, ואם שירותים או זהויות מאפשרים מעבר שלא תוכנן. יש להגדיר מראש מאילו מקטעים מתבצעת הבדיקה ולאילו נכסים מותר להגיע. בדיקת ציוד תקשורת יכולה לכלול ממשקי ניהול והגדרות, אך אינה כוללת אוטומטית בדיקות שמשבשות תעבורה. מערכת תפעולית או רכיב רגיש דורשים כללי עבודה ייעודיים ולעיתים גישה שונה.
נתיבי תקיפה ולא רק רשימת חולשות
כמה ממצאים בעלי חומרה מוגבלת עשויים להתחבר למסלול משמעותי. למשל, גישה לשירות פנימי יכולה ליצור קשר לזהות בעלת הרשאות רחבות יותר. דוגמה כזאת נועדה להסביר את העיקרון ואינה טענה על הסביבה שלכם. דוח תשתיתי צריך לתעד את הקשרים ואת תנאי ההתחלה, כדי שהצוות יבין איפה כדאי לקטוע את המסלול. לפעמים שינוי של הרשאה או סגירת נתיב ניהול מפחיתים סיכון יותר מתיקון של רכיב יחיד. חשוב גם לציין אילו שלבים הודגמו ואילו נשארו בגדר אפשרות שלא נבדקה בגלל מגבלות ההיקף.
חיבור הממצאים לעבודה של צוות התשתיות
המלצות תיקון צריכות להתאים למערכות ולתהליכי השינוי של הארגון. עדכון גרסה, צמצום הרשאות, הגבלת שירות או שינוי הפרדה ברשת יכולים להשפיע על שירותים קיימים. לכן נדרש תיעדוף יחד עם בעלי המערכות ותכנון של בדיקה לאחר השינוי. אם קיימת מערכת ניטור, אפשר להגדיר האם תיבחן גם יכולת הזיהוי שלה במהלך הפעילות. הדבר שונה ממבדק שחותר רק למציאת חולשות. שירותי ענן ואפליקציות צריכים לקבל היקף נפרד כשנדרש כיסוי שלהם. תשתית מוקשחת אינה מבטיחה שהלוגיקה העסקית באפליקציה מוגנת, ולהפך.
איך מתכננים מבדק שאפשר לפעול לפי התוצאות שלו?
מבדק מועיל מתחיל בהגדרת השאלות שהארגון רוצה לקבל עליהן תשובה. האם משתמש יכול להגיע למידע של לקוח אחר? האם גישה מוגבלת מאפשרת התקדמות למערכת קריטית? האם צוות האבטחה מסוגל לזהות פעולה חשודה בזמן? את השאלות האלה מתרגמים להיקף עבודה, לתרחישים ולתוצרים. כך אפשר להבין מה נבדק בפועל, מה נשאר מחוץ לתחום ואילו מגבלות משפיעות על המסקנות. הצעת עבודה טובה מציגה את ההנחות האלה מראש, במקום להשאיר אותן לפרשנות בסיום הפרויקט.
גבולות, הרשאות ותיאום
לפני תחילת הפעילות מגדירים רשימת נכסים, בעלות על המערכות, חשבונות בדיקה, חלון פעילות ואנשי קשר. מגדירים גם פעולות אסורות, ספי עומס ותהליך עצירה במקרה של השפעה לא צפויה. שירות של צד שלישי אינו הופך לחלק מהבדיקה רק מפני שהוא מחובר למערכת שלכם. לכל רכיב נדרשת הרשאה מתאימה. בסביבה פעילה עדיף להשתמש בנתוני בדיקה ובחשבונות ייעודיים, ולתאם מראש כיצד יישמרו ראיות בלי להעתיק מידע אישי או עסקי מעבר לנדרש.
הוכחת השפעה בלי לגרום נזק
הבדיקה מתקדמת ממיפוי להבנת מנגנוני ההגנה ולבחינה מבוקרת של חולשות. כאשר נמצא נתיב אפשרי, המטרה היא לאסוף ראיות שמספיקות כדי להסביר את הסיכון ולתקן אותו. אין צורך להרחיב גישה או להוציא מאגר שלם כדי להראות שבעיית הרשאות קיימת. אפשר להגדיר מראש דוגמת מידע בטוחה ותנאי הצלחה מוסכמים. אם מתגלה ממצא חמור במהלך העבודה, דרך הדיווח וההסלמה צריכה להיות ברורה, כדי שהצוות האחראי יוכל להגיב בלי להמתין לדוח הסופי.
תיעדוף, תיקון ובדיקה חוזרת
בסיום חשוב לחבר בין חומרת הממצא לבין ההקשר של המערכת: רגישות המידע, חשיפה לאינטרנט, הרשאות נדרשות והשפעה תפעולית אפשרית. רשימת חולשות לבדה אינה מספיקה. צוותי הפיתוח והתשתיות צריכים לדעת מהו שורש הבעיה, אילו רכיבים מושפעים ואיך יוכלו לוודא שהתיקון יעיל. בדיקה חוזרת מתייחסת לגרסה ולתצורה המעודכנות, ומבדילה בין ממצא שנסגר, ממצא שנסגר חלקית וממצא שלא ניתן לאמת בגלל שינוי בהיקף או בהנגשת הסביבה.
מה להכין לקראת שיחת תיחום?
כדאי להכין תיאור קצר של המערכת, תרשים רכיבים, רשימת ממשקים ותפקידים, מידע על סביבת הבדיקה ומועד היעד העסקי. אין צורך לשלוח סיסמאות או מידע רגיש בטופס פנייה. בשיחה אפשר לברר אילו חומרים יועברו בערוץ מוסכם, מי מאשר את הפעילות ומי אחראי לתיקונים. אם קיימים ממצאים קודמים, אפשר להשתמש בהם לתכנון העבודה ולזיהוי אזורים שדורשים תשומת לב. אין להסיק מהיעדר ממצאים שהמערכת חסינה; התוצאה משקפת את ההיקף, התנאים והזמן שהוגדרו לבדיקה.
איך מודדים התקדמות לאחר המבדק?
כדאי להגדיר לכל ממצא גורם אחראי, מועד יעד והחלטה מתועדת. לפעמים אפשר לתקן מיד, ולפעמים נדרש שינוי במערכת או תיאום עם ספק. גם במקרה כזה חשוב להבחין בין טיפול בשורש הבעיה לבין אמצעי זמני שמקטין חשיפה. החלטה לדחות תיקון צריכה לכלול הסבר, מגבלה מפצה ומועד בחינה מחדש. כך נשמר הקשר בין הדוח לבין העבודה בפועל, גם כאשר כמה צוותים חולקים אחריות על אותו תהליך.
לאורך הזמן אפשר לעקוב אחר מספר הממצאים הפתוחים לפי חומרה, משך הזמן עד לתיקון וחזרת בעיות מאותו סוג. המדדים האלה מסייעים לזהות צורך בהדרכה, בבקרות פיתוח או בשינוי תצורה. הם אינם מבטיחים שלא יימצאו חולשות חדשות. כאשר מתחלפת גרסה, נוסף ממשק או משתנה מודל ההרשאות, צריך לבחון אם ההיקף הקודם עדיין מייצג את המערכת. בדיקה תקופתית מועילה יותר כאשר היא מתבססת על השינויים שהתרחשו ועל הסיכונים שהארגון רוצה להקטין.
בשיחת הסיכום רצוי להפריד בין מסר להנהלה לבין פירוט לצוותים הטכניים. ההנהלה צריכה להבין את המשמעות ואת סדר העדיפויות; אנשי המקצוע צריכים לקבל ראיות והמלצות שאפשר ליישם. לפני סגירת הפרויקט כדאי לוודא שהדוח הועבר בערוץ מוסכם ושברור מי שומר את החומרים, מי מקבל גישה אליהם ואילו ראיות יימחקו לפי ההסכם. ההנחיות האלה מגינות גם על המידע שנאסף במהלך הבדיקה.
תחומים משלימים שכדאי להכיר
לעיון במסגרת המקצועית: NIST SP 800-115: תכנון בדיקות אבטחה. מסגרת מקצועית מסייעת לתכנון; הכיסוי בפועל מוגדר בהצעת העבודה.
נגדיר יחד היקף שמתאים למערכת שלכם
לתמונה הרחבה ולבחירת סוג המבדק, עברו אל שירות בדיקות החדירות של ExploiX. לתיאום שיחת תיחום אפשר לפנות לצוות עם תיאור קצר של המערכת והצורך העסקי.
שאלות נפוצות
מה ההבדל בין מבדק חיצוני לפנימי?
ההבדל הוא נקודת ההתחלה ורמת הגישה. מבדק חיצוני בוחן חשיפה מבחוץ, ומבדק פנימי בוחן תרחיש בתוך הסביבה. יש להגדיר לכל אחד מטרות וגבולות.
האם מבדק תשתיתי כולל Active Directory?
רק אם הוא נכלל בהיקף. יש להגדיר זהויות בדיקה, מערכות ותנאי פעילות, משום שמערכת זהויות מרכזית משפיעה על שירותים רבים.
האם נדרשות הרשאות מנהל לבדיקה פנימית?
לא בהכרח. נקודת התחלה מוגבלת יכולה לייצג תרחיש שימושי. רמת הגישה נקבעת לפי מטרות המבדק ומופיעה בתיחום העבודה.
האם הבדיקה עלולה להשפיע על הרשת?
כל פעילות מחייבת תכנון כדי לצמצם סיכון תפעולי. ספים, חלונות זמן ופעולות אסורות מוגדרים מראש. רכיבים רגישים עשויים לדרוש בדיקה מצומצמת או סביבה נפרדת.
מה כולל הדוח התשתיתי?
היקף, נקודת התחלה, ממצאים, ראיות ונתיבי גישה שנבחנו. חשוב לקבל המלצות שמבחינות בין תיקון חולשה לבין שינוי שיכול לקטוע מסלול רחב יותר.
האם מבדק רשת מחליף בדיקת Web?
לא. רשת ואפליקציה הן שכבות שונות. כשמערכת עסקית חשופה דרך Web או API, יש לבחון אם נדרש מבדק ייעודי שלה בנוסף לתשתית.