לקבוע זמן עד גילוי לכל דלת שפתחתם

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

כל דלת שדרכה יוצאים נתונים צריכה זמן עד גילוי

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

השבועות האחרונים מראים מה המחיר של היעדרו. בדנמרק, המשרד האחראי על מרשם ה-CPR מסר ב-5 באוקטובר 2026 שגורמים לא מורשים הגיעו לשמות, לכתובות ולמספרי CPR של כ-8.8 מיליון רשומים "באמצעות שימוש לרעה בגישה החוקית של חברה דנית לחיפוש מידע במערכת ה-CPR" (התרגום שלנו). Datatilsynet, הרשות הדנית להגנת מידע, מסרה שהמספרים נשלפו לכאורה באמצעות שאילתות אוטומטיות, ו-Ritzau מדווחת על עמדת השר, שלפיה האבטחה סביב הגישה של אותה חברה לא הייתה טובה מספיק. בארצות הברית, פגם במערכת שיתוף קבצים של Defense Manpower Data Center הותיר קבצים נגישים במשך כתשעה חודשים עד שהתגלה, ומספר קטן של משתמשים לא מורשים ניגשו אליהם, כך מדווח SecurityWeek. ב-Shinhan Bank, גורם חיצוני עקף את האימות הרגיל של שירות חיפוש שנבנה עבור מתווכי הלוואות, ו-Herald Corporation מדווחת שהרשומות נשלפו באמצעות הזנה חוזרת של ערכי שאילתה משתנים. אף בקשה בודדת לא הייתה צריכה להיראות חריגה; הדפוס היה בחזרתיות.

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

ה-SIEM שלכם רואה את האירועים; רק הבעלים יכול לשפוט אותם

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

שימוש לרעה בגישה חוקית נראה כמו פעילות עסקית רגילה. שותף שמושך כמויות גדולות בסוף רבעון הוא עניין רגיל; אותו שותף שמושך נתונים בקצב קבוע במשך עשרה ימים בחודש שגרתי אולי לא. NIST Cybersecurity Framework 2.0 מצפה לשני החצאים: ניטור הפעילות של אנשי הצוות (DE.CM-03) וניטור הפעילות של ספקי שירות חיצוניים (DE.CM-06).

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

להפעיל שלושה שעונים, לא אחד

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

• זמן אמת, למכונות. ה-SIEM מתריע על מה שנראה עוין בכל מה שנרשם אצלכם ביומנים.
• יומי או שבועי, לשאלה אחת. מנהל Kiteworks שואל את Activity Explorer בכל פעם את אותה שאלה מצרפית: מה השתנה לעומת התקופה הקודמת, ואילו סימונים הופעלו? הסימונים הם כללים פשוטים, לא ציונים: נפח יומי של קטגוריה שגבוה פי שלושה מהחציון שלה בתקופה, עשרה כשלים או יותר של חשבון אחד בתוך שעה, יותר מ-100 הורדות של חשבון אחד ביום (ניתן לשינוי), ופעילות מחוץ לשעות העבודה שהגדרתם. מכיוון שהשאלה הזו לא מזכירה אף אדם בשמו, זו השאלה שאפשר להריץ לפי לוח זמנים קבוע, למשל בעזרת המשימות המתוזמנות של Claude. קודם צריך להחליט על שלושה דברים: איזה חשבון מנהל Kiteworks משמש להרצה ומי אישר את הגישה הקבועה הזו, לאן התשובה מגיעה ומי קורא אותה, והאם מחבר ה-Kiteworks שלכם נגיש מהרצה מתוזמנת בסביבה שלכם. לבדוק את זה לפני שסומכים על זה.
• חודשי או רבעוני, לבעלים. הבעלים קורא דוח שמור שמכסה כל תקופה של עד 12 חודשים, בחלונות של 30 יום, בהשוואה לתקופה הקודמת. הדוח מציין עד כמה אחורה היומן הגיע בפועל. User Account Reviewer מוסיף חשבונות רדומים, נעולים וחיצוניים, ו-Sharing Auditor מראה איפה שיתוף ברמת התיקייה פותח גישה מלכתחילה.

ספים יומיים מפספסים שימוש נמוך ואיטי מעצם תכנונם: שותף שנשאר מתחת ל-100 הורדות ביום במשך חודש לא מפעיל אף כלל יומי. השוואה בין תקופות מצמצמת את המקום שבו כדאי לחפש, כי Activity Explorer מציג את השינוי לפי אפליקציה, לפי קטגוריית פעילות ובשיעור המשתמשים החיצוניים. מעקב אחרי המגמה של חשבון אחד הוא שאלה ברמת האדם, ומקומה בתיק או ב-SIEM שלכם, לא בדוח השגרתי.

לספור סוכני AI כאוכלוסייה נפרדת

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

תיעוד הסקירה הוא הראיה שלכם

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

קודם דפוסים, אחר כך אנשים. Activity Explorer מתחיל מנתונים מצרפיים, אף פעם לא מציג כתובות IP או מיקומים, פותח תצוגה ברמת האדם רק עם מספר תיק, ומבקש אישור לפני שדוח שמור נוקב בשמו של מישהו. זה מכסה כלי אחד, לא את התוכנית שלכם: אותה פעילות ב-SIEM שלכם כוללת שמות חשבונות וכתובות IP. לפני ההרצה הראשונה, יש להגיע להסכמה עם הממונה על הגנת הפרטיות (DPO) ועם ועד העובדים, אם יש כזה, על הבסיס המשפטי ועל DPIA לכל הסקירה, כולל ההזנה ל-SIEM; על שימוש בנתוני הסקירה לצורכי אבטחה ולעולם לא להערכת ביצועים; על האופן שבו מיידעים את העובדים; ועל משך השמירה של רשומות שמזכירות מישהו בשמו.

חמש שאלות לקביעת זמן עד גילוי משלכם:

1. אילו ערוצים יכולים להוציא נתונים רגישים, ומי הבעלים של כל אחד מהם?
2. לכל ערוץ: כמה זמן שימוש לרעה יכול להימשך לפני שהבעלים שלו ידע, והאם זה מקובל?
3. אילו ערוצים מזינים את ה-SIEM שלכם, ובאילו אף אחד לא קורא?
4. איזו שאלה אחת כל בעלים רוצה לקבל עליה תשובה בכל שבוע, והאם היא מתוזמנת?
5. מי אישר את הסקירה האחרונה, באיזה תאריך, ומה הוחלט?

המספר הראשון שתקבעו יהיה שגוי. היעדרו גרוע יותר. כדי לחשב איתנו זמן עד גילוי לערוצי ה-Kiteworks שלכם, אפשר לכתוב אל sales@kiteworks.com או לפתוח בשיחה. לא צריך Claude או הגדרת MCP כדי לשאול. לחצי של השאלה שנוגע להרשאות, ראו לבדוק לאן הספקים שלכם עדיין יכולים להגיע.