نگهداری، پایش و تحلیل لاگ؛ حافظه قابل اعتماد برای امنیت شبکه

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

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

همه لاگ‌ها به یک اندازه مهم نیستند

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

• ورود موفق و ناموفق کاربران، مخصوصا حساب‌های مدیریتی؛
• تغییرات Policy، Rule، تنظیمات فایروال، VPN و تجهیزات شبکه؛
• اجرای سرویس‌ها، نصب نرم‌افزار، تغییرات سطح دسترسی و ایجاد حساب جدید؛
• رویدادهای EDR، ضدبدافزار، DNS، Proxy و احراز هویت؛
• ارتباط با مقصدهای مشکوک، ترافیک غیرعادی و تلاش برای اسکن داخلی.

منبع لاگ را درست انتخاب کنید

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

در شبکه‌های کوچک هم می‌شود با چند منبع اصلی شروع کرد: فایروال، Domain Controller، سرورهای حیاتی، EDR یا آنتی‌ویروس مرکزی و سرویس ایمیل. بعد به‌مرور منابع دیگر اضافه می‌شوند.

زمان سیستم‌ها باید دقیق باشد

یکی از خطاهای ساده ولی دردسرساز، اختلاف ساعت بین سیستم‌هاست. وقتی زمان فایروال، سرور و Endpoint هماهنگ نباشد، بازسازی مسیر حادثه سخت می‌شود. NTP باید برای همه تجهیزات و سرورها مشخص و پایدار باشد؛ مخصوصا برای تجهیزاتی که در مسیر احراز هویت، VPN و اینترنت قرار دارند.

نگهداری لاگ فقط آرشیو نیست

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

• برای لاگ‌های امنیتی مهم، حداقل چند ماه نگهداری قابل جست‌وجو در نظر بگیرید.
• آرشیو بلندمدت را از لاگ‌های روزمره جدا کنید.
• دسترسی به لاگ‌ها را محدود و قابل audit کنید.
• برای جلوگیری از تغییر یا حذف لاگ، مسیر ارسال مرکزی و سطح دسترسی مناسب داشته باشید.

از لاگ خام به هشدار قابل اقدام برسید

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

• ورود ناموفق زیاد روی یک حساب یا از یک IP غیرعادی؛
• ورود موفق حساب مدیریتی خارج از زمان یا مکان معمول؛
• ایجاد کاربر جدید، اضافه شدن به گروه Admin یا تغییر Policy حساس؛
• خاموش شدن سرویس امنیتی، EDR یا ارسال لاگ؛
• ارتباط Endpoint با دامنه یا IP مشکوک؛
• تغییر ناگهانی حجم ترافیک یا اسکن داخلی.

تحلیل لاگ باید با دارایی‌ها گره بخورد

وقتی هشدار می‌بینید، باید بدانید آن سیستم چقدر مهم است، مالک آن کیست و در کدام بخش شبکه قرار دارد. هشدار روی سرور مالی یا Domain Controller با هشدار روی یک سیستم تستی یکسان نیست. اتصال لاگ‌ها به Inventory دارایی‌ها، VLAN، نقش سیستم و مالک سرویس باعث می‌شود اولویت‌بندی درست‌تر انجام شود.

داشبورد کمتر، Runbook بیشتر

داشبورد زیبا بدون فرایند واکنش، ارزش محدودی دارد. برای هشدارهای مهم باید Runbook کوتاه داشته باشید: چه کسی بررسی می‌کند، چه لاگ‌هایی باید دیده شود، چه زمانی سیستم ایزوله می‌شود، چه کسی مطلع می‌شود و چه چیزی مستند می‌شود.

برای مثال، اگر ورود موفق ادمین از کشور غیرمعمول دیده شد، فقط دیدن هشدار کافی نیست. باید نشست‌های فعال بررسی شوند، رمز تغییر کند، MFA و لاگ‌های مرتبط چک شود و تغییرات انجام‌شده در بازه زمانی مشکوک بررسی شود.

ابزارهای مفید

برای جمع‌آوری و تحلیل لاگ می‌توان از Splunk، Elastic Stack، Wazuh، Microsoft Sentinel، QRadar، Graylog، FortiAnalyzer، LogRhythm یا ابزارهای مشابه استفاده کرد. در محیط کوچک‌تر حتی یک Syslog Server منظم همراه با Wazuh یا Elastic می‌تواند شروع خوبی باشد. انتخاب ابزار باید با مهارت تیم، حجم لاگ، بودجه و نیاز پاسخ‌گویی هماهنگ باشد.

چک‌لیست سریع لاگ و پایش

• آیا منابع اصلی لاگ مثل فایروال، VPN، AD، سرورها و Endpointها به محل مرکزی ارسال می‌شوند؟
• آیا زمان همه سیستم‌ها با NTP هماهنگ است؟
• آیا لاگ‌های امنیتی مهم به اندازه کافی قابل جست‌وجو نگهداری می‌شوند؟
• آیا تغییرات مدیریتی و ورود حساب‌های حساس هشدار دارند؟
• آیا قطع شدن ارسال لاگ خودش هشدار تولید می‌کند؟
• آیا هشدارها مالک، اولویت و Runbook دارند؟
• آیا بعد از هر حادثه، قوانین پایش و هشدارها اصلاح می‌شوند؟

جمع‌بندی

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