چرا بعضی پروژه‌های امنیتی، با وجود انتخاب ابزار مناسب، در مرحله اجرا متوقف می‌شوند؟
در سه مطلب قبلی، مسیر را از فناوری XDR و نیاز به تیم متخصص در مدل‌های MDR و MXDR تا مقایسه هزینه SOC داخلی با برون‌سپاری پایش امنیتی مرور کردیم. اگر آن مطالب را خوانده باشید، احتمالاً این پرسش برایتان پیش آمده است: «اگر تصمیم به استفاده از MDR گرفتیم، قدم اول چیست؟»
تصمیم به خرید سرویس، به‌تنهایی به معنی شروع موفق آن نیست. چالش اصلی معمولاً خود فناوری نیست؛ بلکه عبور درست از وضعیت فعلی سازمان به مدل جدید پایش و پاسخ است. نگرانی از قطعی سرویس، تداخل با سامانه‌های موجود، حجم داده‌های امنیتی و ناآشنایی تیم داخلی با روند رسیدگی به حادثه می‌تواند اجرای پروژه را به تأخیر بیندازد.
در این مطلب، مراحل استقرار MDR را از ارزیابی اولیه تا نظارت بر اجرای سرویس مرور می‌کنیم؛ مراحلی که کمک می‌کنند سازمان بداند چه چیزی را باید پوشش دهد، چگونه سرویس را راه‌اندازی کند و پس از شروع کار، چه مواردی را پیگیری کند.
گام اول: پیش از شروع، بدانید چه دارایی‌هایی را باید پوشش دهید برای طراحی پوشش امنیتی، ابتدا باید تصویر روشنی از دارایی‌های سازمان داشته باشیم. چند Endpoint و سرور در شبکه وجود دارد؟ کدام سرورها و سامانه‌ها برای ادامه فعالیت سازمان حیاتی‌اند؟ چه بخش‌هایی از شبکه بیشتر در معرض خطر قرار دارند؟
در این مرحله، وضعیت فعلی هم بررسی می‌شود؛ از جمله سیاست‌های آنتی‌ویروس، وضعیت به‌روزرسانی‌ها و وصله‌های امنیتی و لاگ‌هایی که در دسترس هستند. نتیجه این بررسی مشخص می‌کند سرویس MDR قرار است کدام بخش‌ها را پوشش دهد و کدام دارایی‌ها باید زودتر در اولویت قرار بگیرند.
گ ام دوم: سرویس را یک‌باره در کل سازمان فعال نکنید استقرار MDR لازم نیست از همان روز اول همه زیرساخت را دربر بگیرد. روش مناسب این است که ابتدا سرویس روی گروه محدودی از نقاط پایانی، به‌عنوان گروه پایلوت ، اجرا شود و سپس به‌تدریج گسترش پیدا کند.
در این مرحله، نحوه جمع‌آوری داده‌های امنیتی یا تله‌متری نیز تنظیم می‌شود. هدف آن است که تیم پایش اطلاعات کافی برای شناسایی تهدیدها داشته باشد، بدون آنکه حجم داده‌ها بیش از نیاز شود. تنظیم نامناسب می‌تواند دو مشکل ایجاد کند: یا اطلاعات کافی برای دیدن بعضی تهدیدها جمع‌آوری نشود و نقاط کور به وجود بیاید، یا هشدارهای غیرضروری آن‌قدر زیاد شوند که رسیدگی به موارد مهم دشوار شود.
گام سوم: هشدارهای کم‌اهمیت را کنار بزنید تا موارد مهم دیده شوند وقتی اجرای پایلوت پایدار شد، قواعد شناسایی تهدید با توجه به شرایط و سامانه‌های سازمان تنظیم می‌شوند. این کار کمک می‌کند هشدارهای کم‌اهمیت یا نامرتبط کاهش یابند و مواردی که نیازمند توجه هستند، بهتر دیده شوند.
پس از آن، تیم پایش امنیتی، داده‌های امنیتی که در دسترس سرویس است را بررسی می‌کند و روند شناسایی، اولویت‌بندی و اطلاع‌رسانی درباره حوادث آغاز می‌شود. در اجرای درست، فعال‌سازی MDR نباید باعث افت محسوس کارایی شبکه یا توقف سرویس‌های عملیاتی شود. به همین دلیل، استقرار مرحله‌ای و هماهنگی با تیم‌های سازمان در تمام این گام اهمیت دارد.
گام چهارم: فقط سرویس را فعال نکنید؛ بلکه اجرای تعهداتش را هم پیگیری کنید پس از راه‌اندازی، سرویس وارد چرخه عملیاتی می‌شود. تیم متخصص، پایش شبانه‌روزی را طبق سطح سرویس انتخاب‌شده انجام می‌دهد. هشدارها بررسی و اولویت‌بندی می‌شوند و در صورت تأیید تهدید فعال، اطلاع‌رسانی از مسیرهایی که برای آن سطح سرویس در نظر گرفته شده است، مانند پیامک یا تماس، انجام می‌شود.
در این مرحله، سازمان باید بر اجرای تعهدات توافق‌شده در SLA نظارت داشته باشد. سرویس MDR در سطح‌هایی مانند Optimum و Expert ارائه می‌شود و قابلیت‌ها و تعهدات هر سطح با سطح دیگر تفاوت دارد. بسته به سطح انتخاب‌شده، این موارد می‌تواند شامل عمق حسگرهای پیشرفته، اعلام کتبی هشدارهای مهم، نگهداری هشدارها تا یک سال، عملیات فارنزیک تا سقف ساعت مشخص، ارزیابی وضعیت امنیتی شبکه و اعلام نقاط ضعف و قابل بهبود باشد.
چون چارچوب پاسخ به حادثه در SLA سرویس مشخص شده است، تدوین یک Playbook اختصاصی برای هر سازمان، پیش‌شرط راه‌اندازی MDR نیست. کار اصلی در این مرحله، پیگیری این است که تعهدات سطح انتخاب‌شده در عمل اجرا شوند. برای نمونه:
1.آیا هشدارهای مهم از مسیر و در زمان توافق‌شده به سازمان می‌رسند؛ از جمله پیامک، تماس یا گزارش کتبی، در مواردی که برای سطح سرویس تعریف شده است؟
2. آیا گزارش‌های دوره‌ای، علاوه بر رخدادها، آسیب‌پذیری‌ها و نقاط قابل بهبود شبکه را هم نشان می‌دهند؟
3. آیا اطلاعات مربوط به موارد توافق‌شده، مانند زمان اطلاع‌رسانی، هشدارهای تأییدشده یا ساعات استفاده‌شده از عملیات فارنزیک، در گزارش‌ها روشن و قابل بررسی است؟
نتیجه این پیگیری باید به تصمیم‌های عملی منجر شود. برای مثال، گزارش‌ها می‌توانند به اولویت‌بندی نصب وصله‌ها، رفع نقاط ضعف شبکه یا بررسی نیاز به ارتقای سطح سرویس کمک کنند. اگر داده‌های واقعی نشان دهند که نیازهای سازمان از چارچوب استاندارد سرویس فراتر می‌رود، آن زمان می‌توان بررسی کرد که آیا تدوین Playbook اختصاصی لازم است یا نه. چنین تصمیمی باید بر اساس نیاز مشخص سازمان گرفته شود، نه به‌عنوان یک مرحله اجباری برای همه مشتریان.
در این گام، سایا ارتباط نقش واسط و ناظر فنی را میان سازمان و تیم پایش بر عهده دارد: اجرای تعهدات SLA را پیگیری می‌کند، گزارش‌های دوره‌ای را بررسی می‌کند و پیگیر می‌شود که هشدارها و گزارش‌ها به دست مشتری برسند و برای آن‌ها اقدام مناسب تعریف شود.
سایا ارتباط؛ نقطه اتصال تخصص معماری و بازدهی اقتصادی برون‌سپاری پایش امنیتی به معنی کنار گذاشتن نظارت بر دارایی‌های دیجیتال نیست؛ یعنی اجرای پایش و پاسخ طبق مدل سرویس، با پیگیری روشن‌تر تعهدات و گزارش‌ها.
در عمل، سازمان‌ها معمولاً با سه پرسش روبه‌رو هستند:
1. کدام سطح سرویس برایشان مناسب است؟
2.. چه سیاستی برای جمع‌آوری داده‌های امنیتی در نظر بگیرند؟
3. و چگونه مطمئن شوند تعهدات SLA اجرا می‌شود؟
سایا ارتباط به‌عنوان حلقه فنی میان سازمان و تیم پایش، در ارزیابی فنی و اقتصادی، انتخاب سطح سرویس و تنظیم نیازهای اجرایی سازمان نقش دارد. همچنین اجرای تعهدات SLA و رسیدن گزارش‌ها به مشتری را پیگیری می‌کند تا خروجی سرویس به تصمیم‌ها و اقدام‌های قابل اجرا در سازمان تبدیل شود.
☎️ 051-3846 1200 | 051-9100 2052 .
نظرات کاربران