روابط لأجزاء أخرى من الدراسة
- (كنت هنا)
تكمل هذه المقالة دورة المنشورات المخصصة لضمان أمن معلومات المدفوعات المصرفية غير النقدية. هنا نلقي نظرة على نماذج التهديد العامة المشار إليها في :
- .
- .
- .
- .
تحذير هابر !!! أعزائي خابروفيتس ، هذا ليس منشورًا ترفيهيًا.
يتم استدعاء 40+ صفحة من المواد المخبأة تحت القص المساعدة في العمل أو الدراسة الأشخاص المتخصصين في الخدمات المصرفية أو أمن المعلومات. هذه المواد هي المنتج النهائي للدراسة وهي مكتوبة بنبرة رسمية جافة. في الواقع ، هذه فراغات للوثائق الداخلية المتعلقة بأمن المعلومات.حسنًا ، التقليدي "استخدام المعلومات الواردة في المقالة لأغراض غير قانونية يعاقب عليه القانون". قراءة منتجة!
معلومات للقراء الذين قرأوا الدراسة بدءًا من هذا المنشور.
ما هي دراسة حول
أنت تقرأ دليلًا لمتخصص مسؤول عن ضمان أمن معلومات المدفوعات في البنك.
منطق العرض
في البداية في и وصف موضوع الحماية. ثم في يخبرنا كيفية بناء نظام حماية ، ويتحدث عن الحاجة إلى إنشاء نموذج تهديد. في إنه يخبر عن ماهية نماذج التهديد وكيف يتم تشكيلها. في и تحليل الهجمات الحقيقية. и تحتوي على وصف لنموذج التهديد الذي تم إنشاؤه مع مراعاة المعلومات من جميع الأجزاء السابقة.
نموذج التهديدات النموذجية. إتصال شبكة
كائن الحماية الذي يطبق عليه نموذج التهديد (النطاق)
الهدف من الحماية هو البيانات المنقولة من خلال اتصال شبكة تعمل في شبكات البيانات المبنية على أساس مكدس TCP / IP.
هندسة معمارية
وصف عناصر العمارة:
- "عقد النهاية" - عقد تبادل المعلومات المحمية.
- "العقد الوسيطة" - عناصر شبكة نقل البيانات: أجهزة التوجيه والمحولات وخوادم الوصول والخوادم الوكيلة وغيرها من المعدات - التي يتم من خلالها نقل حركة مرور اتصال الشبكة. بشكل عام ، يمكن أن يعمل اتصال الشبكة بدون عقد وسيطة (مباشرة بين العقد النهائية).
تهديدات أمنية عالية المستوى
تقسيم
U1. الوصول غير المصرح به إلى البيانات المرسلة.
U2. تعديل غير مصرح به للبيانات المرسلة.
U3. انتهاك تأليف البيانات المرسلة.
U1. الوصول غير المصرح به إلى البيانات المرسلة
تقسيم
U1.1. <...> ، يتم إجراؤها على العقد النهائية أو الوسيطة:
U1.1.1. <…> من خلال قراءة البيانات أثناء وجودها في أجهزة التخزين الخاصة بالعقدة:
U1.1.1.1. <…> في ذاكرة الوصول العشوائي.
تفسيرات ل V1.1.1.1.
على سبيل المثال ، أثناء معالجة البيانات بواسطة مكدس شبكة العقدة.
U1.1.1.2. <…> في ذاكرة غير متطايرة.
تفسيرات ل V1.1.1.2.
على سبيل المثال ، عند تخزين البيانات المرسلة في ذاكرة التخزين المؤقت أو الملفات المؤقتة أو ملفات الترحيل.
Y1.2. <…> تم تنفيذه على عقد شبكة بيانات تابعة لجهات خارجية:
U1.2.1. <...> من خلال التقاط جميع الحزم التي تقع على واجهة الشبكة الخاصة بالعقدة:
تفسيرات ل V1.2.1.
يتم التقاط جميع الحزم عن طريق تبديل بطاقة الشبكة إلى الوضع المختلط (الوضع المختلط للمحولات السلكية أو وضع الشاشة لمحولات wi-fi).
U1.2.2. <…> بتنفيذ هجمات man-in-the-middle (MiTM) ، ولكن دون تعديل البيانات المرسلة (بدون حساب بيانات الخدمة لبروتوكولات الشبكة).
Y1.2.2.1. وصلة: .
Y1.3. <...> ، يتم تنفيذه بسبب تسرب المعلومات عبر القنوات التقنية (TCUI) من العقد المادية أو خطوط الاتصال.
U1.4. <...> ، يتم تنفيذه لتركيب وسائل تقنية خاصة (STS) على العقد النهائية أو الوسيطة ، بغرض الإزالة السرية للمعلومات.
U2. تعديل غير مصرح به للبيانات المرسلة
تقسيم
U2.1. <...> ، يتم إجراؤها على العقد النهائية أو الوسيطة:
Y2.1.1. <...> من خلال قراءة البيانات وتعديلها أثناء وجودها في أجهزة التخزين الخاصة بالعقد:
Y2.1.1.1. <...> في ذاكرة الوصول العشوائي:
Y2.1.1.2. <…> في الذاكرة غير المتطايرة:
Y2.2. <...> تم تنفيذه على عقد شبكة بيانات تابعة لجهات خارجية:
U2.2.1. <…> بتنفيذ هجمات Man-in-the-Middle (MiTM) وإعادة توجيه حركة المرور إلى المضيف الضار:
Y2.2.1.1. الاتصال المادي لأجهزة المهاجمين لقطع اتصال الشبكة.
Y2.2.1.2. تنفيذ الهجمات على بروتوكولات الشبكة:
Y2.2.1.2.1. <…> إدارة شبكة المنطقة المحلية الافتراضية (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. تعديل غير مصرح به لإعدادات VLAN على المحولات أو أجهزة التوجيه.
Y2.2.1.2.2. <…> توجيه حركة المرور:
Y2.2.1.2.2.1. تعديل غير مصرح به لجداول التوجيه الثابتة لأجهزة التوجيه.
Y2.2.1.2.2.2. الإعلان عن طرق وهمية من قبل المهاجمين من خلال بروتوكولات التوجيه الديناميكي.
Y2.2.1.2.3. <…> التكوين التلقائي:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> العنونة وتحليل الاسم:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. إجراء تغييرات غير مصرح بها على ملفات اسم المضيف المحلي (المضيفون ، و lmhosts ، وما إلى ذلك)
U3. انتهاك تأليف البيانات المرسلة
تقسيم
Y3.1. تحييد آليات تحديد تأليف المعلومات من خلال الإشارة إلى معلومات خاطئة عن المؤلف أو مصدر البيانات:
Y3.1.1. تغيير المعلومات الخاصة بالمؤلف الواردة في المعلومات المنقولة.
Y3.1.1.1. تحييد الحماية المشفرة لسلامة وتأليف البيانات المرسلة:
Y3.1.1.1.1. وصلة: .
Y3.1.1.2. تحييد حماية تأليف البيانات المرسلة ، يتم تنفيذه باستخدام أكواد التأكيد لمرة واحدة:
Y3.1.1.2.1. .
Y3.1.2. تغيير المعلومات حول مصدر المعلومات المرسلة:
Y3.1.2.1. .
Y3.1.2.2. .
نموذج التهديدات النموذجية. تم بناء نظام المعلومات على أساس بنية خادم العميل
كائن الحماية الذي يطبق عليه نموذج التهديد (النطاق)
الهدف من الحماية هو نظام معلومات مبني على أساس بنية خادم العميل.
هندسة معمارية
وصف عناصر العمارة:
- "عميل" - جهاز يعمل عليه جزء العميل من نظام المعلومات.
- "الخادم" - جهاز يعمل عليه جزء الخادم من نظام المعلومات.
- "مخزن البيانات" - جزء من البنية التحتية للخادم لنظام المعلومات ، مصمم لتخزين البيانات التي تتم معالجتها بواسطة نظام المعلومات.
- "إتصال شبكة" - قناة تبادل المعلومات بين العميل والخادم التي تمر عبر شبكة نقل البيانات. للحصول على وصف أكثر تفصيلاً لنموذج العنصر ، راجع .
القيود
عند نمذجة كائن ، يتم تعيين القيود التالية:
- يتفاعل المستخدم مع نظام المعلومات خلال فترات زمنية محددة تسمى جلسات العمل.
- في بداية كل جلسة ، يتم تحديد المستخدم والمصادقة عليه والترخيص له.
- يتم تخزين جميع المعلومات المحمية على جزء الخادم من نظام المعلومات.
تهديدات أمنية عالية المستوى
تقسيم
U1. المهاجمون الذين يرتكبون إجراءات غير مصرح بها نيابة عن مستخدم شرعي.
U2. التعديل غير المصرح به للمعلومات المحمية أثناء معالجتها بواسطة جزء الخادم من نظام المعلومات.
U1. المهاجمون الذين يرتكبون إجراءات غير مصرح بها نيابة عن مستخدم شرعي
تفسير
عادة في أنظمة المعلومات ، يتم تنفيذ ارتباط الإجراءات مع المستخدم الذي قام بها باستخدام:
- سجلات النظام (السجلات).
- السمات الخاصة لكائنات البيانات التي تحتوي على معلومات حول المستخدم الذي أنشأها أو عدلها.
فيما يتعلق بجلسة العمل ، يمكن أن يتحلل هذا التهديد إلى:
- تم إجراء <…> خلال جلسة المستخدم.
- تم إجراء <…> خارج جلسة المستخدم.
يمكن بدء جلسة المستخدم:
- من قبل المستخدم نفسه.
- الدخلاء.
في هذه المرحلة ، سيبدو التحلل الوسيط لهذا التهديد كما يلي:
U1.1. الإجراءات غير المصرح بها التي يتم تنفيذها في جلسة المستخدم:
U1.1.1. <…> حدده المستخدم المهاجم.
U1.1.2. تم تثبيت <…> بواسطة المهاجمين.
Y1.2. تم تنفيذ إجراءات غير مصرح بها خارج جلسة المستخدم.
من وجهة نظر كائنات البنية التحتية للمعلومات التي يمكن أن تتأثر بالمتسللين ، سيبدو تحلل التهديدات الوسيطة كما يلي:
عناصر
تحليل التهديد
Y1.1.1.
Y1.1.2.
Y1.2.
زبون
Y1.1.1.1.
Y1.1.2.1.
إتصال شبكة
Y1.1.1.2.
الخادم
Y1.2.1.
تقسيم
U1.1. الإجراءات غير المصرح بها التي يتم تنفيذها في جلسة المستخدم:
U1.1.1. <…> حدده المستخدم المهاجم:
U1.1.1.1. تصرف المهاجمون بشكل مستقل عن العميل:
1.1.1.1.1 استخدم المهاجمون أدوات الوصول إلى نظام المعلومات القياسية:
Y1.1.1.1.1.1. استخدم المهاجمون وسائل الإدخال / الإخراج الفعلية للعميل (لوحة المفاتيح أو الماوس أو الشاشة أو شاشة اللمس لجهاز محمول):
Y1.1.1.1.1.1.1. تصرف المهاجمون خلال الفترات الزمنية التي كانت فيها الجلسة نشطة ، وتوفر مرافق الإدخال / الإخراج والمستخدم بعيدًا.
Y1.1.1.1.1.2. استخدم المهاجمون أدوات الإدارة عن بُعد (قياسية أو مقدمة بواسطة تعليمات برمجية ضارة) لإدارة العميل:
Y1.1.1.1.1.2.1. تصرف المهاجمون خلال الفترات الزمنية التي كانت فيها الجلسة نشطة ، وتوفر مرافق الإدخال / الإخراج والمستخدم بعيدًا.
Y1.1.1.1.1.2.2. استخدم المهاجمون أدوات الإدارة عن بعد ، والتي يكون تشغيلها غير مرئي للمستخدم المهاجم.
U1.1.1.2. انتحل المهاجمون البيانات الموجودة في اتصال الشبكة بين العميل والخادم ، وقاموا بتعديلها بطريقة يُنظر إليها على أنها تصرفات مستخدم شرعي:
Y1.1.1.2.1. وصلة: .
U1.1.1.3. أجبر المهاجمون المستخدم على تنفيذ الإجراءات التي حددوها باستخدام أساليب الهندسة الاجتماعية.
U1.1.2 <…> تم تعيينه بواسطة المهاجمين:
Y1.1.2.1. المهاجمون تصرفوا من العميل (И):
Y1.1.2.1.1. قام المهاجمون بتحييد نظام التحكم في الوصول لنظام المعلومات:
Y1.1.2.1.1.1. وصلة: .
Y1.1.2.1.2. استخدم المخربون وسائل منتظمة للوصول إلى نظام المعلومات
U1.1.2.2. تصرف المهاجمون من العقد الأخرى لشبكة نقل البيانات ، والتي يمكن من خلالها إنشاء اتصال شبكة بالخادم (И):
Y1.1.2.2.1. قام المهاجمون بتحييد نظام التحكم في الوصول لنظام المعلومات:
Y1.1.2.2.1.1. وصلة: .
Y1.1.2.2.2. استخدم المهاجمون وسائل غير قياسية للوصول إلى نظام المعلومات.
التفسيرات Y1.1.2.2.2.
يمكن للمهاجمين تثبيت عميل نظام معلومات عادي على عقدة طرف ثالث أو يمكنهم استخدام برنامج غير قياسي يقوم بتنفيذ بروتوكولات التبادل القياسية بين العميل والخادم.
P1.2 الإجراءات غير المصرح بها التي يتم تنفيذها خارج جلسة المستخدم.
S1.2.1 نفذ المهاجمون إجراءات غير مصرح بها ، ثم أجروا تغييرات غير مصرح بها على سجلات تشغيل نظام المعلومات أو السمات الخاصة لكائنات البيانات ، مما يشير إلى أن الإجراءات التي ارتكبوها تم تنفيذها بواسطة مستخدم شرعي.
U2. التعديل غير المصرح به للمعلومات المحمية أثناء معالجتها بواسطة جزء الخادم من نظام المعلومات
تقسيم
Y2.1. يقوم المهاجمون بتعديل المعلومات المحمية باستخدام أدوات نظام المعلومات القياسية ويقومون بذلك نيابة عن مستخدم شرعي.
Y2.1.1. وصلة: .
Y2.2. يقوم المهاجمون بتعديل المعلومات المحمية باستخدام آليات الوصول إلى البيانات التي لا يوفرها التشغيل المنتظم لنظام المعلومات.
U2.2.1. يقوم المهاجمون بتعديل الملفات التي تحتوي على معلومات محمية:
Y2.2.1.1. <…> باستخدام آليات معالجة الملفات التي يوفرها نظام التشغيل.
Y2.2.1.2. <...> من خلال إثارة استعادة الملفات من نسخة احتياطية معدلة غير مصرح بها.
U2.2.2. يقوم Malefactors بتعديل المعلومات المحمية المخزنة في قاعدة البيانات (И):
Y2.2.2.1. المهاجمون يحيدون نظام التحكم في الوصول DBMS:
Y2.2.2.1.1. وصلة: .
Y2.2.2.2. يعدل المهاجمون المعلومات باستخدام واجهات DBMS القياسية للوصول إلى البيانات.
Y2.3. يقوم المخالفون بتعديل المعلومات المحمية عن طريق التعديل غير المصرح به لخوارزميات عمل البرنامج الذي يعالجها.
Y2.3.1. يتم إجراء تعديلات على الكود المصدري للبرنامج.
U2.3.1. يتم إجراء تعديلات على رمز الجهاز الخاص بالبرنامج.
Y2.4. يقوم المهاجمون بتعديل المعلومات المحمية من خلال استغلال نقاط الضعف في برامج نظام المعلومات.
Y2.5. يقوم المهاجمون بتعديل المعلومات المحمية عند نقلها بين مكونات جزء الخادم من نظام المعلومات (على سبيل المثال ، خادم قاعدة البيانات وخادم التطبيق):
Y2.5.1. وصلة: .
نموذج التهديدات النموذجية. نظام التحكم في الوصول
كائن الحماية الذي يطبق عليه نموذج التهديد (النطاق)
كائن الحماية الذي يطبق عليه نموذج التهديد هذا يتوافق مع هدف الحماية لنموذج التهديد: "نموذج التهديد النموذجي. نظام معلومات مبني على أساس بنية العميل والخادم.
يُفهم نظام التحكم في وصول المستخدم في نموذج التهديد هذا على أنه أحد مكونات نظام المعلومات الذي ينفذ الوظائف التالية:
- تعريف المستخدم.
- مصادقة المستخدم.
- أذونات المستخدم.
- تسجيل إجراءات المستخدم.
تهديدات أمنية عالية المستوى
تقسيم
U1. إنشاء جلسة غير مصرح به نيابة عن مستخدم شرعي.
U2. رفع غير مصرح به لامتيازات المستخدم في نظام المعلومات.
U1. إنشاء جلسة غير مصرح به نيابة عن مستخدم شرعي
تفسير
سيعتمد تحلل هذا التهديد في الحالة العامة على نوع تعريف المستخدم وأنظمة المصادقة المستخدمة.
في هذا النموذج ، سيتم النظر فقط في تعريف المستخدم ونظام المصادقة باستخدام تسجيل الدخول النصي وكلمة المرور. في هذه الحالة ، سنفترض أن تسجيل دخول المستخدم هو معلومات عامة معروفة للمهاجمين.
تقسيم
U1.1. <…> من خلال التنازل عن بيانات الاعتماد:
U1.1.1. قام المهاجمون بخرق بيانات اعتماد المستخدم أثناء تخزينها.
التفسيرات Y1.1.1.
على سبيل المثال ، يمكن كتابة بيانات الاعتماد على ملاحظة لاصقة مسجلة على الشاشة.
U1.1.2. قام المستخدم بطريق الخطأ أو عن طريق الخطأ بتمرير تفاصيل الوصول إلى المهاجمين.
Y1.1.2.1. تحدث المستخدم ببيانات الاعتماد بصوت عالٍ عند إدخالها.
U1.1.2.2. قام المستخدم عن قصد بتمرير بيانات الاعتماد الخاصة به:
Y1.1.2.2.1. <…> زملاء العمل.
التفسيرات Y1.1.2.2.1.
على سبيل المثال ، حتى يتمكنوا من استبدالها بفترة مرض.
Y1.1.2.2.2. <…> للأطراف المقابلة من صاحب العمل الذين يؤدون العمل على كائنات البنية التحتية للمعلومات.
Y1.1.2.2.3. <…> لأطراف ثالثة.
التفسيرات Y1.1.2.2.3.
واحد ، ولكن ليس الطريقة الوحيدة لتنفيذ هذا التهديد هو استخدام أساليب الهندسة الاجتماعية من قبل المهاجمين.
U1.1.3. فرض المهاجمون أوراق الاعتماد:
Y1.1.3.1. <…> باستخدام آليات الوصول العادية.
U1.1.3.2. <...> بواسطة رموز تم اعتراضها مسبقًا (على سبيل المثال ، تجزئة كلمة المرور) لتخزين بيانات الاعتماد.
U1.1.4. استخدم المهاجمون تعليمات برمجية ضارة لاعتراض بيانات اعتماد المستخدم.
U1.1.5. استخرج المهاجمون بيانات الاعتماد من اتصال الشبكة بين العميل والخادم:
Y1.1.5.1. وصلة: .
U1.1.6. استخرج المهاجمون أوراق اعتماد من سجلات أنظمة مراقبة العمل:
U1.1.6.1. <…> أنظمة المراقبة بالفيديو (في حالة تسجيل ضغطات المفاتيح على لوحة المفاتيح أثناء التشغيل).
U1.1.6.2. <…> أنظمة مراقبة تصرفات الموظفين على الكمبيوتر
التفسيرات Y1.1.6.2.
مثال على مثل هذا النظام .
U1.1.7. قام المهاجمون بخرق بيانات اعتماد المستخدم بسبب عيوب في عملية الإرسال.
التفسيرات Y1.1.7.
على سبيل المثال ، نقل كلمات المرور بنص واضح عن طريق البريد الإلكتروني.
U1.1.8. تعلم المهاجمون بيانات الاعتماد من خلال مراقبة جلسة المستخدم باستخدام أنظمة الإدارة عن بعد.
U1.1.9. استخرج المهاجمون أوراق الاعتماد نتيجة تسربهم عبر القنوات الفنية (TCUE):
U1.1.9.1. تجسس المهاجمون على كيفية إدخال المستخدم لبيانات الاعتماد من لوحة المفاتيح:
E1.1.9.1.1 تم تحديد موقع المهاجمين بالقرب من المستخدم وشاهدوا إدخال بيانات الاعتماد بأعينهم.
ج ١.١.٩.١.١ التفسيرات
تتضمن مثل هذه الحالات تصرفات الزملاء في العمل أو الحالة عندما تكون لوحة مفاتيح المستخدم مرئية لزوار المؤسسة.
E1.1.9.1.2 استخدم المهاجمون وسائل تقنية إضافية ، مثل المناظير أو مركبة جوية بدون طيار ، وشاهدوا إدخال بيانات الاعتماد من خلال نافذة.
U1.1.9.2. استخرج المهاجمون بيانات اعتماد من سجلات التبادل اللاسلكي بين لوحة المفاتيح ووحدة نظام الكمبيوتر إذا كانت متصلة عبر واجهة الراديو (على سبيل المثال ، Bluetooth).
U1.1.9.3. اعترض المهاجمون أوراق الاعتماد عن طريق تسريبها عبر قناة الإشعاع الكهرومغناطيسي الزائف والتقاط (PEMIN).
التفسيرات Y1.1.9.3.
أمثلة الهجوم и .
U1.1.9.4. اعترض المهاجم إدخال بيانات الاعتماد من لوحة المفاتيح من خلال استخدام وسائل تقنية خاصة (STS) مصممة لإزالة المعلومات سرًا.
التفسيرات Y1.1.9.4.
أمثلة .
U1.1.9.5. اعترض المهاجمون إدخال بيانات الاعتماد من لوحة المفاتيح باستخدام
تحليل إشارة Wi-Fi التي تم تعديلها من خلال عملية الضغط على المفاتيح من قبل المستخدم.
التفسيرات Y1.1.9.5.
مثال .
U1.1.9.6. اعترض المهاجمون إدخال بيانات الاعتماد من لوحة المفاتيح من خلال تحليل أصوات ضغطات المفاتيح.
التفسيرات Y1.1.9.6.
مثال .
U1.1.9.7. اعترض المهاجمون إدخال بيانات الاعتماد من لوحة مفاتيح جهاز محمول من خلال تحليل قراءات مقياس التسارع.
التفسيرات Y1.1.9.7.
مثال .
U1.1.10. <...> تم حفظه مسبقًا على العميل.
التفسيرات Y1.1.10.
على سبيل المثال ، يمكن للمستخدم حفظ اسم مستخدم وكلمة مرور في المتصفح للوصول إلى موقع معين.
U1.1.11. اخترق المهاجمون بيانات الاعتماد بسبب عيوب في عملية إبطال وصول المستخدم.
التفسيرات Y1.1.11.
على سبيل المثال ، بعد طرد المستخدم ، ظلت حساباته غير محظورة.
Y1.2. <…> من خلال استغلال الثغرات الأمنية في نظام التحكم في الوصول.
U2. رفع غير مصرح به لامتيازات المستخدم في نظام المعلومات
تقسيم
P2.1 <...> بإجراء تغييرات غير مصرح بها على البيانات التي تحتوي على معلومات حول امتيازات المستخدم.
U2.2 <…> من خلال استغلال الثغرات الأمنية في نظام التحكم في الوصول.
Y2.3. <…> بسبب عيوب في عملية التحكم في وصول المستخدم.
التفسيرات Y2.3.
مثال 1. تم منح المستخدم وصولاً إلى العمل أكثر مما يحتاج إليه بسبب الاحتياجات الرسمية.
مثال 2: بعد نقل مستخدم إلى منصب آخر ، لم يتم إبطال حقوق الوصول الممنوحة مسبقًا.
نموذج التهديدات النموذجية. وحدة التكامل
كائن الحماية الذي يطبق عليه نموذج التهديد (النطاق)
وحدة التكامل - مجموعة من كائنات البنية التحتية للمعلومات مصممة لتنظيم تبادل المعلومات بين أنظمة المعلومات.
مع الأخذ في الاعتبار حقيقة أنه في شبكات الشركات ليس من الممكن دائمًا فصل نظام معلومات عن آخر بشكل لا لبس فيه ، يمكن أيضًا اعتبار وحدة التكامل كحلقة وصل بين المكونات داخل نظام معلومات واحد.
هندسة معمارية
يبدو المخطط العام لوحدة التكامل كما يلي:
وصف عناصر العمارة:
- "Exchange Server (CO)" - عقدة / خدمة / مكون من نظام معلومات يؤدي وظيفة تبادل البيانات مع نظام معلومات آخر.
- "الوسيط" - عقدة / خدمة مصممة لتنظيم التفاعل بين أنظمة المعلومات ، ولكن ليس جزءًا منها.
أمثلة "وسطاء" يمكن أن تكون خدمات البريد الإلكتروني ، ناقل خدمة المؤسسات / بنية SoA ، خوادم ملفات الطرف الثالث ، إلخ. في الحالة العامة ، قد لا تحتوي وحدة التكامل على "وسطاء". - "برمجيات معالجة البيانات" - مجموعة البرامج التي تنفذ بروتوكولات تبادل البيانات وتحويل النسق.
على سبيل المثال ، تحويل البيانات من تنسيق UFEBS إلى تنسيق ABS ، وتغيير حالات الرسائل أثناء الإرسال ، وما إلى ذلك. - "إتصال شبكة" يتوافق مع الكائن الموضح في نموذج التهديد النموذجي "اتصال الشبكة". قد لا تكون بعض اتصالات الشبكة من تلك الواردة في الرسم البياني أعلاه.
أمثلة على وحدات التكامل
المخطط 1. تكامل ABS و AWP KBR من خلال خادم ملفات تابع لجهة خارجية
لتنفيذ المدفوعات ، يقوم موظف البنك المصرح له بتحميل مستندات الدفع الإلكترونية من ABS وحفظها في ملف (بتنسيقه الخاص ، على سبيل المثال ، تفريغ SQL) في مجلد الشبكة (... SHARE) لخادم الملفات. ثم يتم تحويل هذا الملف إلى مجموعة من الملفات بتنسيق UFEBS باستخدام برنامج نصي للمحول ، يتم قراءته بعد ذلك بواسطة CBD AWP.
بعد ذلك ، يقوم موظف معتمد - مستخدم AWS CBD - بتشفير الملف المستلم والتوقيع عليه وإرساله إلى نظام الدفع لبنك روسيا.
عند استلام المدفوعات من بنك روسيا ، يقوم AWP الخاص بـ CBR بفك تشفيرها والتحقق من التوقيع الإلكتروني ، وبعد ذلك يكتبها كمجموعة من الملفات بتنسيق UFEBS إلى خادم الملفات. قبل استيراد مستندات الدفع إلى ABS ، يتم تحويلها باستخدام محول نصي من تنسيق UFEBS إلى تنسيق ABS.
سنفترض أنه في هذا المخطط ، تعمل ABS على خادم فعلي واحد ، وتعمل محطة عمل CBD على كمبيوتر مخصص ، ويعمل محول البرنامج النصي على خادم الملفات.
مطابقة كائنات المخطط المدروس مع عناصر نموذج وحدة التكامل:
"تبادل خوادم من جانب ABS" - خادم ABS.
"تبادل خوادم من جانب AWP KBR" - محطة كمبيوتر KBR.
"الوسيط" - خادم ملفات الطرف الثالث.
"برمجيات معالجة البيانات" - محول البرنامج النصي.
المخطط 2. تكامل ABS و AWS KBR عند وضع مجلد شبكة مشترك مع المدفوعات على AWS KBR
كل شيء مشابه للمخطط 1 ، ولكن لا يتم استخدام خادم ملفات منفصل ؛ بدلاً من ذلك ، يوجد مجلد شبكة (... SHARE) مع مستندات الدفع الإلكترونية على جهاز كمبيوتر مع AWS CBD. يعمل محول البرنامج النصي أيضًا على AWP CBD.
مطابقة كائنات المخطط المدروس مع عناصر نموذج وحدة التكامل:
على غرار المخطط 1 ، ولكن "الوسيط" غير مستعمل.
المخطط 3. تكامل ABS و AWS KBR-N من خلال IBM WebSphera MQ وتوقيع المستندات الإلكترونية "على جانب ABS"
يعمل نظام ABS على منصة غير مدعومة من قبل CIPF SCUD Signature. يتم توقيع المستندات الإلكترونية الصادرة على خادم توقيع إلكتروني خاص (خادم ES). يتحقق الخادم نفسه من التوقيع الإلكتروني بموجب المستندات الواردة من بنك روسيا.
يقوم ABS بتحميل ملف إلى خادم ES مع مستندات الدفع بتنسيقه الخاص.
يقوم خادم ES ، باستخدام برنامج نصي للمحول ، بتحويل الملف إلى رسائل إلكترونية بتنسيق UFEBS ، وبعد ذلك يتم توقيع الرسائل الإلكترونية وإرسالها إلى IBM WebSphere MQ.
يصل AWS KBR-N إلى IBM WebSphere MQ ويتلقى رسائل دفع موقعة من هناك ، وبعد ذلك يقوم موظف معتمد - مستخدم AWS KBR - بتشفيرها وإرسالها إلى نظام الدفع الخاص ببنك روسيا.
عند استلام المدفوعات من بنك روسيا ، تقوم AWP KBR-N بفك تشفيرها والتحقق من التوقيع الإلكتروني. يتم نقل المدفوعات التي تمت معالجتها بنجاح على شكل رسائل إلكترونية مفككة وموقعة بتنسيق UFEBS إلى IBM WebSphere MQ ، حيث يتم استلامها بواسطة ES Server.
يتحقق خادم ES من التوقيع الإلكتروني للمدفوعات المستلمة ويحفظها في ملف بتنسيق ABS. بعد ذلك ، يقوم موظف مخول - مستخدم ABS - بتحميل الملف الناتج إلى ABS بالطريقة المحددة.
مطابقة كائنات المخطط المدروس مع عناصر نموذج وحدة التكامل:
"خادم التبادل من جانب ABS" - خادم ABS.
"خادم Exchange من جانب AWP KBR" - محطة كمبيوتر KBR.
"الوسيط" - خادم ES و IBM WebSphere MQ.
"برمجيات معالجة البيانات" - محول البرنامج النصي ، توقيع CIPF SCAD على خادم ES.
المخطط 4. تكامل خادم RBS و ABS من خلال واجهة برمجة التطبيقات التي يوفرها خادم تبادل مخصص
نفترض أن البنك يستخدم عدة أنظمة مصرفية عن بعد (RBS):
- "Internet Client-Bank" للأفراد (ICB FL) ؛
- "Internet Client-Bank" للكيانات القانونية (ICB LE).
من أجل ضمان أمن المعلومات ، يتم تنفيذ جميع تفاعلات ABS مع أنظمة RB من خلال خادم تبادل مخصص يعمل في إطار نظام معلومات ABS.
بعد ذلك ، سننظر في عملية تفاعل نظام RBS الخاص بـ ICB LE مع ABS.
يجب على خادم RBS ، بعد تلقيه أمر دفع مصدق حسب الأصول من العميل ، إنشاء مستند مناسب في ABS بناءً عليه. للقيام بذلك ، باستخدام API ، يقوم بنقل المعلومات إلى خادم التبادل ، والذي بدوره يقوم بإدخال البيانات في ABS.
عندما تتغير الأرصدة على حساب العميل ، يقوم نظام ABS بإنشاء إخطارات إلكترونية ، يتم إرسالها إلى خادم RBS باستخدام خادم التبادل.
مطابقة كائنات المخطط المدروس مع عناصر نموذج وحدة التكامل:
"خادم Exchange من RBS" - خادم RBS IKB YUL.
"خادم التبادل من جانب ABS" - خادم تبادل.
"الوسيط" - مفقود.
"برمجيات معالجة البيانات" - مكونات خادم RB المسؤولة عن استخدام واجهة برمجة تطبيقات خادم التبادل ومكونات خادم التبادل المسؤولة عن استخدام واجهة برمجة تطبيقات ABS.
تهديدات أمنية عالية المستوى
تقسيم
U1. إدخال المعلومات الخاطئة من قبل المجرمين من خلال وحدة التكامل.
U1. إدخال المعلومات الخاطئة من قبل المهاجمين من خلال وحدة التكامل
تقسيم
U1.1. التعديل غير المصرح به للبيانات المشروعة أثناء نقلها عبر اتصالات الشبكة:
رابط U1.1.1: .
Y1.2. نقل بيانات كاذبة عبر قنوات الاتصال نيابة عن مشارك تبادل شرعي:
رابط U1.1.2: .
Y1.3. التعديل غير المصرح به للبيانات الشرعية أثناء معالجتها على خوادم Exchange أو الوسيط:
Y1.3.1. وصلة: .
U1.4. إنشاء بيانات مزيفة على خوادم Exchange أو وسيط نيابة عن مشارك شرعي في التبادل:
Y1.4.1. وصلة:
Y1.5. التعديل غير المصرح به للبيانات أثناء معالجتها باستخدام برامج معالجة البيانات:
U1.5.1. <…> بسبب إدخال تغييرات غير مصرح بها من قبل المتسللين في إعدادات (تكوين) برنامج معالجة البيانات.
U1.5.2. <…> بسبب قيام المتسللين بإجراء تغييرات غير مصرح بها على الملفات القابلة للتنفيذ الخاصة ببرنامج معالجة البيانات.
U1.5.3. <...> بسبب التحكم التفاعلي في برامج معالجة البيانات من قبل المهاجمين.
نموذج التهديدات النموذجية. نظام حماية المعلومات المشفرة
كائن الحماية الذي يطبق عليه نموذج التهديد (النطاق)
الهدف من الحماية هو نظام حماية المعلومات المشفرة المستخدم لضمان أمن نظام المعلومات.
هندسة معمارية
أساس أي نظام معلومات هو برنامج (برمجيات) تطبيق يقوم بتنفيذ وظائفه المستهدفة.
عادةً ما يتم تنفيذ حماية التشفير في هذه الحالة عن طريق استدعاء أساسيات التشفير من منطق الأعمال الخاص ببرنامج التطبيق ، والموجود في مكتبات متخصصة - نواة التشفير.
تشتمل بدائل التشفير على وظائف تشفير منخفضة المستوى مثل:
- تشفير / فك تشفير كتلة البيانات ؛
- إنشاء / التحقق من التوقيع الإلكتروني لمجموعة البيانات ؛
- حساب دالة التجزئة لكتلة البيانات ؛
- توليد / تحميل / تحميل المعلومات الأساسية ؛
- إلخ
يقوم منطق الأعمال الخاص ببرنامج التطبيق ، باستخدام أساسيات التشفير ، بتنفيذ وظائف ذات مستوى أعلى:
- تشفير الملف بمفاتيح المستلمين المحددين ؛
- إنشاء اتصال شبكة آمن ؛
- الإبلاغ عن نتائج التحقق من التوقيع الإلكتروني ؛
- وهلم جرا.
يمكن إجراء تفاعل منطق الأعمال و crypto-core:
- مباشرة ، من خلال استدعاء مبادئ التشفير من المكتبات الديناميكية للنواة المشفرة (.DLL - لنظام التشغيل Windows ، .SO - لنظام التشغيل Linux) من خلال منطق الأعمال ؛
- مباشرة ، من خلال واجهات التشفير - أغلفة ، على سبيل المثال ، MS Crypto API ، Java Cryptography Architecture ، PKCS # 11 ، إلخ. في هذه الحالة ، يشير منطق العمل إلى واجهة التشفير ، وهو يترجم الاستدعاء إلى مركز التشفير المقابل ، والذي في هذه الحالة يسمى مزود التشفير. يسمح استخدام واجهات التشفير لبرمجيات التطبيقات بالتجريد من خوارزميات تشفير محددة وأن تكون أكثر مرونة.
هناك نوعان من المخططات النموذجية لتنظيم cryptocore:
المخطط 1 - تشفير متآلف النواة
المخطط 2 - انقسام تشفير النواة
يمكن أن تكون العناصر الموجودة في المخططات أعلاه إما وحدات برامج منفصلة تعمل على نفس الكمبيوتر ، أو خدمات شبكة تتفاعل داخل شبكة كمبيوتر.
عند استخدام أنظمة مبنية وفقًا للمخطط 1 ، يعمل برنامج التطبيق ونواة التشفير في بيئة واحدة لتشغيل أحد الوسائل المشفرة (CFC) ، على سبيل المثال ، على نفس الكمبيوتر الذي يعمل بنظام التشغيل نفسه. يمكن لمستخدم النظام ، كقاعدة عامة ، تشغيل برامج أخرى في نفس بيئة التشغيل ، بما في ذلك تلك التي تحتوي على تعليمات برمجية ضارة. في مثل هذه الظروف ، هناك خطر كبير يتمثل في تسرب مفاتيح التشفير الخاصة.
لتقليل المخاطر ، يتم استخدام المخطط 2 ، حيث ينقسم cryptocore إلى جزأين:
- الجزء الأول ، جنبًا إلى جنب مع البرنامج التطبيقي ، يعمل في بيئة غير موثوق بها حيث يوجد خطر الإصابة بالبرامج الضارة. سوف نسمي هذا الجزء "جزء البرنامج".
- الجزء الثاني يعمل في بيئة موثوقة على جهاز مخصص يحتوي على مخزن مفاتيح خاص. علاوة على ذلك سوف نسمي هذا الجزء - "جزء الأجهزة".
يعتبر تقسيم النواة المشفرة إلى أجزاء برمجيات وأجهزة مشروطة للغاية. توجد أنظمة في السوق مبنية وفقًا للمخطط مع نواة تشفير مقسمة ، ولكن يتم تقديم جزء "الأجهزة" في شكل صورة جهاز افتراضي - HSM افتراضي ().
يحدث تفاعل كلا الجزأين من cryptocore بطريقة لا يتم فيها نقل مفاتيح التشفير الخاصة إلى جزء البرنامج ، وبالتالي لا يمكن سرقتها باستخدام تعليمات برمجية ضارة.
واجهة التفاعل (API) ومجموعة أساسيات التشفير المقدمة إلى برنامج التطبيق من قبل مركز التشفير هي نفسها في كلتا الحالتين. يكمن الاختلاف في طريقة تنفيذها.
لذلك ، عند استخدام مخطط مع cryptocore مقسم ، يتم إجراء التفاعل بين البرنامج والأجهزة وفقًا للمبدأ التالي:
- يتم تنفيذ أساسيات التشفير التي لا تتطلب استخدام مفتاح خاص (على سبيل المثال ، حساب وظيفة التجزئة ، والتحقق من التوقيع الإلكتروني ، وما إلى ذلك) بواسطة البرنامج.
- يتم تنفيذ أساسيات التشفير التي تستخدم مفتاحًا خاصًا (إنشاء توقيع إلكتروني ، وفك تشفير البيانات ، وما إلى ذلك) بواسطة الجهاز.
دعنا نوضح طريقة عمل تشفير منفصل باستخدام مثال إنشاء توقيع إلكتروني:
- يحسب جزء البرنامج وظيفة التجزئة للبيانات الموقعة وينقل هذه القيمة إلى الجهاز عبر قناة التبادل بين مراكز التشفير.
- يولد جزء الأجهزة ، باستخدام المفتاح الخاص والتجزئة ، قيمة التوقيع الإلكتروني وينقله إلى جزء البرنامج عبر قناة التبادل.
- يقوم جزء البرنامج بإرجاع القيمة المستلمة إلى البرنامج التطبيقي.
ميزات التحقق من صحة التوقيع الإلكتروني
عندما يتلقى الطرف المتلقي بيانات موقعة بتوقيع إلكتروني ، يجب أن يقوم بعدة مراحل من التحقق. لا تتحقق نتيجة إيجابية للتحقق من التوقيع الإلكتروني إلا إذا اكتملت جميع مراحل التحقق بنجاح.
المرحلة 1. التحكم في سلامة البيانات وتأليف البيانات.
محتوى المرحلة. يتم التحقق من التوقيع الإلكتروني للبيانات وفقًا لخوارزمية التشفير المقابلة. يشير الإكمال الناجح لهذه المرحلة إلى أن البيانات لم يتم تعديلها منذ توقيعها ، وأن التوقيع تم بمفتاح خاص يتوافق مع المفتاح العام للتحقق من التوقيع الإلكتروني.
موقع المرحلة: كريبتوكيرنيل.
المرحلة 2. التحكم في الثقة في المفتاح العام للموقّع والتحكم في فترة صلاحية المفتاح الخاص للتوقيع الإلكتروني.
محتوى المرحلة. تتكون المرحلة من مرحلتين فرعيتين وسيطتين. الأول يحدد ما إذا كان المفتاح العمومي للتحقق من التوقيع الإلكتروني موثوقًا به وقت توقيع البيانات. يحدد الثاني ما إذا كان المفتاح الخاص للتوقيع الإلكتروني صالحًا في وقت توقيع البيانات. في الحالة العامة ، قد لا تتزامن فترات صلاحية هذه المفاتيح (على سبيل المثال ، للشهادات المؤهلة لمفاتيح التحقق من التوقيع الإلكتروني). يتم تحديد طرق إثبات الثقة في المفتاح العام للموقّع من خلال قواعد إدارة المستندات الإلكترونية المعتمدة من قبل الأطراف المتفاعلة.
موقع المرحلة: برنامج التطبيق / crypto-kernel.
المرحلة 3. السيطرة على سلطة الموقع.
محتوى المرحلة. وفقًا للقواعد المعمول بها لإدارة المستندات الإلكترونية ، يتم التحقق مما إذا كان للموقِّع الحق في التصديق على البيانات المحمية. على سبيل المثال ، ضع في اعتبارك حالة انتهاك السلطة. لنفترض أن هناك منظمة يمتلك فيها جميع الموظفين توقيعًا إلكترونيًا. يتلقى نظام إدارة المستندات الإلكترونية الداخلية طلبًا من الرئيس ، ولكن يتم توقيعه بالتوقيع الإلكتروني لمدير المستودع. وفقًا لذلك ، لا يمكن اعتبار مثل هذه الوثيقة شرعية.
موقع المرحلة: تطبيق البرمجيات.
افتراضات عند وصف موضوع الحماية
- تمر قنوات نقل المعلومات ، باستثناء قنوات التبادل الرئيسية ، من خلال برامج التطبيقات وواجهة برمجة التطبيقات ونواة التشفير.
- يتم وضع معلومات حول الثقة في المفاتيح العامة و (أو) الشهادات ، بالإضافة إلى معلومات حول سلطة مالكي المفاتيح العامة ، في مخزن المفاتيح العامة.
- يعمل برنامج التطبيق مع تخزين المفتاح العام من خلال نواة التشفير.
مثال على نظام معلومات محمي بواسطة CIPF
لتوضيح المخططات المقدمة مسبقًا ، ضع في اعتبارك نظام معلومات افتراضي وحدد جميع العناصر الهيكلية عليه.
وصف نظام المعلومات
قررت المنظمتان إدخال إدارة المستندات الإلكترونية الملزمة قانونًا (EDF) بينهما. للقيام بذلك ، أبرموا اتفاقية ذكروا فيها أنه سيتم إرسال المستندات عبر البريد الإلكتروني ، وفي نفس الوقت يجب تشفيرها وتوقيعها بتوقيع إلكتروني مؤهل. كوسيلة لإنشاء المستندات ومعالجتها ، يجب استخدام البرامج المكتبية من حزمة Microsoft Office 2016 ، وكوسيلة لحماية التشفير - CIPF CryptoPRO وبرنامج التشفير CryptoARM.
وصف البنية التحتية للمنظمة 1
قررت المؤسسة 1 أنها ستقوم بتثبيت برنامج CryptoPRO CIPF و CryptoARM على محطة عمل المستخدم - جهاز كمبيوتر فعلي. سيتم تخزين مفاتيح التشفير والتوقيع الإلكتروني على حامل المفاتيح ruToken الذي يعمل في وضع المفتاح القابل للاسترداد. سيقوم المستخدم بإعداد المستندات الإلكترونية محليًا على جهاز الكمبيوتر الخاص به ، وبعد ذلك سيتم تشفيرها وتوقيعها وإرسالها باستخدام عميل بريد مثبت محليًا.
وصف البنية التحتية للمنظمة 2
قررت المنظمة 2 نقل وظائف التشفير والتوقيع الإلكتروني إلى آلة افتراضية مخصصة. في هذه الحالة ، سيتم تنفيذ جميع عمليات التشفير تلقائيًا.
للقيام بذلك ، يتم تنظيم مجلدين للشبكة على جهاز ظاهري مخصص: "… In" ، "… Out". سيتم وضع الملفات المستلمة من الطرف المقابل في شكل مفتوح تلقائيًا في مجلد الشبكة "… In". سيتم فك تشفير هذه الملفات والتحقق من التوقيع الإلكتروني عليها.
في مجلد “… Out” ، سيضع المستخدم الملفات التي تحتاج إلى تشفيرها وتوقيعها وإرسالها إلى الطرف المقابل. سيقوم المستخدم بإعداد الملفات بنفسه على محطة العمل الخاصة به.
لأداء وظائف التشفير والتوقيع الإلكتروني ، يتم تثبيت CryptoPRO CIPF وبرنامج CryptoARM وعميل البريد على الجهاز الظاهري. سيتم تنفيذ الإدارة التلقائية لجميع عناصر الجهاز الظاهري باستخدام البرامج النصية التي طورها مسؤولو النظام. يتم تسجيل عمل البرامج النصية في ملفات السجل (السجلات).
سيتم وضع مفاتيح التشفير للتوقيع الإلكتروني على رمز مميز مع مفتاح JaCarta GOST غير القابل للاسترداد ، والذي سيقوم المستخدم بتوصيله بجهاز الكمبيوتر المحلي الخاص به.
سيتم إعادة توجيه الرمز المميز إلى الجهاز الظاهري باستخدام برنامج USB-over-IP متخصص مثبت على محطة عمل المستخدم وعلى الجهاز الظاهري.
سيتم تعديل ساعة النظام على محطة عمل المستخدم في المؤسسة 1 يدويًا. ستتم مزامنة ساعة النظام الخاصة بالجهاز الظاهري المخصص في المؤسسة 2 مع ساعة نظام برنامج Hypervisor ، والتي بدورها ستتم مزامنتها عبر الإنترنت مع خوادم الوقت العامة.
تخصيص العناصر الهيكلية لـ CIPF
استنادًا إلى الوصف أعلاه للبنية التحتية لتكنولوجيا المعلومات ، نفرد العناصر الهيكلية لـ CIPF ونقوم بتدوينها في جدول.
الجدول - تطابق عناصر نموذج CIPF مع عناصر نظم المعلومات
اسم البند
التنظيم 1
التنظيم 2
تطبيق البرمجيات
برنامج CryptoARM
برنامج CryptoARM
جزء البرنامج من النواة المشفرة
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
جزء العتاد من النواة المشفرة
لا
جاكرتا غوست
API
MS CryptoAPI
MS CryptoAPI
تخزين المفتاح العام
محطة عمل المستخدم:
- الأقراص الصلبة ؛
- مخزن شهادات Windows القياسي.
برنامج Hypervisor:
- HDD.
آلة افتراضية:
- الأقراص الصلبة ؛
- مخزن شهادات Windows القياسي.
تخزين المفتاح الخاص
مفتاح ruToken يعمل في وضع المفتاح القابل للاستخراج
يعمل ناقل مفتاح JaCarta GOST في وضع المفتاح غير القابل للاسترجاع
قناة تبادل المفتاح العام
محطة عمل المستخدم:
- كبش.
برنامج Hypervisor:
- كبش.
آلة افتراضية:
- كبش.
قناة تبادل المفاتيح الخاصة
محطة عمل المستخدم:
- ناقل USB
- كبش.
لا
قناة التبادل بين مراكز التشفير
غائب (لا توجد أجهزة تشفير)
محطة عمل المستخدم:
- ناقل USB
- كبش؛
- وحدة برامج USB-over-IP ؛
- واجهة الشبكة.
شبكة الشركة للمؤسسة 2.
برنامج Hypervisor:
- كبش؛
- واجهة الشبكة.
آلة افتراضية:
- واجهة الشبكة ؛
- كبش؛
- وحدة برامج USB-over-IP.
فتح قناة تبادل البيانات
محطة عمل المستخدم:
- وسائل المدخلات والمخرجات ؛
- كبش؛
- HDD.
محطة عمل المستخدم:
- وسائل المدخلات والمخرجات ؛
- كبش؛
- الأقراص الصلبة ؛
- واجهة الشبكة.
شبكة الشركة للمؤسسة 2.
برنامج Hypervisor:
- واجهة الشبكة ؛
- كبش؛
- HDD.
آلة افتراضية:
- واجهة الشبكة ؛
- كبش؛
- HDD.
قناة تبادل البيانات الآمنة
الانترنت.
شبكة الشركة للمؤسسة 1.
محطة عمل المستخدم:
- الأقراص الصلبة ؛
- كبش؛
- واجهة الشبكة.
الانترنت.
شبكة الشركة للمؤسسة 2.
برنامج Hypervisor:
- واجهة الشبكة ؛
- كبش؛
- HDD.
آلة افتراضية:
- واجهة الشبكة ؛
- كبش؛
- HDD.
قناة الوقت
محطة عمل المستخدم:
- وسائل المدخلات والمخرجات ؛
- كبش؛
- مؤقت النظام.
الانترنت.
شبكة الشركة للمؤسسة 2 ،
برنامج Hypervisor:
- واجهة الشبكة ؛
- كبش؛
- مؤقت النظام.
آلة افتراضية:
- كبش؛
- مؤقت النظام.
قناة إرسال أمر التحكم
محطة عمل المستخدم:
- وسائل المدخلات والمخرجات ؛
- كبش.
(واجهة المستخدم الرسومية لبرنامج CryptoARM)
آلة افتراضية:
- كبش؛
- HDD.
(نصوص الأتمتة)
قناة لتلقي نتائج العمل
محطة عمل المستخدم:
- وسائل المدخلات والمخرجات ؛
- كبش.
(واجهة المستخدم الرسومية لبرنامج CryptoARM)
آلة افتراضية:
- كبش؛
- HDD.
(ملفات السجل لنصوص الأتمتة)
تهديدات أمنية عالية المستوى
تفسير
الافتراضات الموضوعة في تحليل التهديدات:
- يتم استخدام خوارزميات تشفير قوية.
- تُستخدم خوارزميات التشفير بأمان في أوضاع التشغيل الصحيحة (على سبيل المثال ، لا ينطبق على تشفير كميات كبيرة من البيانات ، يؤخذ الحمل المسموح به على المفتاح في الاعتبار ، وما إلى ذلك).
- يعرف المخالفون جميع الخوارزميات والبروتوكولات والمفاتيح العامة المستخدمة.
- يمكن للمهاجمين الوصول إلى جميع البيانات المشفرة.
- يستطيع المهاجمون إعادة إنتاج أي عناصر برنامج في النظام.
تقسيم
U1. حل وسط لمفاتيح التشفير الخاصة.
U2. تشفير البيانات المزيفة نيابة عن مرسل شرعي.
U3. فك تشفير البيانات المشفرة من قبل أشخاص ليسوا متلقين شرعيين للبيانات (الدخلاء).
U4. إنشاء توقيع إلكتروني للموقع الشرعي بموجب بيانات كاذبة.
U5. الحصول على نتيجة إيجابية للتحقق من التوقيع الإلكتروني لبيانات كاذبة.
U6. القبول الخاطئ للوثائق الإلكترونية للتنفيذ بسبب مشاكل في تنظيم إدارة المستندات الإلكترونية.
U7. الوصول غير المصرح به إلى البيانات المحمية أثناء معالجتها بواسطة CIPF.
U1. حل وسط لمفاتيح التشفير الخاصة
U1.1. احصل على المفتاح الخاص من متجر المفتاح الخاص.
Y1.2. الحصول على مفتاح خاص من كائنات بيئة عمل أداة التشفير ، والتي يمكن تحديد موقعها بشكل مؤقت.
التفسيرات Y1.2.
تتضمن الكائنات التي يمكنها تخزين مفتاح خاص مؤقتًا ما يلي:
- الرامات " الذاكرة العشوائية في الهواتف والحواسيب،
- ملفات مؤقتة،
- ملفات الترحيل ،
- ملفات الإسبات ،
- لقطات للحالة "الساخنة" للأجهزة الافتراضية ، بما في ذلك ملفات محتويات ذاكرة الوصول العشوائي للأجهزة الافتراضية التي تم إيقافها مؤقتًا.
U1.2.1. استرجاع المفاتيح الخاصة من ذاكرة الوصول العشوائي العاملة عن طريق تجميد وحدات ذاكرة الوصول العشوائي واستخراجها ثم قراءة البيانات (هجوم التجميد).
التفسيرات Y1.2.1.
مثال .
Y1.3. الحصول على مفتاح خاص من قناة تبادل مفتاح خاص.
التفسيرات Y1.3.
سيتم إعطاء مثال على تنفيذ هذا التهديد .
U1.4. تعديل غير مصرح به للنواة المشفرة ، ونتيجة لذلك أصبحت المفاتيح الخاصة معروفة للمهاجمين.
Y1.5. حل وسط بشأن المفتاح الخاص نتيجة لاستخدام القنوات التقنية لتسرب المعلومات (TCLE).
التفسيرات Y1.5.
مثال .
U1.6. حل وسط بشأن المفتاح الخاص نتيجة استخدام وسائل تقنية خاصة (STS) مصممة للاسترداد السري للمعلومات ("الأخطاء").
Y1.7. حل وسط بشأن المفاتيح الخاصة أثناء تخزينها خارج CIPF.
التفسيرات Y1.7.
على سبيل المثال ، يحتفظ المستخدم بوسائطه الرئيسية في درج سطح المكتب ، حيث يمكن للمتطفلين استرجاعها بسهولة.
U2. تشفير البيانات المزيفة نيابة عن مرسل شرعي
تفسير
يعتبر هذا التهديد فقط لأنظمة تشفير البيانات مع مصادقة المرسل. تم الإشارة إلى أمثلة على هذه المخططات في التوصيات الخاصة بالتوحيد القياسي. . بالنسبة لمخططات التشفير الأخرى ، لا يوجد هذا التهديد ، حيث يتم تنفيذ التشفير على المفاتيح العامة للمستلم ، وهي معروفة بشكل عام للمهاجمين.
تقسيم
U2.1. حل وسط بشأن المفتاح الخاص للمرسل:
Y2.1.1. وصلة: .
Y2.2. استبدال بيانات الإدخال في قناة تبادل البيانات المفتوحة.
ملاحظات U2.2.
فيما يلي أمثلة على تنفيذ هذا التهديد. и .
U3. فك تشفير البيانات المشفرة من قبل أشخاص ليسوا متلقين شرعيين للبيانات (الدخلاء)
تقسيم
Y3.1. حل وسط بشأن المفاتيح الخاصة لمتلقي البيانات المشفرة.
رابط U3.1.1: .
Y3.2. استبدال البيانات المشفرة في قناة تبادل بيانات آمنة.
U4. إنشاء توقيع إلكتروني للموقع الشرعي بموجب بيانات كاذبة
تقسيم
Y4.1. حل وسط بشأن المفاتيح الخاصة للتوقيع الإلكتروني للموقِّع الشرعي.
رابط U4.1.1: .
Y4.2. استبدال البيانات الموقعة في قناة تبادل البيانات المفتوحة.
ملاحظة U4.2.
فيما يلي أمثلة على تنفيذ هذا التهديد. и .
U5. الحصول على نتيجة إيجابية للتحقق من التوقيع الإلكتروني لبيانات كاذبة
تقسيم
Y5.1. يعترض المخالفون في قناة نقل نتائج العمل الرسالة على النتيجة السلبية لفحص التوقيع الإلكتروني واستبداله بالرسالة بنتيجة إيجابية.
Y5.2. ينفذ المهاجمون هجومًا على الثقة في توقيع الشهادات (السيناريو - جميع العناصر مطلوبة):
Y5.2.1. ينشئ المهاجمون مفتاحًا عامًا وخاصًا للتوقيع الإلكتروني. إذا كان النظام يستخدم شهادات مفتاح التوقيع الإلكتروني ، فإنها تنشئ شهادة توقيع إلكتروني مشابهة بقدر الإمكان لشهادة المرسل المزعوم للبيانات التي يريدون تزوير رسالتها.
U5.2.2. يقوم المهاجمون بإجراء تغييرات غير مصرح بها لمخزن المفتاح العام ، مما يمنح المفتاح العام الذي تم إنشاؤه بواسطتهم المستوى الضروري من الثقة والسلطة.
Y5.2.3. يوقع المهاجمون بيانات مزيفة باستخدام مفتاح توقيع إلكتروني تم إنشاؤه مسبقًا ويدمجونها في قناة تبادل بيانات آمنة.
Y5.3. ينفذ المهاجمون هجومًا باستخدام مفاتيح التوقيع الإلكتروني منتهية الصلاحية الخاصة بالموقع القانوني (السيناريو - جميع العناصر مطلوبة):
Y5.3.1. يخترق المهاجمون المفاتيح الخاصة منتهية الصلاحية (غير الصالحة حاليًا) للتوقيع الإلكتروني للمرسل الشرعي.
Y5.3.2. يستبدل المهاجمون الوقت في قناة إرسال الوقت بالوقت الذي كانت فيه المفاتيح المخترقة لا تزال صالحة.
Y5.3.3. يوقع المهاجمون بيانات مزيفة باستخدام مفتاح توقيع إلكتروني تم اختراقه مسبقًا ويدمجونها في قناة تبادل بيانات آمنة.
Y5.4. ينفذ المهاجمون هجومًا باستخدام مفاتيح التوقيع الإلكتروني المخترقة للموقّع القانوني (السيناريو - جميع العناصر مطلوبة):
Y5.4.1. يقوم المهاجمون بعمل نسخة من مخزن المفتاح العام.
Y5.4.2. يخترق المهاجمون المفاتيح الخاصة لأحد المرسلين الشرعيين. يلاحظ الاختراق ، ويلغي المفاتيح ، ويتم وضع معلومات حول إبطال المفتاح في مخزن المفتاح العام.
Y5.4.3. يستبدل المهاجمون مخزن المفتاح العام بالمخزن الذي تم نسخه مسبقًا.
Y5.4.4. يوقع المهاجمون بيانات مزيفة باستخدام مفتاح توقيع إلكتروني تم اختراقه مسبقًا ويدمجونها في قناة تبادل بيانات آمنة.
U5.5. <...> بسبب وجود أخطاء في تنفيذ المرحلتين الثانية والثالثة من التحقق من التوقيع الإلكتروني:
التفسيرات Y5.5.
تم إعطاء مثال على تنفيذ هذا التهديد .
U5.5.1. التحقق من الثقة في شهادة مفتاح التوقيع الإلكتروني فقط من خلال وجود الثقة في الشهادة التي تم توقيعها بها ، دون فحص CRL أو OCSP.
التفسيرات Y5.5.1.
مثال على التنفيذ .
U5.5.2. عند بناء سلسلة ثقة لشهادة ، لا يتم تحليل سلطة إصدار الشهادات
التفسيرات Y5.5.2.
مثال على هجوم ضد شهادات SSL / TLS.
اشترى المهاجمون شهادة شرعية لبريدهم الإلكتروني. ثم قاموا بعمل شهادة موقع ويب احتيالية ووقعوا عليها بشهادتهم الخاصة. إذا لم يتم إجراء فحص بيانات الاعتماد ، فعند التحقق من سلسلة الثقة ، سيتبين أنها صحيحة ، وبالتالي ، ستكون الشهادة الاحتيالية صحيحة أيضًا.
Y5.5.3. عند إنشاء سلسلة ثقة للشهادة ، لا يتم التحقق من الشهادات الوسيطة لإبطالها.
Y5.5.4. يتم تحديث CRLs بشكل أقل من إصدارها من قبل المرجع المصدق.
U5.5.5. يتم اتخاذ قرار الوثوق بالتوقيع الإلكتروني قبل استلام استجابة OCSP حول حالة الشهادة ، وإرسالها بناءً على طلب يتم إجراؤه بعد وقت إنشاء التوقيع أو قبل الموعد التالي بعد استلام توقيع CRL.
التفسيرات Y5.5.5.
في لوائح معظم CAs ، يعتبر وقت إبطال الشهادة هو وقت إصدار أقرب CRL تحتوي على معلومات حول إبطال الشهادة.
U5.5.6. عند استلام البيانات الموقعة ، لا يتم التحقق من ملكية الشهادة من قبل المرسل.
التفسيرات Y5.5.6.
مثال الهجوم. بالنسبة لشهادات SSL ، قد لا يتحقق مما إذا كان عنوان الخادم المطلوب يطابق قيمة حقل CN في الشهادة.
مثال الهجوم. قام المهاجمون بخرق مفاتيح التوقيع الإلكتروني لأحد المشاركين في نظام الدفع. بعد ذلك ، اخترقوا شبكة مشارك آخر وأرسلوا نيابة عنه مستندات دفع موقعة بمفاتيح مخترقة إلى خادم التسوية لنظام الدفع. إذا قام الخادم بتحليل الثقة فقط ولم يتحقق من الامتثال ، فسيتم اعتبار المستندات المزورة شرعية.
U6. القبول الخاطئ للوثائق الإلكترونية للتنفيذ بسبب مشاكل في تنظيم إدارة المستندات الإلكترونية.
تقسيم
Y6.1. لا يكتشف الطرف المتلقي تكرار المستندات المستلمة.
التفسيرات Y6.1.
مثال الهجوم. يمكن للمخالفين اعتراض المستند الذي تم نقله إلى المستلم ، حتى لو كان محميًا بالتشفير ، ثم إرساله بشكل متكرر إلى قناة نقل البيانات الآمنة. إذا لم يكتشف المستلم التكرارات ، فسيتم اعتبار جميع المستندات المستلمة ومعالجتها كمستندات مختلفة.
U7. الوصول غير المصرح به إلى البيانات المحمية أثناء معالجتها بواسطة CIPF
تقسيم
U7.1. <…> بسبب تسرب المعلومات عبر قنوات الجهات الخارجية (هجوم قناة جانبية).
التفسيرات Y7.1.
مثال .
U7.2. <...> بسبب تحييد الحماية ضد الوصول غير المصرح به إلى المعلومات التي تتم معالجتها على CIPF:
Y7.2.1. تشغيل CIPF مع انتهاكات للمتطلبات الموضحة في وثائق CIPF.
Y7.2.2. تم تنفيذ <…> بسبب وجود نقاط ضعف في:
Y7.2.2.1. <…> وسيلة للحماية من الوصول غير المصرح به.
Y7.2.2.2. <…> CIPF نفسه.
Y7.2.2.3. <...> بيئة عمل أداة التشفير.
أمثلة الهجوم
من الواضح أن السيناريوهات التي نوقشت أدناه تحتوي على أخطاء في تنظيم أمن المعلومات وتخدم فقط لتوضيح الهجمات المحتملة.
السيناريو 1. مثال على تنفيذ التهديدات U2.2 و U4.2.
وصف الكائن
يتم تثبيت برنامج ARM KBR و CIPF SCAD Signature على جهاز كمبيوتر فعلي غير متصل بشبكة كمبيوتر. يتم استخدام FKN vdToken كحامل مفتاح في طريقة التشغيل بمفتاح غير قابل للاسترداد.
تفترض لائحة التسوية أن متخصص التسوية من كمبيوتر عمله يقوم بتنزيل الرسائل الإلكترونية بنص واضح (مخطط KBR AWS القديم) من خادم ملفات آمن خاص ، ثم يكتبها على محرك أقراص فلاش USB قابل للإزالة وينقلها إلى KBR AWP حيث يتم تشفيرها وعلاماتها. بعد ذلك ، يقوم المختص بنقل الرسائل الإلكترونية الآمنة إلى وسيط قابل للتحويل ، وبعد ذلك ، من خلال كمبيوتر العمل الخاص به ، يكتبها على خادم ملفات ، ومنه يصلون إلى UTA ثم إلى نظام الدفع الخاص ببنك روسيا.
في هذه الحالة ، ستشمل قنوات تبادل البيانات المفتوحة والآمنة: خادم ملفات ، وكمبيوتر عمل متخصص ، ووسائط قابلة للتحويل.
هجوم
يقوم المهاجمون غير المصرح لهم بتثبيت نظام تحكم عن بعد على كمبيوتر العمل الخاص بالمتخصص ، وفي وقت تسجيل أوامر الدفع (الرسائل الإلكترونية) على الوسيط القابل للتحويل ، يستبدلون محتويات أحدها بشكل مفتوح. يقوم المتخصص بتحويل أوامر الدفع إلى AWS الخاصة بـ KBR ، ويقوم بتوقيعها وتشفيرها دون ملاحظة الاستبدال (على سبيل المثال ، بسبب العدد الكبير من أوامر الدفع أثناء الرحلة ، والتعب ، وما إلى ذلك). بعد ذلك ، يدخل أمر الدفع المزيف ، بعد أن مر عبر السلسلة التكنولوجية ، في نظام الدفع لبنك روسيا.
السيناريو 2. مثال على تنفيذ التهديدات U2.2 و U4.2.
وصف الكائن
يعمل الكمبيوتر المثبت عليه AWS KBR و SKAD Signature وحامل المفتاح المتصل لـ FKN vdToken في غرفة مخصصة دون الوصول من الموظفين.
يتصل اختصاصي التسوية بـ AWS الخاص بـ KBR في وضع الوصول عن بُعد عبر بروتوكول RDP.
هجوم
يعترض المهاجمون التفاصيل ، والتي يستخدمها اختصاصي التسوية في الاتصال والعمل مع مكان العمل الآلي لـ KBR (على سبيل المثال ، بسبب رمز خبيث على جهاز الكمبيوتر الخاص به). ثم يتصلون نيابة عنه ويرسلون أمر دفع مزيفًا إلى نظام الدفع لبنك روسيا.
السيناريو 3. مثال على تنفيذ التهديد U1.3.
وصف الكائن
دعونا نفكر في أحد الخيارات الافتراضية لتنفيذ وحدات تكامل ABS-KBR للمخطط الجديد (ARM KBR-N) ، حيث يحدث التوقيع الإلكتروني للوثائق الصادرة على جانب ABS. في الوقت نفسه ، سنفترض أن ABS يعمل على أساس نظام تشغيل لا يدعمه توقيع CIPF SKAD ، وبالتالي ، يتم وضع وظيفة التشفير على جهاز افتراضي منفصل - وحدة تكامل ABS-CBR .
يتم استخدام رمز USB العادي الذي يعمل في وضع المفتاح القابل للإزالة كحامل رئيسي. عندما تم توصيل ناقل المفتاح بـ Hypervisor ، اتضح أنه لا توجد منافذ USB مجانية في النظام ، لذلك تقرر توصيل رمز USB من خلال موزع USB للشبكة ، وتثبيت عميل USB-over-IP على الجهاز الظاهري الذي سيتواصل مع المحور.
هجوم
اعترض المهاجمون المفتاح الخاص للتوقيع الإلكتروني من قناة الاتصال بين موزع USB و Hypervisor (تم نقل البيانات بنص واضح). بوجود مفتاح خاص ، أنشأ المهاجمون أمر دفع مزيفًا ، ووقعوه بتوقيع إلكتروني وأرسلوه إلى مكان العمل الآلي KBR-N للتنفيذ.
السيناريو 4. مثال على تنفيذ التهديدات U5.5.
وصف الكائن
النظر في نفس الدائرة كما في السيناريو السابق. سنفترض أن رسائل البريد الإلكتروني الواردة من محطة عمل KBR-N تنتهي في مجلد… SHAREIn ، وتلك التي يتم إرسالها إلى محطة عمل KBR-N وإلى نظام الدفع الخاص ببنك روسيا ، انتقل إلى… SHAREout.
سنفترض أيضًا أنه عند تنفيذ وحدة التكامل ، يتم تحديث قوائم الشهادات الملغاة فقط عند إعادة إصدار مفاتيح التشفير ، وأيضًا أن الرسائل الإلكترونية المستلمة في مجلد ... SHAREIn يتم فحصها فقط من أجل التحكم في النزاهة والتحكم في الثقة للمفتاح العام لـ التوقيع الإلكتروني.
هجوم
قام المهاجمون ، باستخدام المفاتيح المسروقة في السيناريو السابق ، بالتوقيع على أمر دفع مزيف يحتوي على معلومات حول استلام أموال على حساب عميل محتال وقاموا بإدخالها في قناة تبادل بيانات آمنة. نظرًا لعدم وجود تحقق من توقيع بنك روسيا على أمر الدفع ، يتم قبوله للتنفيذ.
المصدر: www.habr.com