Archive for the 'SIEM-SOC' Category

25
יונ
14

התגוננות בפני התקפות סייבר Cyber Defense

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

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

התפיסה שיושמה ונוסתה, כוללת את המרכיבים הבאים (רשימה חלקית וראשונית).
הפרדת רשתות: הרגולציה בתחום אבטחת מידע בגופים פיננסיים בארץ, הינה מהמתקדמות בעולם. אחת הדרישות הכי חשובות במספר רגולציות (בנקים, ביטוח) מחייבת הפרדה או חציצה בין רשתות ארגוניות פנימיות לבין רשתות ציבוריות/אינטרנט. החציצה מונעת תקשורת החוצה. (לכל היצרנים/ספקים, מוצר פרוקסי אינו נחשב פתרון כזה.) בשפה תקשורתית, ניסיון ליצור צינור תקשורת החוצה בכל מיני פורטים (80, 443, 22, 21 ועוד) ייחסם ע"י ה – Firewall.
גלישה לאינטרנט תיעשה ע"י פתרונות גלישה מאובטחת. העברת קבצים ע"י פתרונות כספות. וכך הלאה. בטכנולוגיה של היום, הפגיעה בחוויית המשתמש אינה גדולה (חוץ מתלונות מפונקות ע"י עובדים שלא מעניין אותם שהארגון יישאר פרוץ). החריגה היחידה שציינתי בעבר נוגעת לשימוש במייל, שבמקרה זה הפגיעה במשתמשים גדולה ולא מספקת פתרון מקובל מבחינת עלות תועלת.

מעטפת/רכיבי הגנה חיצוניים: כל אותם רכיבים שהיו נהוגים בתפיסת אבטחת המידע הכוללת, רלוונטיים גם כאן. מערכת IPS להגנה מפני התקפות חיצוניות על הרשת, שרת WAF להגנה על אתרי אינטרנט, מערכת סינון תכנים (Content Filtering) ואנטי ספאם, מערכת הגנה נגד APT, הגנה מפני DDoS.
מהיכרות שלי עם ארגונים, ובעיקר עם מנהלי מערכות מידע ומנהלי תשתיות, הם חוטאים בכל קשור לרכיבי האבטחה. במקום לנצל 100% מיכולות החסימה של המוצרים האלה, הרבה הגדרות (לפעמים 50%) אינן מופעלות מהחשש לפגוע בשירות או מכך שזה יביא לעבודה מיותרת בעיניהם. החטא הזה מוביל לכך שפורצים מצליחים ע"י כך לנצל פרצות במעטפת החיצונית. אקווריום אטום "למעט" שני חורים זה עדיין אקווריום דולף. חייבים לחסום הכל, בלי פשרות. מנהלים, תעבדו יותר קשה.

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

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

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

  • צרו רשימת כתובות חשודות. לרשימה זו הכניסו כתובות שביצעו Port Scanning, שלחו מיילים חשודים שהכילו נסיונות Phishing או כתובות שה – WAF זיהה כמקור לתקיפה לאתר החברה.
  • הגדירו חוק המתריע על פתיחת תקשורת (מה – Firewall) לכתובת המצויה ברשימת הכתובות החשודות.
  • חוק המתריע על Port Scanning.
  • חוק המתריע על נסיונות תקיפה (מה – WAF) על האתר. אפשר לעדן את החוק ע"י סינון סוגי מתקפות מסויימים/רלוונטיים או רמת קריטיות של התקפות.
  • חוק המתריע על נסיונות DoS/DDoS (מה – IPS).
  • חוק המתריע על שליחת מייל למעל X נמענים (ממערכת האנטי ספאם). אפשר להוסיף חוק דומה המזהה שליחת מיילים לעובדים רגישים העשויים להיות מושא לנסיונות Phishing (מנהלי רשת, מנהלים בכירים, עובדים בעלי הרשאות רגישות).
  • חוק המתריע על מספר תחנות הנגועות בוירוס או מתקפת APT.
  • חוק המתריע על תקשורת לכתובות הידועות כשרתי Command & Control.

מערך ניטור SOC: חיברתם את כל המערכות והשרתים ל – SIEM וראיתם שמתקבלים חיווים טובים ויש התראות על אירועים חשודים. מה עושים עם כל זה?
כדי להתגונן באופן יעיל מפני התקפות סייבר, יש חשיבות גבוהה להקים מוקד SOC אשר יטפל בהתראות השונות שקופצות במערכת בתוך פרק זמן קצר. במוקדי SOC טובים, המוקדנים יידעו לטפל גם באופן אקטיבי באירועים. למשל, לחסום כתובות IP חשודות ב – Firewall, ב – WAF או ב – IPS, למחוק משרת הדוא"ל מיילים שזוהו כהתקפות Phishing, ואפילו לנתק מהרשת או להעביר לסגמנט רשת מבודד תחנות קצה חשודות.
חשוב להגדיר, בכתב, נהלי טיפול באירועים לכל סוג אירוע שהוגדר לו חוק ב – SIEM, וגם לתרחישים נוספים שאין להם חוקי SIEM. הנהלים יגדירו למי מדווחים, מתי פועלים אקטיבית וכיצד.

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

  • נסיונות חדירה ע"י מייל Phishing המכילים לינקים לאתרים זדוניים והמכילים צרופות המכילות סוסים טרויאניים שעשויים לאפשר מתקפות APT.
  • נסיונות חדירה לרכיבי תשתית ברשת הארגונית.
  • נסיונות חדירה אפליקטיביים ותשתיתיים לאתר האינטרנט.
  • נסיונות חדירה למערכת ה – VPN לגישה מרחוק.
  • נסיונות חדירה ל – IVR.

 

מודעות פרסומת
01
ספט
13

אבטחת מידע ב – SAP

כמעט ואין כיום ארגון גדול שאינו עובד עם מערכת ERP לניהול הכספים, לאפליקציות עסקיות או לרצפת הייצור. שתי המערכות המובילות הינן SAP ו – Oracle Applications. המערכות האלה מאוד רגישות מבחינת אבטחת מידע שכן הן מנהלות כספים (ומהוות כר פורה למעילות וגניבות), מנהלות לקוחות (נתונים פיננסיים ונתונים הקשורים לצנעת הפרט) ועוד.

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

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

  • טרנזקציות המאפשרות ניהול הרשאות (כגון SU01). חשוב לבקר באופן שוטף מי מקבל הרשאות אלה (רק מנהלי/מיישמי ההרשאות). מומלץ לנטר במערכת ה – SIEM הגדרת SU01 למשתמשים.
  • טרנזקציות המאפשרות עדכון נתונים בטבלאות בייצור. בניגוד לבסיסי נתונים SQL כגון Oracle, MS-SQL, בעולם ה – SAP ניתן לגשת לנתונים ישירות לטבלאות (קצת כמו אקסל). טרנזקציה SE16, ונוספות, מאפשרות גישה כזו. זה סיכון שאסור לאפשר (למעט מקרי חירום) וחייבים לחסום אותו.
  • הרשאות המפרות את עיקרון הפרדת הרשויות (Segregation of Duties). ארגון לא אחראי יאפשר בשמחה לעובד אחד גם להקים ספק, גם ליצור דרישת תשלום לאותו ספק, ולבסוף לסגור את הספק במערכת. נשמע מעולה, לא?
  • ממשקים אל ומהמערכת שאינם מאובטחים. כמו כל מערכת אחרת, האם הממשקים מוגבלים בהרשאות גישה? האם מידע רגיש (למשל, כרטיסי אשראי) עובר באופן מוצפן?
  • כתיבת קוד מעבר לקיים בחבילת הבסיס (למשל ABAP ב – SAP) שחושף את המערכת לפרצות אבטחה.
  • התקנת טלאי אבטחה לתשתית המערכת.

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

31
מאי
13

למה צריך NAC?

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

למרות שכיום התופעה הזאת פחות נפוצה כיוון שאנשי מכירות יכולים להתחבר לרשת דרך הסלולר, עדיין יש צורך בכלי בקרת גישה לרשת.
מזה שנים רבות קיים תקן IETF לבקרת חיבור מחשבים לרשת – תקן 802.1x. לתקן ישנה הרחבה (EAP) המאפשרת זיהוי מחשב לא רק עפ"י כתובת MAC, אלא גם על סמך תעודות דיגיטליות באופן המקשה מאוד על עקיפת הפתרון ע"י זיוף כתובת MAC.
החסרון של פתרון זה שהוא מתאים רק לרכיבי מחשוב המסוגלים לשמור תעודות דיגיטליות. כמו כן, מבחינת שרידות הפתרון אינו מאוד יציב ומידי פעם נוצרות תקלות המשביתות משתמשים.

למרות שפתרון (Network Access Control  (NAC נחשב פחות חזק מפתרון EAP, הוא מספק, כאמור, פתרון להתקנים שונים (כגון מדפסות, בקרי כניסה) שפתרון EAP לא תומך בהם. מוצרי NAC מתקדמים מספקים כיום הגנה בפני מספר סיכונים:

  • התחברות לא מורשית של אורח לרשת החברה
  • חיבור מחשב ארגוני (או מחשב אורח מורשה לחיבור) לרשת כאשר המחשב אינו עומד במדיניות האבטחה ומסכן את הרשת (כגון אנטי וירוס לא מותקן)
  • חיבור מחשב מורשה כאשר התקנים מסוימים פתוחים (כגון USB או WiFi)
  • שליחת התראות (ל – SIEM או במייל) כאשר מחשב שאינו מורשה מחובר לרשת

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

01
ספט
12

מתי לא לסמוך על דוחות אבטחה של המערכת עצמה?

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

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

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

כיצד מתמודדים עם הבעיה? כיום ישנם כלי Compliance המאפשרים סריקת המחשבים ברשת בלי להסתמך על סוכנים. כלים כאלה סורקים לרוב ע"י WMI ופרוטוקול SSH. בעזרת כלים כאלה ניתן ליצור דוח המציג את כל התחנות ללא סוכן של מערכת הטלאת Patches, סוכן AV או של DLP. סריקה שבועית של כל הרשת תאפשר להציף תחנות לא מאובטחות שיועברו לטיפול מנהל הרשת. ברשתות מתקדמות, ניתן לחבר כלים אלה למערכות SIEM, למשל ע"י Syslog, וליצור חוקי התרעה על תחנות שאינן עומדות בדרישות.

27
יונ
11

האפקטיביות של בקרות מפצות

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

בואו נתחיל מההתחלה. מה זו בקרה מפצה אתם שואלים? ראשית, נבחן מהו מנגנון מניעה. נאמר שרוצים למנוע גישה לשרתים ברשת מסוימת. מגדירים חוק Drop ב – Firewall ואף אחד לא מגיע לשרתים. זהו מנגנון מניעה.
מה קורה אם בין המשתמש לשרתים אין Firewall? אנחנו בבעיה. אפשר להגדיר לוג על השרתים שידווח למערכת SIEM על כל ניסיון התחברות לאותם שרתים. זה בקרה מפצה –  אמצעי לבדוק בדיעבד (בין אם דקה לאחור ובין אם בעיון בדוח מלפני חודש) האם בוצעה עבירה על הנהלים.

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

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

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

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

26
אפר
11

האתגרים (שלא מודעים להם) בהטמעת מערכת מניעת זליגה DLP

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

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

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

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

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

כדי לכסות טוב יותר את ערוצי זליגת המידע, כדאי לשלוח התראות בקטגוריות מסוימות ממערכת DLP למערכת SIEM. במערכת SIEM ישנה אפשרות לסנן באופן עמוק יותר אירועים ולהציף לטיפול רק כאלה שעוברים סף (Threshold) מסוים. למשל, ע"י קישור ל – LDAP, רק אירועים מעובדים שאינם חברים בקבוצה מסוימת ששלחו תוכן בקטגוריה של משאבי אנוש, יוצפו בממשק ה – SOC לטיפול. כך ניתן להקטין את כמות ההתראות המטופלות ולטפל ביותר קריטיים.

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

13
פבר
11

SIEM – יצירת ערך מוסף

הצגתי כאן בעבר את השימוש העיקרי במערכת SIEM; ניהול אירועי אבטחת מידע. מחברים את המערכת למקורות מידע (לוגים והתראות) של אפליקציות ומערכות תשתית ומקפיצים אירועים חשודים לבירור של אנשי SOC.

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

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

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

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

דוחות לבקרות SOX: אפשר להגדיר דוח המציג פעילות 'בנתיב הכספים'. את העובדים שהקימו ישות כספית במערכת הכספים וגם ביצעו פקודות תשלום לספקים. עובדים מאגף IT שהתחברו למערכות ייצור ועוד.

דוחות ל – PCI: משתמשים שהתחברו לשרתים עם יוזר אדמין.

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

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

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




יולי 2018
א ב ג ד ה ו ש
« מאי    
1234567
891011121314
15161718192021
22232425262728
293031  
מודעות פרסומת