لاگ‌ها وارد 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