KPI ניהוליים שבאמת משנים התנהגות: מעבר לציות בלבד

By Mirko Peters · 2026-08-11

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

Automatically translated with AI from the original post. Read the English original

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

הקדמה: מעבר לציות ולמדדי יוהרה

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

השכבה הנסתרת: מה Microsoft Defender באמת קולט

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

ראשית, התבוננו ב-Threat Explorer. זהו המקום שבו חושפים את הקשרים האמיתיים בין קמפיינים. הוא ממפה את תשתית השולחים, קבצים זדוניים, ועוקב אחר מי בדיוק עוד בארגון הותקף באותו גל. שנית, בחנו את תוצאות Automated Investigation and Response (AIR). AIR מספק פעולות מתואמות, היקפי מכשירים ותיבות דואר, ותובנות לגבי האופן שבו ספרי הפעולה הרקעיים פותרים איומים ללא התערבות אנושית. לבסוף, היעזרו ב-User Submissions. האות האנושי הוא אחד ממקורות הנתונים החשובים ביותר שיש לכם. דיווחי משתמשים מסמנים לעתים קרובות התקפות מתוחכמות שהסננים האוטומטיים החמיצו לגמרי. התעלמות מהגשות משתמשים פירושה התעלמות מחיישנים האנושיים בחזית שלכם.

למה לוחות מחוונים ניהוליים מסורתיים נשברים

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

יתרה מזאת, סחף סכמה (schema drift), כלומר שדות ששונו שמם או הוצאו משימוש, שובר דוחות עם קידוד קשיח באופן מיידי. GUIDs מעורבים מול שמות משתמש עיקריים (UPN), פערים בעימוד (pagination) של ה-API וצמצום קצב (throttling) ב-DirectQuery יוצרים כאב ראש אינסופי. כשתזמון הרענון נכשל בסוף השבוע, פגישות ההנהלה של יום שני מתחילות עם נתונים מיושנים ומטעים. אם הארכיטקטורה שלכם נשענת על פתרונות מאולתרים, היא תקרוס תחת משקל נפחי הנתונים הארגוניים בעולם האמיתי.

תכנון מסגרת עמידה: מהקונקטורים ועד למודלי הנתונים

בניית לוח מחוונים ששורד שינויי סכמה והתפתחות טקטיקות תקיפה דורשת מסגרת משמעתית בת ארבעה חלקים. ראשית, אתם זקוקים לקונקטורים אמינים. השתמשו ב-APIs של Defender עם רישומי אפליקציות תקינים, OAuth והרשאות ממוקדות (scoped), וודאו שאתם מיישמים עימוד מלא וחלונות השלמת נתונים (backfill) חזקים.

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

ניווט במלכודות של אינטגרציה עם Power BI

Power BI הוא כלי יוצא דופן להצגה חזותית של נתוני אבטחה של Microsoft 365, אבל מלכודות אינטגרציה רבות מסתתרות בדרך אם לא יודעים למה להיזהר. תדירות החלפת אישורי הגישה (authentication churn) עלולה לשבש את הרענונים המתוזמנים שלכם. החליפו תמיד את הסודות כראוי, והעדיפו זהויות מנוהלות (managed identities) בכל מקום אפשרי. כדי להתמודד ביעילות עם סחף סכמה (schema drift), גרסו את טרנספורמציות הנתונים שלכם ובנו טיפול מסודר בערכים לא ידועים או ריקים.

הפסיקו לערבב ייצואים ידניים עם משיכות API. ריכזו את צינור הקליטה שלכם בתוך dataflows של Power BI. בדקו את לוגיקת הפאג'ינג (pagination) שלכם בימים עמוסים במיוחד, כדי שלא תחמיצו רשומות כשנפח ההתקפות מזנק. לפערים ברענון, תזמנו משיכות תוך-יומיות והוסיפו טעינות דלתא (delta loads) שילכדו פעילות בסופי שבוע ובחגים. לשיפור הביצועים, שמרו על סכמת כוכב קפדנית, השתמשו ברענון incremental, בצעו מחיצות (partitioning) לפי תאריך, והימנעו לחלוטין מעמודות מחושבות כבדות ברמת השורה.

מדדי KPI למנהלים שבאמת מניעים התנהגות אבטחתית

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

• שיעור הצלחת התקיפה: אחוז ניסיונות הפישינג שעקפו את הבקרות הטכניות וגם הובילו לאינטראקציה של משתמשים.
• השוואת לחיצה מול דיווח של משתמשים: מבט השוואתי על מי לחץ על קישורים זדוניים מול מי דיווח עליהם, במעקב לאורך זמן כדי למדוד את בשלות המודעות לאבטחה.
• זמן שהייה עד לתיקון: משך הזמן המדויק מהזיהוי הראשוני ועד לבלימה מלאה, מפורט לפי וקטור התקיפה וסוג הקמפיין.
• חשיפה של ישויות בסיכון גבוה: תדירות הפניית מתקפות חוזרות כלפי אישים בכירים (VIP), צוותי כספים וחשבונות עם הרשאות מוגברות.
• שיעור הסלמה של כמעט-אירועים: מעקב אחר חסימות לאחר לחיצה, התערבויות של Safe Links והצלות טכניות ברגע האחרון שמנעו אסון.
• מגמת קמפיינים שבועית: מבט השוואתי שבועי שעוקב אחר שינוי בשיטות התוקפים, מעבר מקישורים לקבצים מצורפים או להונאות דוא"ל עסקי (BEC).
• יעילות אוטומציה: שיעור הפתרון בלולאה סגורה של AIR, מול תדירות העקיפות הידניות של צוות SecOps.

רמזים חזותיים: בניית פריסת דשבורד שמציגה חריגות בראש

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

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

הנחיות לשמירה על עמידות והצלחה לטווח ארוך

כדי שמערך הדיווח שלכם ישאר אמין ועמיד לאורך זמן, חובה לקבוע כללי הנדסה מחמירים. בצעו תמיד בקרת גרסאות ל-dataflows ולמדידות DAX. הוסיפו לצינורות הרענון שלכם בדיקות אוטומטיות לשינויי סכמה, כדי שתקבלו התראה לפני שהדוחות נשברים. תעדו כל הגדרת KPI בבירור: אין מקום לשינויים שקטים או להזזת יעדים בין רבעונים פיסקליים. לבסוף, הפעילו בכל המערכת גלאי "הפסקה" (blackout detector) שיתריע מיד אם נפח האירועים הצפוי יורד באופן בלתי צפוי, מצב שבדרך כלל מעיד על מחבר (connector) שבור ולא על ירידה פתאומית בפשיעת הסייבר העולמית.

דפוסים בעייתיים שיש לפסול מיד

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

תוכנית פריסה של 30 יום

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

• שבוע 1: הקימו גישת API, הגדירו זרימות נתונים (dataflows), בנו את לוגיקת הפגינציה והגדירו את מודל הכוכב הבסיסי שלכם.
• שבוע 2: טפלו בנרמול, מפו מזהי ישויות מ-GUID ל-UPN, וחשבו את קבוצת מדדי ההתנהגות האמיתיים הראשונה שלכם.
• שבוע 3: בנו את עמוד המנהלים ותצוגת התפעול של ה-SOC, יישמו כללי זיהוי חריגות והגדירו רענונים מצטברים (incremental refresh).
• שבוע 4: בצעו בדיקה retroactive של המודל החדש מול הרבעון הקודם, בנו עמודי drill-through וכתבו את ספר ההפעלה התפעולי שלכם.

סיכום

המעבר מתיבות סימון מונחות ציות למדדי אבטחה מבוססי התנהגות הוא הדרך הטובה ביותר לשדרג את הבשלות של תוכנית ההגנה הסייברית שלכם. בעזרת הטלמטריה העמוקה שמסתתרת ב-Microsoft Defender, הימנעות ממלכודות שילוב נפוצות עם Power BI והתמקדות במדדי KPI מעשיים כמו זמן שהייה (dwell time), חשיפה של ישויות בסיכון גבוה ושיעורי הצלחה אמיתיים של מתקפות, תוכלו להפוך את הדשבורדים שלכם ממסכי תצוגה פסיביים למנועי קבלת החלטות פעילים. אם תרצו להעמיק בבניית דוחות פישינג עמידים ובשליטה בטלמטריה הזו, כדאי לצפות בפרק הקשור Build Better Phishing Reports with Defender and Power BI. המשיכו לבנות חכם יותר, הישארו מאובטחים, ונתראה בפרק הבא!