في مجال أمن المعلومات ، قمنا بتطوير عدد من البديهيات التي لا يمكن المجادلة معها:

• لا تقم أبدًا بتطبيق التشفير الخاص بك.
  
  
• استخدم دائمًا TLS.
  
  
• الأمن بالغموض سيء.

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

المخاطر والدفاع الطبقي والجبن السويسري

من المهام الرئيسية لأمن المعلومات الحد من المخاطر. وفقًا لمنهجية OWASP ، يتم حساب خطر حدوث مشكلة باستخدام الصيغة:

المخاطرة = الاحتمالية * التأثير

من خلال هذه الصيغة ، تشكل مشكلة تنفيذ التعليمات البرمجية عن بُعد (RCE) خطرًا أكبر من مشكلة البرمجة النصية عبر المواقع ، لأن RCE لها تأثير أكبر. كل شيء بسيط هنا. ولكن ماذا عن مقياس الاحتمال؟ وفقًا لـ OWASP ، يتم تحديد الاحتمال على النحو التالي:

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

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







وفقًا لهذا النموذج ، تحتاج إلى بناء آليات دفاع في نموذج متعدد الطبقات بطريقة بحيث أنه حتى إذا تجاوز المهاجم المستوى الأول ، فسيتم إيقافه عند الآخرين.

الأمن من خلال الغموض

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



لنأخذ في الاعتبار عدة سيناريوهات:

• على الخادم الخاص بي ، يعمل SSH على المنفذ الافتراضي 22 وبيانات الاعتماد root:123456. ما هو احتمال التسوية؟

تبلغ الاحتمالية 100٪ تقريبًا ، نظرًا لأن المتسللين في جميع أنحاء الإنترنت هم خدمات شديدة القوة بأوراق اعتماد قياسية.

• يعمل SSH على المنفذ 22 وبيانات الاعتماد utku:123456. ما هو احتمال التسوية؟

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

• يعمل SSH على المنفذ 64323 وبيانات الاعتماد utku:123456. ما هو احتمال التسوية؟

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





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



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

تطبيقات أخرى

بالطبع ، بصرف النظر عن تغيير القيم الافتراضية ، يمكنك استخدام نفس المنهجية في مناطق أخرى. في بعض الحالات (ليس دائمًا) يمكن تطبيق الأفكار التالية.

• التعتيم على الكود : بالطبع ، هذه معرفة عامة. القراصنة هم بشر أيضًا. إذا قمت بتشويش التعليمات البرمجية الخاصة بك جيدًا ، فسيتعين عليهم قضاء المزيد من الوقت في البحث عن المشكلات. في النهاية قد يستسلموا.
  
  
• أسماء المتغيرات العشوائية لتطبيق الويب : يمكنك استخدام أحرف عشوائية بدلاً من أسماء المتغيرات المألوفة. يمكن أن يساعد بنفس طريقة تشويش الكود.
  
  
• : encryption_algorithm(data, key). , — decryption_algorithm(data, key). , , , . - - , (, SQL-), .

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







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

انتاج |

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