سلسلة توريد البرمجيات العالمية موجودة دائمًا التهديد من مجرمي الإنترنت الذين يهددون بسرقة المعلومات الحساسة أو الملكية الفكرية والإضرار بسلامة النظام. قد تؤثر هذه المشكلات على الشركات التجارية بالإضافة إلى قدرة الحكومة على تقديم الخدمات للجمهور بشكل آمن وموثوق.
نشر مكتب الإدارة والميزانية الأمريكي (OMB) في يوليو 2022 مذكرة حول هذا الموضوع، والتي قمنا بتغطيتها هنا بالتفصيل. في سبتمبر 2022، تم إصدار مذكرة جديدة، تركز هذه المرة على أمان وسلامة سلسلة توريد البرامج، مع التركيز على الدور الهام الذي تلعبه SBOMs. فهو يقدم قائمة بالمتطلبات الدقيقة، ولأول مرة، يشارك جدولًا زمنيًا ملزمًا فعليًا لتنفيذ التغييرات.
تحتوي المذكرة على نقطتين رئيسيتين تتعلقان بالأمر التنفيذي رقم 14028، تحسين الأمن السيبراني للدولة:
- يوجه منظمة الأخلاقيات المعهد الوطني للمعايير والتكنولوجيا (NIST) لمشاركة التوجيهات الخاصة بتطوير الممارسات التي تهدف إلى تعزيز أمان سلسلة توريد البرامج. للمساعدة في تحقيق ذلك، أصدرت NIST وثيقتين: إطار تطوير البرمجيات الآمنة (SSDF)، ليرة 800-218و إرشادات أمان سلسلة توريد البرمجيات. يُطلق عليهما معًا اسم NIST Guidance ويحددان مجموعة من الممارسات التي تشكل الأساس لإنشاء برامج آمنة.
- يوجه EO أيضًا مكتب الإدارة والميزانية للبدء في مطالبة الوكالات بالامتثال لإرشادات NIST وأي تحديثات أخرى.
شهادة الذات شرط أساسي، ولكن هل هي كل شيء؟
يُطلب من منتجي البرمجيات الآن منح الوكالات إقرارًا ذاتيًا قبل البدء في استخدام برامجهم. هناك في الواقع ثلاث فئات تتطلب الإقرار الذاتي: شراء البرامج الجديدة، وترقيات الإصدارات الرئيسية، وتجديد البرامج. الهدف هو تزويد الوكالات بمنتجات برمجية آمنة ومرنة تحميها من التهديدات مثل ماذا سولارويندز من ذوي الخبرة، الأمر الذي أضر بالعديد من الوكالات.
لنبدأ بالأساسيات: ما هي شهادة الذات بالضبط؟
الإقرار الذاتي هو مستند يعمل كبيان مطابقة، يشهد على امتثال منتج البرنامج للممارسات الواردة في إرشادات NIST. تتمثل الفكرة في حصول الوكالات على شهادة ذاتية لكل منتج أو خدمة برمجية تابعة لجهة خارجية تندرج ضمن متطلبات المذكرة. يتضمن ذلك تجديدات البرامج وتحديثات الإصدارات الرئيسية.
هناك نقطة أخرى مهمة في المذكرة وهي أن تقوم الوكالات بتشجيع شركات البرمجيات على أن تكون شاملة للمنتج. وهذا من شأنه تمكينهم من تقديم نفس الشهادة لجميع وكالات الشراء.
يجوز للوكالة الاحتفاظ بوثيقة الإقرار الذاتي ما لم تنشرها شركة البرمجيات علنًا وتقدم رابطًا للنشر ضمن اقتراحها.
ملحوظة: في حين أن جميع المذكرات أو الإرشادات الأخرى حتى الآن تدعي أن الشهادة الذاتية جيدة بما يكفي للبدء بها، فإن هذه المذكرات تضع الثقة والشفافية كأهداف رئيسية. إنه يركز على سلسلة توريد البرامج على وجه التحديد، وليس فقط الأمن السيبراني أو SSDF (حتى لو كانا جزءًا منه).
ماذا يحدث إذا لم تتمكن شركة البرمجيات من تقديم الشهادة الذاتية بالتنسيق القياسي؟
قد لا يتمكن منتج البرامج من التصديق على ممارسة واحدة أو أكثر من إرشادات NIST كما هو محدد في نموذج الإقرار الذاتي القياسي. في هذه الحالة، ستطلب الوكالة التي تطلب البرنامج من الشركة ما يلي:
- حدد تلك الممارسات التي لا يمكنهم أن يشهدوا عليها
- توثيق جميع الممارسات المستخدمة للتخفيف من تلك المخاطر
- تطوير خطة العمل والمعالم الرئيسية (POA&M)
وبطبيعة الحال، يجب على الوكالة التأكد من عدم نشر الوثائق علنًا (سواء من قبل البائع أو الوكالة نفسها).
لنفترض أن البائع يقدم جميع الوثائق ويكون مرضيًا للوكالة. وفي هذه الحالة، يجوز للأخير استخدام المنتجات أو الخدمات البرمجية على الرغم من افتقار المنتج إلى الإقرار الذاتي الكامل.
ما الذي يجب أن تتضمنه الشهادة الذاتية المقبولة؟
يجب أن تتضمن وثيقة الإقرار الذاتي الحد الأدنى من المتطلبات التالية:
- اسم شركة البرمجيات
- وصف لمنتجات البرمجيات التي يشير إليها البيان (من الناحية المثالية، تصف هذه النقطة شركة البرمجيات أو مستوى خط الإنتاج، بما في ذلك جميع المنتجات غير المصنفة المقدمة للوكالات)
- بيان يؤكد أن البائع يعمل بما يتماشى مع ممارسات ومهام التطوير الآمنة (مفصلة في نموذج الإقرار الذاتي)
هذا النوع من الإقرار الذاتي هو الحد الأدنى المطلوب. ومع ذلك، إذا رغبت الوكالات في شراء برمجيات بدونها - على سبيل المثال، بسبب أهميتها - فقد تنفذ قرارات قائمة على المخاطر بمساعدة تقييم من طرف ثالث (المحدد في M-21-30).
ومع ذلك، يشجع التوجيه الوكالات على استخدام نموذج الإقرار الذاتي القياسي. سيقترح مجلس تنظيم الاستحواذ الفيدرالي (FAR) وضع قواعد حول استخدام نموذج الإقرار الذاتي القياسي والموحد.
الشهادة الذاتية للبرمجيات مفتوحة المصدر
لنفترض أن الوكالة ترغب في الحصول على برنامج مفتوح المصدر أو منتج برمجي يتضمن مكونات مفتوحة المصدر. في هذه الحالة، يمكن اللجوء إلى تقييم طرف ثالث مقدم من منظمة تقييم الطرف الثالث المعتمدة من FedRAMP (3PAO) أو منظمة معتمدة من قبل الوكالة نفسها.
يعتبر مثل هذا التقييم مقبولًا بدلاً من الإقرار الذاتي للبائع طالما أن 3PAO تستخدم إرشادات NIST كخط أساس لها.
أصبحت SBOMs معيارًا صناعيًا. هل انت مستعد لها؟
على الرغم من أن الإقرار الذاتي هو الحد الأدنى المطلوب، إلا أن الوكالات قد لا تحتاج إليه إذا كان المنتج أو الخدمة التي يتطلعون للحصول عليها أمر بالغ الأهمية ولا يمكنها تقديم الإقرار الذاتي في نموذج قياسي.
المهم هو أن المذكرة تشجع الوكالات على الحصول على القطع الأثرية من البائعين التي تثبت توافقها مع ممارسات تطوير البرمجيات الآمنة. تتضمن إحدى هذه الممارسات وجود SBOM.
ما هو SBOM وكيف يعمل؟
يشير SBOM إلى قائمة مواد البرنامج، وهي عبارة عن جرد لجميع المكونات والتبعيات التي تشكل جزءًا من تطوير منتج البرنامج وتقديمه.
قد تطلب الوكالة سبوم كجزء من متطلبات تقديم العروض، اعتمادًا على مدى أهمية البرنامج بالنسبة للوكالة.
تتضمن المذكرة الإرشادات التالية لشراء واستخدام SBOM من قبل الوكالات:
- يمكن للوكالة الاحتفاظ بـ SBOM ما لم ينشره منتج البرنامج ويشارك رابطًا له مع الوكالة.
- يجب إنشاء SBOMs باستخدام أحد تنسيقات البيانات المحددة في ملف SBOM تقرير NTIA "الحد الأدنى من العناصر الخاصة بقائمة مواد البرامج (SBOM)" أو الإرشادات اللاحقة المنشورة بواسطة وكالة الأمن السيبراني وأمن البنية التحتية.
- عند النظر في SBOMs، يتعين على الوكالات أن تأخذ في الاعتبار المعاملة بالمثل لـ SBOM وغيرها من المنتجات من منتجي البرامج التي تحتفظ بها الوكالات الأخرى. يعتمد هذا على قابلية تطبيق القطع الأثرية المباشرة والعملة.
- قد تطلب الوكالة عناصر أخرى غير SBOM إذا لزم الأمر - على سبيل المثال، تلك المتعلقة بالأدوات والعمليات الآلية للتحقق من صحة سلامة التعليمات البرمجية المصدر أو إجراء عمليات التحقق من الثغرات الأمنية.
- قد تطلب الوكالة أيضًا من شركة البرمجيات إظهار دليل على مشاركتها في أ برنامج الكشف عن نقاط الضعف.
وتقترح المذكرة أيضًا أن تسمح الوكالات للبائعين بمعرفة هذه المتطلبات في أقرب وقت ممكن في عملية الاستحواذ. للامتثال لتوجيهات Order وNIST، تحتاج الوكالات إلى التخطيط بشكل مناسب وإدراج جميع المتطلبات في عملية تقييم البرامج الخاصة بها. لاحظ أن هذا يجب أن يتماشى أيضًا مع الجدول الزمني المحدد في المذكرة (سيتم تناول ذلك في القسم التالي).
يجب على الوكالات تحديد المتطلبات في طلب تقديم العروض (RFP) أو في وثائق التماس أخرى. الفكرة هنا هي أن تتأكد الوكالة من قيام البائع بالتنفيذ والاستخدام ممارسات تطوير البرمجيات الآمنة بما يتماشى مع إرشادات NIST طوال دورة حياة تطوير البرامج بأكملها.
من الواضح أن SBOM هو أفضل ممارسة صناعية على الطريق نحو الاستخدام الواسع النطاق، خاصة للتخفيف مخاطر سلسلة توريد البرمجيات.
ولمساعدة الشركات على بناء الثقة في منتجاتها البرمجية، أطلقنا مؤخرًا منصة سهلة الاستخدام تساعد على إنشاء SBOMs ومشاركتها داخل المؤسسات وعبرها. محاولة إعطائها مجانًا لمعرفة مدى سهولة إنشاء وإدارة ومشاركة SBOMs.
لم تعد مجرد توصية؛ الآن هناك جدول زمني ملزم للمتابعة
يتعين على الوكالات الالتزام بمتطلبات المذكرة بما يتماشى مع هذا الجدول الزمني:
- وكالات لديها 90 أيام لجرد جميع برامج الطرف الثالث الخاصة بهم، بما في ذلك جرد منفصل لـ "البرامج المهمة".
- ضمن 120 أيام، يتعين عليهم إنشاء "عملية متسقة لتوصيل المتطلبات ذات الصلة في هذه المذكرة إلى البائعين والتأكد من جمع خطابات التصديق التي لم ينشرها مقدمو البرامج علنًا في نظام وكالة مركزية واحد."
- لديهم ايضا 270 أيام لجمع خطابات التصديق التي لم يتم نشرها علنًا لـ "البرامج المهمة". وفي غضون عام واحد، كان من المفترض أن تكون الوكالات قد جمعت الرسائل الخاصة بجميع برامج الطرف الثالث.
- وأخيرا، في الداخل 180 أيام اعتبارًا من تاريخ المذكرة (14 سبتمبر 2022)، يتعين على مديري تكنولوجيا المعلومات في الوكالة تقييم أي احتياجات تدريبية ووضع خطط تدريب لمراجعة وثائق التصديق والعناصر الاصطناعية والتحقق من صحتها.
يمكن للوكالات أن تطلب تمديدًا لمدة 30 يومًا على الأقل قبل أي موعد نهائي ذي صلة مذكور في المذكرة، بالإضافة إلى خطة لتلبية المتطلبات المعلقة. من الممكن أيضًا طلب الإعفاء، ولكن فقط في ظروف استثنائية ولفترة زمنية محدودة.
الملخص
سيشارك مكتب الإدارة والميزانية تعليمات محددة لتقديم طلبات الإعفاءات أو التمديدات خلال 90 يومًا من تاريخ المذكرة (حتى منتصف ديسمبر 2022). علاوة على ذلك، وبالتشاور مع CISA وإدارة الخدمات العامة، فإنها ستحدد متطلبات "المستودع المركزي لشهادات البرامج والتحف" مع الآليات المناسبة للحماية والمشاركة بين الوكالات.
قد يصبح مثل هذا المكان المركزي يومًا ما موقعًا مركزيًا لمجموعة متنوعة من الأدلة والشهادات الأمنية بما يتجاوز نموذج الإقرار الذاتي أو SBOM. إن وضع جميع الأدلة في مكان واحد يمكن مشاركته يساعد المؤسسات على التعامل مع المشكلات المشتركة، مثل برمجيات استغلال الثغرات الجديدة الناشئة أو مكافحة التطرف العنيف.
هذا هو بالضبط ما يدور حوله الكاتب. نلقي نظرة على هذه الصفحة لمعرفة المزيد حول منصتنا الشاملة لإنشاء وإدارة ومشاركة SBOMs داخل المؤسسات وعبرها.
يتم تقديم هذا المحتوى إليك بواسطة Scribe Security، وهي شركة رائدة في مجال توفير حلول أمان سلسلة توريد البرامج الشاملة - حيث توفر أحدث الأمان لعناصر التعليمات البرمجية وعمليات تطوير التعليمات البرمجية وتسليمها عبر سلاسل توريد البرامج. تعرف على المزيد.
الوظائف ذات الصلة
