از آنجایی که نقشها و مسئولیتهای تیم پاسخدهی به حادثه عملکردهای مختلفی را دربر میگیرند و محدود به کارمندان فنی نیستند، میتوان بخشهایی از تیم پاسخ به رخداد (CSIRT) را براساس بودجه و تخصص خود برونسپاری کرد. در ادامه خلاصهی کوتاهی از مزایا و معایب برونسپاری نقشهای تیم پاسخدهی به حادثه مطرح میگردد.
عملکردهای CSIRT که میتوان برونسپاری کرد | مزایا | معایب |
ساخت برنامه پاسخدهی به حادثه | مشاوران خارجی در ایجاد برنامه پاسخدهی به حادثه متخصص هستند. | ممکن است برنامهای که توسط شخص سومی ساخته شده باشد، مالکیت و نظارت داخلی نداشته باشد. |
مانیتورینگ | یک مرکز عملیات امنیت مدیریتشده (MSSP) یا فراهمکنندهی شناسایی و پاسخ مدیریتشده (MDR) میتواند برای سازمانهایی که بهطور ۲۴ ساعته کارمند ندارند یا از تخصص کافی بیبهره هستند، مناسب باشد. | ممکن است در صورت عدم انتخاب درستMSSP ، بین شناسایی رخداد و شروع تحقیق و بررسی تأخیر زمانی وجود داشته باشد. همچنین برونسپاری سازمان را از مسئولیتهای قانونی رها نمیکند. |
تحقیق و بررسی | شرکتهای جرمشناسی رایانهای وجود دارند که متخصص رسیدگی به تحقیقات هستند. | ممکن است وارد کردن متخصصان امنیتی خارجی زمان ببرد و معمولاً کار پرهزینهای است. |
اصلاح | شاید با برونسپاری بتوان تخصص امنیتی بیشتری پیدا کرد. | ممکن است تیمهای خارجی دسترسی به حقوق و ساختار لازم برای رسیدگی مناسب به مسئله را نداشته باشند. |
ارتباطات داخلی | حقیقتاً برونسپاری در این مورد هیچ مزیتی ندارد. | این عملکرد حیاتی نباید توسط شخص سوم انجام پذیرد. |
روابط عمومی | ممکن است شرکت روابط عمومی بتواند بهسرعت واکنش نشان دهد. همچنین شرکتهایی هستند که در ارتباط در زمان بحران تخصص دارند. | ممکن است شرکت روابط عمومی به اندازهی خود شرکت با کسبوکار و ریسکهای بازار آشنا نباشد و همچنین ممکن است با اطلاعات حساس سروکار داشته باشد. |
حقوقی | ممکن است مشاور خارجی قبلاً برای مشتری دیگری به حادثهی مشابهی رسیدگی کرده باشد. | معمولاً سرعت واکنش مشاوران خارجی کمتر از مشاوران داخلی است که درهرصورت باید در جریان قرار بگیرند. |
جدول ۲: مزایا و معایب برونسپاری عملکردهای مختلف تیم پاسخدهی به حادثه
محل قرارگیری کارمندان تیم پاسخدهی به حادثه
یک امر همیشه در حوادث امنیتی صدق میکند: این حوادث همیشه در بدترین مواقع رخ میدهند؛ آخر هفته، بعد از ساعت کاری، در تعطیلات یا زمان استراحت شخصی. هکرها در فصل خرید در تعطیلات نقضهای امنیتی گستردهای را انجام دادهاند، زیرا منشیها عجله دارند و مشتریان در بررسی خریدهای آنلاین خود کوتاهی میکنند. این نظریه وجود دارد که عاملان مخرب آخر هفته یا در تعطیلات ملی حمله میکنند، زیرا میدانند که کارمندان امنیتی آماده نیستند که جلویشان را بگیرند.
به همین دلیل مهم است که کارمندان تیم پاسخدهی به حادثه از لحاظ جغرافیایی پراکنده باشند. ایدهآل این است که فردی ۲۴ ساعته بیدار و در دسترس باشد. همچنین باید برای هر عضو تیم افزونگی وجود داشته باشد، مثلاً بیش از یک متخصص قانونی یا نمایندهی روابط عمومی داشته باشیم. راه سادهای برای دستیابی به این مهم این است که وقتی اعضای تیم در دسترس نیستند، برای خود نماینده تعیین کنند.
اگر سازمان کوچکی داشته باشیم یا سازمانی در یک کشور باشد اما مشتریانش در سراسر دنیا باشند، میتوانیم در ساعات تعطیلی، آخر هفتهها و در طول تعطیلات منطقهی جغرافیایی خود، عملکردهای تیم پاسخدهی به حادثه را برونسپاری کنیم.
توسعه یک برنامهی پاسخدهی به حادثه
ایجاد یک برنامهی Incident Response اولین کاری است که تیم پاسخدهی به حادثه، چه داخلی و چه برونسپاری شده، باید انجام دهد. سازمانهایی که تجربه کافی ندارند میتوانند یک مشاور استخدام کنند تا در آمادهسازی برنامه به آنها کمک کند. مهم است که تیم برای ایجاد برنامه اعضای کافی داشته باشد (حتی اگر از مشاوران خارجی کمک گرفته شود) برای اینکه تیم پاسخدهی به حادثه، در صورت بروز رخداد، قادر به پیادهسازی برنامه IR باشد.
در ادامه، اقدامات حیاتی برای توسعهی برنامهی پاسخ به حادثه یا IRP مطرح میشود. واقعاً مهم نیست که این موارد اسلاید، سند یا صفحه گسترده باشند. مهمترین چیز این است که پیدا کردن برنامه در زمان بحران آسان باشد و فردی که در آن لحظه دچار سردرگمی است بتواند بهراحتی درکش کند.
- بدست آوردن موافقت مدیران اجرایی: رهبر تیم کسی است که باید این مسئله را پیش ببرد. اگر این فرد عضو تیم اجرایی مثلاً CIO یا CISO باشد، این قدم بسیار سادهتر خواهد شد. باید اطمینان حاصل شود که CEO، CFO (فردی که شاید با سرمایهگذاران سروکار داشته باشد)، مشاور ارشد و اعضای کلیدی دیگر تیم اجرایی نسبت به خط مشی آگاهی و موافقت لازم را دارند. تیم پاسخدهی به حادثه، به اطلاعات حساس نگاه خواهد کرد و جزئیات را به اشتراک خواهد گذاشت، پس ضروری است که تیم در سطح اجرایی مورد اعتماد و تحت پشتیبانی باشد.
- تائید نقشها و مسئولیتها: با توجه به دستورالعملهای بالا مبنی بر استخدام کارمندان، تعریف نقشها باید مورد تایید قرار گیرد و اطمینان حاصل شود که همه توافق لازم را دارند. باید برای زمانی که کسی در تعطیلات بود یا قابلدسترس نبود، برای هر نقش یک جایگزین در نظر گرفته شود. مهم است که وقتی به تائید اجرایی نیاز است، موافقت مدیرعامل اتخاذ شود و تصمیم گرفته شود که تیم پاسخدهی به حادثه در چه شرایطی میتواند خط مشی خود را پیش ببرد.
- ثبت داراییهای حیاتی: سیستمهای حیاتی و مالکیتهای فکری باید مشخص شوند. ارزش کد منبع و داراییهای وب نیز باید درک شود. باید از تأثیر مالی قطع شدن یک شبکه آگاه بود. باید بدانیم که وقتی چیزی دچار قطعی میشود یا چیزی مثل دادههای حیاتی گم میشود، چه تأثیری روی کسبوکار دارد. یکی از داراییهای حیاتی دیتابیس مشتریان است. شاید نیاز به الزاماتی مبنی بر اطلاعرسانی در مورد نقض امنیتی یا حتی جریمه وجود داشته باشد. بررسی گزارشات از ممیزیهای گذشته نیز میتواند در این مرحله مفید باشد.
- ایجاد یک برنامه و پروتکل ارتباطی: نحوهی ارتباط تیم باید تعیین شود. مثلاً اگر بحرانی وجود داشته باشد که نیمی از تیم پاسخدهی به حادثه منتظر یک تماس تلفنی و نیم دیگر منتظر پیغام متنی باشند، چه کسی قرار است تماس را شروع کند؟ اگر آن فرد حضور نداشت چطور؟ چند وقت یک بار باید بروزرسانیهایی را برای تیم اجرایی فراهم کنید؟ چه زمانی باید از یک مدیر که در تیم نیست اجازه بگیرید؟ ایدهآل این است که تمام سناریوها از قبل مد نظر قرار گیرند و تأییدیهها انجام شوند.
- ایجاد ارتباطات اساسی از قبل: تمام حوادث احتمالی مثل سرقت دادههای مشتری، نقض امنیتی سیستم، خرابی شبکه یا سایت، زورگویی سایبری توسط یک کارمند و غیره باید از قبل فهرست شوند. سپس باید پستهای رسانههای اجتماعی، بیانیههایی کوتاه برای رسانهها و حتی اعلامیهای مطبوعاتی برای حادثههای جدی که نیازمند بحثهای قانونی است از پیش آماده شوند. درگذشته به این بیانیهها، «بیانههای کشویی» گفته میشد، زیرا برای مواقع اضطراری در کشوی میز نگهداری میشدند. وقتیکه این پیشنویسها آماده شدند، باید توسط تیم حقوقی بررسی و تائید شوند؛ این گونه در میانهی بحران نیاز به تأییدیه نخواهیم داشت.
- آماده شدن برای انجام تمرینها: مثل مسائل ارتباطی که قبلاً در موردش صحبت کردیم، مسائل زیادی میتوانند اشتباه پیش بروند و در طول بحران از دید ما مخفی بمانند. رهبر تیم باید بتواند تمرینهای دورهای ترتیب دهد و فرایند مشخصی را برای آنها تعیین کند. این کار نهتنها مشکلات احتمالی را نشان میدهد، بلکه به تیم اعتمادبهنفس بیشتری میدهد.
- منتقل کردن منشور تیم پاسخدهی به حادثه به شرکت: در ابتدا مدیرعامل و تیم اجرایی باید منشور CSIRT و سپس برنامه پیشنویس را بررسی و تائید کنند. پسازاینکه تائید انجام شد، CSIRT و منشور آن باید به اطلاع شرکت برسد. همچنین افراد شرکت باید بدانند که در طول یک حادثهی امنیتی عمومی چطور با هم ارتباط برقرار کنند. بههیچعنوان دلمان نمیخواهد که همه فروشندههای شرکت به تیم روابط عمومی یا رئیس شرکت ایمیل بزنند و بپرسند که چه اتفاقی در حال رخ دادن است. در نهایت باید شفافسازی شود که فقط اعضای تیم پاسخدهی به حادثه، ارتباطات با مشتریان و شرکا را انجام خواهند داد.
در نهایت تجربه باعث یادگیری میشود. پس مهم است که بهطور مداوم بازخورد بگیریم و فرایند خود را بهبود بخشیم. این تجربه شامل انجام بهبودهای مختلفی مثل اضافه کردن یا تغییر اعضای تیم و تغییر روش ارتباطی است.
حوادث امنیتی خارج از کنترل ما رخ خواهند داد. اما اینکه چطور یک تیم پاسخدهی به حادثه ساخته شود، یا از نیروهای متخصص یک شرکت ارائهدهنده این خدمت استفاده شود، بستگی مستقیم به خط مشی سازمان دارد. مورد مهم این است در شرایط فعلی، نیاز مهم و حیاتی به تیم پاسخدهی به حادثه برای تمام سازمانها و شرکتها وجود دارد و این مهم در میان سایر راهبردها و ابزارهای امنیتی نباید مهجور بماند.
شرکت امنپردازان کویر (APK)، با تکیه بر تخصص و توان تیم پاسخدهی به حادثه خود، سرویس CSIRT را بهصورت حرفهای به سازمانها ارائه مینماید. با تکمیل فرم مشاوره، میتوانید اطلاعات بیشتر و کاملتری در خصوص نوع خدمات ارائه شده کسب کنید.