أهم نصيحتين من مسعف للاستجابة لحوادث السحابة

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

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

مريض أم غير مريض

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

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

• بيانات أصبحت عامة في تخزين الكائنات (S3) بينما لا ينبغي أن تكون كذلك.
• كيان IAM يُحتمل أنه مخترق ويتمتع بامتيازات إدارية أو امتيازات عالية أخرى.
• عدة استدعاءات API ناجحة باستخدام مستخدمي IAM مختلفين من عنوان IP مجهول واحد.
• مشاركة صورة أو لقطة عبر الحسابات مع حساب مجهول.
• مثيل/جهاز افتراضي يُحتمل أنه مخترق ويملك امتيازات IAM.

عندما أكتب هذه الأمثلة، يقول معظم المستجيبين: "بالطبع، هذا بديهي"، لكن من واقع خبرتي، يحتاج المستجيبون التقليديون إلى بعض الوقت للتعرّف على هذه المشكلات وإدراك أنها أشد خطورة بكثير من جهاز افتراضي مخترق عادي.

عبارة "مريض أم غير مريض" في السحابة تعني دائماً تقريباً: "هل الأمر عام أم أنهم انتقلوا إلى مستوى الإدارة (IAM)؟".

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

أوقف النزيف

ربما حضر كثير منكم دورة في الإنعاش القلبي الرئوي والإسعافات الأولية. وعلى الأرجح تعلمتم "ABCs": المجرى الهوائي والتنفس والدورة الدموية.

نعم، تبيّن أننا أخطأنا في ذلك خطأً فادحاً.

بدأت الأبحاث تُظهر أن الناس، في حالات الطوارئ، يركزون على "ABCs" على حساب الصورة الأكبر. حتى المسعفون كانوا يُضبطون وهم يجرون إنعاشاً قلبياً رئوياً لشخص ينزف حتى الموت من جرح في ساقه. وأحياناً كان إنعاشاً مثالياً. كان بإمكانك أن تعرف ذلك من سرعة نفاد الدم من المريض. أما اليوم فنضيف "عالج تهديد الحياة" في البداية، و"أوقف النزيف" هي الأولوية القصوى.

هل ترى إلى أين أتجه؟

في كل صف دَرَّسته، أجد مستجيبين ذوي خبرة عالية يركزون على تحليلهم وتحقيقهم بينما السحابة تنزف أمامهم. لماذا؟

لأنهم غير معتادين على أن يكون كل شيء (احتمالاً) على الإنترنت. مستوى الإدارة بأكمله موجود على الإنترنت، فإذا حصل مهاجم على بيانات الاعتماد، لا يمكنك إيقافه بجدار حماية أو بإغلاق الوصول إلى خادم. وإذا اختُرق شيء وانكشف، فهو مخترق ومنكشف أمام... حسناً، ربما أمام الجميع، في كل مكان، وفي الوقت نفسه.

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

قائمتي المختصرة؟

• أي كيان IAM يتمتع بامتيازات عالية ويبدو أنه مخترق.
• بيانات حساسة أصبحت عامة بطريقة ما.
• مشاركة عبر الحسابات/الاشتراكات/المشاريع أو وصول إلى وجهة مجهولة.

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

رؤية الأمر عملياً

إليك مثالاً. لقطات الشاشة مزيج من Slack ووحدة تحكم AWS و FireMon Cloud Defense. هذه هي سلسلة أدواتي، وسينجح الأمر مع أي أدوات لديك. في الدورات التدريبية، نستخدم أيضاً استعلامات Athena لمحاكاة SIEM، لكنني أريد إبقاء هذه التدوينة قصيرة (نوعاً ما).

لنبدأ بتنبيه متوسط الخطورة في Slack من منصتنا المدمجة CSPM/CDR:

مريض أم غير مريض؟ لا نعرف بعد. قد يكون هذا مشروعاً تماماً. حسناً، حان وقت التحقيق. سأعرض هذا في المنصة وفي وحدة تحكم AWS معاً. خطوتي الأولى هي معرفة ما الذي تمت مشاركته وأين. وبما أن التنبيه يتضمن معرّف AMI، يمكننا الانتقال إليه مباشرة:

حسناً، أستطيع أن أرى أن هذه تمت مشاركتها مع حساب آخر. هل هو حساب أملكه؟ حساب أعرفه؟ تصنّفه أداتي على أنه غير موثوق لأنه ليس حساباً مسجلاً في النظام، لكن في الواقع العملي، سأرغب في مراجعة قائمة الحسابات الرئيسية لمؤسستي للتأكد.

حسناً، مريض أم غير مريض؟ في ذهني، ما زال الجواب "ربما". لدي صورة تمت مشاركتها مع حساب يُحتمل أنه غير موثوق. لكنني لا أعرف بعد ما الذي تمت مشاركته. عليّ تتبع ذلك وصولاً إلى المثيل المصدر. لن أشغل نفسي بالتحليل الجنائي الكامل؛ سأعتمد على المعلومات السياقية لأنني بحاجة إلى معرفة ذلك بسرعة. في هذه الحالة، حالفنا الحظ:

الاسم يتضمن "Prod"، لذا... أصنّف هذه الحالة بأنها "مريضة على الأرجح". أوقف النزيف؟ في الواقع العملي، سأحاول أولاً الاتصال بمالك حساب AWS ذاك، لكن اليوم أعتقد أن لدي معلومات كافية لعزل AMI. إليك الطريقة في وحدة التحكم وفي Cloud Defense:

حسناً، هل أوقفنا النزيف؟ لقد أوقفنا... جزءاً من النزيف. أحكمنا إغلاق AMI، لكننا ما زلنا لا نعرف كيف وصلت إلى هناك. كما لا نعرف من يملك حساب AWS ذاك. هل يمكننا معرفة ذلك؟ لا. إذا لم يكن حسابنا، فكل ما يمكننا فعله هو الإبلاغ عنه إلى AWS وترك البقية لهم.

لنبحث عن استدعاءات API لمعرفة من شاركها وما الذي فعله أيضاً. سأنفّذ الأجزاء التالية في المنصة، لكن يمكنك تشغيل استعلامات في SIEM أو Athena للعثور على المعلومات نفسها. سأكتب تدوينات لاحقة عن جميع الاستعلامات، لكن هذه التدوينة تركز على مفهومي "المريض" و"النزيف".

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

• ImageBuilder هو مستخدم IAM يملك امتيازات إنشاء الصور وتعديل سماتها، لا أكثر. غير أن السياسة لا تتضمن قيوداً على الموارد، لذا يمكنه إنشاء صورة لأي مثيل. ولا تتضمن قيوداً شرطية، لذا يمكنه المشاركة مع أي حساب. هذا نطاق تأثير متوسط إلى منخفض؛ فالامتيازات زائدة، لكن ليس بصورة مروّعة. أسميها: مريضة نوعاً ما.
• جاء استدعاء API من عنوان IP مجهول. هذا مريب، لكنه ما زال مريضاً نوعاً ما فقط.
• إنها المرة الأولى التي أرى فيها هذا المستخدم في IAM يستخدم عنوان IP ذاك، ويُظهر المستخدم نشاطاً سابقاً متسقاً مع عملية دفعية. حسناً، الآن أميل إلى تصنيفها "مريضة". عادةً لا نرى عناوين IP متغيرة لمهام كهذه، والأمر تفوح منه رائحة بيانات اعتماد مفقودة:

• يمكن لمستخدم IAM ذاك الاستمرار في تنفيذ هذه الإجراءات. وما لم يخبرني أحد بأنه قصد ذلك، فإنني أصنّفها مريضة وسوف أوقف النزيف وأضع قيداً في IAM على حساب ذلك المستخدم (على الأرجح سياسة رفض الكل، ما لم تكن هذه عملية حرجة، وعندها سأستخدم قيداً على عنوان IP).

باختصار:

• وجدت AMI تمت مشاركتها مع حساب مجهول: مريضة
• كانت تلك AMI خاصة بأصل إنتاجي: مريضة وأوقف النزيف
• جاء الإجراء من مستخدم IAM يملك امتيازات واسعة لإنشاء صور AMI ومشاركتها، لا أكثر: ربما مريضة، التحقيق ما زال جارياً.
• أنشأ مستخدم IAM تلك AMI من عنوان IP جديد ومجهول: مريضة، أوقف (بقية) النزيف.
• لا يوجد أي نشاط آخر تم رصده من عنوان IP: من المرجح أنه محتوى ولم يعد في حالة حرجة
• ما زلت لا أعرف كيف تم تسريب بيانات الاعتماد تلك: حالة حرجة، وقد حان الوقت للاستعانة بزملائنا في الاستجابة التقليدية للحوادث لمعرفة ما إذا كان الاختراق قد طال الشبكة أو المضيف.

لقد استعرضت هذا الأمر بسرعة لأبيّن كيف أفكر في مثل هذه المسائل. وباختلافات بسيطة فقط، كان يمكن لهذا الاكتشاف نفسه أن يكون طبيعياً تماماً. تخيّل أننا أدركنا أنه تمت مشاركته مع حساب جديد نملكه نحن لكنه لم يُسجَّل بعد. أو أن الـ AMI كانت مخصصة لمثيل تطوير لا يحتوي على أي بيانات حساسة. أو أن استدعاءات واجهة البرمجة جاءت من شبكتنا، في الوقت المتوقع، أو من نظام أحد المسؤولين وكان يقصد مشاركتها. هذا المثال ليس فادحاً، لكنه شكل معروف من أشكال تسريب البيانات الذي تستخدمه جهات تهديد نشطة. ومع كل معلومة أعثر عليها، أقيّم ما إذا كانت الحالة حرجة أو غير حرجة، وما إذا كنت بحاجة إلى وقف النزيف.

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