وقتی Splunk ES سالم است، اما حمله را نمی‌بیند

در سناریوی بازسازی‌شده از عیب‌یابی ES، لاگ‌های ورود ناموفق ویندوز دریافت می‌شدند، تعدادشان از آستانه تشخیص عبور می‌کرد و Correlation Search نیز موفق اجرا می‌شد؛ اما هشداری تولید نمی‌شد. عجیب‌تر اینکه همان جست‌وجو، کمی دیرتر و به‌صورت دستی، نتیجه می‌داد.

این تناقض، سؤال اصلی را تغییر داد: آیا مشکل در SPL بود، یا داده هنگام اجرای تشخیص هنوز آماده نبود؟

ابتدا استخراج فیلدها، انطباق با CIM، قیود Data Model، دسترسی کاربر اجراکننده و محدوده زمانی بررسی شدند. سرنخ اصلی در tstats و تنظیم summariesonly=true بود: جست‌وجو فقط خلاصه‌های شتاب‌دهی‌شده را می‌خواند. بنابراین وجود لاگ در ایندکس، دیده‌شدن آن در مسیر تشخیص را تضمین نمی‌کرد.

مقایسه خروجی جست‌وجو با summariesonly=true و summariesonly=false روی بازه‌ای ثابت، اختلاف نشان داد. سپس سه زمان کنار هم قرار گرفتند: وقوع رویداد، ایندکس‌شدن و قابل‌جست‌وجوشدن در خلاصه‌ها.

رویدادی ساعت ۱۰:۰۲ رخ داده، ۱۰:۰۸ ایندکس شده و بعدتر وارد خلاصه‌ها شده بود؛ اما قاعده هر پنج دقیقه، فقط پنج دقیقه گذشته را بررسی می‌کرد. هنگام اجرای اول، داده نرسیده بود؛ هنگام اجرای بعدی، زمان وقوعش از پنجره خارج شده بود.

بررسی scheduler.log نیز رقابت منابع و اجرای Skip‌شده بعضی جست‌وجوهای شتاب‌دهی را آشکار کرد.

راه‌حل، صرفاً تغییر کوئری نبود: تأخیر منابع اندازه‌گیری شد، زمان‌بندی جست‌وجوهای سنگین توزیع شد و پنجره تشخیص با تأخیر واقعی داده تطبیق یافت. برای پنجره‌های هم‌پوشان نیز کنترل تکرار هشدار تعریف شد، بدون آنکه فعالیت مستقل بعدی پنهان شود.

پذیرش نهایی با بازاجرای سناریو و سنجش زمان رسیدن هشدار انجام شد؛ نه صرفاً مشاهده اجرای موفق Search.

درس مهم: نتیجه نداریم ، الزاماً یعنی تهدید صفر نیست؛ گاهی داده و منطق درست، در زمان مناسب به هم نمی‌رسند.

#Splunk #SplunkES #SOC #DetectionEngineering #Troubleshooting #CIM #SIEM