ما يجب أن يكون RASP

في السنوات الأخيرة ، و أمان التطبيق شهد العالم صعود الحماية الذاتية لتطبيق وقت التشغيل (RASP) تكنولوجيا. كما وصفته شركة Gartner ، فإن RASP عبارة عن تقنية أمان مدمجة في تطبيق أو بيئة وقت التشغيل الخاصة به ، وهي قادرة على التحكم في الهجمات في الوقت الفعلي ومنعها. لسوء الحظ ، كثير جدار حماية تطبيقات الويب (WAF) رأت الشركات فرصة للاستفادة من المصطلح. لقد أدخلوا عوامل "تشبه RASP" في طبقة الشبكة ، والتي لا تتبنى بشكل كامل تعريف تقنية RASP.

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

ثلاثة مجالات كان خطأ RASP فيها

1. مشكلة الكلب النباح: معظم التنبيهات إيجابية كاذبة

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

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

2. مشكلة 999 رجلاً سيئًا: فقط قادرون على اختبار عينة

صدق أو لا تصدق ، يخبرك بعض البائعين بتشغيل حل الأمان الخاص بهم في بيئات الإنتاج فقط إذا كنت تحمي حجم عينة فقط. هذا يعني أنه يسحب عينة - ربما واحدًا من كل 1,000 طلب - ويختبر تلك العينة أثناء التعرف على ما يحدث لـ 999 التالية. بمعنى ، إذا كنت ممثلًا جيدًا ، فسيتم سحب توقيعك. ولكن بغض النظر عما إذا كان لدى الممثلين الـ 999 التاليين نوايا سيئة أم لا ، فسوف ينجحون في ذلك. يرجع سبب عدم الاتساق هذا إلى أن RASPs المستندة إلى WAF لا يمكنها التعامل مع متطلبات الأداء المتمثلة في الاضطرار إلى اختبار كل طلب.

3. مشكلة "تستغرق وقتًا طويلاً": الكمون يؤثر على الأداء

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

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

لماذا تم تخفيف تعريف RASP؟

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

تعمل True RASP على تحسين التعليمات البرمجية للأداء بالإضافة إلى الأمان

نظرًا لأن معظم منصات RASP تتصرف مثل WAFs ، فهناك قدر كبير من النفقات العامة ، مما يتطلب تشغيلها في وضع العينة. في المقابل ، يقوم RASP الأصلي بالحماية الفعلية في وقت التشغيل.

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

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

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

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

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

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

يمكن وينبغي عقد RASP على مستوى أعلى

باختصار ، يجب أن يكون RASP على مستوى أعلى. عند القيام بذلك ، من الممكن تأمين آلاف التطبيقات ، وتقليل التكلفة الإجمالية لملكية WAFs الخاصة بك والمساعدة في منع الإرهاق في فرق الأمان الخاصة بك.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. الوصول هنا.
• المصدر https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been