در امنیت شبکه، لاگ فقط برای بعد از حادثه نیست. لاگ خوب کمک میکند بفهمیم تغییرات چه اثری گذاشتهاند، ترافیک از کدام Rule عبور کرده، VPN چرا قطع شده، WAF چرا یک درخواست را block کرده و آیا رفتار مشکوک تکرار میشود یا نه. اما لاگ زیاد و بیهدف هم مشکل را حل نمیکند؛ اگر همه چیز ارسال شود و هیچ اولویتی نباشد، تیم عملیاتی بعد از مدتی به هشدارها بیاعتماد میشود.
من معمولاً لاگهای امنیت شبکه را به دو گروه جدا میکنم: لاگهایی که برای عملیات روزانه لازماند و لاگهایی که در حادثه باید مسیر را بازسازی کنند. بعضی eventها در هر دو گروه مهم هستند، مثل تغییر policy یا ورود مدیر. بعضی دیگر فقط وقتی ارزش پیدا میکنند که کنار دادههای دیگر دیده شوند، مثل denyهای پرتعداد یا alertهای IPS.
لاگ تغییرات مدیریتی را سبک نگیرید
هر تغییری روی فایروال، WAF، load balancer یا سوئیچ core باید قابل ردیابی باشد. چه کسی وارد شده؟ از کجا؟ چه زمانی؟ چه چیزی تغییر کرده؟ آیا تغییر comment یا ticket دارد؟ اگر بعد از یک قطعی نفهمیم چه کسی یک Rule، NAT، VIP، SSL profile یا health monitor را تغییر داده، تحلیل حادثه به حدس تبدیل میشود. این لاگها باید به جایی خارج از خود دستگاه هم ارسال شوند.
- login موفق و ناموفق مدیران
- تغییر configuration و policy
- commit، deploy یا publish شدن تغییر
- تغییر وضعیت HA یا sync
- خطاهای backup و ذخیره configuration
فایروال و VPN: فقط deny کافی نیست
در فایروال، denyها مهماند، اما کافی نیستند. باید بدانیم ترافیک مجاز از کدام Rule عبور کرده، NAT چه تغییری داده، VPN tunnel چه زمانی بالا یا پایین رفته، و اگر SD-WAN یا چند لینک داریم، مسیر انتخابشده کدام بوده است. در FortiGate، Firepower یا Juniper SRX، کیفیت لاگ زمانی مشخص میشود که بخواهیم یک مسیر واقعی را از ابتدا تا انتها دنبال کنیم.
برای VPN هم فقط up/down مهم نیست. خطای احراز هویت، mismatch در proposal، مشکل route، ترافیکی که داخل tunnel نمیرود، و قطعیهای کوتاه باید قابل دیدن باشند. اگر VPN هر چند ساعت برای چند ثانیه قطع میشود، بدون زمان دقیق و correlation با لاگ لینک، ISP یا فایروال، پیدا کردن علت سخت میشود.
WAF و Load Balancer را از SIEM جدا نکنید
در خیلی از شبکهها SIEM فقط لاگ فایروال را خوب میبیند و WAF یا load balancer در حاشیه میماند. این اشتباه است. اگر کاربر خطای ۵۰۲ میگیرد، اگر API در FortiWeb یا F5 ASM block میشود، یا اگر pool member در F5 down شده، بخشی از داستان امنیتی همانجاست. لاگ WAF باید نشان دهد کدام host، کدام path، کدام signature یا constraint و با چه actionی درگیر شده است.
برای F5 هم لاگ LTM، وضعیت health monitor، تغییر pool member، خطاهای SSL profile و iRule/log messageهای محدود اهمیت دارند. البته log زیاد در F5 میتواند خودش فشار ایجاد کند؛ پس باید سطح لاگ و مدت زمان فعال بودن آن کنترل شود.
یک روش عملی برای شروع
بهتر است از سرویسهای حیاتی شروع کنیم. برای هر سرویس بپرسیم: اگر فردا کاربر گفت سرویس قطع است یا حملهای رخ داده، برای بازسازی مسیر چه لاگهایی لازم داریم؟ فایروال، WAF، load balancer، DNS، VPN، سرور و سامانه احراز هویت باید کنار هم دیده شوند. بعد برای هر دستگاه حداقل eventهای لازم تعریف شود، نه اینکه همه چیز با severity یکسان به SIEM برود.
این موضوع به لاگ و مانیتورینگ Cisco Firepower، عیبیابی FortiWeb با لاگ و Request و مانیتورینگ و پشتیبانی امنیت شبکه وصل است. لاگ خوب قرار نیست فقط آرشیو باشد؛ باید در روز تغییر، روز قطعی و روز حادثه قابل استفاده باشد.
کیفیت لاگ را با یک سناریو تست کنید
برای فهمیدن اینکه لاگها کافی هستند یا نه، یک سناریوی واقعی بسازید. مثلاً یک کاربر VPN وصل نمیشود، یک درخواست API در WAF block میشود، یا یک سرویس پشت F5 خطای intermittent دارد. بعد ببینید آیا از روی لاگها میتوان زمان، مسیر، دستگاه درگیر، تصمیم policy و نتیجه نهایی را پیدا کرد یا نه. اگر برای جواب دادن به هر سؤال باید وارد چند دستگاه شد و دستی دنبال شواهد گشت، یعنی هنوز visibility کامل نیست.
هدف از این تست پیدا کردن ضعف ابزار نیست؛ پیدا کردن شکاف بین عملیات واقعی و چیزی است که SIEM یا syslog نشان میدهد. گاهی فقط یک field کم است، گاهی زمان دستگاهها هماهنگ نیست، و گاهی event مهم با severity پایین ارسال میشود و در داشبورد دیده نمیشود. همین اصلاحهای کوچک در روز حادثه چند ساعت زمان میخرند.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
