چگونه FireMon تغییرات فایروال را قبل از استقرار ارزیابی می کند

تجزیه و تحلیل گام به گام ارزیابی قبل از تغییر (PCA)

تغییرات فایروال جایی است که نیت خوب به قطع تبدیل می شود.

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

ارزیابی پیش از تغییر (PCA) برای پاسخ به یک سوال ساده وجود دارد:

این تغییر پس از اجرا چه تاثیری بر ریسک و اتصال خواهد داشت؟

در این پست نحوه ارزیابی تغییرات فایروال توسط FireMon به صورت گام به گام شرح داده شده است، بنابراین شما می توانید دقیقاً درک کنید که چگونه یک خطر قبل از تبدیل شدن به یک حادثه شناسایی می شود.

مشکل: شما نمی توانید تاثیر تغییر در انزوا را ببینید

قوانین فایروال به طور مستقل کار نمی کنند. هر تغییر با:

• مجموعه‌های خط‌مشی موجود برای چندین دستگاه
• توپولوژی شبکه و مسیرهای مسیریابی
• گروه‌های شی و سیاست‌های میراث
• نقاط اجرایی بالادست و پایین دست

یک تغییر قانون می تواند:

• ایجاد دسترسی بین مناطق
• قوانین انصراف موجود را جایگزین کنید
• مسیرهای حرکت جانبی بالقوه را گسترش دهید
• وابستگی های اتصال برنامه را قطع کنید

اکثر تیم ها سعی می کنند تغییرات را به صورت دستی با بررسی پیکربندی ها، ردیابی جریان ها و تکیه بر تجربه تأیید کنند.

این رویکرد مقیاس پذیر نیست. مهمتر از آن، رفتار واقعی سیاست در محیط را مدل نمی کند.

ارزیابی قبل از تغییر چه می کند؟

ارزیابی قبل از تغییر، تأثیر تغییر فایروال پیشنهادی را قبل از اجرا ارزیابی و مدل می‌کند.

به جای پرسیدن:
“آیا این قانون درست به نظر می رسد؟”

PCA می پرسد:
اگر این تغییر اجرا شود چه خطری وجود خواهد داشت؟

ورودی و خروجی PCA

درک PCA مستلزم نگاه کردن به آنچه در تجزیه و تحلیل می رود و آنچه بیرون می آید، دارد.

ورودی ها

• تغییر یا اصلاح قانون پیشنهادی
• تنظیمات فایروال در سطح محیطی
• توپولوژی شبکه و اطلاعات مسیریابی
• گروه های شی و نقشه آدرس
• نظم موجود و اولویت قوانین

خارج می شود

• مسیرهای دسترسی تازه فعال شده است
• تغییرات در اتصالات موجود
• نقض قوانین بر اساس قوانین خاص
• تضادهای خط مشی مانند سایه زدن یا لغو
• بینش ریسک و راهنمایی های اصلاح

مرحله 1: تغییر پیشنهادی را بپذیرید

هر ارزیابی با تغییر خاصی شروع می شود.

این ممکن است شامل موارد زیر باشد:

• یک قانون جدید اضافه کنید
• منبع، مقصد یا پورت را تغییر دهید
• ترتیب یا اولویت قوانین را تغییر دهید
• گسترش گروه های اشیاء

تغییر نمونه

حل: منبع = App_Server_Group
مقصد = DB_Servers
پورت = 1433 (SQL)

در این مرحله تغییر به صورت مجزا ارزیابی نمی شود. به عنوان یک دلتا نسبت به وضعیت فعلی سیاست تلقی می شود.

مرحله 2: مدل سیاست فعلی را بسازید

FireMon یک مدل محیط نرمال شده را با استفاده از:

• تنظیمات فایروال بین فروشنده
• توپولوژی شبکه، از جمله مسیریابی، مناطق و رابط ها
• گروه های شی و نقشه آدرس
• نظم موجود و اولویت قوانین

این مدل نشان دهنده دسترسی موثر فعلی در محیط است.

نه فقط آنچه پیکربندی شده است، بلکه آنچه در واقع بر اساس سیاست و توپولوژی موجود است.

مرحله 3: تغییر پیشنهادی را در مدل اعمال کنید

قانون پیشنهادی در یک شبیه‌سازی برای حالت سیاست مدل‌سازی شده اعمال می‌شود.

اینجاست که PCA با بازرسی دستی متفاوت است:

• این تغییر در مدل سیاست اعمال می شود، نه فقط بررسی می شود
• فعل و انفعالات قوانین در سراسر محیط مورد ارزیابی مجدد قرار می گیرند
• مسیرهای دسترسی بر اساس سیاست و توپولوژی دوباره ارزیابی می شوند

سیستم با این پاسخ پاسخ می دهد: اگر این قانون وجود داشته باشد، اکنون چه ترافیکی مجاز است که قبلا وجود نداشت؟

مرحله 4: تغییرات مسیر دسترسی را ارزیابی کنید

FireMon تجزیه و تحلیل می کند که چگونه این تغییر اتصال بین سیستم ها را تغییر می دهد.

این شامل:

1. مسیرهای تازه افتتاح شده

• جریان از منبعی به مقصدی که قبلا وجود نداشته است
• دسترسی گسترده فراتر از محدوده مورد نظر

2. مسیرهای بالقوه حرکت جانبی

• این که آیا این تغییر مسیرهای اضافی بین سیستم ها را امکان پذیر می کند یا خیر
• آیا مناطق حساس به طور غیرمستقیم قابل دسترسی می شوند یا خیر

3. نقض قوانین تقسیم بندی

• اینکه آیا این قانون با سیاست‌های تقسیم‌بندی تعریف‌شده مغایرت دارد یا خیر
• آیا مناطق محدود متصل می شوند

نتیجه نمونه

در نظر گرفته شده برای:

App_Server_Group → DB_Servers (پورت 1433)

نتیجه واقعی:

App_Server_Group → DB_Servers (1433)
App_Server_Group → Backup_DB (1433)
App_Server_Group → Reporting_DB (1433)

تفاوت بین قصد و نتیجه در جایی است که خطر نهفته است.

مرحله 5: تشخیص تضادها و لغو قوانین

رفتار دیوار آتش تا حد زیادی به ترتیب و اولویت قوانین بستگی دارد.

PCA ارزیابی می کند:

• قوانین انصراف لغو شده که می توان آنها را دور زد
• قوانین اضافی معرفی شده توسط این تغییر

این تغییر را تضمین می کند:

• همانطور که انتظار می رود کار می کند
• کنترل‌های موجود را بی‌صدا نمی‌شکند

مرحله 6: ارزیابی در برابر سیاست و الزامات انطباق

خروجی مدل شده را می توان بر اساس سیاست های خاصی ارزیابی کرد، از جمله:

• الزامات تقسیم بندی
• استانداردهای امنیت داخلی
• الزامات انطباق زمانی که مشخص شود

این پاسخ می دهد: آیا این تغییر هرگونه کنترل اجباری را نقض می کند؟

به جای یافتن مشکلات در حین ممیزی یا پس از اجرا، آنها زودتر در فرآیند شناسایی می شوند.

مرحله 7: اطلاعات ریسک و راهنمایی تولید کنید

نتیجه نهایی PCA به سادگی عبور یا شکست نیست. اطلاعات مفیدی را ارائه می دهد:

• راه های دسترسی جدید معرفی شده اند
• قرار گرفتن در معرض خطر بالا ایجاد می شود
• نقض قوانین مشاهده شده است
• راهنمای اصلاح

این به تیم ها اجازه می دهد:

• با اطمینان تغییر را تایید کنید
• قبل از استقرار قانون را اصلاح کنید
• تغییرات ناامن را رد کنید

این در عمل چگونه به نظر می رسد؟

بدون PCA:

• تغییری ایجاد شده است
• یک مشکل بعداً کشف می شود، مانند قطع، قرار گرفتن در معرض یا ناسازگاری
• تیم ها برای تعمیر و عقب نشینی تلاش می کنند

با PCA:

• تغییر از قبل ارزیابی می شود
• خطر زود شناسایی می شود
• این قانون قبل از رسیدن به تولید وصله می شود

چرا این موضوع در محیط های هیبریدی اهمیت دارد

در محیطی مدرن:

• خط‌مشی‌های امنیتی شبکه شامل لایه‌های on-prem، cloud و micro-segmentation می‌شوند
• تغییرات توسط چندین تیم انجام می شود
• وابستگی ها همیشه قابل مشاهده نیستند

این شکاف بین:

آنچه شما قصد داشتید اجازه دهید و آنچه که شبکه در واقع اجازه می دهد.

ارزیابی قبل از تغییر این شکاف را برطرف می کند.

تغییر بزرگتر: از اجرای تغییر تا تضمین تغییر

مدیریت فایروال موضوع آزمون و خطا نیست.

در یک محیط بالغ، تغییرات کورکورانه ایجاد نمی شوند و بعداً اصلاح نمی شوند. از آنها انتظار می رود که در اولین بار طبق برنامه کار کنند.

چالش واقعی ایجاد تغییرات نیست. تضمین می کند که این تغییرات به نتیجه مطلوب می رسد و دسترسی ناخواسته ای را ایجاد نمی کند.

ارزیابی قبل از تغییر این سطح از اطمینان را فراهم می کند.

تیم ها به جای تکیه بر بررسی دستی یا حدس و گمان می توانند:

• تأیید کنید که تغییر پیشنهادی نیازهای کسب و کار را برآورده می کند
• ریسک ناشی از این تغییر را اندازه گیری و درک کنید
• شناسایی و حل مشکلات قبل از استقرار
• نحوه تأثیرگذاری این تغییر بر سیاست در طول زمان را حفظ کنید

این در مورد حدس زدن و واکنش نیست.

این در مورد اجرای تغییرات با اطمینان است که توسط اعتبارسنجی، بینش ریسک و مدیریت مداوم پشتیبانی می شود.

حرف آخر

بسیاری از خرابی های فایروال به عنوان یک تغییر درست به نظر می رسد.

سوال عمدی نیست مهم است که قبل از اعمال تغییر، ریسک کاملاً درک و کنترل شود.

ارزیابی قبل از تغییر FireMon تضمین می کند که:

• ریسک شناسایی، اندازه گیری و گزارش می شود
• دسترسی محدود به آنچه مورد نیاز است است
• تغییرات نیازهای پیش‌بینی‌شده کسب‌وکار را بدون مواجهه غیرضروری برآورده می‌کنند

زیرا عملیات شبکه ایمن به معنای عدم تغییر است. آنها در مورد مالکیت نتیجه آن تغییرات هستند.