זיהוי איומים (Threat Detection) מה זה? המפתח להסבר על הגנת הסייבר

נכתב במקור על ידי האנה המילטון באתר Jamf

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

קודם כל, בואו נגדיר מה אנחנו מתכוונים באיום. המכון הלאומי לסטנדרטים וטכנולוגיה של ארה"ב (NIST) מגדיר איום סייבר כ:

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

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

בואו נדבר על כמה סוגי איומים נפוצים.

סוגי איומים

תוכנות זדוניות (Malware)

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

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

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

הנדסה חברתית (Social Engineering)

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

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

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

אי-תצורה ופגיעויות (Misconfigurations and Vulnerabilities)

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

  • תוכנה או מערכות הפעלה לא מעודכנות
  • תוכנה עם חולשות ידועות או לא ידועות שתוקפים יכולים לנצל אותן
  • מדיניות סיסמאות חלשות
  • מדיניות גישה רחבה מדי; חוסר שימוש בעקרונות הרשאות מינימליות

מניעת שירות – Denial of Service

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

איומים פנימיים (Insider Threats)

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

איומים לא ידועים

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

שיטות זיהוי איומים

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

זיהוי מבוסס-חתימה (Signature-based Detection)

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

זיהוי מבוסס-התנהגות (Behavior-based Detection)

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

בינה מלאכותית ולמידת מכונה (AI/ML)

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

אבולוציה של ניהול מכשירי Apple: מאיפה התחלנו

 

בהתחלה, היה ה-Binary.

ב-2003, לפני ש-Apple שחררה את ה-MDM framework, רוב מנהלי Apple ניהלו מכשירי macOS עם Casper Suite – שלימים נודע כ-Jamf Pro.

מנהלי Mac היו:

  1. רושמים את המכשירים הארגוניים בשירותי Apple
  2. מקבלים binaries מקומיים עם הרשאות root
  3. שולחים נתונים על ה-Mac לשרת ניהול במועדים מוגדרים

מנהלי Mac יכלו גם לגרום ללקוח המקומי לבצע פעולות תכנותיות על ידי הורדת חבילות והרצת סקריפטים מקומיים.

זה היה ניהול מכשירים בשיטת "forced pull".

תרשים של זרימת מידע עם binary

איור 1: ניהול מכשירים ב-"forced pull" עם binary

iPhone שינה הכל.

עם הצגת iOS ב-2007, החיים נהיו מעניינים יותר.

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

בהתחלה, IT ניהל מכשירי iOS ארגוניים באופן ידני דרך iTunes. Apple הציגה פרופילים – קבצי XML שמחילים הגדרות תצורה על מכשיר iOS – עם iPhone Configuration Utility ב-2008.

זה עזר, אבל מנהלי Apple עדיין היו צריכים דרך לנהל macOS ו-iOS בצורה יותר מתוחכמת.

כש-Apple שחררה את iPhone 4 הם גם הציגו יכולות MDM עם פרוטוקול ה-MDM שלהם. זה פתח את הדלת להמון אפשרויות חדשות עבור macOS ו-iOS.

תוך כדי תנועה במהירות של Apple, Jamf פיתחה יכולות MDM עבור לקוחות במקביל אליהם.

נעלם סוכן עם גישת root שיוצר קשר עם שרת ניהול באופן תקופתי.

חיבור מתמשך

MDM דרש התראות push. כך שבמקום שסוכן מקומי יצור קשר תקופתי עם השרת ניהול ושואל "האם אני צריך לעשות משהו? ועכשיו?" השרתים שמרו על חיבור מתמשך מול Apple.

כאשר שרת הניהול רצה שמשהו יקרה, הוא שלח ping לשירותי הליבה של Apple וביקש מ-Apple שהמכשיר ייצור איתו קשר כדי לקבל הגדרה או פקודה.

פרוטוקול ה-MDM גדל מאוד מאז ש-Apple הציגה אותו, עם הרבה יותר פקודות והגדרות מפורטות יותר הזמינות. זו הטכנולוגיה ש-Jamf משתמשת בה לצד ה-Jamf Management Framework כבר כמעט 13 שנים. למעשה, Jamf Pro עדיין משתמש בפעולות משיכה הקשורות ל-binary וגם בפקודות דחיפה של MDM.

תרשים של זרימת המידע עם פרוטוקול ה-MDM

איור 2: MDM עם התראות push

זרימות עבודה מסורתיות של MDM

מבנה ה-MDM היה שיפור לעומת הסתמכות בלעדית על ה-binary, וגם Apple וגם Jamf עשו הרבה עם מבנה זה כדי להפוך את העבודה לפשוטה יותר עבור כולם.

אבל זה לא היה ללא בעיות.

זכור ש-MDM מסורתי תלוי במכשיר שיש לו חיבור קבוע ל-Apple, ובשרת ניהול שמבקש מ-Apple שהמכשיר המנוהל ייצור איתו קשר כדי לקבל פקודה או שאילתה.

הפקודה יכולה להיות:

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

ואז השאילתה העוקבת כדי לוודא שהמכשיר ביצע את השינוי כראוי יכולה להיות:

  • מהי מערכת ההפעלה שלך כרגע?
  • האם החלת את הגדרת ה-Wi-Fi?
  • ספר לי אילו אפליקציות מותקנות אצלך.

אז ב-MDM מסורתי, IT מקבלים אישורים כשפקודות התקבלו או הושלמו, והם יכולים לקבל הרבה מידע בחזרה מהמכשיר כשהם שואלים – אבל הם צריכים לשאול. שוב ושוב.

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

  • לקלוט ולנתח את המידע
  • אולי לבצע חישובים עליו
  • להפעיל פקודות וסקירות עוקבות
  • להפעיל סקרים נוספים

וכך הלאה והלאה והלאה.

זה מסתכם בזה: MDM מסורתי הוא מאוד פטפטן ויכול להשתמש בהרבה משאבי רשת.

תיאור של ניהול מכשירים דקלרטיבי

איור 3: ניהול מכשירים דקלרטיבי

מה כל כך נהדר ב-DDM?

בפשטות, ניהול מכשירים דקלרטיבי (DDM) מצמצם את כל הפטפוט הזה, ומאפשר ביצועים וסקלביליות טובים יותר.

זה מאפשר למכשיר להחיל באופן עצמאי הגדרות ולדווח לשרת ה-MDM מבלי שיבקשו ממנו.

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

מכשיר macOS או iOS משתף באופן פרואקטיבי מידע על מצבו הנוכחי (וכל שינוי) עם שרת ה-MDM, מה שאומר שמכשירים יכולים להגיב מיד כדי למנוע התקפות תוכנות זדוניות, לשמור על תאימות ולוודא שכל המשתמשים הם משתמשים מהימנים.

למד עוד מידע על DDM מ-Apple.

זרימות עבודה של DDM חלקות יותר.

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

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

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

DDM: העתיד של MDM הוא עכשיו.

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

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

נכתב במקור ב – 22 במרץ 2024 על ידי האדייר קופלי-וודס, קייטי אינגליש באתר Jamf