وقتی 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

لاگ‌ها وارد Splunk شده‌اند؛ اما آیا واقعاً برای Detection آماده‌اند؟

خطای پنهان در Data Onboarding که حتی مدیران باتجربه Splunk ممکن است نادیده بگیرند


یکی از اشتباهات رایج در پروژه‌های پیاده‌سازی Splunk Enterprise Security این است که موفقیت Data Onboarding را با دریافت موفق لاگ‌ها اشتباه می‌گیریم.

تصور کنید یک Splunk Administrator گزارش می‌دهد که لاگ‌های Windows، Firewall و Active Directory با موفقیت وارد Index شده‌اند. نرخ EPS طبیعی است، رویدادها قابل جست‌وجو هستند و تأخیری در دریافت داده‌ها مشاهده نمی‌شود.

آیا می‌توان نتیجه گرفت که این منابع برای استفاده در Splunk ES آماده‌اند؟

پاسخ منفی است؛ زیرا Searchable بودن داده الزاماً به معنای CIM-Compliant بودن آن نیست و CIM Compliance نیز به‌تنهایی Detection Readiness را تضمین نمی‌کند.

اینجا باید میان سه مفهوم تمایز قائل شویم: Data Ingestion، Data Normalization و Detection Readiness.

در مرحله نخست، داده دریافت، پردازش و ایندکس می‌شود. در مرحله دوم، ساختار و معنای داده با الزامات Common Information Model یا CIM تطبیق پیدا می‌کند. در مرحله سوم، باید اطمینان حاصل کنیم که داده واقعاً پیش‌نیازهای Detectionهای موردنظر را تأمین می‌کند.

اما نکته ظریف‌تر در مرحله دوم قرار دارد.

وCIM Compliance صرفاً به معنای یکسان‌سازی نام فیلدها نیست.

فرض کنید رویداد Windows Event ID 4625 وارد Splunk شده است. این رویداد نشان‌دهنده یک تلاش ناموفق برای ورود است. ممکن است Administrator فیلد IpAddress را به src و فیلد TargetUserName را به user نگاشت کند.

این اقدام ضروری است، اما کافی نیست.

اگر مقدار action به‌درستی به failure نرمال‌سازی نشده باشد، یک Detection که به دنبال ورودهای ناموفق می‌گردد ممکن است رویداد را شناسایی نکند.

از سوی دیگر، در Splunk CIM، مفاهیمی مانند Event Type، Tag و Dataset Constraints نیز اهمیت دارند. Event Type می‌تواند گروه مشخصی از رویدادها را شناسایی کند و Tagها در طبقه‌بندی آن‌ها نقش داشته باشند. محدودیت‌های Dataset نیز تعیین می‌کنند کدام رویدادها در محدوده یک Data Model قرار می‌گیرند.

بنابراین ممکن است رویدادی در Index وجود داشته باشد، فیلدهای آن نیز استخراج شده باشند، اما به دلیل ناسازگاری با محدودیت‌های Dataset، در جست‌وجوی مبتنی بر Data Model ظاهر نشود.

این مسئله زمانی خطرناک‌تر می‌شود که Detectionهای سازمان بر مبنای Data Modelهای CIM توسعه یافته باشند.

در چنین شرایطی، داشبوردهای مربوط به Ingestion ممکن است وضعیت سالمی نشان دهند، در حالی که بخشی از قابلیت کشف تهدید عملاً دچار Blind Spot شده است.

نکته مهم دیگر، تفاوت میان Data Model Compatibility و Data Model Acceleration است. فعال‌سازی Acceleration می‌تواند عملکرد جست‌وجوهای سازگار را بهبود دهد، اما داده‌ای را که از نظر معنایی یا ساختاری نادرست نرمال‌سازی شده است، اصلاح نمی‌کند.

از منظر مهندسی، Data Onboarding باید فراتر از اتصال Log Source به Index تعریف شود. یک فرآیند حرفه‌ای باید دریافت داده، صحت Timestamp، شناسایی Sourcetype، استخراج فیلدها، نرمال‌سازی مقادیر، تطبیق با CIM، بررسی Dataset Membership و در نهایت اعتبارسنجی Detection را پوشش دهد.

حتی عبور موفق از آزمون CIM نیز پایان کار نیست. ممکن است Detection به Lookup، Asset and Identity Context، فیلدهای تکمیلی، آستانه‌های زمانی یا شرایط همبستگی وابسته باشد.

به همین دلیل، بهترین معیار موفقیت Data Onboarding، صرفاً تعداد رویدادهای دریافتی نیست؛ بلکه توانایی داده در پشتیبانی از سناریوهای کشف تهدید مورد انتظار است.

برای مثال، در یک سناریوی Brute Force باید بتوانیم مسیر رویداد را از تولید در سیستم مبدأ تا دریافت در Splunk، نرمال‌سازی، ورود به Dataset مناسب و اجرای موفق Detection ردیابی و اعتبارسنجی کنیم.

این همان جایی است که Data Onboarding از یک فعالیت صرفاً عملیاتی به بخشی از Detection Engineering تبدیل می‌شود.

پیام نهایی برای Splunk Administrators:

وقتی یک Log Source را Onboard می‌کنید، تنها نپرسید: «آیا لاگ‌ها وارد Splunk شده‌اند؟»

بپرسید: «آیا این داده‌ها با CIM سازگارند، در Data Model مناسب قرار می‌گیرند و می‌توانند Detectionهای مورد انتظار را به‌درستی تغذیه کنند؟»

زیرا در یک SOC، خطرناک‌ترین نقص همیشه نبود داده نیست؛ گاهی داده وجود دارد، اما سامانه کشف تهدید نمی‌تواند از آن به‌درستی استفاده کند.

**دوره اسپلانک پیشرفته 09902857290

#Splunk #SplunkES #DataOnboarding #CIM #DetectionEngineering #SIEM #SOC #DataNormalization #ThreatDetection #CyberSecurity