بازبینی Ruleها در Cisco Firepower؛ چطور Policy شلوغ را قابل دفاع کنیم؟

در Cisco Firepower و FMC، Policy بعد از چند ماه تغییر مداوم معمولاً شلوغ می‌شود: Ruleهای موقت باقی می‌مانند، objectها تکراری می‌شوند، exceptionها دلیلشان را از دست می‌دهند و لاگ‌ها یا بیش از حد زیادند یا برای مسیرهای مهم اصلاً فعال نیستند. نتیجه این است که تیم شبکه از تغییر می‌ترسد، چون نمی‌داند حذف یا جابه‌جایی یک Rule چه اثری دارد.

Rule Review در Firepower یعنی تبدیل یک Policy پرابهام به مجموعه‌ای از تصمیم‌های قابل دفاع. این کار فقط برای زیبایی نیست؛ روی امنیت، سرعت عیب‌یابی، کیفیت لاگ SIEM و حتی موفقیت deploy اثر مستقیم دارد.

اول Policy را بر اساس هدف دسته‌بندی کنید

قبل از حذف یا تغییر، باید Ruleها را از نظر هدف جدا کنید: دسترسی کاربران به اینترنت، دسترسی کاربران به سرورها، دسترسی مدیریت، VPN، DMZ، سرویس‌های منتشرشده و exceptionهای خاص. وقتی همه این‌ها در یک جریان ذهنی دیده شوند، احتمال حذف اشتباه بالا می‌رود.

• Ruleهای دسترسی عمومی کاربران را از Ruleهای حساس مدیریتی جدا کنید.
• برای DMZ و سرویس‌های publish شده، مقصد و لاگ را دقیق‌تر بررسی کنید.
• Ruleهای VPN را با مسیر واقعی شعبه‌ها و NAT مقایسه کنید.
• Ruleهایی که owner ندارند را مستقیم حذف نکنید؛ اول اثرشان را از لاگ و hit count بفهمید.

Hit Count مفید است، اما کافی نیست

Rule بدون hit در بازه طولانی می‌تواند کاندید حذف باشد، اما تصمیم نهایی نباید فقط با hit count گرفته شود. بعضی Ruleها برای سناریوی اضطراری یا سرویس‌های فصلی هستند. در مقابل، Rule پرhit هم لزوماً خوب نیست؛ شاید بیش از حد باز است و ترافیک‌های نامرتبط را هم عبور می‌دهد.

برای Ruleهای مشکوک، بهتر است یک دوره مانیتورینگ با لاگ مناسب داشته باشید و بعد محدوده source، destination و application را کوچک‌تر کنید.

با Ruleهای any برخورد مرحله‌ای داشته باشید

هر Rule که source، destination یا application آن any است الزاماً بد نیست، اما باید دلیل روشن داشته باشد. مشکل وقتی است که any برای راحتی deploy استفاده شده و بعد در Policy مانده است. در Rule Review، این Ruleها را جدا علامت‌گذاری کنید و با لاگ واقعی آنها را به Ruleهای محدودتر بشکنید.

اگر Rule مربوط به اینترنت کاربران است، application و URL category می‌تواند کمک کند. اگر مربوط به سرورهاست، معمولاً باید مقصد و سرویس دقیق‌تر شود. برای ترافیک حساس، فعال بودن IPS و لاگ session اهمیت بیشتری دارد.

Objectهای تکراری و مبهم را پاکسازی کنید

در FMC، objectهای تکراری یکی از علت‌های اصلی خطای انسانی هستند. دو object با IP یکسان و نام متفاوت باعث می‌شوند Ruleها قابل خواندن نباشند. قبل از پاکسازی، dependency objectها را ببینید و objectهای مشترک را با نام استاندارد جایگزین کنید.

نام object باید از روی آن قابل فهم باشد: نوع دارایی، محیط، سرویس یا مالک. نام‌هایی مثل temp، test، server1 یا old در Policy production جایی ندارند مگر با توضیح و تاریخ مشخص.

لاگ و SIEM را همزمان بازبینی کنید

Rule Review بدون بررسی لاگ ناقص است. بعضی Ruleها ترافیک زیادی تولید می‌کنند و ارسال همه رخدادها به SIEM فقط نویز می‌سازد. بعضی Ruleهای حساس باید حتماً لاگ داشته باشند. معیار تصمیم باید اهمیت مسیر، حساسیت مقصد، نیاز incident response و ظرفیت مانیتورینگ باشد.

برای طراحی مسیر لاگ، مطلب لاگ و مانیتورینگ Cisco Firepower مکمل همین چک‌لیست است.

قبل از پاکسازی، برنامه Deploy و Rollback داشته باشید

در Firepower تغییر Policy تا deploy نشود روی دستگاه اعمال نمی‌شود. برای پاکسازی جدی، تغییرات را کوچک نگه دارید، بعد از deploy وضعیت health و رخدادها را بررسی کنید و اگر مشکلی رخ داد بدانید دقیقاً کدام تغییر باید برگردد. اگر deploy خودش خطا می‌دهد، اول مسیر عیب‌یابی deploy را جدا حل کنید؛ مطلب عیب‌یابی Deploy نشدن Policy در Cisco FMC/FTD برای همین سناریو نوشته شده است.

جمع‌بندی

پاکسازی Policy در Cisco Firepower کار یک‌باره و نمایشی نیست. باید Ruleها را بر اساس هدف دسته‌بندی کرد، anyها را با داده واقعی محدود کرد، objectهای تکراری را جمع کرد، لاگ را متناسب با حساسیت مسیر تنظیم کرد و deploy را مرحله‌ای جلو برد. Policy خوب فقط کار می‌کند؛ قابل خواندن، قابل دفاع و قابل تغییر هم هست.