المعايير المشتركة

المعايير المشتركة لتقييم أمن تكنولوجيا المعلومات ، أو ببساطة المعايير المشتركة ( CC )، هي معيار لأمن المعلومات . وقد تم اعتمادها في ISO/IEC 15408:2022 .

المعايير المشتركة هي إطار عمل يمكّن مستخدمي أنظمة الحاسوب من تحديد متطلباتهم الأمنية الوظيفية ومتطلبات ضمان الأمان (SFRs وSARs على التوالي) في هدف أمني (ST)، ويمكن استخلاص هذه المتطلبات من ملفات تعريف الحماية (PPs). وبإمكان الموردين بعد ذلك تطبيق أو تقديم ادعاءات حول السمات الأمنية لمنتجاتهم، كما يمكن لمختبرات الاختبار تقييم هذه المنتجات لتحديد مدى استيفائها لهذه الادعاءات. بمعنى آخر، توفر المعايير المشتركة ضمانًا بأن عملية تحديد وتنفيذ وتقييم منتج أمن الحاسوب قد تمت بطريقة صارمة ومعيارية وقابلة للتكرار، وبمستوى يتناسب مع بيئة الاستخدام المستهدفة. [ 1 ] تحتفظ المعايير المشتركة بقائمة بالمنتجات المعتمدة، بما في ذلك أنظمة التشغيل، وأنظمة التحكم في الوصول، وقواعد البيانات، وأنظمة إدارة المفاتيح. [ 2 ]

صفات

تُجرى تقييمات المعايير المشتركة على منتجات وأنظمة أمن الحاسوب.

هدف التقييم (TOE)
المنتج أو النظام الذي يخضع للتقييم. يهدف التقييم إلى التحقق من صحة الادعاءات المتعلقة بالمنتج أو النظام المستهدف.
ملف الحماية (PP)
وثيقة، عادةً ما يُعدّها مستخدم أو مجموعة مستخدمين، تُحدد متطلبات الأمان لفئة من أجهزة الأمان (مثل البطاقات الذكية المستخدمة للتوقيعات الرقمية ، أو جدران الحماية الشبكية ) ذات الصلة بهذا المستخدم لغرض معين. يمكن لموردي المنتجات اختيار تطبيق منتجات تتوافق مع واحد أو أكثر من معايير الأمان، وتقييم منتجاتهم وفقًا لهذه المعايير. في هذه الحالة، قد يُستخدم معيار الأمان كنموذج لهدف الأمان الخاص بالمنتج (كما هو مُعرّف أدناه)، أو يضمن مُعدّو هدف الأمان على الأقل ظهور جميع المتطلبات الواردة في معايير الأمان ذات الصلة في وثيقة هدف الأمان الخاصة بالمنتج. يمكن للعملاء الذين يبحثون عن أنواع مُحددة من المنتجات التركيز على تلك المُعتمدة وفقًا لمعيار الأمان الذي يُلبي متطلباتهم.
هدف أمني (ST)
الوثيقة التي تحدد الخصائص الأمنية للمنتج المستهدف للتقييم. قد يدّعي المنتج المستهدف للتقييم (ST) المطابقة مع واحد أو أكثر من معايير الأداء الرئيسية (PP). يتم تقييم المنتج المستهدف للتقييم (TOE) وفقًا لمتطلبات الأداء الوظيفية الأمنية (SFRs) المحددة في تقييمه (انظر أدناه)، لا أكثر ولا أقل. يتيح هذا للبائعين تخصيص التقييم ليتناسب بدقة مع القدرات المقصودة لمنتجاتهم. هذا يعني أن جدار الحماية الشبكي لا يُشترط أن يفي بنفس المتطلبات الوظيفية لنظام إدارة قواعد البيانات ، وأن جدران الحماية المختلفة قد تُقيّم في الواقع وفقًا لقوائم متطلبات مختلفة تمامًا. عادةً ما يُنشر تقييم المنتج المستهدف للتقييم (ST) ليتمكن العملاء المحتملون من تحديد ميزات الأمان المحددة التي تم اعتمادها من خلال التقييم.
المتطلبات الوظيفية الأمنية (SFRs)
تُحدد معايير التقييم المشتركة وظائف الأمان الفردية التي قد يوفرها المنتج. وتقدم هذه المعايير قائمة قياسية بهذه الوظائف. على سبيل المثال، قد تُحدد وظيفة أمان أساسية كيفية التحقق من هوية المستخدم الذي يؤدي دورًا معينًا . قد تختلف قائمة وظائف الأمان الأساسية من تقييم لآخر، حتى لو كان المنتجان المستهدفان من النوع نفسه. مع أن معايير التقييم المشتركة لا تُلزم بتضمين أي وظائف أمان أساسية في اختبار الأمان، إلا أنها تُحدد التبعيات التي يعتمد فيها التشغيل الصحيح لوظيفة ما (مثل القدرة على تقييد الوصول وفقًا للأدوار) على وظيفة أخرى (مثل القدرة على تحديد الأدوار الفردية).
متطلبات ضمان الأمن (SARs)
تتضمن هذه الوثيقة وصفًا للإجراءات المتخذة أثناء تطوير المنتج وتقييمه لضمان توافقه مع وظائف الأمان المعلنة. على سبيل المثال، قد يتطلب التقييم حفظ جميع شفرة المصدر في نظام إدارة التغييرات، أو إجراء اختبار وظيفي شامل. توفر المعايير المشتركة قائمة بهذه الإجراءات، وقد تختلف المتطلبات من تقييم لآخر. أما متطلبات أهداف أو أنواع منتجات محددة، فتُوثق في كل من تقرير الأمان (ST) وتقرير الأداء (PP) على التوالي.
مستوى ضمان التقييم (EAL)
يُشير التصنيف العددي إلى مدى عمق ودقة التقييم. يتوافق كل مستوى تقييم أمني (EAL) مع حزمة من متطلبات ضمان الأمان (SARs، انظر أعلاه) التي تُغطي التطوير الكامل للمنتج، بمستوى مُحدد من الصرامة. تُحدد معايير التقييم المشتركة سبعة مستويات، حيث يُعد المستوى EAL  1 هو الأساسي (وبالتالي الأقل تكلفة في التنفيذ والتقييم)، بينما يُعد المستوى EAL  7 هو الأكثر صرامة (والأكثر تكلفة). عادةً، لا يختار مُعدّ اختبار الأمان (ST) أو برنامج الحماية (PP) متطلبات الضمان بشكل فردي، بل يختار إحدى هذه الحزم، وقد يُضيف إليها متطلبات من مستوى أعلى في بعض المجالات. لا يعني ارتفاع مستوى التقييم الأمني ​​بالضرورة "أمانًا أفضل"، بل يعني فقط أن ضمان الأمان المُعلن عنه في اختبار الأمان قد تم التحقق منه بشكل أكثر شمولًا .

حتى الآن، كانت معظم المنتجات المعتمدة (PPs) ومعظم المنتجات المعتمدة (STs) التي تم تقييمها مخصصة لمكونات تكنولوجيا المعلومات (مثل جدران الحماية وأنظمة التشغيل والبطاقات الذكية).

يُشترط أحيانًا الحصول على شهادة المعايير المشتركة (Common Criteria) عند شراء معدات تقنية المعلومات. وتشمل المعايير الأخرى، على سبيل المثال، معايير التشغيل البيني، وإدارة الأنظمة، وتدريب المستخدمين، والمعايير التكميلية للمعايير المشتركة، ومعايير المنتجات الأخرى. ومن الأمثلة على ذلك معيار ISO/IEC 27002 ومعيار الحماية الأساسي لتقنية المعلومات الألماني .

تفاصيل التنفيذ التشفيري ضمن إطار عمل TOE تقع خارج نطاق CC. بدلاً من ذلك، تحدد المعايير الوطنية، مثل FIPS 140-2 ، مواصفات وحدات التشفير، وتحدد معايير مختلفة خوارزميات التشفير المستخدمة.

في الآونة الأخيرة، يقوم مؤلفو PP بتضمين متطلبات التشفير لتقييمات CC التي عادة ما يتم تغطيتها بتقييمات FIPS 140-2، مما يوسع نطاق CC من خلال تفسيرات خاصة بالمخطط.

تتجه بعض برامج التقييم الوطنية إلى إلغاء التقييمات القائمة على معايير التقييم المعتمدة، ولا تقبل إلا المنتجات التي تدّعي مطابقة تامة لمعايير الأداء المعتمدة. وتقتصر الولايات المتحدة حاليًا على التقييمات القائمة على معايير الأداء المعتمدة فقط.

تاريخ

نشأت CC من ثلاثة معايير:

  • ITSEC – المعيار الأوروبي، الذي تم تطويره في أوائل التسعينيات من قبل فرنسا وألمانيا وهولندا والمملكة المتحدة. وكان أيضاً توحيداً لأعمال سابقة، مثل النهجين البريطانيين ( مخطط التقييم التابع لـ CESG UK الموجه لسوق الدفاع/الاستخبارات وكتاب DTI الأخضر الموجه للاستخدام التجاري)، وقد تم اعتماده من قبل بعض الدول الأخرى، مثل أستراليا.
  • معيار CTCPEC - المعيار الكندي مشتق من معيار وزارة الدفاع الأمريكية، ولكنه تجنب العديد من المشاكل، وقد استخدمه مقيّمون من الولايات المتحدة وكندا بشكل مشترك. نُشر معيار CTCPEC لأول مرة في مايو 1993.
  • TCSEC – معيار وزارة الدفاع الأمريكية DoD 5200.28، المعروف باسم " الكتاب البرتقالي" وأجزاء من سلسلة "قوس قزح" . نشأ "الكتاب البرتقالي" من أعمال أمن الحاسوب، بما في ذلك تقرير أندرسون، التي أجرتها وكالة الأمن القومي والمكتب الوطني للمعايير (الذي أصبح فيما بعد المعهد الوطني للمعايير والتكنولوجيا ) في أواخر السبعينيات وأوائل الثمانينيات. وتستند الفكرة الأساسية لـ"الكتاب البرتقالي" إلى العمل الذي قام به ديف بيل ولين لابادولا لمجموعة من آليات الحماية.

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

منظمات الاختبار

يجب على جميع مختبرات الاختبار الامتثال لمعيار ISO/IEC 17025 ، وعادة ما يتم اعتماد هيئات إصدار الشهادات وفقًا لمعيار ISO/IEC 17065.

يتم عادةً إثبات الامتثال لمعيار ISO/IEC 17025 لهيئة اعتماد وطنية:

تم فحص خصائص هذه المنظمات وعرضها في المؤتمر الدولي العاشر للمؤتمر الدولي للتغير المناخي (ICCC 10).

اتفاقية الاعتراف المتبادل

إلى جانب معيار المعايير المشتركة، توجد أيضًا اتفاقية اعتراف متبادل بالمعايير المشتركة على مستوى المعاهدة الفرعية، حيث يعترف كل طرف فيها بالتقييمات التي تجريها الأطراف الأخرى وفقًا لمعيار المعايير المشتركة. وقد وُقِّعت الاتفاقية في الأصل عام ١٩٩٨ من قِبَل كندا وفرنسا وألمانيا والمملكة المتحدة والولايات المتحدة، وانضمت إليها أستراليا ونيوزيلندا عام ١٩٩٩، تلتها فنلندا واليونان وإسرائيل وإيطاليا وهولندا والنرويج وإسبانيا عام ٢٠٠٠. ومنذ ذلك الحين، أُعيد تسمية الاتفاقية إلى اتفاقية الاعتراف بالمعايير المشتركة ( CCRA )، ولا تزال العضوية فيها تتوسع. [ ٤ ] وفي إطار اتفاقية الاعتراف بالمعايير المشتركة، لا يُعترف إلا بالتقييمات التي تصل إلى مستوى EAL ٢ (بما في ذلك التحسينات التي تتضمن معالجة الثغرات). وتعترف الدول الأوروبية المنضوية تحت مظلة اتفاقية الاعتراف المتبادل بالأمن السيبراني (SOGIS-MRA) عادةً بمستويات EAL الأعلى أيضًا. أما التقييمات التي تبلغ EAL ٥ وما فوق، فتميل إلى مراعاة المتطلبات الأمنية لحكومة الدولة المضيفة.

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

في 2 يوليو 2014، تم التصديق على اتفاقية جديدة لإدارة رأس المال الاستثماري [ 5 ] وفقًا للأهداف المحددة في بيان الرؤية لعام 2012. [ 6 ] تشمل التغييرات الرئيسية في الاتفاقية ما يلي:

  • الاعتراف بالتقييمات التي تتم فقط وفقًا لملف تعريف الحماية التعاوني (cPP) أو مستويات ضمان التقييم من 1 إلى 2 و ALC_FLR.
  • ظهور المجتمعات التقنية الدولية (iTC)، وهي مجموعات من الخبراء التقنيين المكلفين بإنشاء cPPs.
  • خطة انتقالية من اتفاقية CCRA السابقة، بما في ذلك الاعتراف بالشهادات الصادرة بموجب النسخة السابقة من الاتفاقية.

مشاكل

متطلبات

المعايير المشتركة هي معيار عام للغاية؛ فهي لا تقدم بشكل مباشر قائمة بمتطلبات أو ميزات أمان المنتج لفئات محددة من المنتجات: وهذا يتبع النهج الذي اتبعته ITSEC ، ولكنه كان مصدرًا للنقاش بالنسبة لأولئك الذين اعتادوا على النهج الأكثر تحديدًا للمعايير السابقة الأخرى مثل TCSEC و FIPS 140-2 .

قيمة الشهادة

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

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

في حالة مايكروسوفت، تشمل الافتراضات A.PEER:

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

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

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

تبقى إصدارات مايكروسوفت ويندوز المعتمدة عند مستوى EAL4+ دون تضمين تطبيق أي تصحيحات أمنية من مايكروسوفت في تكوينها المُقيّم. وهذا يُظهر كلاً من محدودية وقوة التكوين المُقيّم.

الانتقادات

في أغسطس/آب 2007، قام ويليام جاكسون، كاتب عمود في مجلة أخبار الحوسبة الحكومية (GCN)، بتحليل منهجي لمعايير التقييم المشتركة وتطبيقها في الولايات المتحدة من خلال برنامج تقييم معايير التقييم المشتركة والتحقق منها (CCEVS). [ 8 ] تضمن المقال مقابلات مع مسؤولين تنفيذيين من قطاع الأمن، وباحثين، وممثلين عن الشراكة الوطنية لضمان المعلومات (NIAP). وتشمل الاعتراضات الواردة في المقال ما يلي:

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

في ورقة بحثية نُشرت عام 2006، أشار ديفيد أ. ويلر، المتخصص في علوم الحاسوب، إلى أن عملية المعايير المشتركة تُمارس التمييز ضد المؤسسات ونماذج التطوير التي تركز على البرمجيات الحرة والمفتوحة المصدر . [ 9 ] وتستند متطلبات ضمان الجودة في المعايير المشتركة عادةً إلى منهجية تطوير البرمجيات التقليدية القائمة على نموذج الشلال . في المقابل، يُنتج الكثير من برمجيات المصادر المفتوحة باستخدام نماذج التطوير الرشيقة الحديثة . ورغم أن البعض يرى أن هذين النموذجين لا يتوافقان جيدًا، [ 10 ] فقد حاول آخرون التوفيق بينهما. [ 11 ] وأثار عالم السياسة يان كالبرغ مخاوف بشأن غياب الرقابة على الإنتاج الفعلي للمنتجات بعد اعتمادها، وغياب هيئة تنظيمية دائمة تُعنى بمراقبة الامتثال، وفكرة الحفاظ على الثقة في شهادات أمن تكنولوجيا المعلومات الخاصة بالمعايير المشتركة عبر الحدود الجيوسياسية. [ 12 ]

في عام 2017، تم اكتشاف ثغرة ROCA الأمنية في قائمة منتجات البطاقات الذكية المعتمدة وفقًا لمعايير Common Criteria. وقد سلطت هذه الثغرة الضوء على العديد من أوجه القصور في نظام اعتماد Common Criteria: [ 13 ]

  • تكمن الثغرة الأمنية في خوارزمية توليد مفاتيح RSA محلية الصنع، لم تُنشر ولم تُحلل من قِبل مجتمع تحليل التشفير. مع ذلك، وافق مختبر الاختبار TÜV Informationstechnik GmbH (TÜViT) في ألمانيا على استخدامها، وأصدرت هيئة الاعتماد BSI في ألمانيا شهادات المعايير المشتركة للمنتجات المعرضة لهذه الثغرة. وادعى الهدف الأمني ​​للمنتج المُقيّم أن مفاتيح RSA تُولّد وفقًا للخوارزمية القياسية. واستجابةً لهذه الثغرة، تعتزم BSI الآن تعزيز الشفافية من خلال اشتراط أن يُحدد تقرير الاعتماد، على الأقل، ما إذا كانت تقنية التشفير الخاصة المُطبقة لا تتوافق تمامًا مع معيار مُوصى به. ولا تعتزم BSI اشتراط نشر الخوارزمية الخاصة بأي شكل من الأشكال.
  • على الرغم من إدراك جهات منح الشهادات الآن أن ادعاءات الأمان المحددة في شهادات المعايير المشتركة لم تعد سارية، إلا أن كلاً من الوكالة الوطنية لأمن نظم المعلومات (ANSSI) والمكتب البريطاني لأمن المعلومات (BSI) لم يلغيا الشهادات ذات الصلة. ووفقًا للمكتب البريطاني لأمن المعلومات ، لا يمكن سحب الشهادة إلا إذا صدرت بناءً على فهم خاطئ، كأن يُكتشف تقديم أدلة غير صحيحة. بعد إصدار الشهادة، يُفترض أن صلاحيتها تتضاءل بمرور الوقت نتيجةً لتطور الهجمات واكتشاف هجمات جديدة. يمكن لجهات منح الشهادات إصدار تقارير صيانة، بل وإعادة اعتماد المنتج. مع ذلك، يجب أن يبادر البائع إلى هذه الإجراءات ويرعاها.
  • رغم تأثر العديد من المنتجات الحاصلة على شهادة المعايير المشتركة بثغرة ROCA، إلا أن استجابات الموردين في سياق الاعتماد كانت متباينة. فبالنسبة لبعض المنتجات، صدر تقرير صيانة ينص على أن مفاتيح RSA التي يبلغ طولها 3072 و3584 بت فقط هي التي تتمتع بمستوى أمان لا يقل عن 100 بت، بينما بالنسبة لبعض المنتجات الأخرى، لم يذكر تقرير الصيانة أن التغيير في معيار TOE يؤثر على وظائف الأمان التشفيرية المعتمدة، بل خلص إلى أن التغيير يقتصر على مستوى وثائق التوجيه ولا يؤثر على ضمان الجودة.
  • بحسب هيئة المعايير البريطانية (BSI) ، كان ينبغي على البائعين إبلاغ مستخدمي المنتجات النهائية المعتمدة بوجود ثغرة أمنية في نظام ROCA . إلا أن هذه المعلومات لم تصل في الوقت المناسب إلى السلطات الإستونية التي قامت بتثبيت المنتج المُعرّض للثغرة على أكثر من 750 ألف بطاقة هوية إستونية .

مناهج بديلة

على مدار عمر CC، لم يتم اعتمادها عالميًا حتى من قبل الدول المنشئة، على وجه الخصوص، حيث يتم التعامل مع الموافقات المشفرة بشكل منفصل، كما هو الحال في التطبيق الكندي / الأمريكي لـ FIPS-140 ، ومخطط المنتجات المدعومة من CESG (CAPS) [ 14 ] في المملكة المتحدة.

كما قدمت المملكة المتحدة عدداً من المخططات البديلة عندما تبين أن الجداول الزمنية والتكاليف والنفقات العامة للاعتراف المتبادل تعيق عمل السوق:

  • مخططات تقييم نظام CESG (SYSn) ونهج المسار السريع (FTA) لضمان أنظمة الحكومة بدلاً من المنتجات والخدمات العامة، والتي تم دمجها الآن في خدمة ضمان CESG المصممة خصيصًا (CTAS) [ 15 ] .
  • علامة CESG Claims Tested Mark (علامة CCT)، والتي تهدف إلى التعامل مع متطلبات ضمان أقل شمولاً للمنتجات والخدمات بطريقة فعالة من حيث التكلفة والوقت.

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

في سبتمبر من عام 2012، نشرت معايير التقييم المشتركة بيان رؤية [ 18 ] يُطبّق إلى حد كبير أفكار كريس سالتر من العام السابق. وشملت العناصر الرئيسية للرؤية ما يلي:

  • ستركز المجتمعات التقنية على إعداد ملفات تعريف الحماية التي تدعم هدفها المتمثل في الحصول على نتائج تقييم معقولة وقابلة للمقارنة وقابلة للتكرار وفعالة من حيث التكلفة
  • ينبغي إجراء التقييمات وفقًا لهذه المعايير الأمنية إن أمكن؛ وإذا لم يكن ذلك ممكنًا، فإن الاعتراف المتبادل بالأهداف الأمنية سيقتصر على مستوى EAL2.

انظر أيضاً

مراجع

  1. "المعايير المشتركة - مؤسسة أمن الاتصالات" . مؤرشف من الأصل بتاريخ 2021-02-01 . تم الاطلاع عليه بتاريخ 2015-03-02 .
  2. "المنتجات المعتمدة وفقًا لمعايير الجودة المشتركة" . تم الاطلاع عليه بتاريخ 30-12-2023 .
  3. "نظرة عامة على نظام شهادات المعايير المشتركة الهندية (IC3S)" . تم الاطلاع عليه بتاريخ 30-12-2023 .
  4. "أعضاء لجنة المعايير المشتركة" . بوابة المعايير المشتركة . مؤرشف من الأصل بتاريخ 22-08-2008.
  5. "اتفاقية الاعتراف بشهادات المعايير المشتركة في مجال أمن تكنولوجيا المعلومات" (ملف PDF) . 2014-07-02 . تاريخ الاطلاع: 2023-12-30 .
  6. "بيان رؤية لجنة إدارة المعايير المشتركة" (ملف PDF) . 2012-09-01 . تم الاطلاع عليه بتاريخ 2023-12-30 .
  7. «إصدارات من ويندوز تحصل على مستوى 4+ من معايير التقييم المشتركة لأمن المعلومات والتقنية» . أخبار أمن المعلومات والتقنية الشبكية . 14 ديسمبر 2005. مؤرشف من الأصل في 14 أكتوبر 2006.
  8. تحت الهجوم: معايير التقييم المشتركة لديها الكثير من الانتقادات، ولكن هل تتعرض للظلم؟ مؤرشف في 23 أبريل 2021 في أرشيف الإنترنت الحكومي، أخبار الحاسوب، تم استرجاعه في 14 ديسمبر 2007
  9. ويلر، ديفيد (11 ديسمبر 2006). "البرمجيات الحرة والمفتوحة المصدر (FLOSS) وضمان البرمجيات / أمن البرمجيات" (ملف PDF) . تم الاطلاع عليه بتاريخ 30 ديسمبر 2023 .
  10. وايرينين، ج.؛ بودين، م.؛ بوستروم، ج. (2004). "هندسة الأمن والبرمجة المتطرفة: زواج مستحيل؟". البرمجة المتطرفة والأساليب الرشيقة - عالم البرمجة المتطرفة/الرشيقة 2004. سلسلة محاضرات في علوم الحاسوب. المجلد 3134. الصفحات 117-128 . doi : 10.1007/978-3-540-27777-4_12 . ISBN   978-3-540-22839-4.
  11. بيزنوسوف، كونستانتين؛ كروشتن، فيليب (16-10-2005). "نحو ضمان أمني مرن" . تم الاطلاع عليه بتاريخ 30-12-2023 .
  12. كالبرغ، جان (1 أغسطس 2012). "المعايير المشتركة تلتقي بالسياسة الواقعية - الثقة والتحالفات والخيانة المحتملة" (ملف PDF) . تم الاطلاع عليه بتاريخ 30 ديسمبر 2023 .
  13. بارسوفس، أرنيس ( 2021-03-03). بطاقة الهوية الإلكترونية الإستونية وتحدياتها الأمنية (أطروحة دكتوراه) (باللغة الإستونية). جامعة تارتو. ص 141-143 . تاريخ الاطلاع: 2023-12-30 . 
  14. "CAPS: برنامج المنتجات المدعومة من CESG" . مؤرشف من الأصل بتاريخ 2008-08-01.
  15. خدمات ضمان أمن المعلومات والشهادات (IACS) مؤرشفة في 20 فبراير 2008، على موقع Wayback Machine
  16. سالتر، كريس (10 يناير 2011). "إصلاحات المعايير المشتركة: منتجات أمنية أفضل من خلال زيادة التعاون مع الصناعة" (ملف PDF) . مؤرشف من الأصل (ملف PDF) في 17 أبريل 2012.
  17. بريكمان، جوشوا (2011-03-11). "إصلاحات المعايير المشتركة - إما النجاح أو الفشل - كيف ينبغي للصناعة التعامل مع الثورة التي تلوح في الأفق مع المعايير المشتركة؟" .{{cite web}}: CS1 maint: deprecated archiveal service ( link )
  18. "بيان رؤية لجنة إدارة هيئة تنظيم وتطوير رأس المال (CCRA) بشأن التوجه المستقبلي لتطبيق قانون رأس المال (CC) وقانون تنظيم وتطوير رأس المال (CCRA)" (ملف DOCX) . 18-09-2012 . تاريخ الاطلاع: 30-12-2023 .