در WAF، exception اجتنابناپذیر است. هیچ محیط production بدون تنظیم و استثنا مدت زیادی سالم نمیماند. اما تفاوت زیادی هست بین exception دقیق و خاموش کردن بخشی از دفاع. اگر هر false positive با disable کردن یک signature روی کل سایت حل شود، بعد از مدتی WAF فقط از بیرون روشن است و از داخل پر از مسیرهای کور شده است.
مدیریت Exception یعنی مشکل کاربر واقعی حل شود، اما سطح دفاع تا حد ممکن باقی بماند. برای این کار باید بدانیم خطا دقیقاً روی کدام host، path، method، پارامتر، header یا payload رخ داده است. اگر این دادهها را نداریم، اول باید log و request sample را کامل کنیم. Exception بدون شواهد، بدهی امنیتی است.
Exception باید کوچک شروع شود
فرض کنید یک endpoint آپلود فایل در FortiWeb یا F5 ASM بهخاطر یک الگوی خاص block میشود. راه ساده این است که signature را برای کل دامنه خاموش کنیم. راه درست این است که بررسی کنیم آیا مشکل فقط روی همان endpoint است، آیا method مشخصی دارد، آیا فقط یک پارامتر درگیر است، و آیا میتوان exception را فقط برای همان مسیر ساخت. هرچه محدوده exception کوچکتر باشد، ریسک کمتر است.
- Exception را به host و path مشخص محدود کنید.
- اگر ممکن است method را هم شرط کنید.
- پارامتر یا header دقیق را مشخص کنید.
- برای API، token/client معتبر را در نظر بگیرید.
- برای هر exception تاریخ بازبینی بگذارید.
Exception دائمی همیشه مشکوک است
بعضی exceptionها واقعاً طولانیمدت هستند، اما باید دلیل داشته باشند. اگر یک exception فقط برای عبور از بحران ساخته شده، باید بعد از اصلاح application یا تغییر policy حذف شود. در غیر این صورت WAF کمکم به فهرست استثناهایی تبدیل میشود که هیچکس جرأت دست زدن به آنها را ندارد. این وضعیت در audit امنیتی هم قابل دفاع نیست.
برای همین بهتر است exceptionها owner داشته باشند. مالک میتواند تیم application، تیم امنیت یا مسئول سرویس باشد، اما نباید بینام بماند. کنار هر exception باید علت، تاریخ، شواهد، ریسک و تاریخ بازبینی ثبت شود. اگر WAF این metadata را خوب نگه نمیدارد، باید در مستندات داخلی یا change system ثبت شود.
بعد از Exception چه چیزی را مانیتور کنیم؟
ساخت exception پایان کار نیست. باید ببینیم آیا خطای کاربر واقعاً حل شده، آیا ترافیک مشکوک از همان مسیر بیشتر شده، آیا signatureهای دیگر هنوز فعالاند، و آیا SIEM یا لاگ WAF همچنان دید کافی دارد. اگر exception باعث شد eventها کاملاً ناپدید شوند، یعنی visibility هم از دست رفته است.
یک روال قابل دفاع
روال پیشنهادی ساده است: اول request واقعی را پیدا کنید، بعد rule یا signature درگیر را مشخص کنید، سپس exception محدود بسازید، بعد با همان سناریوی خطا تست کنید، و در نهایت یک بازه بازبینی بگذارید. اگر مسئله از طراحی application است، exception نباید جای اصلاح application را بگیرد؛ فقط باید زمان امن برای اصلاح بخرد.
این موضوع با کاهش False Positive در FortiWeb، کاهش False Positive در F5 ASM و Tuning WAF برای API مرتبط است. Exception خوب قرار نیست WAF را بیدردسر کند؛ قرار است دفاع را دقیقتر و قابل نگهداریتر کند.
Exception را در گزارشهای دورهای زنده نگه دارید
بسیاری از exceptionهای خطرناک از روز اول خطرناک نبودهاند. برای حل یک مشکل واقعی ساخته شدهاند، اما بعد از تغییر application، حذف endpoint یا تغییر رفتار کاربران همچنان باقی ماندهاند. برای همین exceptionها باید در گزارش دورهای WAF دیده شوند: کدامها هنوز hit دارند، کدامها دیگر استفاده نمیشوند، کدامها روی مسیر حساس هستند و کدامها میتوانند محدودتر شوند.
اگر exception حذفشدنی نیست، حداقل باید compensating control داشته باشد. مثلاً اگر برای یک endpoint خاص مجبور به کاهش حساسیت هستیم، لاگ همان endpoint دقیقتر شود، rate محدودتر شود، احراز هویت سختگیرانهتر بماند یا مانیتورینگ جدا داشته باشد. این نگاه باعث میشود exception از «خاموش کردن دفاع» به «مدیریت ریسک مشخص» تبدیل شود.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
