خطة الاستجابة للحوادث لشركة من 10 أشخاص: شو المطلوب بدون مجلدات ومستندات طويلة؟

أول شي سويه إنك ما تحفظ هالخطة على سيرفر الشركة. لما يدخل فدية إلكترونية ما رح تقدر توصل لسيرفرك. خلي نسخة مطبوعة عند المدير وعند القائد التقني، ونسخة كمان في مجلد سحابي خارجي مستقل. وللتواصل كمان لازم تحددون من البداية قناة خارجية غير إيميل الشركة.

نحن ندير وكالة بحجم مشابه في ميونخ. السنة الماضية تم اختراق حساب إيميل أحد عملائنا. لأننا ما كتبنا من قبل مين بيتصل بمين، خسرنا أول 4 ساعات في ذعر داخلي ونسأل بعضنا أسئلة. بعد هالحادثة طلعنا مخطط سير من صفحة واحدة. تحضيره أخذ منا 3 ساعات بس، لكن في مشكلة DNS صغيرة بعدها نظّمنا أنفسنا في 20 دقيقة.

أكبر غلط على الجانب التقني هو سحب فيش السيرفر بدافع الذعر أو إعادة تشغيله فوراً. سجلات الذاكرة المتطايرة على RAM تُمحى وما رح تقدر تحدد من وين دخل المهاجم. لازم تكون قاعدة واضحة في الخطة: «لا تطفئ الجهاز، فقط افصل كابل الشبكة أو عطّل محوّل الشبكة في السيرفر الافتراضي».

إذا كنت تعمل في ألمانيا لا تتجاهل الجانب القانوني. لازم يكون في خطة الاستجابة للحوادث خطوة واضحة لالتزام الإبلاغ خلال 72 ساعة للجهة الرقابية المختصة وفق المادة 33 من GDPR، وإذا لزم الأمر عملية إشعار أصحاب البيانات. الشركات غالباً تفوّت هذه المدة وسط الفوضى الداخلية.

نماذج التدقيق اللي يرسلها عملاؤك هي قوائم تحقق مؤسسية. الخطة من صفحتين اللي رح تحضّرها بتشتغل ممتاز داخلياً، لكن المدقق المؤسسي ممكن يدوّر على بنود مثل مركز عمليات 7/24. اكتب الخطة، بس لما تقدّمها للعميل ارسم إطار واضح وقول «خطة رشيقة مكيّفة على هيكل تنظيمي من 10 أشخاص»، وإلا رح تتعب بلا داعي.

ملاحظة: سُئل هذا أدناه، وكتبت الإجابة في الرسالة الثانية.

فريقنا كمان فيه 8 أشخاص، ولما صارت عندنا حالة مشابهة اكتشفنا إنه ما حدا يعرف رقم المحامي. قائمة هواتف الطوارئ وعنوان التواصل الاحتياطي لكل واحد هي الجزء الأهم. يكفي إنه اسم الملف يكون خطة الاستجابة للحوادث، والمحتوى يبقى ملخص من صفحتين.

عميلك في التدقيق بس يسأل عن وجود الخطة، ولا كمان يطلب تقرير آخر اختبار وموافقة طرف ثالث؟ بعض التدقيقات بس تبي تشوف محضر التمرين، وبعضها تطلب تقرير تدقيق خارجي. تأكدت من الملحق الأمني في عقدك؟

لا تحمّل نفسك فوق طاقتها، ما في أي داعي تغرق في القوالب المؤسسية. أضف لخطتك كمان تصنيفاً بسيطاً يحدد مستوى الحادثة: منخفض (متأثر مستخدم واحد)، متوسط (فيه انقطاع خدمة بس البيانات بأمان)، مرتفع (تسرب بيانات أو فقدان بيانات حرجة). هذا التصنيف يوضّح كثيراً مين لازم يُبلَّغ ومتى.

أنا في نفس الوضع، لذلك أسأل. إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا.

الحلول التي تنجح على نطاق صغير تنهار عند التوسع، تعلمت هذا متأخراً. إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

أتفق، بل أود التأكيد على هذه النقطة. معظم الحوادث لا تبدأ من ثغرة أمنية، بل من كلمة مرور مسربة.

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

لدي سؤال، ولا أريد الخروج عن صلب الموضوع. لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها.

إمكانية الوصول إلى النسخة الاحتياطية عبر نفس الشبكة ونفس الهوية تجعلها جزءًا من الهدف. طيب صححوا لي إن أخطأت.

شكرًا جزيلاً، سأجربها اليوم.

سأجرب ذلك لكن انظروا أولاً إلى البيانات المتاحة لديكم عند اتخاذ القرار.

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

هذا العنوان مؤرشف.

حدث معنا هذا. إمكانية الوصول إلى النسخة الاحتياطية عبر نفس الشبكة ونفس الهوية تجعلها جزءًا من الهدف.

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

موضوع في الوقت المناسب تمامًا.

سأجمع الموضوع، لأن هناك عدة إجابات مختلفة ثم يعني معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

أتمنى أن يفيدك هذا.

نعم، الوضع في موضوع خطة الاستجابة للحوادث هو بالضبط هكذا. الإجراء المتخذ دون جرد المخزون يترك باباً لا تراه مفتوحاً.