הרשת הסבוכה של אסטרטגיות IR

הרשת הסבוכה של אסטרטגיות IR

צומת המקור: 2599231

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

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

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

מסבך את סביבת ה-IR הנוכחית היא העובדה שנופי האיומים הארגוניים נעשו מורכבים יותר באופן אקספוננציאלי בשנים האחרונות, במיוחד במונחים של היותם נקבוביים כמו גם מתן לרעים הרבה יותר מקומות להסתתר. מעבר למערכות ה-WAN והחברה, יש את המערכות המקומיות המצטמקות - אך עדיין רלוונטיות - מספר רב של סביבות ענן (גם ידוע וגם לא ידוע), IoT/IIoT, שותפים עם גישה הרבה יותר גדולה, משרדים ביתיים עם רשתות LAN לא מאובטחות, ציי רכב עם שמירת נתונים וכתובות IP משלהם, מכשירים ניידים עם אישורים מלאים (לעתים קרובות בבעלות עובדים, מה שמעורר חששות אבטחה נוספים) , ואפליקציות SaaS שמתארחות במערכות עם חורים לא ידועים משלהן.

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

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

בדוק את המפה

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

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

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

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

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

הממד האנכי

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

עבור נתונים תעשייתיים/אנכיים, זה אומר שילוב מרכזי שיתוף וניתוח מידע (ISACs) יחד עם התראות קוד פתוח, הודעות ספקים, סוכנות הסייבר לאבטחת תשתיות (CISA) ו-(מסד הפגיעות הלאומי (NVD) ועוד רבים אחרים, שיר עם נתוני SIEM פנימיים.

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

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

האם לצוות SOC יש גישה לכל סביבות הענן? האם הם רשומים כאנשי קשר לכל צוות התמיכה ב-colocation ובענן?

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

בול זמן:

עוד מ קריאה אפלה