SIEM (XDR Core)

Kaspersky SIEM XDR Core، تحلیل فنی و راهنمای کامل برای سازمان ها

قبل از هر چیز، SIEM XDR Core چه تفاوتی با KUMA دارد؟

کسپرسکی سال ها دو مسیر موازی در حوزه پایش و کشف تهدید داشت. KUMA یا به بیان کامل Kaspersky Unified Monitoring and Analysis Platform به عنوان SIEM مستقل، و خانواده محصولات EDR و XDR برای کشف و پاسخ در سطح اندپوینت و شبکه. مشتری هایی که هر دو را همزمان داشتند، میدانند که کار کردن با آنها یعنی انتقال هشدارهای EDR با کانکتور به KUMA، مدیریت دو کنسول جدا، و تحمل یکپارچه سازی هایی که با هر بروزرسانی نیاز به بازبینی داشتند.

خانواده SIEM XDR که کسپرسکی در سال ۲۰۲۵ معرفی کرد، دقیقاً برای بستن همین شکاف طراحی شده است: ترکیب رسمی و تحت پشتیبانی واحد، میان موتور SIEM مبتنی بر KUMA و سنسورها و عامل های کشف و پاسخ. سطح Core پایینترین سطح این خانواده است؛ برای سازمان هایی که به پایش مرکزی رویدادها و توان پاسخ اولیه نیاز دارند، اما هنوز به اجزای سنگینتر مانند سندباکس و تحلیل عمیق ترافیک شبکه نیازی ندارند. مشخصات و شرایط تهیه Kaspersky SIEM XDR Core در صفحه محصول درج شده و در این متن قرار است فراتر از مشخصات فنی، منطق انتخاب و ملاحظات استقرار آن را بررسی کنیم.

در گروه آتنا نماینده رسمی کسپرسکی، این محصول را معمولاً به سازمان هایی پیشنهاد می کنیم که از مرحله حفاظت پایه عبور کرده اند؛ یعنی اندپوینت هایشان پوشش داده شده و حالا سؤال اصلی این است: "چه کسی در حال حاضر دارد به کل این هشدارها نگاه میکند؟"

جایگاه Core در سبد سازمانی کسپرسکی

برای اینکه تصمیم گیری ساده تر شود، سبد کسپرسکی را می شود در چهار لایه تصور کرد:

• لایه اول حفاظت اندپوینت است.
• لایه دوم کشف و پاسخ در سطح اندپوینت یعنی EDR.
• لایه سوم XDR است که دید اندپوینت را با دید شبکه و قابلیت های تحلیلی بیشتر ترکیب می کند.
• لایه چهارم پایش و همبستگی مرکزی در مقیاس کل زیرساخت است؛ همانجایی که SIEM XDR Core قرار می گیرد.

مرور کلی راهکارهای امنیت سازمانی کسپرسکی نشان میدهد هر لایه برای چه مرحلهای از بلوغ امنیتی طراحی شده و این محصول در انتهای این مسیر می نشیند، نه ابتدای آن.

یک تجربه تکرارشونده در پروژه ها: سازمان هایی با ۱۰۰ تا ۲۰۰ کاربر که اکوسیستم IT ساده ای دارند، گاهی تحت تأثیر تبلیغات به سراغ SIEM میروند در حالی که هنوز به آن نیاز ندارند. اگر سازمان شما در این محدوده است، نگاهی به راهکارهای امنیتی کسب و کارهای متوسط بیندازید؛ احتمالاً ترکیب حفاظت اندپوینت و یک EDR سبک برای شما کفایت می کند و ورود زود هنگام به دنیای SIEM فقط هزینه و بار عملیاتی اضافه تحمیل می کند.

معماری فنی: از KUMA چه چیزی باید بدانید

هسته پردازشی این محصول همان KUMA است و شناخت اجزای آن برای هر تصمیم فنی ضروری است:

• Core: واحد مرکزی که شامل موتور همبستگی و ذخیره سازی است. ذخیره سازی روی ClickHouse بنا شده که یک ستون محور تخصصی برای داده های رویدادی است و همین موضوع جستوجو در حجم بالا از لاگ های تاریخی را عملی میکند.
• Collector: نقش دریافت داده را دارد و در چند نسخه قابل استقرار است؛ در دیتاسنتر مرکزی، در شعب، یا کنار منبع تولید رویداد. در سازمان های چندسایتی، استقرار کلکتور محلی و ارسال داده فشرده به مرکز، عملاً تنها راه قابل قبول از نظر پهنای باند است.
  Sensor
• Sensor: در صورت نیاز به تحلیل ترافیک شبکه، سنسور KUMA روی Mirror Port یا TAP قرار می گیرد و متادیتای شبکه را به موتور همبستگی تزریق میکند.

نکته ای که در مذاکرات خرید کمتر گفته می شود اما در استقرار تعیین کننده است: لایسنس KUMA بر پایه EPS یا تعداد رویداد در ثانیه محاسبه می شود، نه تعداد کاربر. تیم های خرید عادت دارند بر اساس سرشمار حساب کنند و اینجا اشتباه می کنند. باید نرخ تولید رویداد واقعی زیرساخت خود را اندازه بگیرید، نه میانگین را بلکه پیک ساعات اوج را، و بر همان مبنا ظرفیت تهیه کنید. زیرخرید کردن EPS یعنی دور ریختن رویدادها در دقیقه ای که دقیقاً به آن نیاز دارید؛ یعنی وسط حادثه.

قابلیت های موتور همبستگی که قابل ذکر است: نرمال سازی رویدادهای ناهمگون با دیکشنری ها، لیست های فعال برای نگهداری وضعیت بین رویدادها، جداول زمینه برای غنی سازی، و نگاشت قوانین به تکنیک های MITRE ATT&CK که به تیم اجازه می دهد بفهمد دقیقاً کدام تکنیک ها را می بیند و کجای دیدش کور است. برای سازمان های ارائهدهنده خدمات مدیریت شده، قابلیت Multi-Tenancy هم وجود دارد.

این داده ها از کجا می آیند؟

واقعیت زیرساخت های ایرانی این است که ناهمگون اند: ویندوزهای سرور با نسخه های مختلف، لینوکس های پراکنده، فایروال ها و پروکسی های متنوع و گاهی تجهیزات قدیمی که فقط syslog تحویل میدهند. KUMA برای همین واقعیت ساخته شده است؛ رویدادها را از Windows Event Log، syslog، Kafka، فایل، WMI و فرمت های استاندارد مانند CEF دریافت می کند.

سهم مهم داده ها اما از عامل کسپرسکی روی اندپوینت ها می آید. همان عامل کسپرسکی Endpoint Security که احتمالاً هم اکنون روی سیستم هایتان نصب است، تلمتری رفتاری تولید می کند: ساخت پروسه ها (رویداد ۴۶۸۸ در ویندوز)، ورودهای ناموفق مکرر (۴۶۲۵)، نصب سرویس های جدید (۷۰۴۵) و موارد مشابه. یعنی اگر از قبل کسپرسکی داشته باشید، بخش عمده ای از زیرساخت دریافت داده اندپوینت آماده است و هزینه و زمان استقرار پایین می آید.

یک درد آشنا در استقرارهای داخلی که کمتر کسی از قبل به آن فکر می کند: یکسان نبودن ساعت و تایمزون منابع. وقتی لاگ فایروال با UTC ثبت شده و لاگ ویندوز با زمان محلی، همبستگی رویدادها عملاً از کار میافتد. قبل از اتصال هر منبعی، سرویس NTP و تنظیم تایمزون باید یکدست شود؛ این مورد به تنهایی هفته ها کسری زمان در پروژه های مختلف ایجاد کرده است.

وظایف روزمره تیم امنیت با این پلتفرم
جریان کاری استاندارد این است: رویدادها وارد می شوند، قوانین همبستگی الگوها را شناسایی می کنند و به جای هزاران رکورد خام، هشدارهای اولویت بندی شده تحویل می دهند. تحلیلگر هشدار را برمیدارد، به همان کنسول نگاه می کند که پروسه ها چه اجرا شده، چه فایلی ساخته شده و چه ارتباطی برقرار شده، و در صورت تشخیص تهدید، پاسخ میدهد: ایزوله کردن هاست از شبکه، قطع پروسه مخرب، قرنطینه فایل. همه این اقدامات از طریق همان عامل کسپرسکی اجرا می شود و تحلیلگر لازم نیست بین ابزارها جابجا شود.

برای سناریوهای تکرارشونده میتوان پاسخ خودکار تعریف کرد، اما توصیه ما در پروژه ها محافظه کارانه است: اتوماسیون پاسخ را برای مواردی فعال کنید که نرخ مثبت کاذب آنها تقریباً صفر اثبات شده. یک قانون خودکار اشتباه که سرور پایگاه داده حیاتی را در ساعات کاری ایزوله کند، هزینه اش چند برابر هر باج افزاری است.

قابلیت شکار تهدید هم برای تیم های باتجربه اهمیت دارد. وقتی اندیکاتور جدیدی منتشر می شود، اسکن گذشته نگر روی کل تاریخچه نگهداری شده انجام می شود و مشخص میکند آیا این تهدید قبلاً در محیط حضور داشته یا نه. کوئری ها قابل ذخیره و اجرای دوره ای هستند.

دید شبکه، چیزی که از اندپوینت پیدایش نمی شود

بخشی از رفتار مهاجم فقط در ترافیک شبکه دیده می شود: حرکت جانبی بین سرورها، ارتباط دورهای با سرور فرماندهی، پرسوجوهای DNS مشکوک و انتقال غیرعادی داده. سنسور شبکه KUMA این الگوها را از متادیتای ترافیک استخراج می کند. اگر سازمان شما نیاز به تحلیل عمیق تر محتوا، بازسازی فایل و شناسایی تهدیدهای هدفمند دارد، کسپرسکی NDR KATA به عنوان مکمل تخصصی تر قابل افزودن است و خروجی آن میتواند به همین پلتفرم تزریق شود.

Core یا EDR یا XDR؟ تصمیم بر اساس نیاز

این پرسش پرتکرارترین پرسش مشتریان است و پاسخ صادقانه آن این است که به الزامات بستگی دارد. اگر فقط حفاظت و کشف اولیه اندپوینت میخواهید، EDR Optimum نقطه شروع است. اگر تحلیل ریشه ای عمیق حوادث و شکار تهدید پیشرفته در سطح اندپوینت لازم دارید، کسپرسکی EDR Expert گزینه مناسبی است. ترکیب اندپوینت و شبکه با قابلیت های تحلیلی بیشتر را XDR Optimum پوشش می دهد. اما به محض اینکه نگهداری مرکزی لاگ برای ممیزی، همبستگی رویدادهای کل زیرساخت و مستندسازی حوادث تبدیل به الزام شود، به SIEM نیاز پیدا میکنید و SIEM XDR Core دقیقاً برای همین مرحله بسته بندی شده است. سؤال تعیین کننده این است: آیا نظارتی از شما می خواهد که لاگ ها را برای بازه مشخصی نگه دارید؟ اگر پاسخ بله است، بحث EDR در برابر SIEM اصلاً معنا ندارد، هر دو لازم اند.

ملاحظات سایزینگ و استقرار

محاسبه ظرفیت ساده اما دقت بالا می طلبد: نرخ EPS پیک را در ثانیه های روز و روزهای نگهداری ضرب کنید تا حجم ذخیره سازی مشخص شود. بعد برآورد سخت افزار: پردازنده و حافظه برای موتور همبستگی، و فضای NVMe برای ذخیره سازی که ClickHouse بدون دیسک سریع عملکرد دلخواه را نشان نمی دهد. تمام معماری به صورت کاملاً درون سازمانی مستقر می شود و هیچ دادهای از مرز شبکه خارج نمی شود، برای سازمان هایی با محدودیت حاکمیتی یا مقرراتی روی داده، این نکته گاهی تعیین کننده انتخاب است.

توصیه عملی ما برای شروع: به جای استقرار همه جا، با تعریف ده تا پانزده Use Case مشخص شروع کنید. مثلاً تشخیص رفتار شبیه باج افزار، ورودهای مشکوک سرورهای حیاتی، یا سوءاستفاده از VPN. سپس دو تا چهار هفته اجرای آزمایشی، و سنجش متریک ها: میانگین زمان کشف و میانگین زمان پاسخ. اگر این دو عدد بعد از استقرار بهبود محسوس نداشت، مشکل از پلتفرم نیست؛ از طراحی قوانین است و باید بازنگری شود.

جمع بندی

SIEM XDR Core پاسخ کسپرسکی به یک نیاز واقعی است: سازمان هایی که هم پایش مرکزی رویداد می خواهند و هم توان پاسخ سریع، بدون تحمل هزینه و شکنندگی یکپارچه سازی دو محصول جدا. انتخاب درست آن منوط به سه شرط است: زیرساختی که از آستانه مدیریت دستی عبور کرده، الزامی به نگهداری و پایش لاگ، و تیمی حتی کوچک که قرار است با این ابزار کار کند. اگر هر سه شرط برقرار است، جلسه سایزینگ بر اساس EPS واقعی زیرساخت، قدم اول است و تیم فنی آتنا از طراحی معماری تا آموزش و پشتیبانی در طول دوره لایسنس در کنار شما خواهد بود.