پیاده‌سازی SIEM چگونه انجام می‌شود؟ بررسی مراحل اجرا و دلایل شکست پروژه‌های SIEM

سازمان‌ها روزانه حجم زیادی از رویدادها و لاگ‌های امنیتی را از فایروال‌ها، سرورها، تجهیزات شبکه، سرویس‌های ابری، پایگاه‌های داده، نرم‌افزارهای سازمانی و سیستم‌های Endpoint دریافت می‌کنند. بررسی دستی این اطلاعات نه‌تنها زمان‌بر است، بلکه احتمال نادیده گرفته‌شدن نشانه‌های اولیه یک حمله سایبری را نیز افزایش می‌دهد. راهکارهای Security Information and Event Management یا SIEM برای حل همین مشکل طراحی شده‌اند. SIE اطلاعات امنیتی را از منابع مختلف جمع‌آوری، پردازش و با یکدیگر مرتبط می‌کند تا رفتارهای مشکوک، حملات احتمالی و نقض سیاست‌های امنیتی شناسایی شوند.

بااین‌حال، خرید و نصب , پیاده‌سازی SIEM به‌تنهایی نمی‌تواند امنیت سازمان را تضمین کند. بسیاری از پروژه‌های SIEM پس از صرف هزینه و زمان قابل‌توجه، به سامانه‌ای برای ذخیره انبوه لاگ‌ها و تولید تعداد زیادی هشدار تبدیل می‌شوند؛ هشدارهایی که بخش زیادی از آن‌ها بررسی نمی‌شوند یا ارزش عملیاتی ندارند. بنابراین سؤال اصلی این نیست که سازمان از SIEM استفاده می‌کند یا خیر؛ بلکه باید پرسید: آیا SIEM سازمان می‌تواند تهدید واقعی را در زمان مناسب شناسایی کند و اطلاعات لازم برای واکنش سریع را در اختیار تیم امنیت قرار دهد؟

SIEM چیست و چه نقشی در امنیت سازمان دارد؟

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

مفهوم و مزایا و کاربرد SIEM

منابع اطلاعاتی SIEM می‌توانند شامل موارد زیر باشند:

• فایروال‌ها، WAFها و تجهیزات امنیت شبکه
• سیستم‌های تشخیص و جلوگیری از نفوذ
• سرورهای ویندوز و لینوکس
• Active Directory  و سرویس‌های مدیریت هویت
• EDR، آنتی‌ویروس و تجهیزات Endpoint
• تجهیزات شبکه مانند Router و Switch
• پایگاه‌های داده و نرم‌افزارهای سازمانی
• سرویس‌های ابری و محیط‌های چندابری
• سامانه‌های ایمیل و Secure Email Gateway
• تجهیزات مجازی‌سازی و زیرساخت‌های Container
• ابزارهای مدیریت آسیب‌پذیری
• منابع  Threat Intelligence

CISA در راهنمای پیاده‌سازی SIEM و SOAR تأکید می‌کند که سازمان‌ها باید جمع‌آوری لاگ را بر اساس اهمیت منابع، قابلیت تشخیص تهدید و نیازهای عملیاتی اولویت‌بندی کنند؛ نه اینکه بدون برنامه تمام داده‌های موجود را وارد SIEM کنند.

بیشتر بخوانید: تحلیل آسیب‌پذیری‌ها و نقاط ضعف حیاتی در سامانه‌های SIEM سازمانی

یک SIEM مؤثر باید بتواند علاوه بر ذخیره‌سازی داده، زنجیره‌ای از فعالیت‌های مرتبط را شناسایی کند. برای مثال، ورود ناموفق متعدد به یک حساب کاربری ممکن است به‌تنهایی اهمیت زیادی نداشته باشد؛ اما اگر پس از آن یک ورود موفق از موقعیت غیرعادی، ایجاد حساب مدیریتی و دسترسی به یک سرور حساس مشاهده شود، مجموعه این رویدادها می‌تواند نشان‌دهنده تصاحب حساب کاربری باشد.

چرا پیاده‌سازی SIEM با شکست مواجه می شود؟

شکست یک پروژه SIEM معمولاً به ضعف خود محصول محدود نمی‌شود. در بسیاری از موارد، مشکل اصلی به طراحی نامناسب، نبود فرآیند مشخص، انتخاب اشتباه منابع داده و ناهماهنگی میان فناوری، نیروی انسانی و اهداف امنیتی سازمان مربوط است.

اجرای پروژه بدون تعریف سناریوهای امنیتی

یکی از متداول‌ترین اشتباهات، آغاز پروژه SIEM با جمع‌آوری لاگ است؛ بدون اینکه سازمان بداند چه تهدیدهایی را می‌خواهد شناسایی کند. هر پروژه باید با تعریف Use Caseهای امنیتی آغاز شود. برای نمونه:

• شناسایی حملات Brute Force
• تشخیص ایجاد حساب کاربری مدیریتی
• شناسایی تغییر عضویت در گروه‌های حساس
• تشخیص پاک‌شدن لاگ‌های امنیتی
• شناسایی ارتباط باIPهای مخرب
• تشخیص اجرای ابزارهای غیرمجاز
• شناسایی انتقال غیرعادی اطلاعات
• کشف دسترسی مشکوک به پایگاه داده
• تشخیص تغییرات غیرمجاز در تجهیزات شبکه
• شناسایی حرکت جانبی مهاجم در شبکه

اگر Use Case مشخص نباشد، سازمان حجم زیادی از اطلاعات را جمع‌آوری می‌کند، اما خروجی قابل‌استفاده‌ای برای تیم امنیت تولید نخواهد شد.

بیشتر بخوانید: امنیت سازمان با Splunk ES؛ گذار از SIEM سنتی به پلتفرم هوشمند مبتنی بر ریسک و هوش مصنوعی

ارسال تمام لاگ‌ها به SIEM

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

• این منبع چه تهدیدی را قابل‌شناسایی می‌کند؟
• آیا لاگ موردنظر جزئیات کافی دارد؟
• آیا زمان رویدادها دقیق و همگام است؟
• چه مدت باید این اطلاعات نگهداری شوند؟
• آیا داده جمع‌آوری‌شده در تحقیقات امنیتی قابل‌استفاده است؟
• ارزش امنیتی داده در مقایسه با هزینه نگهداری آن چقدر است؟

راهنمای مشترک CISA درباره ثبت رویدادها نیز بر ایجاد یک خط مبنای مشخص برای Logging و استفاده از رویدادهای مناسب برای شناسایی تهدید تأکید می‌کند.

کیفیت پایین لاگ‌ها

گاهی SIEM به منبع داده متصل شده است، اما لاگ دریافتی اطلاعات کافی ندارد. برای مثال ممکن است نام کاربر، IP مبدأ، نتیجه عملیات، نام سیستم مقصد یا شناسه نشست در رویداد ثبت نشده باشد. مشکلات رایج کیفیت لاگ عبارت‌اند از:

• نبود هماهنگی زمانی میان سیستم‌ها
• تفاوت قالب داده‌ها
• ناقص‌بودن رویدادهای  Audit
• ثبت‌نشدن فعالیت کاربران مدیریتی
• تغییر نام فیلدها پس از به‌روزرسانی محصول
• قطع‌شدن Forwarder یا  Collector
• دریافت تکراری رویدادها
• اشتباه‌بودن Sourcetype یا  Parser
• نبود اطلاعات هویتی و زمینه‌ای

در چنین شرایطی حتی بهترین موتور تحلیل نیز نمی‌تواند نتیجه قابل‌اعتمادی ارائه کند.

نبود اطلاعات دارایی‌ها و هویت‌ها

یک هشدار بدون Context ارزش محدودی دارد. مشاهده تلاش برای ورود به یک سیستم زمانی اهمیت بیشتری پیدا می‌کند که SIEM بداند سیستم هدف یک Domain Controller، سرور مالی یا پایگاه داده حساس است.

اطلاعات زمینه‌ای مناسب می‌تواند شامل موارد زیر باشد:

• اهمیت و طبقه‌بندی دارایی
• مالک سرویس یا سامانه
• موقعیت شبکه‌ای سیستم
• آسیب‌پذیری‌های موجود
• نقش و سطح دسترسی کاربر
• وضعیت استخدامی یا سازمانی کاربر
• ساعات معمول فعالیت
• حساسیت اطلاعات نگهداری‌شده
• اینترنتی یا داخلی بودن سرویس

افزودن اطلاعات دارایی و هویت به رویدادها کمک می‌کند هشدارها بر اساس ریسک واقعی اولویت‌بندی شوند.

اتکا به قوانین پیش‌فرض

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

• معماری واقعی شبکه
• ساعات کاری سازمان
• حساب‌های کاربری ویژه
• سرویس‌های حیاتی
• رفتار طبیعی کاربران
• استثناهای تأییدشده
• سطح ریسک دارایی‌ها
• تهدیدات مرتبط با صنعت سازمان

تولید هشدارهای بیش‌ازحد

اگر SIEM هر رویداد غیرعادی را به‌عنوان Incident نمایش دهد، تحلیلگران با پدیده Alert Fatigue مواجه می‌شوند. در این وضعیت، حجم بالای هشدارها باعث می‌شود حتی هشدارهای مهم نیز دیر بررسی شوند. برای کاهش هشدارهای کاذب می‌توان از روش‌های زیر استفاده کرد:

• تنظیم دقیق Thresholdها
• تعریف لیست‌های مجاز کنترل‌شده
• غنی‌سازی رویدادها با اطلاعات دارایی و هویت
• تجمیع هشدارهای مرتبط در یک Incident
• استفاده از Threat Intelligence معتبر
• امتیازدهی ریسک به کاربران و دارایی‌ها
• بررسی دوره‌ای عملکرد قوانین
• حذف قوانین فاقد ارزش عملیاتی
• مستندسازی دلیل ایجاد هر هشدار

قابلیت‌هایی مانند Risk-Based Alerting کمک می‌کنند چند فعالیت کم‌خطر مرتبط به یک کاربر یا دارایی در طول زمان تجمیع شوند و تنها زمانی هشدار سطح بالا ایجاد شود که ریسک کلی از آستانه مشخصی عبور کند. Splunk نیز Risk-Based Alerting ،UEBA و یکپارچگی با SOAR را از قابلیت‌های کلیدی SIEMهای مدرن معرفی می‌کند.

نبود فرآیند پاسخ به رخداد

تشخیص تهدید تنها آغاز کار است. اگر پس از ایجاد هشدار مشخص نباشد چه کسی، در چه زمانی و با چه روشی باید آن را بررسی کند، SIEM ارزش عملیاتی خود را از دست می‌دهد. برای هر Use Case مهم باید یک Playbook پاسخ به رخداد تدوین شود. این Playbook باید موارد زیر را مشخص کند:

• مسئول بررسی اولیه هشدار
• اطلاعات موردنیاز برای اعتبارسنجی
• روش تعیین شدت  Incident
• شرایط ارجاع به سطح بالاتر
• اقدامات مهار تهدید
• روش جمع‌آوری شواهد
• نحوه اطلاع‌رسانی به مدیران
• شرایط مسدودسازی کاربر یا سیستم
• فرآیند بازگردانی سرویس
• نحوه ثبت درس‌آموخته‌ها

یکپارچه‌سازی SIEM با SOAR می‌تواند برخی اقدامات تکراری مانند بررسی اعتبار IP، غیرفعال‌کردن حساب، مسدودسازی Indicator یا ایجاد Ticket را خودکار کند.

مراحل صحیح پیاده‌سازی SIEM

برای پیاده‌سازی مؤثر SIEM می‌توان پروژه را در چند مرحله اجرا کرد.

مرحله اول: شناخت نیازهای سازمان

در این مرحله دارایی‌های حیاتی، الزامات قانونی، تهدیدات محتمل، ساختار تیم امنیت و اهداف پروژه شناسایی می‌شوند.

مرحله دوم: ارزیابی منابع داده

تمام منابع لاگ فهرست و بر اساس اهمیت، کیفیت داده، حجم و کاربرد امنیتی اولویت‌بندی می‌شوند.

مرحله سوم: تعریف Use Case

سناریوهای تشخیص بر اساس ریسک‌های واقعی سازمان طراحی شده و برای هر سناریو، منبع داده، منطق تشخیص، سطح اهمیت و فرآیند پاسخ مشخص می‌شود.

مرحله چهارم: طراحی معماری و ظرفیت

معماری Collectorها، Forwarderها، اجزای پردازشی، ذخیره‌سازی، High Availability و Disaster Recovery طراحی می‌شود.

مرحله پنجم: اتصال تدریجی منابع داده

بهتر است ابتدا منابع حیاتی مانند Active Directory، فایروال، EDR، سرورهای مهم و تجهیزات امنیتی به SIEM متصل شوند و پس از بررسی کیفیت داده، منابع بعدی اضافه شوند.

مرحله ششم: تنظیم، آزمایش و بهینه‌سازی

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

مرحله هفتم: بهبود مستمر

تهدیدات، زیرساخت و رفتار کاربران همواره در حال تغییر است. به همین دلیلUse Caseها، داشبوردها، منابع داده و Playbookها باید به‌صورت دوره‌ای بازبینی شوند.

نقش Splunk Enterprise Security در پیاده‌سازی SIEM

Splunk Enterprise Security یا Splunk ES یک پلتفرم SIEM و تحلیل امنیتی است که برای پشتیبانی از فرآیندهای اصلی مرکز عملیات امنیت طراحی شده است. این راهکار می‌تواند قابلیت‌هایی مانند موارد زیر را در اختیار تیم امنیت قرار دهد:

• جمع‌آوری و تحلیل داده از منابع متنوع
• ایجاد Correlation Search
• مدیریت و اولویت‌بندی Incidentها
• تحلیل دارایی‌ها و هویت‌ها
• Risk-Based Alerting
• Threat Intelligence
• Threat Hunting
• نگاشت تشخیص‌ها به MITRE ATT&CK
• ایجاد داشبوردهای مدیریتی و فنی
• یکپارچه‌سازی با UEBA و SOAR
• بررسی و تحلیل زنجیره رویدادهای مرتبط

نسخه‌های جدید Splunk Enterprise Security فراتر از ذخیره‌سازی و همبسته‌سازی سنتی لاگ حرکت کرده‌اند و قابلیت‌های SIEM ،UEBA ،SOAR ،Threat Intelligence و فرآیندهای تشخیص، بررسی و پاسخ را در یک بستر یکپارچه ارائه می‌کنند. بااین‌حال، موفقیت Splunk ES نیز مانند هر SIEM دیگری به طراحی معماری، کیفیت داده، Use Caseهای مناسب و توانمندی تیم عملیاتی وابسته است