مسؤول الأمن قال إننا بحاجة إلى 'فخاخ العسل' (honeypot) — ما هي، وهل نحتاجها فعلاً؟

فخاخ العسل في الشبكة الداخلية تكون عادةً مشاركة ملفات SMB مزيفة أو منفذ قاعدة بيانات مزيف تُترك مفتوحة في الشبكة. عندما يتسلل المهاجم إلى شبكة المكتب، يمسح ما حوله ليتحرك بحرية في الداخل (lateral movement). وفي اللحظة التي يلمس فيها ذلك المنفذ المزيف، تصل إشارة إلى النظام المركزي 'هناك غريب في الشبكة'. الفكرة نظيفة تقنياً جداً لكن إدارتها تتطلب خبرة.

المستشار يحاول أن يبيعكم خدمة فاخرة بمستوى enterprise ويربطكم باشتراك شهري. حتى لو أمسكتم بالمهاجم الذي تسلل إلى خادمكم بفخ العسل في شركة فيها 35 شخصاً، هل لديكم بعد ذلك فريق أمن داخلي يتدخل في الحادثة؟ اصرفوا تلك الميزانية أولاً على تقوية بنية النسخ الاحتياطي.

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

بدل أن تعطوا ذلك المال للمستشار، ابحثوا عن خدمات canary token المجانية. تضعون في خادم الملفات ملفاً مزيفاً باسم 'maas-listesi-2024.xlsx'. وفي اللحظة التي يُفتح فيها هذا الملف يصلكم تنبيه على بريدكم. التكلفة صفر دولار، والتركيب خمس دقائق.

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

حاولوا يبيعون لنا برضه باقة أمن مشابهة، لا تدفعوا فلوس شهرياً على الفاضي... فعّلوا mfa على الـ vpn وقوّوا كلمات مرور الخوادم وهذا يكفي، فخ العسل مبالغة كبيرة لتاجر جملة فيه 35 شخص.

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

تعديل: كتبت خطأً أعلاه، أرجو المعذرة.

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

لو كنت مكانك، لسلك هذا المسار.

أنا مشروع صغير، دعوني أشرح من منظوري. ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة.

لو كنت مكانك، لسلك هذا المسار.

بالتأكيد. وإذا أردت إضافة شيء: تسير الأمور على ما يرام في الأشهر الثلاثة الأولى، وتظهر المشاكل في الشهر الرابع.

وقت اكتشاف المشكلة يحدد تكلفتها بشكل مباشر. هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

أنا في نفس الوضع، لذلك أسأل. إذا كان التحقق بخطوتين مفعلًا، فإن كلمة المرور المسروقة وحدها لا تكفي.

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

شكرًا جزيلًا، كان مفيدًا جدًا.

أوافق.

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

صححوا لي إن أخطأت.

صحيح نظرياً، لكنه لا يسير هكذا عملياً. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

الأمان ليس مطلقاً؛ بل يعني جعل الهجوم غير مجدٍ من حيث الجهد. أتمنى أن يفيدك هذا.

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

صحيح بشكل عام، لكن هناك جزء ناقص. طيب عندما تحاول تغيير كل شيء دفعة واحدة، لا يستقر أي شيء.

إذا قمت بتوبيخ الإنذارات الكاذبة، فلن يقوم أحد بالإبلاغ مرة أخرى. بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

دعني أشرح كيف يتم التطبيق عملياً. لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها.

مثبت بالتجربة.