المجال الرئيسي
الأمن
ضمن فئة المجال الرئيسي، تجمع تحليلات الأمن التقارير حسب المجال الأساسي ليتمكن القراء من متابعة مجال مركّز من مجالات البنية التحتية للإنترنت أو الحوكمة أو أسواق الاتصالات أو رأس المال الرقمي. وتضم الصفحة المقالات ذات الصلة والأدلة العامة والمؤسسات والشركات والأشخاص والانتشار الإقليمي والتبعيات التشغيلية وسياق السوق التي قد تكون موزعة عبر صفحات فئات منفصلة. وتشرح الصفحة المجال ونوع الجهات الفاعلة المحتملة وسياق السوق أو الحوكمة والمادة المصدرية التي ينبغي للقراء استخدامها عند مقارنة المؤشرات. ويمكن للمشغلين والمحللين والمهتمين بالحوكمة أن يروا كيف يظهر المجال نفسه عبر الأحداث والملفات الشخصية وتحولات السوق والأدلة المستقاة من المصادر العامة والتبعيات الإقليمية وقرارات البنية التحتية طويلة الأجل بمرور الوقت.
خدمات سحابية في أمريكا الشمالية
عرض Proofpoint لشراء Varonis يختبر الربط بين إشارات التهديد والوصول إلى البيانات
لا تصبح التنبيهات الأمنية مفيدة عملياً إلا عندما يمكن ربط من قام بالفعل، والبيانات التي استطاع الوصول إليها، والصلاحية التي أتاحت ذلك، وما إذا كان الإجراء قد خفّض التعرض فعلاً. تقول Proofpoint إن شراء Varonis سيقرّب هذه العناصر. لم تُغلق الصفقة بعد، وما أُعلن عن تكامله ما زال خطة…
التقارير
في فعالية FIRST المصاحبة لـLACNIC 46، تُبقي CEDIA القرارات الحرجة بيد البشر
جلسة مقررة في 21 أكتوبر ستعرض DALIA بوصفها أداة ذكاء اصطناعي لمساندة فرز بلاغات CSIRT وربط الإشارات وترتيب الأولويات، مع إبقاء القرارات الحرجة والاحتواء ضمن مسؤولية البشر. ولا يوضح الملخص كيف يُفرض هذا الحد.
IETF
نجح التطابق، لكن جزءاً من الرسالة لم يدخل الاختبار
لا يرى مرشح Sieve «متن الرسالة» كحقيقة واحدة. قد يرى البايتات غير المفكوكة، أو أجزاء MIME التي اختارها النوع، أو نصاً صنعه أفضل محول متاح. يبين RFC 5173 أن نجاح البحث يصف تلك السطح المحلي فقط، لا كل ما حملته الرسالة ولا ما قصده مرسلها.
IETF
كان الرمز الابن صالحاً، لكن سلسلة التفويض كلها بقيت مطالبة بإثبات سلطته
قد يكون توقيع رمز OAuth المفوَّض صحيحاً تماماً من دون أن يمنح عملية واحدة قابلة للتنفيذ. فالسلطة لا تأتي من الابن منفرداً، بل من جذر موثوق وكل انتقال وتضييق وحالة راهنة وقرار محلي يجتمع عند خادم المورد.
IETF
وقّعت الشركة المصنّعة جذور الثقة الجديدة، وبقي خادم التسليم بلا مصادقة
يمكن لجهاز لا يعرف بعد سلطة التصديق التشغيلية أن يتلقى حزمة موقعة بمفتاح ثقة زُرع في المصنع. لكن التوقيع يثبت الحزمة ولا يثبت الخادم الذي نقلها؛ وتظل سياسة المشغّل والجلسة الجديدة والتسجيل والنتيجة مراحل ذات أدلة مستقلة.
IETF
الاسم مسجّل، لكن معناه التنفيذي لم يكتمل بعد
قد يظهر معرّف في السجل قبل أن تصبح كل تفاصيل مواصفته متاحة، والغاية المعقولة هي منع تصادم الأسماء. لكن سلسلة الإنتاج قد تقرأ وجود الاسم كأنه ضمان للمعنى والتنفيذ والإذن. هنا يتحول إجراء تنسيق مفيد إلى استنتاج لم يثبته السجل.
IETF
عبر التعليمة جلستان وبينهما إنسان، ولم ينشأ تفويض من تلقاء نفسه
ينقل المستخدم سلسلة DUJ من خدمة إلى لوحة مشغّل DNS. لكن حمل البايتات بين اتصالين موثّقين لا يربط هوية الخدمة بصلاحية الحساب على المنطقة، ولا يثبت أن التغيير ظهر لاحقاً في DNS العام.
IETF
نجح التوقيع، لكن من فوّض المفتاح لتمثيل الشريك؟
قد تصل شهادة جديدة في موعد التدوير، ويعمل اتصال HTTPS، وتتطابق أسماء AS2، ويصح التوقيع وMIC. لا يجيب أي من ذلك وحده عن السؤال الإداري الحاسم: من ربط هذا المفتاح بهذا الشريك وفي هذا الاتجاه؟
ملف القضية
مرّ رقم الخوارزمية عبر ثلاث سلطات ولم يحمل الحكم نفسه
لا يصبح الرقم حقيقة تشغيلية لمجرد ظهوره في حزمة. ففي 1 أكتوبر 2026 كانت المسودة العاملة لـOpenPGP تعرّف الأرقام 37 إلى 44 كثماني تركيبات تجمع خوارزميات ما بعد الكم بمنحنيات NIST وBrainpool، بينما كان سجل IANA العلني يعرض النطاق 37–99 على أنه غير مخصّص. وبين النص والسجل والبرنامج…
IETF
تغيّر مفتاح ACME، لكن تفويض DNS القديم ما زال سارياً
تفصل المراجعة الجديدة لتحدي DNS الدائم في ACME بين صيانة المفتاح وسحب الصلاحية. قد يتوقف المفتاح الخاص القديم عن توقيع الطلبات، فيما تظل بصمته العامة سنداً لتفويض لم تنته مدته.
IETF
نجح التحقق من الدليل. فمن يتحمّل مسؤولية الوسم؟
تستطيع شفافية المفاتيح إثبات أن إجابة الدليل متسقة مع سجل سابق، لكنها لا تعيّن وحدها صاحب السلطة ولا الطرف الذي اعتمد على الإجابة ولا من يلزمه الاستمرار في المراقبة. وهذه هي الفجوة التي أعادتها مراجعة IETF الأخيرة إلى الواجهة.
تاريخ
مخاطر إرشاد بلا وصي: درس مجموعة grip في IETF وسجل RFC 2350
في يونيو 1998 نشر فريق عمل بالمهندسين (IETF) وثيقة تحدد ما يمكن للمؤسسات أن تتوقعه من فرق الاستجابة لحوادث أمن الحواسيب. وقد اختُتم الفريق المعني — مجموعة grip الموسومة بـ "G & R for Security Incident Processing" — في ديسمبر 2001. غير أن وثيقته الرئيسية، RFC 2350، لا تزال المعيار…
ملف القضية
كانت القيمة واحدة، لكن البايتات المعاد بناؤها لم تتطابق
عرضت جهة التوقيع وجهة التحقق خريطة CBOR نفسها: المفاتيح ذاتها والقيم ذاتها. ومع ذلك حسبتا مدخلين مختلفين للتوقيع. لم يعبث أحد بالمحتوى، بل استخدم كل مُرمِّز حرية مشروعة تركها البروتوكول بلا صاحب قرار.
ملف القضية
لم يرتبط البرهانان، لكن الغلاف تعرّف إلى الشخص نفسه: حدود توقيعات BBS
وصل برهانان من BBS بقيمتين مختلفتين لا تكشف إحداهما أنهما مشتقتان من التوقيع نفسه. ومع ذلك حملا رأساً نادراً، وعشرة مواضع للرسائل، والمزيج غير المعتاد نفسه من الفهارس المكشوفة، ومفتاحاً استُخدم لاثني عشر حاملاً فقط. أوفت الخوارزمية بوعدها؛ أما النظام فوسّع الوعد من قيمة البرهان…
ملف القضية
سجّل RFC 9952 الاسم `co` ولم يأمر المصافحة باستخدامه
يستطيع السجل أن يسمّي خياراً من دون أن يأمر العميل بإرساله أو الخادم باختياره. هذه ليست ثغرة في RFC 9952، بل حدّه المقصود: تنسيق اسم قصير لخدمة CoAP فوق DTLS، مع إبقاء التنفيذ والاتصال الفعلي في طبقة أخرى.
ملف القضية
بقي الاسم AEGIS وتغيّرت قاعدة إعادة الاستخدام: RFC 10032
تصل وسمٌ صالح إلى نظام ما، فيُطلب منه أن يؤدي ثلاث وظائف: إثبات سلامة رسالة، والعمل كبصمة للمحتوى، ثم توفير مادة لمفتاح جديد. يجيز RFC 10032 الوظيفة الأولى ضمن عقد محدد، ويرفض الوظيفتين الأخريين. شكل الخرج واحد تقريباً، لكن السلطة التي يحملها ليست واحدة.
IETF
يمنح IDMEFv2 الرمز 204 معنى الحيازة، لا معنى حسم الحادث
قد يحفظ المدير تنبيهاً ثم ينقطع المسار قبل وصول الرد إلى المُحلّل. فيرى المرسل فشلاً بينما يكون المستقبل قد نجح. يجعل مشروع نقل IDMEFv2 الرمز 2xx إيصالاً مهماً، لكنه يترك للتحالف تحديد معنى POST الثاني.
ملف القضية
نجح التحقق من التوقيع، لكنه لم يسمِّ أصحاب الموافقة: RFC 9591
وجد فريق التدقيق رسالةً وتوقيع Schnorr صالحاً ومفتاح المجموعة العام. لم يجد أسماء المشاركين في الجلسة. فالتحقق يثبت أن عتبة التوقيع عملت على البايتات المحددة، ولا يثبت من اختير أو ماذا راجع أو بأي صلاحية وافق. يشرح RFC 9591 كيف يضغط FROST حصصاً متعددة في توقيع واحد؛ أما سجل…
ملف القضية
قالت قائمة القدرات EdDSA، لكنها لم تسمِّ المنحنى بعد: RFC 9864
قد يتطابق اسم الخوارزمية في قائمتين من دون أن تتطابق العملية القابلة للتنفيذ. فالاسم `EdDSA` لا يبين إن كان الطرف يدعم Ed25519 أو Ed448 أو كليهما. يعيد RFC 9864 الاختيار الإلزامي إلى المعرّف نفسه، لكنه لا يحوّل الاسم إلى إثبات على وجود الكود أو تفعيله أو نجاح التبادل.
ملف القضية
أعادت النسخة الاحتياطية المفتاح — وأعادت معه حالة الأمس: RFC 9802
قد يبدأ جهازا توقيع من النسخة الاحتياطية نفسها، ويحمل كل منهما مادة المفتاح الصحيحة، وينتج كل منهما توقيعاً ينجح في التحقق. لكن إذا استهلكا الفهرس أحادي الاستخدام نفسه، فقد كسرت الاستعادة فرضية الأمان من دون أن يكشف الشهادة ذلك. يعرّف RFC 9802 أنظمة HSS وXMSS داخل X.509، لكنه لا…