Ce que RASP aurait dû être

Ces dernières années, sécurité de l'application monde a vu la montée de Autoprotection des applications d'exécution (RASP) technologie. Comme décrit par Gartner, RASP est une technologie de sécurité intégrée à une application ou à son environnement d'exécution, capable de contrôler et de prévenir les attaques en temps réel. Malheureusement, beaucoup Pare-feu applicatif Web (WAF) les entreprises ont vu une opportunité de tirer parti du terme. Ils ont introduit des agents « de type RASP » au niveau de la couche réseau, ce qui ne correspond pas entièrement à la définition de la technologie RASP.

En revanche, la technologie RASP authentique fonctionne au niveau de la couche d'application, où elle dispose d'un contexte complet de l'utilisateur, de la logique d'application et des informations de domaine. Ce contexte permet à un RASP de prendre des décisions éclairées sur la sécurité de l'application et d'empêcher les exploits avant qu'ils ne causent des dommages. Par conséquent, un vrai RASP devrait avoir zéro faux positif et une latence réduite, offrant une amélioration immédiate des performances. True RASP nécessite une liste de règles immuables qui utilisent le contexte pour comprendre quand une nouvelle vulnérabilité est introduite et agir en conséquence. Cette immuabilité est possible lorsque les règles sont intégrées dans la base de code au niveau de la couche d'application et ne nécessitent aucune modification une fois déployées.

Trois domaines où RASP a mal tourné

1. Le problème du chien qui aboie : la plupart des alertes sont des faux positifs

Le problème avec les WAF est qu'ils fonctionnent au niveau de la couche réseau, un indicateur retardé de l'exécution de l'application. Le manque de contexte qui en résulte entraîne des taux élevés de faux positifs, de longs temps d'attente et de mauvaises performances, car les WAF ne peuvent que deviner la nature d'une vulnérabilité en fonction de ce à quoi ils ont été exposés auparavant.

Imaginez un chien de garde dans la cour qui aboie chaque fois qu'il entend un bruit au-delà de la clôture. Ces bruits peuvent être l'approche d'un intrus, mais il peut aussi s'agir de voitures qui passent. Le chien de garde ne peut pas évaluer avec précision la différence, de sorte que la gravité d'un bruit donné est perdue, ce qui empêche les personnes à l'intérieur de la maison de savoir quelles alertes sont authentiques et lesquelles sont de faux positifs. Ce scénario est essentiellement la capacité de l'offre RASP standard.

2. Le problème des 999 méchants : seulement capable de tester un échantillon

Croyez-le ou non, certains fournisseurs vous conseillent de n'exécuter leur solution de sécurité dans des environnements de production que si vous ne protégez qu'un échantillon. Cela signifie qu'il extrait un échantillon - peut-être une requête sur 1,000 999 - et teste cet échantillon tout en capturant ce qui se passe pour les 999 prochaines. Cela signifie que si vous êtes un bon acteur, votre signature sera vérifiée. Mais que les XNUMX acteurs suivants aient ou non de mauvaises intentions, ils s'en sortiront. Ce manque de cohérence est dû au fait que les RASP basés sur WAF ne peuvent pas gérer les exigences de performances liées au test de chaque requête.

3. Le problème « Cela prend trop de temps » : la latence affecte les performances

Chaque fois que vous avez un RASP basé sur WAF, vous rencontrez une latence accrue, car il ne peut en aucun cas influencer la base de code de l'application. Pendant ce temps, les RASP largement disponibles doivent envoyer des charges utiles de texte entier à leur analyseur Web, puis attendre qu'il soit renvoyé, ce qui peut prendre beaucoup de temps. Et si vos clients attendent que les paiements soient effectués, ils pourraient abandonner et rechercher vos concurrents à la place.

L'amélioration de ce processus est similaire à l'optimisation du code. Lors de la création d'une liste, les développeurs la configurent pour ajouter de nouveaux éléments au début d'une liste au lieu de la fin. Cette optimisation empêche la machine virtuelle de reconstruire la liste entière chaque fois qu'un nouvel élément est ajouté, ce qui évite d'augmenter la latence à mesure que la liste s'allonge. Les ingénieurs compilateurs ont résolu ces problèmes en implémentant la compilation juste-à-temps (JIT) au début des années 2000, qui optimise automatiquement le code en fonction des nuances du langage donné.

Pourquoi la définition de RASP a-t-elle été si édulcorée ?

Le développement de la technologie RASP nécessite une combinaison de compétences en ingénierie de la sécurité et en génie logiciel. Pour être efficace, le développeur RASP doit comprendre en profondeur l'architecture de l'application et les nuances du langage de programmation utilisé. Cela nécessite une expertise du domaine qui est rare chez les professionnels de la sécurité.

True RASP optimise le code pour les performances et la sécurité

Étant donné que la plupart des plates-formes RASP se comportent comme des WAF, il y a une surcharge énorme impliquée, ce qui nécessite de les exécuter en mode échantillon. En revanche, un véritable RASP exécute la protection réelle au moment de l'exécution.

Ces opérations existent en mémoire, ce qui est très efficace, et comme celle-ci existe dans le même espace que vos applications, elles sont très performantes. En exécutant la protection pendant l'exécution, il n'est pas nécessaire de limiter le débit ou d'effectuer une protection dans les tailles d'échantillon, car l'opération réelle ne prend que quelques millisecondes.

Quelles que soient les modifications apportées à l'application, la sécurité haute performance reste constante. Cette philosophie s'aligne sur la philosophie de l'infrastructure en tant que code, dans laquelle vous définissez l'état souhaité de votre infrastructure, et peu importe ce qui se passe dans l'environnement, l'état de l'infrastructure reste le même.

RASP, par définition, met en parallèle de nombreux principes d'infrastructure en tant que code. Ce parallèle est possible grâce à la conscience contextuelle profonde de l'application et du langage dans lequel elle est construite. Comme infrastructure en tant que code, une véritable approche de RASP peut et doit utiliser l'immuabilité pour garantir que les règles sont appliquées quelles que soient les modifications apportées à la base de code.

L'immuabilité est possible en effectuant une vérification de la sortie d'une fonction la première fois qu'elle est appelée et en désactivant toute fonctionnalité malsaine avec une fonctionnalité protégée, garantissant que l'application est toujours saine lors de son exécution.

Cette approche permet à la sécurité d'être indépendante du déploiement et ne nécessite pas de modifications du code de l'application, de réglage ou d'attente de fenêtres de déploiement.

En effectuant une protection dans le runtime, en corrigeant les résultats avec une protection immédiate sur toutes les instances en cours d'exécution de l'application, on élimine le besoin de faux positifs constants et supprime le risque de futurs exploits.

RASP peut et doit être tenu à un niveau plus élevé

En bref, RASP devrait être tenu à un niveau plus élevé. Lorsque cela est fait, il est possible de sécuriser des milliers d'applications, de réduire le coût total de possession de vos WAF et d'aider à prévenir l'épuisement professionnel au sein de vos équipes de sécurité.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been