ידע מעשי של CyberFixCrew

מה לבדוק ביומני האתר אחרי התראה ואיך שומרים ראיות

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

תעדו את ההתראה ואת השאלה שרוצים לברר

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

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

בחרו מקורות לפי מסלול הפעולה

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

מה כל מקור יכול לעזור לברר
מקורשאלת בדיקה אפשריתמגבלה שחייבים לציין
CDN או WAFהאם בקשה הגיעה לשכבת ההגנה ומה הוחלטלא בהכרח מכסה גישה ישירה למקור
שרת אינטרנטאיזו בקשה טופלה ובאיזה מצב HTTPקוד מצב לבדו אינו תוצאת פעולה עסקית
יישום או מערכת ניהולאיזה שינוי או כשל תועדתלוי באירועים שהיישום רושם
ספק זהותאיזה חשבון התחבר או שינה הגדרההתחברות אינה הוכחת כוונה מורשית
פריסה או קבציםהאם שינוי תואם לעדכון מאושרחותמת זמן לבדה אינה מסבירה מקור שינוי

חברו זמנים ומזהים לפני הסקת רצף

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

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

ASD ACSC ושותפים: איכות לוגים, זמנים ושמירה

שמרו עותק מתאים, בלי להרחיב איסוף מידע רגיש

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

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

OWASP: תכנון לוגים ומידע שאין לרשום

דוגמה: WAF חסם בקשה, אבל השאלה נוגעת להזמנה

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

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

סיימו עם ממצא, מגבלה והמשך טיפול

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

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

מקור מקצועי: ASD ACSC ושותפים: איכות לוגים, זמנים ושמירהמקור מקצועי: OWASP: תכנון לוגים ומידע שאין לרשוםמקור מקצועי: NIST SP 800-61r3: הכנה, תגובה ולמידה מאירועים

תשובות ברורות

שאלות שעולות בנושא

שגיאת 404 היא הוכחה שמישהו פרץ?

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

אין אירוע בלוג. אפשר לסגור?

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

אפשר לשלוח לכם את כל הלוגים בטופס?

התחילו בתיאור ההתראה, הזמן והמערכת, ללא סודות או מידע לקוחות. אם נדרש קובץ, מתאמים ערוץ, היקף והרשאות מסירה.

מתקדמים לפי הצורך

יש התראה ולא ברור מה היא מוכיחה?

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

לתיאום בדיקה וטיפול