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

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

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

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

قد تكون المشكلة في
SIEM . قد لا تعمل كما تريد. قد تكون الأحداث التي تقع فيها مرتبطة بشكل غير صحيح بسبب وجود أخطاء في قواعد الارتباط ، والتي سوف تؤدي إلى تخطي تصرفات المهاجم. تجدر الإشارة إلى أنه لا توجد دائمًا بيانات كافية من مصدر واحد. هناك حالات عندما يكون من الضروري ، عند تحديد الحوادث الأمنية ، الجمع بين البيانات من عدة مصادر في وقت واحد للحصول على صورة كاملة لما يحدث في النظام. ولكن قد يتضح أن القاعدة قد تم تكوينها بحيث يكون تحديد ما حدث قد لا يكون بيانات كافية من مصدر واحد ، مما يدل على حقيقة اكتماله. أي لغز يتكون من بيانات من عدة مصادر لن ينجح. أيضًا ، قد لا توجد قواعد لبعض أحداث الأمان على الإطلاق.
في مرحلة الارتباط بالحدث في SIEM ، يمكن أن تنشأ عدة مشاكل في وقت واحد. أحدها قد يكون تأخيرًا في نقل الأحداث من بعض المصادر ، مما قد يتداخل مع الارتباط الناجح.
قد لا يتم تكوين
قواعد تصنيف الأحداث على أنها أحداث في SIEM بشكل صحيح بمفردها ، أو قد لا تكون متاحة لأي أحداث. أيضًا ، عادة ما يكون للحوادث مستوى شدة ، والتي إذا لم يتم تحديدها بشكل صحيح يمكن أن تؤدي إلى مشاكل كبيرة.
يمكن للأشخاص الذين يعملون مع SIEM ، والتي تتمثل مهمتها في الاستجابة للحوادث الأمنية ، أن يتسببوا أيضًا في حدوث هجمات ضائعة ومشاكل أمنية لاحقة في المعلومات. قد يفوتهم بعض الإشارات من SIEM أو يتفاعلون بشكل غير صحيح مع تصرفات المهاجم لأسباب مختلفة. هناك أيضًا مشكلة في أن الناس سوف يستقيلون عاجلاً أم آجلاً ، والموظفون الجدد بحاجة إلى وقت للتدريب.
بالنظر إلى ما سبق ، فإن اختبار SOC للتحقق من الأداء مهم للغاية سواء في مرحلة تنفيذ SOC أو بمرور الوقت. نظرًا لأن المتخصصين في شركتنا لديهم بالفعل خبرة في هذا الشأن ، فقد قررنا وصف النقاط والفوارق الرئيسية.
الجزء 3. التحقق من فعالية SOC
يمكن إجراء اختبار SOC في إحدى الشركات في عدة سيناريوهات. دعونا نتحدث عن تلك التي تبدو أكثر فعالية بالنسبة لنا.
تتضمن مهام اختبار SOC اختبار الأمان من خلال إعادة إنتاج سيناريوهات السلوك النموذجي الملازمة لمجرمي الإنترنت. وتشمل هذه:
- التكرار من خلال حسابات المستخدمين الآخرين باستخدام القوة الغاشمة ، وكذلك باستخدام تقنية رش كلمة المرور. يمكن استخدام هذه التقنية إذا كان لديك وصول إلى قائمة الحسابات الموجودة في النظام ، على سبيل المثال ، من خلال دفتر العناوين لعميل البريد. في تجربتنا ، غالبًا ما تُنسى تقنيات رش كلمات المرور ، وبالتالي لا يمكن لقواعد SOC اكتشاف مثل هذا الهجوم ؛
- ضخ البيانات من أحد موارد الويب ، سواء أكانت ويكي أو مدير مهام. يمكن تنفيذ مثل هذا الهجوم بما في ذلك استخدام مختلف آليات الزحف على الويب والدليل الغاشمة. بشكل منفصل ، يهتم مراجعو الحسابات بخدمات API وقدراتهم ؛
- المحاولات المتكررة للوصول إلى الموارد أو المشاريع التي تقع خارج اختصاص الدور الذي يعمل عليه المهاجم. مثال بسيط هو محاولة تخويل مستخدم من مجموعة من المطورين على موارد مسؤولي الشبكات وخدمات الأمن ؛
- محاولات تنزيل كمية كبيرة من المعلومات من شبكة الشركة باستخدام تقنيات التصفية الالتفافية. هذا في المقام الأول يتعلق بنظم dns وأنفاق icmp ، ولكن في بعض الأحيان يكون من المنطقي أن تبدأ بفحوصات أبسط ، على سبيل المثال ، حاول البحث عن منفذ tcp أو udp مفتوح في الخارج ، بالإضافة إلى بوابة إضافية. للبحث عن بوابات ، بالمناسبة ، هناك تطبيق منقح لأداة شائعة من أحد الموظفين.
يمكن متابعة قائمة الشيكات المماثلة لفترة طويلة. من المهم للغاية الاسترشاد بالاحتياجات الحقيقية للعميل والشيكات التي ينفذها.
يمكن إجراء اختبار SOC بطريقتين:
- عمياء - الصندوق الاسود.
- مع المعرفة البنية التحتية - whitebox.
مزيد من التفاصيل حول كل منهم.
بادئ ذي بدء ، يجب عليك التحقق من تشغيل SOC في وضع اختبار الصندوق الأسود. جوهرها هو أن موظفي قسم SOC ليسوا على دراية بالعمل الذي يتم تنفيذه والرد على جميع الأحداث في وضع القتال. يحصل المدققون / المراقبون على حق الوصول إلى شبكة الشركة ، ويمكن أيضًا تقديم الحسابات من أكثر الخدمات استخدامًا على نطاق واسع في الشركة.
يفترض هذا النموذج أن المهاجم الذي ليس لديه أي معلومات إضافية قد تمكن من الوصول إلى شبكة الشركة وأي من الحسابات الموجودة بطريقة غير معروفة. تتميز تصرفات مثل هذا المهاجم بدرجة عالية من العشوائية و "الضوضاء". إنه يقوم بمسح الشبكة بنشاط ، ويتكرر عبر الأدلة ، والحسابات ، ويرسل جميع عمليات الاستغلال التي يعرفها إلى جميع المنافذ ، ويلقي XSS ، و SQLi ، و RCE ، و SSTI ، و NoSQLi ، وغيرها من تطبيقات الويب مع المتجهات. بشكل عام ، يتصرف بقوة شديدة على أمل اختراق شيء على الأقل. أثناء التدقيق ، يقلد المراجعون تصرفات هذا المهاجم ، ويحافظون على درجة معينة من الجنون ، لكنهم مستعدون للتوقف في أي وقت بناءً على طلب خدمة SOC أو في حالة نشوء مشاكل تقنية. بالمناسبة ، قد تكون النتيجة غير المتوقعة والممتعة اكتشاف الخدمات والتطبيقات الضعيفة في البنية التحتية للشركة.
نموذج اختبار آخر هو whitebox. في هذه الحالة ، يتم وضع سيناريو الموظف عديمي الضمير. عادة ، في هذه المرحلة ، يكون المراجعون على دراية جيدة بشبكة العميل ويمكنهم لعب هذا الدور. يمكن وصف سلوك المهاجم المحتمل في هذه الحالة بالانتقائية العالية لكل من وسائل وأهداف الهجوم. هنا يمكن بالفعل رسم بعض أوجه التشابه مع
هجمات APT . يهاجم المدققون فقط أضعف الأماكن في رأيهم ويستخدمون متجهات هجومية مدروسة وموجهة بشكل ضيق ، ويحاولون أيضًا الوصول إلى معلومات حساسة خارج نطاق اختصاص دورهم في الحساب مع محاولة لاحقة لإخراجها من المحيط الآمن. يحاولون تنفيذ جميع الإجراءات بطريقة لا يلاحظها أحد من قبل خدمة الأمن الخاصة بالشركة.
بعد الاختبار ، عادة ما يبدأ تحليل ومقارنة النتائج التي حصل عليها المراجعون والحوادث التي اكتشفها موظفو شركة نفط الجنوب. ستوفر هذه المرحلة صورة شاملة لفعالية عمل شركة نفط الجنوب الحالية ، ويمكن أن تكون بمثابة نقطة انطلاق لجميع الخطط الإضافية لتوسيع عمليات الفحص والمناهج الحالية.
أخيرًا ، عند تجميع فكرة عن أمان البنية الأساسية المختبرة ، يمكن للمراجعين استخدام اختبار الصندوق الأبيض لتحليل مجموعة القواعد الحالية ، وكذلك الأحداث التي تم تشكيل هذه القواعد عليها. يمكن أن يكون هذا التفاعل بين مراجعي الحسابات ومحللي SOC مثمرًا جدًا ، وخلال المشاورة سيساعد على تحديد الأخطاء المنطقية والإغفالات في تكوين مكونات SOC. عادةً ما يكون السبب الرئيسي وراء ذلك هو عدم فهم محللي شركة نفط الجنوب لكيفية تصرف المهاجم الحقيقي وما هي الحيل التي يمكنه القيام بها على الأنظمة.
استنتاج
يتم اختبار الخدمات الأكثر أهمية التي تستحق عن كثب الاهتمام بشكل منفصل باستخدام نموذجين من الدخلاء.
مجموعة مماثلة من التدابير تسمح لك:
- زيادة وعي مديري الأمن بحالة البنية التحتية لديهم بشكل كبير ؛
- إجراء مناورات عسكرية لقسم SOC مع إتاحة الفرصة للحصول على مشورة من خبراء في مجال التدقيق ؛
- اكتشاف وتصحيح الأخطاء الموجودة في عمل شركة نفط الجنوب ، وكذلك زيادة أمان الشركة بشكل عام.
للمساعدة في كتابة هذا المقال ، أشكر
دينيس _ttffdd_ ريبين وإيفان تشاليكين .