تصویر شاخص قابلیت بازیابی اطلاعات؛ Backup امن در برابر حادثه و باجافزار
لاگها زمانی ارزش دارند که به درد تصمیمگیری بخورند. صرفا روشن بودن Syslog، ذخیره چند فایل متنی یا داشتن یک داشبورد شلوغ یعنی هنوز کنترل لاگ کامل نیست. در حادثه واقعی، سوالهای سادهای مطرح میشود: چه کسی وارد شد، از کجا، چه تغییری داد، کدام سیستم با کدام مقصد ارتباط گرفت و از چه زمانی رفتار غیرعادی شروع شد؟
هدف این کنترل این است که رخدادهای مهم امنیتی از سیستمها، تجهیزات شبکه و سرویسها جمعآوری، نگهداری، پایش و قابل تحلیل باشند. بدون لاگ قابل اعتماد، بررسی حادثه بیشتر به حدس و حافظه افراد وابسته میشود.
اول باید مشخص شود کدام رویدادها برای امنیت مهماند. اگر همه چیز را بدون اولویت جمع کنید، هم هزینه ذخیرهسازی بالا میرود و هم تیم فنی بین هشدارهای بیارزش گم میشود. اگر هم فقط چند لاگ سطحی بگیرید، زمان حادثه چیزی برای بررسی ندارید.
برای دید امنیتی، فقط لاگ سرورها کافی نیست. تجهیزات شبکه، فایروال، VPN، Active Directory، سرویسهای ابری، ایمیل، Endpoint و برنامههای حساس باید در برنامه لاگبرداری باشند. اگر مهاجم از VPN وارد شود، روی یک سیستم ابزار اجرا کند و بعد به یک سرور داخلی وصل شود، باید بتوانید این مسیر را از چند منبع کنار هم ببینید.
در شبکههای کوچک هم میشود با چند منبع اصلی شروع کرد: فایروال، Domain Controller، سرورهای حیاتی، EDR یا آنتیویروس مرکزی و سرویس ایمیل. بعد بهمرور منابع دیگر اضافه میشوند.
یکی از خطاهای ساده ولی دردسرساز، اختلاف ساعت بین سیستمهاست. وقتی زمان فایروال، سرور و Endpoint هماهنگ نباشد، بازسازی مسیر حادثه سخت میشود. NTP باید برای همه تجهیزات و سرورها مشخص و پایدار باشد؛ مخصوصا برای تجهیزاتی که در مسیر احراز هویت، VPN و اینترنت قرار دارند.
مدت نگهداری لاگ باید با نیاز عملیاتی، الزامات قانونی و ریسک سازمان هماهنگ باشد. نگهداری خیلی کوتاه باعث میشود حملههایی که دیر کشف میشوند قابل بررسی نباشند. نگهداری بیبرنامه و طولانی هم هزینه و ریسک حریم خصوصی ایجاد میکند.
لاگ خام بهتنهایی کمک زیادی نمیکند. باید روی رخدادهایی که واقعا نیاز به بررسی دارند هشدار ساخته شود. هشدار خوب نه آنقدر زیاد است که کسی نگاه نکند، نه آنقدر کم که حمله از چشم پنهان بماند.
وقتی هشدار میبینید، باید بدانید آن سیستم چقدر مهم است، مالک آن کیست و در کدام بخش شبکه قرار دارد. هشدار روی سرور مالی یا Domain Controller با هشدار روی یک سیستم تستی یکسان نیست. اتصال لاگها به Inventory داراییها، VLAN، نقش سیستم و مالک سرویس باعث میشود اولویتبندی درستتر انجام شود.
داشبورد زیبا بدون فرایند واکنش، ارزش محدودی دارد. برای هشدارهای مهم باید Runbook کوتاه داشته باشید: چه کسی بررسی میکند، چه لاگهایی باید دیده شود، چه زمانی سیستم ایزوله میشود، چه کسی مطلع میشود و چه چیزی مستند میشود.
برای مثال، اگر ورود موفق ادمین از کشور غیرمعمول دیده شد، فقط دیدن هشدار کافی نیست. باید نشستهای فعال بررسی شوند، رمز تغییر کند، MFA و لاگهای مرتبط چک شود و تغییرات انجامشده در بازه زمانی مشکوک بررسی شود.
برای جمعآوری و تحلیل لاگ میتوان از Splunk، Elastic Stack، Wazuh، Microsoft Sentinel، QRadar، Graylog، FortiAnalyzer، LogRhythm یا ابزارهای مشابه استفاده کرد. در محیط کوچکتر حتی یک Syslog Server منظم همراه با Wazuh یا Elastic میتواند شروع خوبی باشد. انتخاب ابزار باید با مهارت تیم، حجم لاگ، بودجه و نیاز پاسخگویی هماهنگ باشد.
نگهداری و تحلیل لاگ یعنی داشتن حافظه قابل اعتماد برای شبکه. بدون آن، تشخیص نفوذ، بررسی ریشه حادثه و اصلاح کنترلها سخت و کند میشود. لاگ خوب باید از منبع درست بیاید، زمان دقیق داشته باشد، امن نگهداری شود، قابل جستوجو باشد و به هشدارهای قابل اقدام تبدیل شود.
تست نفوذ و ردتیم وقتی ارزش دارد که خروجی آن به اصلاح واقعی کنترلها برسد،…
روز حادثه وقت تصمیمگیری از صفر نیست. باید از قبل بدانیم چه کسی چه کاری…
وقتی برنامه وب آسیبپذیر باشد، شبکه سالم و فایروال مرتب هم همیشه نمیتواند جلوی سوءاستفاده…
آموزش امنیتی وقتی مفید است که به کار روزانه وصل باشد؛ نه یک فایل طولانی…
اکانت رها شده، رمز قدیمی و دسترسی باقیمانده از شغل قبلی، از مسیرهای ساده ولی…
شبکه بیسیم اگر درست کنترل نشود، عملا یک کابل شبکه است که تا بیرون ساختمان…