OnWorks Linux ו-Windows Online WorkStations

לוגו

אירוח מקוון בחינם עבור תחנות עבודה

<הקודם | תוכן | הבא>

11.2.1. הערכת פגיעות


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

בשל פשטותו היחסית, מבחן פגיעות מושלם לרוב בסביבות בוגרות יותר על בסיס קבוע כחלק מהדגמת גילוי הנאותות שלהם. ברוב המקרים, כלי אוטומטי, כמו אלה ב-Vennerability Analysis7 ויישומי אינטרנט8 קטגוריות של אתר Kali Tools ותפריט Kali Desktop Applications, משמשת לגילוי מערכות חיות בסביבת יעד, זיהוי שירותי האזנה וספירתם כדי לגלות מידע רב ככל האפשר כגון תוכנת השרת, גרסה, פלטפורמה וכן הלאה. .

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

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

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

• ארכיטקטורת מעבד: יישומי תוכנה רבים זמינים עבור ארכיטקטורות מעבדים מרובות כגון Intel x86, Intel x64, גרסאות מרובות של ARM, UltraSPARC וכן הלאה.


תמונה

5https://en.wikipedia.org/wiki/Executable_space_protection#Windows 6https://en.wikipedia.org/wiki/Address_space_layout_randomization 7http://tools.kali.org/category/vulnerability-analysis 8http://tools.kali.org/category/web-applications‌‌‌

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

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

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

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

• False Positive: החתימה מותאמת; אולם הבעיה שזוהתה אינה פגיעות אמיתית. בהערכה, אלה נחשבים לרוב לרעש ויכולים להיות די מתסכלים. לעולם אינך רוצה לפסול חיובי אמיתי כחיובי שגוי ללא אימות נרחב יותר.

• True Negative: החתימה אינה מותאמת ואין פגיעות. זהו התרחיש האידיאלי, המוודא שלא קיימת פגיעות ביעד.

• False Negative: החתימה אינה מתאימה אך קיימת פגיעות קיימת. עד כמה ש-false positive היא גרועה, ש-false negative היא הרבה יותר גרועה. במקרה זה, קיימת בעיה אך הסורק לא זיהה אותה, כך שאין לך אינדיקציה לקיומה.

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

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

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

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

המחאות שיהיו קשורות לשירותים אלה. זו העלות של ביצוע סריקה; זה הולך לכבוש משאבי מערכת. מושג כללי לגבי המשאבים שייצרכו וכמה עומס יכולה מערכת היעד לקחת חשוב בעת הפעלת הכלים הללו.


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

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


כאשר סריקת פגיעות מסתיימת, הבעיות שהתגלו מקושרות בדרך כלל למזהים סטנדרטיים בתעשייה כגון מספר CVE9, EDB-ID10, ועצות לספקים. מידע זה, יחד עם ציון הפגיעות CVSS11, משמש לקביעת דירוג סיכון. יחד עם שליליות שגויות (וחיוביות שגויות), דירוגי סיכון שרירותיים אלה הם נושאים נפוצים שיש לקחת בחשבון בעת ​​ניתוח תוצאות הסריקה.

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

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

אמנם אין הסכמה אוניברסלית על דירוגי סיכון, פרסום מיוחד של NIST 800-3012 מומלץ כבסיס להערכת דירוגי הסיכון והדיוק שלהם בסביבתך. NIST SP 800-30 מגדיר את הסיכון האמיתי של פגיעות שהתגלתה כ שילוב של הסבירות להתרחשות וההשפעה הפוטנציאלית.



9https://cve.mitre.org 10https://www.exploit-db.com/about/ 11https://www.first.org/cvss‌‌‌

12http://csrc.nist.gov/publications/PubsSPs.html#800-30

 

מחשוב ענן מערכת ההפעלה המוביל ב-OnWorks: