אז יש לכם "אח גדול" בחברה?
מבוא
מערכות המידע בחברה מהוות תשתית קריטית להמשך פעילותו של הארגון ותשתית הכרחית לאספקת שירותים. לכן חברות נדרשות לפעולות פרואקטיביות למימוש מערכי הגנה מתאימים אל מול איומי סייבר ואבטחת מידע.
שרתים, ציוד קצה, ציוד רשת, מערכות מחשוביות ועוד, כל אלה יוצרים רישום (לוג) לגבי פעולות שונות שהתרחשו. רישום בודד בדרך כלל לא מועיל וחסר משמעות, ורק החיבור למערכות המתאימות יניב תמונה מלאה ויסייע להתריע על אירועי אבטחת מידע שמתרחשים בחברה. לשם כך החברה נדרשת לרכוש מערכות SIEM (Security Information and Event Management) המשמשות לניהול אירועי אבטחת מידע. המערכת מקבלת נתונים ממערכות ארגוניות שונות, מנתחת אותם ומאפשרת בקרה על תהליכים ואירועים, הפקת דוחות, זיהוי פרצות אבטחה, ותגובה למתקפות המתרחשות בזמנים שונים (וקרוב לזמן אמת ככל הניתן).
על מנת לתת מענה לכל האינפורמציה שמגיעה למערך ה-SIEM, נדרש מערך עם יכולות אנליטיות. מערך זה כולל כוח אדם וכלים מתאימים לאיסוף החיוויים, ניתוחם ומימוש פעילות מיטיגציה בהתאם.
במאמר זה אפרט צעדים מהותיים שעל מערך הביקורת הפנימית לבצע כדי לבחון אם מערכי ה- SIEM/SOCהקיימים בארגון הם אפקטיביים ומסוגלים לספק מענה הולם, הן באיתור מוקדם של ניסיונות אירוע אבטחת מידע/סייבר מהותי והן בהתממשות בפועל של אירוע מסוג זה. שאלה בסיסית שנשאל היא האם בארגון שלנו יש "אח גדול" שרואה מה מתרחש, רושם, ומתריע בפני צוות ה- SOC (Security Operation Center)?
רקע
SIEM הוא כלי לאיסוף מידע וניתוח, ו-SOC הוא כוח האדם המטפל במידע שהתקבל. מרכז בקרה (SIEM/SOC) יכול לפעול במספר תצורות:
- פנימי באופן מלא
הן מערך ה-SIEM (ממוחשב) והן ה-SOC (מערך כוח אדם) הם בבעלות החברה ומתופעלות על ידה באופן מלא.
- חיצוני באופן חלקי
מערך ה-SIEM הוא של חברה חיצונית ומתופעל על ידה, ואילו ה-SOC הוא פנים ארגוני.
- חיצוני באופן מלא
כל המערך מועבר לידיים חיצוניות והפעילות היא במתכונת של Outsourcing מלא, בין אם הגוף מספק השירות יושב מקומית או חיצונית.
חברות שעדיין לא נמצאות בעולם ה-SIEM/SOC מסתכנות בשדה ראייה חסום, ויש שיגידו אף בעיוורון (חלקי או מלא), שכן הן אינן רואות פעילויות חשודות ואנומליות המתרחשות במערכות החברה. מטרת מרכז בקרה כזה היא לאתר ברמת דיוק גבוהה אירועים חריגים, לנתח אותם, ולקבוע אם קיים צורך בטיפול מיידי או שההתראה אינה משמעותית וניתנת לטיפול בהמשך.
- מערכות משולבות במערך ה-SIEM
אחד השלבים הראשונים בשילוב מערכת SIEM בארגון הוא מיפוי המערכות וקביעת סף לשילוב מערכת. למשל, לקבוע כי כל המערכות שקיבלו ציון סיכון גבוה ישולבו. לעיתים לא מתבצע מיפוי כזה, ומערכות ששולבו למערך ה-SIEM הן מערכות התשתית הקיימות או מערכות אבטחת מידע המספקות חיווי אודות פעילות שהן מאתרות ולא מערכות מרכזיות בחברה (מערכות כספיות, תפעוליות וכו'). משמעות הדברים היא שהחברה לא מודעת למתרחש במערכות מרכזיות ולאירועי אבטחת מידע באופן מקיף.
- מעורבות מנהל סיכונים בתהליך
על מנהל הסיכונים להנחות את מנהל אבטחת המידע לגבי המקומות שהוא מבקש שינוטרו כחלק מתהליך ניהול הסיכונים במסגרת מערך ה-SIEM. הניסיון מראה כי לפעמים מנהל הסיכונים של החברה כלל אינו מעורב בהגדרות המערך, לא אפיין צרכים לטובת ניהול הסיכונים, ולא קיבל משוב לגבי סוג המידע שמוגן או לא מוגן במסגרת המערך.
- מיפוי התרעות
מערך ה-SIEM מקבל מאות התרעות ביום וחשוב לבחון את רשימת החוקים שבגינם מתקבלות התראות: האם מדובר בחוקים כלליים שלא עברו התאמה לחברה, כמה חוקים הותאמו והאם יש חוקים ייעודיים.
חלק חשוב בבדיקה זו היא להבין האם החוקים מטויבים על בסיס קבוע ובמסגרת זמן/אירוע ברורים. ככל שהחוקים אינם מטויבים היטב, כך יכולת הצוות (SOC) לתת מענה הולם ומהיר יורד. לדעת מומחים יש קשר ישיר בין טיוב החוקים ב-SIEM לאיכות הצוות (SOC) המטפל בחוקים/התרעות.
- טיפול באירוע אבטחת מידע
שאלה מרכזית שעל החברה לשאול היא איך הצוות מטפל באירועי אבטחת מידע לאחר קבלת התרעות. לכל סוג התרעה מוגדר סיווג של התרעה (גבוה, בינוני ונמוך). התראה ברמת גבוה משקפת אירוע אבטחת מידע המצריך טיפול מיידי, ועל החברה לבחון את עצמה כמה זמן לקח לה לטפל באירוע כזה – שעות בודדות, ימים, שבועות – או שמא ההתראות ברמה גבוה בכלל לא קיבלו מענה.
- 24/7
אירועי סייבר מתרחשים בעולם בכל שעות היממה, ולעיתים במיוחד בשעות שבהן לא קיימת פעילות עסקית ופעילות בקרה בשל היכולת לחמוק "מתחת לרדאר". כאן נבחן האם לארגון יש מענה הולם בשעות לא שגרתיות ומי ייתן מענה אם תתקבל התרעה בשתיים בלילה; האם הוגדרו כוננים מעבר לשעות העבודה, והאם מדובר באדם בודד או בקבוצת אנשים. לעיתים התרעה אחת יכולה להשפיע על מספר תחומים (תשתיות, בסיס נתונים, אבטחת מידע ועוד) ולא רק על גורם אחד. לכן נבדוק האם לגורמים שאמורים לתת מענה במניעת או עצירת נזקים מאירועי אבטחת מידע יש יכולת להתחבר לחברה מרחוק או להגיע בזמן קצר לחברה.
- מבדק חדירה מול מערך ה-SIEM
העובדה שחברה טייבה את החוקים עדיין לא אומרת שהטיוב בוצע בצורה תקינה ומתאימה. על מנת לבחון את הקמת ה-SIEM, נהוג ומקובל לבצע מבדק חדירה אל מול המערך במטרה לבחון את יעילותו. ישנן חברות שלא מבצעות מבדק מסוג זה, והמשמעות היא שחברות אלו יתקשו לקבוע כי המערך מסוגל לאתר ולהתריע באופן יעיל אודות מתקפות פנימיות או חיצוניות.
- התראות אודות פעילות עסקית חריגה
מומלץ לבחון האם החוקים ששולבו ב-SIEM הם בעלי אופי טכנולוגי במהותם או ששולבו חוקים בעלי אופי עסקי. ברור לכולנו כי פעילות תקיפה יכולה לבוא לידי ביטוי גם בפן העסקי ולא בהכרח בפן הטכנולוגי. לדוגמה, מימוש תקיפה שמשמעותה מתן פקודה להעברת תשלומים בחצות הלילה כשהחברה לא עובדת בשעות האלו, שינוי מספרי חשבון של ספקים, וכדומה. במצב שבו לא קיימת בקרה ברמת ה-SIEM אודות תקיפות סייבר שמתבטאות בפעילות עסקית, רק חלק מתמונת המצב משוקפת לצוות הבקרה. לכן לא מן הנמנע שתקיפות הפעילות העסקית עלולות לעבור מתחת לרדאר של אנשי אבטחת המידע ובוודאי של גורמים עסקיים.
- יכולת מערך ה-SIEM לזהות תקיפה בתהליך
תקיפת רשת היא תהליך מובנה ברוב המקרים, הכולל ביצוע שלבים המוכרים לכל תוקף ונלמדים במסגרת CEH [Certified Ethical Hacker (הסמכת האקרים)]. הסמכה זו מקבילה לפעולות שיבצע האקר ב"עולם האמיתי" ולכן קיימת חשיבות לכך שחוקים שמטרתם לאתר תוקף ישקפו תהליך תקיפה מקובל. פעולות אלה יכולות לכלול (בתקיפה מתוך הסביבה הפיזית) לדוגמה:
- הורדה והעלאה מרובה של מחשב הקצה.
- עצירת שירותים של יישומי הגנה ובכללם אנטי וירוס.
- ניסיון התקנת יישומים חריגים.
על המבקר לבחון האם החוקים שהוגדרו, הותאמו לכל הפחות לתהליך תקיפה "מקובל", והאם החברה תצליח לאתר תוקף.
- לסיכום
שילובו של מערך SIEM הוא תהליך מורכב וממושך המחייב תכנון סדור של שלבי המהלך. ביקורת פנימית חייבת לבחון את הנושא לעומק על מנת לוודא כי קיימת יכולת איתור וטיפול באירועי אבטחת מידע וסייבר, החל משלב קבלת החיוויים ועד מתן מענה/תגובה למתקפות המתרחשות באופן הולם ומהיר. אז יש לכם "אח גדול" בחברה?
