בחרו אות לפי התהליך שהעסק צריך
מפו מה העסק רוצה לדעת: האם מבקר מגיע לאתר, האם ניתן להשלים פעולה, האם גיבוי נכשל והאם ניהול השתנה. קוד HTTP תקין בדף הבית אינו מוכיח שכל התהליכים תקינים. לכל בדיקה צריך לדעת איזה נתיב היא עוברת ומה נמצא מחוץ לכיסוי.
Cloudflare מתעדת למשל monitors עם פרוטוקול ותנאי הצלחה מוגדרים. זו המחשה לכך שהבדיקה קובעת מה פירוש בריא באותו מנגנון, ולא הבטחה שכל מסלול המשתמש נבדק. המוצר הוא דוגמה טכנית בלבד; יכולות והיקף תלויים בתצורה ובשירות.
לכל התראה כתבו פעולה אפשרית
הטבלה היא מסגרת עבודה מקורית. היא אינה דרישה לנטר כל אירוע בכל אתר. בוחרים לפי נכסים וסיכון ובלי להכניס נתונים רגישים להודעות. אם אין פעולה מוסכמת, צריך לברר למה נאסף האות ומי אמור להשתמש בו.
| אות לדוגמה | מה הוא עשוי לומר | פעולה שצריך להגדיר |
|---|---|---|
| כשל זמינות | נתיב בדיקה אינו זמין | אימות והבחנה מתקלה מקומית |
| כשל תהליך | טופס או חיבור לא הושלם | בדיקת רכיב ויעד מאושר |
| גיבוי נכשל | נקודה מתוכננת לא נוצרה | בירור כיסוי ותיקון משימה |
| שינוי ניהול | אירוע גישה או הרשאה | השוואה לאישור ובירור חריגה |
| שגיאות יישום חוזרות | כשל בתלות או ברכיב | הקשר זמן ושינוי אחרון |
| הפסקת דיווח | ייתכן שהמנטר עצמו לא פועל | בדיקת שרשרת איסוף ומשלוח |
רעש לא נפתר בהשתקת כל ההתראות
OWASP ממליץ להתאים רישום וניטור לסיכון ומזהיר מהצפת התראות שמקשה לזהות בעיות. הגדירו הקשר, חזרתיות והבחנה משינוי מתוכנן. ניסיון כניסה שנכשל אינו כשלעצמו הוכחה להשתלטות. כמות גדולה של אירועים אינה מדד ישיר למספר אירועים עסקיים.
לפני שינוי סף בדקו מה נחשב רגיל ומה עלול להיעלם. תעדו איחוד הודעות וחריגות, וקבעו מתי מחזירים מצב רגיל אחרי תחזוקה. אין צורך לשמור גוף הודעות, סיסמאות או מידע לקוחות בתוך התראה כדי לאפשר טיפול ראשוני.
בדקו את השרשרת עד לנמען ולמטפל
בדיקת ניטור כוללת יצירת תנאי ניסיון מתאים, רישום, משלוח, קבלה ופתיחת טיפול. אפשר לתכנן סימולציה או בדיקה בסביבת ניסיון לפי המוצר. אין צורך להפיל אתר חי, למחוק גיבוי או לבצע פעולה חשודה בחשבון לקוח כדי להראות שהמסלול עובד.
ודאו שהנמען אינו עובד שעזב ושקיים מחליף לפי השעות שהוסכמו. הפרידו זמינות של כלי מניטור אנושי ומזמן התחלת עבודה. מערכת שאוספת מידע ברציפות אינה הוכחה שמישהו בוחן ומגיב בכל שעה. כיסוי כזה דורש שירות והתחייבות מפורשים.
דוגמה: דף הבית זמין אך החיבור העסקי נכשל
התרחיש להמחשה בלבד. בדיקת זמינות ממשיכה להיות ירוקה לאחר שינוי, אבל חיבור לטיפול בפניות מחזיר שגיאה. ניטור שמוגדר רק לדף הבית אינו מכסה את הכשל. הצוות מגדיר בדיקת תהליך מותרת, עם נתוני ניסיון ובלי יצירת פניות ללקוחות.
התגובה כוללת זיהוי רכיב, אישור שינוי ובדיקת סיום, ולא רק סגירת ההודעה. אם אין מספיק מידע, מתעדים פער ואחראי לבירור. תוצאת ניסיון בתנאים מסוימים אינה מדידת זמינות שנתית או התחייבות לזמן פתרון בכל תקלה.
סגרו התראה עם ראיה ועדכנו את ההגדרה
רשומת סגירה מתארת מה נצפה, מה נעשה ואיך אומת חידוש התפקוד. אם זו התרעת שווא, כתבו מדוע ואיזה שינוי בהגדרה אושר. שינוי בעלים, כלי או כתובת דיווח מחייב בדיקה חוזרת של שרשרת המסירה. גם המידע שנאסף צריך הרשאות ותקופת שמירה מתאימות.
ב-CyberFixCrew אפשר לברר בדיקת כיסוי תפעולי וניטור במסגרת השירותים והתחזוקה הקיימים. היקף, שעות ואחריות נקבעים מראש. אין במדריך הצעה חדשה לשירות SOC או למענה רציף, ואין להסיק שהגדרות ניטור כבר הופעלו באתר של העסק.
