لاگ و مانیتورینگ Cisco Firepower؛ چه چیزی را به SIEM بفرستیم؟

در بسیاری از شبکه‌ها Firepower لاگ تولید می‌کند، اما لاگ‌ها واقعاً به تصمیم عملیاتی کمک نمی‌کنند. یا logging روی ruleهای مهم خاموش است، یا آن‌قدر event غیرضروری ارسال می‌شود که رخداد مهم بین نویز گم می‌شود. هدف از لاگ گرفتن این نیست که همه چیز را بدون فکر به SIEM بفرستیم؛ هدف این است که در زمان حادثه بتوانیم مسیر رخداد را بفهمیم و تصمیم بگیریم.

لاگ خوب باید به چند سؤال پاسخ دهد: چه کسی به کجا وصل شد؟ کدام rule اجازه داد یا مسدود کرد؟ آیا NAT انجام شد؟ آیا IPS یا malware inspection چیزی دید؟ آیا VPN، SSL Decryption یا policy deploy در همان بازه تغییر داشته است؟ اگر این پاسخ‌ها در چند ابزار جدا و بدون correlation پخش باشند، incident response کند می‌شود.

از Access Control Policy شروع کنید

ruleهای مهم باید logging روشن و قابل فهم داشته باشند. برای ruleهای حساس مثل دسترسی ادمین، سرویس‌های منتشرشده، ارتباط دیتاسنتر، VPN و ترافیک بین segmentهای مهم، لاگ باید حداقل در ابتدای اتصال یا انتهای اتصال مطابق نیاز ثبت شود. اما برای ruleهای پرحجم و کم‌اهمیت، logging بی‌هدف می‌تواند SIEM را پر از رخداد کم‌ارزش کند.

در طراحی policy، ruleهایی که فقط برای «رد شدن کار» اضافه شده‌اند معمولاً لاگ بدی هم دارند. بهتر است ruleها با owner، دلیل، scope و سطح logging مشخص نوشته شوند. وقتی rule مبهم باشد، event آن هم برای تحلیل مبهم خواهد بود.

IPS و رخدادهای امنیتی را از ترافیک عادی جدا کنید

رخداد IPS باید با زمینه دیده شود: source، destination، application، rule مرتبط، شدت signature و اینکه action فقط alert بوده یا block. اگر همه signatureها بدون tuning به SIEM بروند، تیم امنیت بعد از مدتی حساسیتش را از دست می‌دهد. اولویت باید روی رخدادهای قابل اقدام باشد؛ مخصوصاً روی سرویس‌های منتشرشده، segmentهای حساس و مسیرهایی که قبلاً پرریسک شناخته شده‌اند.

برای همین tuning IPS و logging از هم جدا نیستند. وقتی روی تنظیم IPS در Cisco Firepower کار می‌کنید، هم‌زمان باید تصمیم بگیرید کدام رخدادها برای SIEM ارزش دارند و کدام‌ها فقط در FMC برای بررسی دوره‌ای کافی هستند.

NAT و VPN را در لاگ قابل ردیابی کنید

در رخدادهای واقعی، دانستن translated address و original address حیاتی است. اگر تیم امنیت فقط آدرس بعد از NAT را ببیند، ممکن است نتواند کاربر یا سرور واقعی را پیدا کند. در VPN هم باید معلوم باشد ترافیک از کدام peer و کدام subnet آمده و به کدام rule خورده است.

show logging
show conn detail
show xlate
show crypto ipsec sa

همه چیز را به SIEM نفرستید

ارسال کورکورانه همه eventها معمولاً هم هزینه ذخیره‌سازی را بالا می‌برد و هم کیفیت هشدارها را پایین می‌آورد. بهتر است eventها لایه‌بندی شوند: رخدادهای امنیتی و blockهای مهم برای هشدار، رخدادهای access حساس برای correlation، رخدادهای تغییر policy و deploy برای audit، و ترافیک عادی فقط در جاهایی که واقعاً نیاز عملیاتی دارد.

در کنار SIEM، خود FMC هم باید برای بررسی‌های روزمره قابل استفاده بماند. اگر همه چیز فقط به ابزار بیرونی واگذار شود و ساختار policy نامفهوم باشد، هنگام troubleshooting دوباره باید از اول مسیر را پیدا کرد.

تغییرات policy را هم مانیتور کنید

گاهی ریشه حادثه یک حمله نیست؛ یک تغییر اشتباه است. deploy شدن policy، تغییر NAT، اضافه شدن rule باز، تغییر در SSL Decryption یا خاموش شدن logging روی یک rule حساس باید در audit دیده شود. این لاگ‌ها شاید امنیتی به معنی کلاسیک نباشند، اما برای کنترل ریسک عملیاتی بسیار مهم‌اند.

جمع‌بندی

لاگ Firepower باید برای تیم عملیات و امنیت قابل استفاده باشد. logging خوب یعنی event کمتر اما معنادارتر، ruleهای قابل فهم، ارتباط روشن بین Access Control، IPS، NAT و VPN، و ارسال انتخاب‌شده به SIEM. اگر این طراحی انجام نشود، در زمان حادثه فقط حجم زیادی داده داریم، نه دید عملیاتی.

برای اینکه لاگ‌ها واقعاً کمک کنند، این موضوع را کنار طراحی NAT، عیب‌یابی VPN و برنامه تغییرات FMC و FTD ببینید.

منابع رسمی

• Cisco Secure Firewall Threat Defense Configuration Guides
• Cisco Secure Firewall Management Center Configuration Guides