Log Analytics & SIEM

امنیت و کنترل دسترسی

تحلیل رخداد و Splunk / SIEM

بدون لاگ، پس از هر حادثه فقط می‌توان حدس زد. با لاگِ بدون ساختار، می‌توان ساعت‌ها حدس زد.

معرفی تخصصی

تحلیل رخداد و SIEM در عمل چه کاری انجام می‌دهد

هر سرور، فایروال و سرویس سازمانی لاگ تولید می‌کند. مشکل نبود داده نیست؛ پراکندگی آن است. وقتی لاگ‌ها روی ده‌ها دستگاه جداگانه و با قالب‌های متفاوت باقی بمانند، عملاً قابل استفاده نیستند.

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

لایهٔ بعد، تشخیص است: تعریف قواعدی که الگوهای مشکوک را علامت بزنند. اینجا همان اصل پایش صدق می‌کند — سامانه‌ای که همه‌چیز را هشدار می‌دهد، عملاً هیچ‌چیز را هشدار نمی‌دهد.

مسئله

چه مشکلی را حل می‌کند

در بیشتر سازمان‌ها لاگ‌ها روی خود دستگاه‌ها باقی می‌مانند و با چرخش خودکار، پس از چند روز بازنویسی می‌شوند. وقتی حادثه‌ای کشف می‌شود — که معمولاً هفته‌ها پس از وقوع رخ می‌دهد — داده‌ای برای بررسی باقی نمانده است.

مسئلهٔ دوم این است که همان دستگاهی که ممکن است در معرض دستکاری باشد، نگهدارندهٔ لاگ خودش هم هست.

  • پراکندگی لاگ روی ده‌ها دستگاه با قالب‌های متفاوت
  • بازنویسی خودکار لاگ‌ها پیش از آنکه حادثه کشف شود
  • نگهداری لاگ روی همان دستگاهی که ممکن است در معرض دستکاری باشد
  • نبود قاعده‌ای برای تشخیص الگوهای مشکوک؛ اتکا به مشاهدهٔ اتفاقی
  • ناتوانی در پاسخ به اینکه چه کسی، چه زمانی و از کجا تغییری ایجاد کرده است
  • پیاده‌سازی‌هایی که همه‌چیز را جمع می‌کنند و در حجم داده غرق می‌شوند

کاربرد سازمانی

کجا به این خدمت نیاز پیدا می‌شود

  • تحقیق پس از حادثه

    بازسازی زنجیرهٔ رویدادها برای تعیین اینکه چه اتفاقی افتاد، از چه مسیری و چه چیزی تحت تأثیر قرار گرفت.

  • پایش دسترسی‌های حساس

    تشخیص ورود با حساب‌های دارای اختیار بالا، به‌ویژه در ساعات غیرعادی یا از مبدأ غیرمنتظره.

  • تشخیص الگوهای مشکوک

    علامت‌گذاری رفتارهایی مانند تلاش مکرر ناموفق برای ورود یا تغییر ناگهانی در حجم ترافیک خروجی.

  • پاسخ به نیاز ممیزی

    در دسترس داشتن سوابق قابل جست‌وجو برای بررسی‌های داخلی یا الزامات بیرونی.

معماری پیشنهادی

ساختاری که پیشنهاد می‌کنیم

سامانهٔ تحلیل رخداد در چهار لایه ساخته می‌شود. تصمیم کلیدی در لایهٔ اول گرفته می‌شود: چه چیزی جمع شود و چه چیزی نشود.

نمودار معماری — تحلیل رخداد و SIEM
منابع رخدادسرورهاتجهیزات مرزیسرویس دامیننرمال‌سازیقواعد تشخیصنگهداشتکنسول بررسی

برای دیدن کامل نمودار، آن را به چپ و راست بکشید.

  1. جمع‌آوریارسال لاگ از سرورها، تجهیزات مرزی، سرویس‌های دامین و سامانه‌های کلیدی به مقصد مرکزی، جدا از خود دستگاه‌ها.
  2. نرمال‌سازیتبدیل قالب‌های متفاوت به ساختار مشترک، تا جست‌وجو و همبستگی میان منابع ممکن شود.
  3. قواعد تشخیصتعریف الگوهای قابل اقدام بر پایهٔ رفتار واقعی سازمان، با تمرکز بر کیفیت هشدار نه تعداد آن.
  4. نگهداشت و بررسیسیاست نگهداشت متناسب با زمان معمول کشف حادثه، و کنسول جست‌وجو برای تحقیق پس از رویداد.

قابلیت‌ها

اجزا و قابلیت‌های فنی

  • تعیین دامنهٔ جمع‌آوری

    انتخاب منابعی که واقعاً ارزش تحلیلی دارند، به‌جای جمع‌آوری هر چیزی که لاگ تولید می‌کند.

  • پیاده‌سازی تجمیع لاگ

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

  • نرمال‌سازی و غنی‌سازی

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

  • تدوین قواعد تشخیص

    ساخت قواعد بر پایهٔ سناریوهای واقعی سازمان، با آزمون و تنظیم برای کاهش هشدار نادرست.

  • سیاست نگهداشت

    تعیین مدت نگهداری متناسب با ظرفیت و نیاز بررسی، با سطح‌بندی میان داده‌های داغ و آرشیو.

  • پشتیبانی تحقیق

    همراهی تیم فنی در بررسی پس از حادثه و استخراج زنجیرهٔ رویدادها از داده‌های نگهداری‌شده.

مزیت‌ها

چه چیزی در عملیات روزمره تغییر می‌کند

  • پاسخ به‌جای حدس

    پس از حادثه می‌توان گفت چه شد، چه زمانی و از کجا.

  • لاگ خارج از دسترس دستکاری

    نگهداری متمرکز، سوابق را از دستگاهی که ممکن است در معرض باشد جدا می‌کند.

  • تشخیص زودتر

    قواعد معنادار، الگوهای مشکوک را پیش از گسترش علامت می‌زنند.

  • آمادگی برای ممیزی

    سوابق قابل جست‌وجو در زمان نیاز در دسترس‌اند.

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

سه وضعیت پرتکرار و پاسخ ما به آن‌ها

این سناریوها الگوی طراحی‌اند، نه شرح پروژه‌های انجام‌شده؛ برای هر سازمان با اندازه‌گیری وضعیت واقعی بازنویسی می‌شوند.

  • وضعیت

    سازمانی که متوجه تغییر غیرمنتظره در تنظیمات یک سرور شده اما نمی‌داند چه کسی و چه زمانی آن را اعمال کرده است.

    رویکرد

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

    نتیجهٔ مورد انتظار

    همان پرسش در رویداد بعدی ظرف چند دقیقه پاسخ می‌گیرد، به‌جای آنکه بی‌پاسخ بماند.

  • وضعیت

    پیاده‌سازی موجودی که همهٔ لاگ‌ها را جمع می‌کند و در حجم داده و هشدارهای بی‌اهمیت غرق شده است.

    رویکرد

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

    نتیجهٔ مورد انتظار

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

مراحل اجرا

از ارزیابی تا بهره‌برداری

  1. تعیین دامنه و سناریو

    مشخص کردن منابع لاگ و سناریوهایی که سامانه باید بتواند آن‌ها را تشخیص دهد یا پاسخ بدهد.

  2. پیاده‌سازی جمع‌آوری

    برپایی مسیر ارسال، نرمال‌سازی ساختار و اعمال سیاست نگهداشت.

  3. تدوین و تنظیم قواعد

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

  4. تحویل و همراهی

    آموزش کار با کنسول جست‌وجو، تحویل مستندات و همراهی در نخستین بررسی‌ها.

فناوری‌ها

سکوها و فناوری‌های مرتبط

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

  • Splunk
  • Elastic Stack
  • Wazuh
  • Graylog
  • Syslog / Windows Event Forwarding
  • Sigma Detection Rules

پرسش‌های متداول — تحلیل رخداد و SIEM

تفاوت این خدمت با مانیتورینگ چیست؟

مانیتورینگ به سلامت و کارایی می‌پردازد: آیا سرویس بالاست، آیا دیسک پر شده. تحلیل رخداد به رویدادها و رفتارها می‌پردازد: چه کسی وارد شد، چه چیزی تغییر کرد، چه الگوی غیرعادی دیده می‌شود. این دو مکمل‌اند و معمولاً در کنار هم پیاده می‌شوند.

حتماً باید از Splunk استفاده کنیم؟

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

چه مدت لاگ‌ها باید نگهداری شوند؟

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

آیا این سامانه به تیم اختصاصی نیاز دارد؟

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

دربارهٔ تحلیل رخداد و SIEM در سازمان خود صحبت کنیم

در جلسهٔ تخصصی، وضعیت فعلی، محدودیت‌ها و اهداف قابل اندازه‌گیری شما بررسی می‌شود و تصویر روشنی از معماری پیشنهادی و مراحل اجرا ارائه می‌گردد.