Microsoft Sentinel در مقابل Splunk: انتخاب یک SIEM

هر دو ابزار کار اصلی یکسانی انجام می‌دهند: جمع‌آوری لاگ، همبستگی رویدادها و ارائه هشدارهایی که اهمیت دارند. تفاوت‌ها در مدل قیمت‌گذاری، زبان کوئری و میزان زیرساخت‌هایی که شما مسئول آن هستید ظاهر می‌شوند.

واقعیت هر محصول

Microsoft Sentinel یک SIEM بومی ابری است که بر روی Azure Log Analytics ساخته شده است. هیچ زیرساختی برای patch کردن نیست، هیچ خوشه indexer برای تعیین اندازه نیست، و از Kusto Query Language (KQL) برای همه چیز از شکار تا قوانین تشخیص استفاده می‌کند. بر اساس هر GB داده‌ای که به workspace دریافت می‌شود صورت‌حساب می‌شود، با چند سطح (pay-as-you-go، سطح‌های تعهدی که از حدود 100 GB/day شروع می‌شوند) که نرخ هر GB را تغییر می‌دهند.

Splunk به‌عنوان یک پلتفرم لاگ on-prem شروع شد و برای بسیاری از شرکت‌ها هنوز به‌همین‌گونه کار می‌کند، اگرچه Splunk Cloud اکنون توصیه پیش‌فرض برای배포‌های جدید است. از SPL (Search Processing Language) استفاده می‌کند، که قدیمی‌تر، بالغ‌تر است و کتابخانه‌ی بسیار بزرگ‌تری از برنامه‌های جامعه در Splunkbase دارد. از لحاظ تاریخی Splunk نیز بر اساس حجم دریافت صورت‌حساب می‌کرد، اما آن‌ها مشتریان را به سمت قیمت‌گذاری مبتنی بر بار کاری هدایت کردند که برای محاسبات (search job‌ها، indexing) به‌جای حجم داده‌ی خام هزینه می‌گیرد — بررسی شرایط فعلی ارزشمند است زیرا این‌ها بیش از یک‌بار تغییر کردند.

زبان کوئری: KQL در مقابل SPL

KQL مانند یک خط لوله از فیلترها خوانده می‌شود، شبیه LINQ اگر با C# سروکار داشته‌اید:

SecurityEvent
| where EventID == 4625
| summarize FailedLogons = count() by Account, bin(TimeGenerated, 1h)
| where FailedLogons > 10

SPL همین کار را با نحو متفاوتی انجام می‌دهد:

index=wineventlog EventCode=4625
| bucket _time span=1h
| stats count as FailedLogons by Account, _time
| where FailedLogons > 10

تحلیل‌گران که از SQL استفاده کردند معمولاً KQL را سریع‌تر یاد می‌گیرند. SPL دستورات داخلی بیشتری برای چیزهایی مانند transaction، eventstats و یکپارچگی ابزارهای یادگیری ماشینی دارد، که در صورتی که anomaly detection فراتر از آستانه‌های ساده انجام می‌دهید مهم است. هیچ زبانی از نظر موضوعی بهتر نیست — هزینه واقعی بازآموزش تیمی است که قبلاً سال‌های حافظه عضلانی را در یکی یا دیگری دارند.

دریافت داده و کانکتورها

Sentinel اگر estate شما قبلاً Microsoft-heavy است در مزیت است: کانکتورهای بومی، کم‌اتکا برای Azure AD (Entra ID) sign-in log‌ها، Defender for Endpoint، Office 365 و Azure activity log‌ها. لوله‌کشی داده‌های AWS یا on-prem Syslog از طریق Azure Monitor Agent خوب کار می‌کند، اما در مقایسه با منابع Azure بومی یک hop اضافی است.

Ecosystem کانکتور Splunk از نظر تعداد خام گسترده‌تر است زیرا مدت‌زمانی‌ای که وجود دارد طولانی‌تر است — Splunkbase هزاران برنامه و add-on دارد، از جمله برنامه‌های نگه‌داری شده توسط جامعه برای محصولات گوشه و کنار. اگر از یک محیط مختلط (Cisco firewall‌ها، on-prem AD قدیمی، برنامه‌های SaaS تصادفی بدون API مدرن) دریافت می‌کنید، احتمالاً Technology Add-on (TA) از پیش‌ساخته برای Splunk را پیدا خواهید کرد قبل از اینکه کانکتور Sentinel معادل پیدا کنید.

قوانین تشخیص و threat intelligence

Sentinel با template‌های analytics rule که به MITRE ATT&CK نگاشت شده‌اند ارائه می‌شود، و threat intelligence feed خود Microsoft (Microsoft Threat Intelligence) مستقیماً یکپارچه می‌شود. Fusion، موتور correlation Sentinel، هشدارهای کم‌دقت را به‌طور خودکار به یک incident پیوند می‌دهد، که برای تیم‌های کوچک‌تر بدون یک گروه تشخیص مهندسی اختصاصی خستگی هشدار را کاهش می‌دهد.

Splunk Enterprise Security (یک add-on جداگانه و پولی، در Splunk base گنجانده نشده است) به شما Notable Events، risk-based alerting و یک framework correlation search قابل تعدیل‌تر می‌دهد. Risk-based alerting به‌خصوص — نمره‌دهی موجودیت‌ها در طول زمان به‌جای fire کردن روی single event‌ها — یکی از الگوهای تشخیص قوی‌تر است که در هر یک از پلتفرم‌ها موجود است، و Splunk آن را مدت‌زمانی‌ای دارد.

هزینه و overhead عملیاتی

مدل serverless Sentinel به این معنی است که برنامه‌ریزی ظرفیت برای indexer‌ها یا search head‌ها نیست، اما هزینه‌های دریافت می‌تواند سریع بالا برود اگر منابع verbose مانند DNS یا firewall traffic را بدون فیلتر کردن قبل از آن لاگ می‌کنید. Data Collection Rules (DCRs) به شما اجازه می‌دهد داده را قبل از رسیدن به workspace فیلتر و تبدیل کنید، که شایسته است به‌زودی تنظیم شود تا بعد از اولین صورت‌حساب شگفت‌انگیز نباشد.

Splunk on-prem به شما کنترل کامل بر روی retention و hardware sizing می‌دهد اما به این معنی است که کسی مالک indexer cluster، license usage و upgrade cycle است. Splunk Cloud اکثر آن را حذف می‌کند اما شما هنوز under newer pricing model برای search‌های compute-heavy پرداخت می‌کنید، پس SPL query‌های بدنویس بیش مستقیماً کیف شما را تحت تأثیر قرار می‌دهند نسبت به طرح قدیمی مبتنی بر دریافت.

کدام‌یک در محیط شما مناسب است

اگر قبلاً عمیقاً در Azure و Microsoft 365 هستید، Sentinel معمولاً هزینه‌ی کمتری برای راه‌اندازی و نگه‌داری دارد. اگر نیاز به یکپارچگی‌های گسترده شخص ثالث، یک ecosystem برنامه بالغ یا تیم شما قبلاً SPL را می‌شناسید، انعطاف‌پذیری Splunk علیرغم عملیات بالاتر سود می‌رساند. بسیاری از enterprise‌های بزرگ‌تر در واقع هر دو را اجرا می‌کنند — Splunk برای منابع on-prem legacy، Sentinel برای سمت Azure-native — و داده‌های خلاصه‌شده بین آن‌ها جابه‌جا می‌کنند به‌جای اینکه یکی را انتخاب کنند.

برای اطلاعات بیشتر درباره ساخت قوانین تشخیص و log pipeline‌ها، بخش‌های SIEM و Blue Team مرتبط را در Korra Studio بررسی کنید.