کاهش False Positive در F5 ASM؛ از Learning تا Exception قابل دفاع

False positive در F5 ASM یعنی request سالم به‌اشتباه مشکوک یا مخرب تشخیص داده شود. در محیط عملیاتی، این اتفاق فقط یک هشدار امنیتی نیست؛ ممکن است پرداخت، ورود کاربر، upload فایل، API موبایل یا پنل داخلی را از کار بیندازد. واکنش سریع اما اشتباه این است که Rule یا Signature را کلی غیرفعال کنیم. واکنش درست این است که violation را دقیق بخوانیم و exception را تا حد ممکن محدود نگه داریم.

اگر هنوز تفاوت نقش ASM با Load Balancer روشن نیست، اول مطلب F5 ASM چیست و چه فرقی با Load Balancer دارد؟ را ببینید.

هر violation را به URL و parameter واقعی وصل کنید

گزارش ASM باید به یک رفتار واقعی برنامه وصل شود. فقط دیدن نام Signature یا violation کافی نیست. باید بدانید request مربوط به کدام URL بوده، parameter کدام بوده، کاربر چه کاری انجام می‌داده، content-type چه بوده و آیا همان رفتار در نسخه جدید برنامه تغییر کرده است یا نه.

policy: customer-portal-asm
url: /profile/upload
method: POST
content-type: multipart/form-data
violation: attack signature detected / file type check
parameter: document
business_owner: customer portal team
decision: allow only expected file types, keep signature enabled elsewhere

Learning را با تغییرات برنامه هماهنگ کنید

اگر تیم توسعه مسیر جدید، فیلد جدید یا فرمت جدیدی اضافه کرده باشد، ASM ممکن است رفتار سالم را غیرعادی ببیند. بهتر است قبل از releaseهای مهم، مسیرهای جدید در محیط staging یا بازه کنترل‌شده بررسی شوند. اگر بعد از release ناگهان false positive زیاد شد، اول changelog برنامه را کنار لاگ ASM بگذارید.

Exception محدود بهتر از خاموش کردن Signature است

در بیشتر سناریوها لازم نیست یک Signature برای کل سایت خاموش شود. اگر مشکل فقط روی یک parameter یا یک URL است، همان محدوده را اصلاح کنید. exception باید دلیل، مالک و تاریخ بازبینی داشته باشد. اگر این اطلاعات ثبت نشود، بعد از مدتی Policy پر از استثناهای قدیمی می‌شود و کسی جرئت حذف کردنشان را ندارد.

• Exception را تا سطح URL، parameter، file type یا flow خاص محدود کنید.
• اگر payload سالم شبیه حمله است، علت برنامه‌ای آن را مستند کنید.
• بعد از هر exception، یک تست منفی هم انجام دهید تا حمله مشابه آزاد نشده باشد.
• استثناهای موقت release را بعد از پایدار شدن برنامه دوباره بررسی کنید.

Blocking را مرحله‌ای فعال کنید

برای برنامه حساس، رفتن ناگهانی از حالت باز به Blocking کامل ریسک دارد. بهتر است اول مسیرهای پرترافیک و شناخته‌شده، بعد endpointهای حساس، و در نهایت بخش‌های کم‌داده‌تر وارد کنترل سخت‌گیرانه شوند. معیار تصمیم باید داده لاگ، تجربه تیم برنامه و نتیجه تست باشد، نه عجله برای «فعال شدن WAF».

جمع‌بندی

کاهش false positive در F5 ASM یعنی حفظ تعادل بین امنیت و پایداری سرویس. راه‌حل خوب نه خاموش کردن دفاع است، نه سخت‌گیری کور. باید violation را به request واقعی وصل کرد، learning را با تغییرات برنامه هماهنگ کرد، exception را محدود نوشت و بعد از هر تغییر دوباره تست کرد.

منبع رسمی: برای جزئیات نسخه‌ها و قابلیت‌ها، مستندات F5 BIG-IP documentation مرجع اصلی است.