یک پرسش زمانی برای پرونده رخداد
کاربری می‌گوید بعد از باز کردن یک پیوست، مرورگرش صفحه ورود دیگری نشان داده است. سامانه هویت از ورود موفقی در همان روز خبر می‌دهد و گزارش میزبان نیز اجرای فرایندی ناشناخته را ثبت کرده است. برای تحلیل باید ترتیب رخدادها، منبع هر زمان و فاصله میان آن‌ها روشن شود. Timesketch ابزاری برای بررسی مشترک خط‌های زمانی است. تحلیلگران می‌توانند داده چند منبع را در یک پرونده کنار هم ببینند، جست‌وجو را ذخیره کنند، روی رویدادها توضیح بنویسند و روایتی بسازند که به شواهد قابل بازیابی اشاره دارد.
نقطه آغاز یک پرسش قابل پاسخ است. در این مثال می‌خواهیم بدانیم نخستین نشانه اجرای فایل چه زمانی ثبت شده و آیا ورود حساب پس از آن رخ داده است. پرسش «همه فعالیت مشکوک کاربر را پیدا کن» دامنه مبهمی دارد و ممکن است تحلیل را به مرور بی‌پایان داده بکشاند. بازه اولیه، منابع موجود و فرض‌های زمان را بنویسید. اگر گزارش هویت فقط با دقت دقیقه ثبت شده و گزارش میزبان تا میلی‌ثانیه دقیق است، این تفاوت را همان ابتدای پرونده ثبت کنید. مرتب‌سازی ظاهری نباید دقتی بیش از داده اصلی القا کند.
ساخت پرونده و جدا نگه‌داشتن منابع
در معماری کاری Timesketch، یک Sketch معمولاً پرونده بررسی را نمایندگی می‌کند و می‌تواند چند خط زمانی و چند نمای جست‌وجو داشته باشد. برای نمونه یک خط زمانی از رخدادهای میزبان، یکی از گزارش مرورگر و دیگری از سامانه هویت بسازید. نام هر خط باید منبع، دستگاه یا حساب مرتبط و بازه گردآوری را روشن کند. اگر سه فایل با نام‌های «خروجی نهایی» و «گزارش جدید» وارد شوند، مقایسه نتیجه و بازبینی مستقل دشوار می‌شود. نگه داشتن منشأ کنار هر داده از آغاز هزینه تحلیل بعدی را کم می‌کند.
نسخه اصلی شواهد را خارج از محیط تحلیل با روش نگه‌داری مناسب حفظ کنید. فایل تبدیل‌شده برای ورود به Timesketch نسخه کاری است و ممکن است تنها بخشی از فیلدهای منبع را داشته باشد. ثبت کنید چه کسی تبدیل را انجام داده، چه فیلدهایی حذف شده و زمان چه تغییری کرده است. اگر بعداً تحلیلگر درباره یک رویداد سؤال داشت، باید بتواند به رکورد اولیه برگردد. یک جدول زمانی مرتب ارزش عملی دارد، ولی جای فایل اصلی و اطلاعات اعتبارسنجی آن را نمی‌گیرد. این تمایز در پرونده‌هایی که احتمال بازبینی بیرونی دارند اهمیت بیشتری پیدا می‌کند.
آماده‌کردن داده برای ورود
راهنمای رسمی ورود داده، نمونه قالب جدولی و JSON خط‌به‌خط را ارائه می‌دهد. در این مسیر باید توضیح رخداد، تاریخ و زمان و معنای زمان مشخص باشد. فیلدهای اضافی می‌توانند نام میزبان، حساب، فرایند یا شناسه رکورد را نگه دارند. پیش از تبدیل هزاران سطر، چند نمونه نماینده بسازید و آن‌ها را در پرونده آزمایشی وارد کنید. ببینید متن پیام خوانا است، منطقه زمانی درست نمایش داده می‌شود و ستون اصلی برای جست‌وجو باقی مانده است. اصلاح نگاشت روی نمونه کوچک بسیار آسان‌تر از پاک‌سازی یک واردسازی بزرگ است.
توصیف زمان باید عمل واقعی را بیان کند. «زمان نوشتن فایل» با «زمان رسیدن گزارش به گردآورنده» متفاوت است، حتی اگر هر دو در یک ستون تاریخ ذخیره شوند. در گزارش مرورگر، زمان بازدید و زمان ثبت در پایگاه محلی نیز ممکن است فرق داشته باشند. اگر همه را با عنوان مبهم «زمان رخداد» وارد کنید، روایت بعدی می‌تواند ترتیب نادرست بسازد. برای هر منبع یک مثال تحلیلی بنویسید که نشان دهد زمان به کدام عمل اشاره می‌کند و با چه عدم قطعیتی ثبت شده است. اطلاعات حدسی را صریح از زمان مشاهده‌شده جدا کنید.
برای تمرین می‌توان یک رویداد ساختگی را به صورت یک خط در فایل JSONL گذاشت. نام میزبان آزمایشی، زمان و معنای آن را هم‌زمان ثبت کنید. این سطر وقوع اجرای یک فرایند را گزارش می‌کند و اطلاعاتی درباره محتوای پیوست یا مجاز بودن فرایند نمی‌دهد.
{"message":"Process started: invoice-preview","datetime":"2026-10-12T09:15:30+00:00","timestamp_desc":"Process start","hostname":"lab-client-01"}
پس از ورود، رویداد را در زمان درج‌شده پیدا کنید و ستون نام میزبان را به نمای جست‌وجو اضافه کنید. سپس یک رویداد دوم از گردآورنده با زمان دریافت متفاوت بسازید و برای آن توضیح زمان متفاوت بگذارید. این دو سطر تمرینی کمک می‌کنند پیش از واردسازی پرونده بزرگ، تفاوت وقوع و دریافت را در رابط ببینید.
منطقه زمانی، دقت و ساعت دستگاه
یک پرونده ممکن است داده دستگاهی با ساعت محلی، سرویس ابری با زمان جهانی و فایلی بدون نشانه منطقه زمانی داشته باشد. قبل از ورود، قرارداد تبدیل را تعیین کنید. اگر منطقه زمانی از سند یا تنظیمات دستگاه معلوم است، آن را ثبت کنید. اگر معلوم نیست، چند فرض را در تحلیل نگه دارید و تبدیل قطعی انجام ندهید. جابه‌جایی یک ساعت می‌تواند ترتیب ظاهری ورود و اجرای فایل را برعکس کند. تبدیل یکنواخت به زمان جهانی برای مقایسه مفید است، به شرطی که مقدار اولیه و دلیل تبدیل همچنان قابل بازیابی باشند.
اختلاف ساعت دستگاه‌ها همیشه به اندازه یک منطقه زمانی کامل نیست. ممکن است میزبان چند دقیقه جلو باشد یا گردآورنده گزارش را با تأخیر بگیرد. از یک رخداد مشترک مانند درخواست شناخته‌شده آزمایشی یا ورود ثبت‌شده در دو سامانه برای برآورد اختلاف استفاده کنید. هم‌زمانی تقریبی دو رخداد، دلیل یکسان بودن آن‌ها نیست. شناسه درخواست، نام کاربر و میزبان می‌توانند شواهد تکمیلی بدهند. اگر فاصله زمانی از میزان عدم قطعیت کوچک‌تر است، در گزارش بنویسید ترتیب قطعی قابل تعیین نیست. این نتیجه از روایت دقیق ولی نادرست قابل دفاع‌تر است.
پیدا کردن رویداد لنگر
برای شروع جست‌وجو، رویدادی انتخاب کنید که هویت و زمان آن نسبتاً روشن است. در مثال پیوست، هش فایل یا نام فرایند همراه با شناسه میزبان می‌تواند لنگر باشد. جست‌وجوی تنها یک نام رایج ممکن است هزاران نتیجه بسازد. ابتدا خط زمانی و میزبان را محدود کنید، سپس چند دقیقه پیش و پس از رویداد را بررسی کنید. رخدادهای نزدیک را در زمینه فعالیت عادی همان دستگاه ببینید. اگر برنامه‌ای هر روز به شکل زمان‌بندی‌شده اجرا می‌شود، نزدیکی آن به رخداد مشکوک ممکن است صرفاً تصادف باشد.
در نمای بررسی، ستون‌های مرتبط با پرسش را اضافه کنید. مستندات پروژه توضیح می‌دهد ستون‌های موجود از داده خط زمانی می‌آیند. برای پرونده اجرای فرایند، نام میزبان، شناسه فرایند، فرایند والد و حساب کاربر می‌توانند از متن پیام به تنهایی مفیدتر باشند. اگر ستون مورد نیاز وجود ندارد، به تبدیل منبع و فهرست فیلدهای واقعی برگردید. حدس زدن نام فیلد در همه منابع معمولاً نتیجه خالی می‌دهد. نمایی که برای گزارش میزبان مفید است ممکن است برای سامانه هویت نیاز به ستون‌های دیگری داشته باشد.
نماهای ذخیره‌شده و علامت‌گذاری
نمای ذخیره‌شده پرس‌وجو را برای استفاده دوباره یا همکاری حفظ می‌کند. یک نما می‌تواند «ورودهای حساب آزمایشی پیرامون دریافت پیوست» باشد و نمای دیگر «فرایندهای فرزند برنامه نمایش سند در همان میزبان». نام نما باید دامنه و هدف را نشان دهد. اگر عضو دیگری همان نما را باز کند، باید بداند چه چیزهایی عمداً از جست‌وجو حذف شده‌اند. ذخیره پرس‌وجو، تصمیم تحلیل را قابل بازبینی می‌کند و از اختلاف ناشی از اجرای دستی چند جست‌وجوی مشابه جلوگیری می‌کند.
رویدادهای مهم را می‌توان ستاره‌دار کرد و درباره آن‌ها نظر نوشت. طبق راهنمای پروژه، نظر در زمینه همان پرونده نگه داشته می‌شود، حتی اگر خط زمانی در چند پرونده استفاده شود. این ویژگی برای فرضیه‌های مخصوص یک بررسی مفید است. هنگام نوشتن نظر، مشاهده را از برداشت جدا کنید. «فرایند در ساعت مشخص با والد برنامه نمایش سند ثبت شد» مشاهده است. «این فرایند احتمالاً توسط پیوست ایجاد شده» فرضیه است و به شاهد بیشتر نیاز دارد. خواننده باید بتواند با دیدن داده خام درباره فرضیه قضاوت کند.
تحلیلگر خودکار و بازبینی انسانی
تحلیلگرهای Timesketch می‌توانند روی رویدادها کار کنند، نشانه اضافه کنند، نما بسازند یا الگوهای مرتبط را پیدا کنند. مستندات نمونه‌هایی برای فعالیت مرورگر و یافتن فاصله در گزارش رخداد معرفی می‌کند. خروجی چنین تحلیلی یک سرنخ است. فاصله میان شماره رکوردهای یک گزارش ممکن است به پاک‌سازی عمدی مربوط باشد، اما می‌تواند ناشی از گردآوری ناقص یا سیاست نگه‌داری هم باشد. برای هر نشانه، منبع اولیه را ببینید و علت‌های جایگزین را بررسی کنید. خودکار شدن جست‌وجو مسئولیت تفسیر را از تحلیلگر نمی‌گیرد.
اگر تحلیلگری بر داده حساس با سرویس بیرونی تعامل دارد، پیش از اجرا نوع داده و مجوز ارتباط را بررسی کنید. همه تحلیلگرها نیاز و رفتار یکسان ندارند. برای پذیرش اولیه، تحلیلگری انتخاب کنید که اثرش روی یک خط کوچک قابل مشاهده باشد و خروجی مورد انتظار را از قبل می‌دانید. زمان اجرا، برچسب‌های ایجادشده و نماهای افزوده‌شده را ثبت کنید. پس از ارتقا همان ورودی را دوباره بررسی کنید تا تغییر رفتار روشن شود. این روش از اعتماد بی‌دلیل به نتیجه‌ای که منشأ آن برای تیم ناشناخته است جلوگیری می‌کند.
ساخت روایت از شواهد
بخش روایت امکان ترکیب توضیح، نماهای ذخیره‌شده و داده‌های تجمیعی را فراهم می‌کند. برای پرونده پیوست، روایت می‌تواند با مشاهده دریافت نامه شروع شود، سپس نخستین شاهد اجرای فایل و بعد ورود حساب را نشان دهد. در هر گام به رویداد یا نمای قابل بازبینی وصل شوید. اگر ارتباط میان اجرا و ورود هنوز ثابت نشده است، آن را به صورت فرضیه بنویسید و شواهد لازم برای تأیید را مشخص کنید. ترتیب زمانی به تنهایی رابطه علت و معلول ایجاد نمی‌کند. دو رویداد می‌توانند پشت سر هم رخ دهند و علت مشترک دیگری داشته باشند.
تجمیع برای فهم ترکیب داده مفید است. برای نمونه می‌توان انواع رخدادهای موجود در بازه را بررسی کرد و دید آیا منبعی برخلاف انتظار هیچ داده‌ای ندارد. اما تعداد بیشتر رخداد از یک میزبان ممکن است فقط نتیجه سطح گزارش‌دهی متفاوت باشد. پیش از مقایسه حجم میان دو دستگاه، سیاست ثبت، مدت پوشش و خطاهای ورود را بررسی کنید. نمودار یا جدول خلاصه وقتی ارزش دارد که خواننده بتواند به رکوردهای پشتیبان برگردد. برای تصمیم حساس، نمونه‌های خام را کنار نتیجه تجمیع نگه دارید.
عیب‌یابی نتیجه خالی یا ترتیب غیرمنتظره
اگر جست‌وجوی شناسه معلوم نتیجه نمی‌دهد، ابتدا وجود خط زمانی و پایان پردازش ورود را بررسی کنید. سپس فهرست ستون‌ها و نوع مقدار را ببینید. ممکن است شناسه عددی به شکل رشته وارد شده یا نام فیلد در تبدیل تغییر کرده باشد. بازه زمانی را موقتاً گسترش دهید تا خطای منطقه زمانی آشکار شود. یک پیام نمونه را از فایل اصلی تا نمایش نهایی دنبال کنید. این مسیر مشخص می‌کند مشکل از منبع، تبدیل، نمایه‌سازی یا پرس‌وجو آمده است و از تغییر چند تنظیم هم‌زمان جلوگیری می‌کند.
اگر چند رخداد با ترتیب عجیب دیده می‌شوند، نوع زمان و دقت را مقایسه کنید. زمان تغییر فایل لزوماً زمان اجرای آن نیست و زمان دریافت شبکه می‌تواند بعد از ثبت محلی باشد. در پرونده نهایی، سؤال‌های باز را همراه با روش حل آن‌ها ثبت کنید. برای مثال، دریافت گزارش دیگری از سامانه هویت ممکن است ترتیب را روشن کند، در حالی که افزایش تعداد رویدادهای میزبان کمکی به اختلاف ساعت نمی‌کند. نتیجه مطلوب زمانی است که بازبین دوم بتواند همان نماها را باز کند، مسیر استدلال را ببیند و حدود اطمینان هر نتیجه را مستقل ارزیابی کند.
