الاستجابة للحادث: ما يدين لك SOC



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



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



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



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



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



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



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



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



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



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



في هذه النتائج لتحليل الحادث ، يجب تحديد الموظف المسؤول عن الاستجابة التقنية بوضوح. ما



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



هناك حاجة إلى نفس المعلومات لتحديد مدى خطورة الحادث. على سبيل المثال ، البنك مستعد للتفاعل مع عدوى فيروس سيارة في فرع في ماجادان بشكل أبطأ بكثير وبمساعدة أخصائي أمن المعلومات المحلي. إذا كنا نتحدث عن AWP المحلي لـ KBR ، فإن الحادث يتطلب استجابة ومشاركة فورية ، بما في ذلك CISO الخاص بالعميل لتنسيق المخاطر ، بالإضافة إلى المتخصصين في مركز الاتصال على الموقع لعزل المضيف على الفور.



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



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







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



يجب أن يحتوي التحقق من نتائج الاستجابة على إمكانية التحكم الفني لكل من حقيقة تنفيذ التوصيات (باستخدام السجلات في SIEM أو أدوات أخرى) ، وحقيقة أن الحادث لن يتكرر في المستقبل.



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



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



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



All Articles