تحديات تكوين المكونات من أجل السلامة وبناء الفريق

مقال بقلم روبرتو جالو

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

إن فحص الأدبيات ومستودعات الثغرات الأمنية المعروفة (مقاطع فيديو CVE التي تحتفظ بها MITRE) وحتى الوسائط حول هذا الموضوع يسمح لنا بتحديد الحالات الهامة التي أدى فيها بعض جوانب مكونات النظام إلى ظهور مشاكل أمنية كان من الممكن تجنبها مع نشر المعرفة الأمنية بشكل أكبر لفرق تصميم أنظمة الكمبيوتر.

وتشمل بعض الأمثلة البارزة ما يلي:

هجمات سلسلة التوريد على SolarWinds Orion وتفشي XZ (CVE-2024-3094) حيث تم تخريب هذه المكونات التي تستخدمها حلول أخرى،

المساس بالأنظمة التي تستخدمها؛

هجمات القناة الجانبية Downfall على وحدة المعالجة المركزية Intel (CVE-2023-12301)، وInception على وحدة المعالجة المركزية AMD (CVE-2023-12302) ومؤخرًا هجوم GoFetch

تحت وحدة المعالجة المركزية Apple Mx (2024) التي سمحت بتسريب المعلومات (المفاتيح التشفيرية) بين العمليات (المكونات) للنظام؛

حالات البنية التحتية غير الكافية جنبًا إلى جنب مع سوء تكوين دلاء Amazon S3 التي أدت إلى تسريبات بيانات شهيرة مثل تسرب 1 تيرابايت من Attunity في عام 2019 وتسريب 100 مليون عميل من Capital One في عام 2019.

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

بعض المشاكل المتعلقة بالمكونات

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

ولكن هذه الفوائد لا تفلت من الأسس النظرية الجوهرية للحوسبة، ولا من الظواهر الملموسة الشائعة التي تشكل مصادر للتهديدات، والتي، من المدهش، لا يتم دمجها في عقلية العديد من المهنيين الذين يتخرجون من التعليم العالي في مجال الحوسبة. بعد ذلك، في شكل ملخص نيابة عن نظرًا لحدود المساحة المتاحة في هذا المنشور، فسوف أذكر بعضًا من أهمها:

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

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

إن صياغة سياسات الأمان أمر صعب للغاية: إن صياغة سياسات الأمان الفردية للمكونات في سياسة ناتجة عن نظام ما هي مشكلة NP أو حتى مشكلة أسيّة، حتى باستخدام نماذج رسمية مع قيود، مثل شبكات بتري الممتدة [2].

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

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

ومن الأعراض أيضًا أن معظم تراخيص البرامج تنص على أن "هذا البرنامج لا يأتي مع أي ضمان على الإطلاق، ولا يُضمن ملاءمته لأي غرض معين"؛

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

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

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

لا يُعرف الكثير عن المشكلة، لكن البيانات من Apache Maven [3] تشير إلى أن متوسط تطبيق Java في عام 2022 يعتمد على ما يقرب من 40 (!) مكتبة تابعة لجهات خارجية. وفي هذا السياق، هناك فرصة يؤدي هجوم على سلسلة التوريد بنسبة تلوث تبلغ 1,7% فقط لكل مكون فردي إلى زيادة احتمالية تعرض التطبيق للخطر بنسبة 50%.

من ناحية أخرى، من المعروف في مجال هندسة البرمجيات أن تآكل البنية [4] هو عنصر يجعل من الصعب تحديد مشاكل الأمان وتصحيحها، مما يجعل دورة التخفيف بطيئة.

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

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

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

أفضل الممارسات لتأمين الأنظمة المركبة

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

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

تظهر الخبرة العملية أن تصميم وتنفيذ وصيانة المكونات والأنظمة ذات المستوى العالي من الأمان يميل إلى أن يكون أقل صعوبة نسبيًا من الحصول على مستوى عالٍ من التأكيد، ويرجع ذلك أساسًا إلى تأثيرات نظرية رايس وتكوين سياسة الأمان. بشكل عام، فإن المستوى العالي من الجهد المطلوب لتحقيق مستوى عالٍ من التأكيد غير متوافق مع العديد من سيناريوهات الاستخدام، حيث يصل إلى 3.83 مرة أكبر [5] من التأكيدات الأكثر مرونة، مثل مستويات EAL 1 مقابل EAL 7 في معيار ISO / IEC 15408 - "المعايير المشتركة".

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

خط الأساس للمفردات والمنهجيات: يجب تدريب جميع أعضاء الفريق على استخدام مصطلحات مشتركة للتعبير عن أنفسهم من حيث أهداف الأمان والتهديدات والثغرات الأمنية وفحوصات الأمان والاستجابة للحوادث وما إلى ذلك، باستخدام إطار عمل موثق لإدارة دورة حياة الأنظمة الآمنة، مثل Microsoft SDL أو نموذج SAMM؛

يجب أن يمتلك مهندس الحلول الأمن في المشاريع الصغيرة والمتوسطة الحجم: في المشاريع الصغيرة والمتوسطة الحجم، من المهم أن يفهم مهندس الحلول، أو الدور المماثل، جميع الوحدات ومكونات النظام، سواء من حيث الكود المصدر والهندسة المعمارية، كما أنه على دراية بالأنواع الرئيسية للهجمات. يعد هذا منصبًا صعبًا للغاية، ولكنه يقلل إلى حد كبير من الحاجة إلى إضفاء الطابع الرسمي على عملية تطوير البرامج وصيانتها. بشكل عام، يتضمن تدريب هذه المواهب مسارات تدريبية في دورة حياة آمنة (على سبيل المثال MS-SDL، SAMM)، والتقنيات المحددة المستخدمة في التطبيق، والأمن الهجومي (على سبيل المثال CEH، CompTIA PenTest+، ECSA/LPT)؛

تتطلب المشاريع الحرجة مهما كان حجمها شكليات ومن الضروري استخدام منهجية ضمان، مثل NATO AEP-67 ENGINEERING FOR SYSTEM ASSURANCE NATO IN PROGRAMMES، والتي تقدم طريقة لتوثيق وإثبات مطالبات الأمن ومستويات الضمان المقابلة أثناء دورة حياة الحل، مع الأخذ في الاعتبار جميع مكوناته. بفضل قوتها التنسيقية ومستوى الجهد القابل للتعديل، تم استخدام AEP-67 التابع لحلف شمال الأطلسي بنجاح في العديد من المشاريع الناجحة، فضلاً عن كونها بمثابة أساس لتدريب الفريق [6]، وهو موضوع سيتم مناقشته لاحقًا؛

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

حالات التأكيد كأداة لبناء الفريق

تنظم حالات التأكيد في شكل خطة عمل الناتو AEP-67 المطالبات الأمنية بطريقة هرمية، كما هو موضح في الشكل 1. ويمكن دعم كل "مطالبة" بمطالبة وسيطة واحدة أو أكثر ("مطالبات فرعية") بشكل متكرر.

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

تين. 01 | مقتطف من قضية تأمين، المصدر [6].

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

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

في التجربة التعليمية، أثبتت حالات الضمان أنها أساسية في ثلاثة جوانب تعليمية على الأقل: (أ) أجبرت كل طالب على تحدي افتراضاته حول أمان مكونات النظام، (ب) أظهرت للفريق الحاجة إلى تحديد وتوثيق سياسات/مطالبات أمنية بسيطة ودقيقة لمكونات النظام، و(ج) عملت كمحور التواصل الموضوعي بين أعضاء الفريق، وتحسين الجهود والحد من الفجوات.

وبعيدًا عن كونها مجرد مكسب نظري وتمرين أكاديمي، بعد التجربة المذكورة في [6]، تمكنت من رؤية كيف كانت حالات التأكيد أساسية للتحسين المستمر، و"التدريب أثناء العمل" للمحترفين. فضلاً عن ذلك، فقد خدمت مثل هذه الحالات أصحاب المصلحة في الأنظمة المتقدمة، حيث أصبح لديهم الآن وصف دقيق لما يمكنهم توقعه من أنظمتهم.

اختتام

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

لتقليل عدد الثغرات الأمنية، يجب على فرق التطوير والعمليات والأمن أن تتبنى نفس نماذج التهديدات والمفردات وممارسات التطوير، بالإضافة إلى رؤية شاملة للأنظمة ومكوناتها. ولتحقيق هذه الغاية، أثبتت منهجيات وأطر عمل مثل Microsoft SDL وSAMM وNATO AEP-67 فعاليتها.

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

المراجع

لين باس، وبول كليمنتس، وريك كازمان، "هندسة البرمجيات في الممارسة العملية"، الطبعة الرابعة، أغسطس 4.

ين، هسو تشون. "حول انتظام لغات شبكة بتري." وقائع المؤتمر الدولي السنوي الثالث عشر لمعهد مهندسي الكهرباء والإلكترونيات (IEEE) فينيكس

مؤتمر الحاسبات والاتصالات (1994): 329.

م. مير، م. كيشاني وس. بروكش، "حول تأثير الانتقالية والحبيبية على انتشار الضعف في

"نظام Maven البيئي"، مؤتمر معهد مهندسي الكهرباء والإلكترونيات الدولي لعام 2023 حول تحليل البرمجيات وتطويرها وإعادة هندستها (SANER)، تايبا،

ماكاو، 2023، ص 201-211، دوى: 10.1109/SANER56733.2023.00028.

الله خان، م. منيب، يو. منظور وس. نفطي، "تحليل المخاطر على المستوى المعماري"، المؤتمر الدولي حول

مجتمع المعلومات (i-Society 2011)، لندن، المملكة المتحدة، 2011، ص 231-236، doi: 10.1109/i-Society18435.2011.5978442.

كو، ك.، جونغ، ج.، ولي، ج. (2008). تعريف مستويات ضمان التقييم وتقدير جهود التقييم

نظام التشغيل القائم على ISO/IEC 19791. المؤتمر الدولي لتكنولوجيا الأمن 2008، 176-183. https://doi.

org/10.1109/SECTECH.2008.41

جالو، ر.، دهب، ر. (2015). حالات التأكيد كأداة تعليمية لأمن المعلومات. في: بيشوب، م.، ميلوسلافسكايا، ن.،

ثيوشاريدو، م. (المحررون) تعليم أمن المعلومات عبر المناهج الدراسية. WISE 2015. التقدم في مجال المعلومات من IFIP

وتكنولوجيا الاتصالات، المجلد 453. سبرينغر، شام. https://doi.org/10.1007/978-3-319-18500-2_2

روبرتو غالو

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