تنظیم IPS در Cisco Firepower؛ از Alert زیاد تا Policy قابل استفاده

IPS در Cisco Firepower اگر بدون شناخت ترافیک واقعی فعال شود، خیلی زود از یک کنترل امنیتی به یک منبع نویز تبدیل می‌شود. خروجی آن می‌تواند صدها alert باشد که تیم عملیات فرصت بررسی‌شان را ندارد، یا بدتر از آن ruleهایی که به خاطر ترس از قطعی هیچ‌وقت وارد حالت block نمی‌شوند. در پروژه واقعی، مسئله فقط روشن کردن Intrusion Policy نیست؛ مسئله این است که بدانیم کدام سرویس‌ها حساس‌اند، کدام segmentها باید سخت‌گیرانه‌تر دیده شوند، و چه زمانی می‌شود از alert به جلوگیری فعال رسید.

در مستندات رسمی Cisco Firepower، Intrusion Policy کنار Access Control Policy و Network Analysis Policy معنی پیدا می‌کند. این نکته مهم است، چون IPS مستقل از طراحی policy خوب کار نمی‌کند. اگر access ruleها خیلی باز باشند، اگر zoneها دقیق تعریف نشده باشند، یا اگر logging به درستی تنظیم نشده باشد، IPS هم خروجی قابل اتکایی نمی‌دهد.

از policy عمومی شروع نکنید

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

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

اول alert، بعد block

در بیشتر شبکه‌ها مسیر کم‌ریسک این است که ابتدا ruleهای IPS در حالت مشاهده و alert بررسی شوند. این مرحله نباید بی‌پایان بماند، اما حذف آن هم خطرناک است. چند روز تا چند هفته داده واقعی کمک می‌کند بفهمیم کدام signatureها نویز تولید می‌کنند، کدام رخدادها واقعاً مهم‌اند، و کدام سرویس‌ها با ruleهای سخت‌گیرانه مشکل پیدا می‌کنند.

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

Network Analysis Policy را دست‌کم نگیرید

بخشی از کیفیت تشخیص به این برمی‌گردد که Firepower ترافیک را چطور decode و normalize می‌کند. Network Analysis Policy در همین نقطه مهم می‌شود. اگر فقط روی Intrusion Policy تمرکز کنیم و تحلیل پایه ترافیک را نادیده بگیریم، ممکن است رخدادها ناقص یا گمراه‌کننده شوند.

برای شبکه‌هایی که سرویس‌های خاص، پروتکل‌های قدیمی، یا ترافیک غیرمعمول دارند، بررسی این لایه ضروری است. هدف این نیست که تنظیمات را بی‌دلیل پیچیده کنیم؛ هدف این است که IPS داده‌ای را تحلیل کند که درست فهمیده شده باشد.

Logging باید قابل پیگیری باشد

یک alert بدون context به درد عملیات نمی‌خورد. حداقل باید مشخص باشد رخداد از کدام rule آمده، سورس و مقصد چه بوده، کدام access rule اجازه عبور داده، چه application یا URL category درگیر بوده و آیا رخداد تکرار شده یا نه. اگر این اطلاعات در FMC یا سامانه لاگ مرکزی قابل جست‌وجو نباشد، تیم بعد از مدتی alertها را نادیده می‌گیرد.

برای همین قبل از سخت‌گیر کردن IPS باید مسیر لاگ، retention و فرآیند triage روشن باشد. خروجی قابل استفاده یعنی رخداد امنیتی بتواند به تصمیم مشخص برسد: false positive است، نیاز به تغییر policy دارد، باید block شود، یا باید در سطح endpoint/server بررسی شود.

چه زمانی tuning لازم است؟

اگر بعد از فعال‌سازی IPS تعداد زیادی رخداد تکراری روی سرویس‌های سالم می‌بینید، اگر ruleهای مهم همیشه در حالت alert مانده‌اند، اگر تیم فقط رخدادهای critical را نگاه می‌کند و بقیه را رها کرده، یا اگر بعد از هر تغییر policy ترس از قطعی دارید، یعنی tuning جدی لازم است.

tuning خوب معمولاً از چند کار ساده شروع می‌شود: محدود کردن بازرسی به مسیرهای درست، جدا کردن policy برای دارایی‌های حساس، بررسی رخدادهای پرتکرار، مستندسازی exceptionها، و تبدیل تدریجی ruleهای مطمئن از alert به block. این کار باید دوره‌ای تکرار شود، چون شبکه و تهدیدها ثابت نمی‌مانند.

مسیر پیشنهادی برای اجرا

• اول asset و segmentهای مهم را مشخص کنید.
• Access Control Policy را تمیز کنید تا IPS روی مسیرهای مبهم ننشیند.
• برای شروع، IPS را روی ترافیک حساس در حالت alert بررسی کنید.
• رخدادهای پرتکرار و false positiveها را جداگانه تحلیل کنید.
• برای ruleهای مطمئن، block را مرحله‌ای فعال کنید.
• بعد از هر تغییر، deploy و لاگ را کنترل کنید.

اگر در حال طراحی یا بازبینی فایروال سازمانی هستید، بهتر است این کار کنار طراحی Access Control Policy در Cisco Firepower و مسیر کلی پیاده‌سازی فایروال سازمانی دیده شود. IPS جدا از معماری ruleها نتیجه خوبی نمی‌دهد.

منابع رسمی

• Cisco Firepower Threat Defense Configuration Guide – Intrusion Policies
• Cisco Secure Firewall Threat Defense Configuration Guides