ماذا يبقى من شروط الإفصاح بعد اقتطاع التقرير؟

الخلاصة

• يمكن أن يرث عنصر في تقرير IODEF قيد الإفصاح من عنصر أعلى، ويمكن للعنصر الفرعي أن يضع استثناء أكثر تشددا أو أكثر سماحا. وسم الملف كله لا يصف كل أجزائه بالضرورة.
• نقل الاسم والعنوان وسائر الوقائع بدقة لا يضمن نقل شروط استخدامها. فقد تضيع العلاقة التي كانت تحدد نطاق مشاركتها.
• لا تتطابق دلالة amber القديمة في IODEF مع TLP:AMBER الحالية التي قد تشمل العملاء. استبدال الوسم قد يوسع الجمهور، وليس مجرد تحسين للشكل.

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

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

يحدد RFC 7970 الإصدار الثاني من IODEF، وهو نموذج لتمثيل تقارير الحوادث الأمنية والمؤشرات مع صيغة بيانات تستند إلى XML. نُشر في نوفمبر 2016، وما زال سجله الرسمي الحالي يصنفه Proposed Standard. وجود تنسيق مشترك يسهل التعاون بين فرق التشغيل، لكنه لا يجعل كل معلومة منفردة مستقلة عن التقرير الذي يحتويها. RFC 7970، السجل الرسمي.

قد يسمح الاستثناء بما يمنعه عنوان الملف

في القسم 3.3.1، يعبر restriction عن إرشاد المرسل بشأن الإفصاح. يسري على الفئة التي تحمله وعلى العناصر التابعة لها، لكن يمكن لعنصر فرعي أن يستبدله بقيد أشد أو بإرشاد أوسع. وعند غياب قيمة محلية، تُورث القيمة من أقرب عنصر أعلى حددها. وتضع القاعدة العامة قيمة افتراضية هي private لفئة Incident.

لنتصور، على سبيل المثال لا على سبيل وصف واقعة، Incident محددا صراحة بأنه private ويحتوي Contact محددا صراحة بأنه public. يستطيع المرسل بذلك أن يبين أن معلومات التواصل قابلة للنشر من دون فتح ملف الحادث كله. ويمكن أيضا أن يحتوي تقرير مخصص للشركاء على جهة تواصل private. هذه أمثلة على ما يسمح التنسيق بالتعبير عنه، وليست إثباتا لامتلاك المرسل جميع الحقوق اللازمة للإفصاح. RFC 7970، القسم 3.3.1.

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

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

الغياب لا يعني القيمة الافتراضية الصريحة

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

أما القيمة الصريحة default فلها مرجع مختلف: سياسة إفصاح متفق عليها مسبقا بين الطرفين المتواصلين. إنها ليست مرادفا لترك الخاصية فارغة. في حالة الغياب ينبغي تتبع العنصر الأعلى؛ وفي حالة default ينبغي تحديد الاتفاق. جمع الحالتين تحت عبارة «إعداد التطبيق الافتراضي» قد يستبدل مرجع المرسل بسياسة محلية لم يقصدها. سجل Restriction لدى IANA.

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

اللون نفسه لا يضمن الجمهور نفسه

يحتفظ سجل IANA الذي جرى التحقق منه بأسماء الألوان القديمة: white يقابل public، وgreen يقابل partner، وamber يقابل need-to-know، وred يقابل private. وفي هذا الاستخدام، يقتصر need-to-know على من يحتاجون إلى المعلومات داخل المنظمة. IANA.

لكن TLP 2.0 لدى FIRST، وهو الإصدار الحالي المعتمد منذ أغسطس 2022، يرسم حدا مختلفا في النقطة المهمة هنا. يتيح TLP:AMBER المشاركة على أساس الحاجة إلى المعرفة داخل الجهة المستقبلة ومع عملائها، بالقدر اللازم لحمايتهم ومنع مزيد من الضرر. أما TLP:AMBER+STRICT فيحصرها داخل المنظمة. ويجوز للمصدر إضافة قيود، بينما يتطلب توسيع النطاق إذنا صريحا منه. تبقى هذه الوسوم بصيغتها الأصلية حتى في النص العربي. FIRST TLP 2.0.

لذلك فإن تحويل amber آليا إلى TLP:AMBER وحده قد يضيف العملاء إلى جمهور كان داخليا. هذه نتيجة مقارنة التعريفات المنشورة، لا دليل على تسريب وقع أو عيب في منتج، وليست جدولا معتمدا للتحويل في جميع البيئات. تبقى الحدود التنظيمية والقيود الإضافية جزءا من التفسير المطلوب.

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

صحة البنية لا تكمل الاتفاق

يفرق RFC 7970 نفسه بين سلامة XML وبين اكتمال التفسير. يطلب القسم 4.3 أن يكون المستند سليما من ناحية الصياغة، ويوصي بالتوافق مع المخطط، مع مراعاة القيود الإضافية في نموذج المعلومات. نجاح القبول التقني لا يثبت فهم جميع الشروط التشغيلية.

تقدم التصويبة التقنية 5543، التي تم التحقق منها في نوفمبر 2018، مثالا محدودا. فهي تصلح مخطط Confidence ليسمح بالمحتوى العددي الذي يتحدث عنه النص. ذلك يصحح التمثيل، لا المعنى المشترك للأرقام؛ تفسير الثقة العددية يبقى خارج تعريف RFC. ولا تحسم هذه التصويبة القيم الافتراضية لـ restriction. تحويل إصلاح جزئي إلى ضمان شامل يعيد الخلط بين مستويين مختلفين. التصويبة 5543، RFC 7970.

المسؤولية لا تنتهي عند وصول الملف

يشترط IODEF السرية والسلامة والأصالة في وسيلة التبادل الأساسية، لكنه يقر بأن إرشاد الإفصاح لا يتضمن ضمانا تقنيا لامتثال المستقبل. وتشمل مناقشة الخصوصية التقارير المخزنة والتحليلات المشتقة ومعلومات الأطراف الثالثة. كما قد تصبح المعرفات أكثر كشفا عند ربطها عبر تبادلات متكررة. RFC 7970، القسم 9.

يناقش RFC 6545 الخاص بـ RID اتفاقات الخصوصية وملفات المشاركة من حيث أنواع البيانات وحمايتها ومدى إعادة إرسالها والموافقات المطلوبة. ويتصور إمكان الإبلاغ عن إجراء تخفيف من دون كشف هوية مصدر الهجوم. فالتعاون المفيد لا يستلزم دائما أكبر قدر من الإفصاح. كذلك لا تحسم حماية كل وصلة بمفردها من يرى المعلومات على طول سلسلة التبادل. هذه اعتبارات تصميم وليست إذنا قانونيا معاصرا بمشاركة معينة. RFC 6545، القسمان 9.5 و9.6.

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

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

يمكن للجزء المفيد أن يغادر الملف الأصلي. ما ينبغي ألا يضيع هو تفسير السبب الذي يسمح له بالوصول إلى هؤلاء المستلمين تحديدا.