Qu’est-ce que la sécurité des applications (AppSec) ?

application Menaces de sécurité : Le Top 10 de l'OWASP

D’innombrables menaces de sécurité affectent les applications logicielles. Toutefois, la liste des dix principales menaces d’application du projet Open Web Application Security Project (OWASP, projet de sécurité ouvert d’application web) compile les menaces pesant sur les applications qui sont les plus répandues et les plus graves, et qui sont les plus susceptibles d’affecter les applications en production.

Les initiatives AppSec doivent au moins se concentrer sur ces menaces à profil élevé pour les applications modernes :

1. Injection -L'injection de codeimplique une requête ou une commande envoyée à une application logicielle, qui contient des données malveillantes ou non fiables. La plus courante est l'injection SQL, mais elle peut également affecter les serveurs NoSQL, les systèmes d'exploitation et les serveurs LDAP.
2. Authentification défaillante : de nombreuxsites application ont des fonctions d'authentification et d'autorisation inadéquates ou défectueuses. Cela peut permettre à un pirate de voler les informations d'identification de l'utilisateur ou d'obtenir facilement un accès sans les informations d'identification appropriées.
3. Exposition de données sensiblesapplication et les API peuvent exposer ouvertement des données sensibles appartenant à l'organisation ou à ses clients, y compris des données financières ou de paiement et des informations personnelles identifiables (PII).
4. Entités externes XML (XXE)- Les attaquants peuvent faire un usage malveillant des références aux entités externes dans les documents XML, en raison de la vulnérabilité des anciens analyseurs XML. Ils peuvent être utilisés pour accéder à des fichiers internes, scanner des ports et exécuter du code à distance.
5. Contrôle d'accès défaillant - les restrictions imposéesaux utilisateurs authentifiés ne sont pas mises en œuvre correctement. Un attaquant pourrait s'en servir pour accéder à des fonctions ou à des données non autorisées, accéder au compte d'un autre utilisateur, consulter des fichiers sensibles ou modifier les autorisations d'autres utilisateurs.
6. Mauvaise configuration de la sécurité - mêmesi une application dispose de fonctions de sécurité, celles-ci peuvent être mal configurées. Cela se produit souvent parce que personne n'a modifié la configuration par défaut de l'application. Il s'agit notamment de l'absence de correctifs apportés aux systèmes d'exploitation et aux cadres de travail.
7. Cross-Site Scripting (XSS) - permet à un pirate d'exécuter un script malveillant dans le navigateur d'un utilisateur. Cela peut être utilisé pour voler leur session, rediriger les utilisateurs vers des sites malveillants ou défigurer des sites web.
8. Désérialisation non sécurisée - Défautsdans la manière dont le code est extrait d'un fichier et transformé en objet. Cela peut permettre l'exécution de codes malveillants, l'escalade des privilèges et le rejeu d'activités par des utilisateurs autorisés.
9. Utiliser des composants dont la vulnérabilité est connue - Plusieursbases de données de vulnérabilité signalent les vulnérabilités connues dans les composants logiciels. Les logiciels qui utilisent un composant vulnérable (même s'il s'agit simplement d'une dépendance de l'un de ses composants) sont exposés à des attaques.
10. Insuffisance de la journalisation et de la surveillance - de nombreuxsites application n'ont pas les moyens d'identifier ou d'enregistrer les tentatives de violation. Cela peut signifier que des brèches ne sont pas détectées et que les attaquants peuvent effectuer des mouvements latéraux pour compromettre d'autres systèmes.

Un processus AppSec de base implique les étapes suivantes :

1. Définition des actifs d’entreprise
2. Détermination de la façon dont chaque application affecte ces actifs
3. Création d’un profil de sécurité pour chaque application
4. Identification et hiérarchisation des menaces potentielles
5. Enregistrement des incidents de sécurité et des tentatives d’atténuation

Outils de test de sécurité des applications

Il existe trois catégories principales d'outils dans la boîte à outils AppSec : SAST, DAST et IAST.

Test de sécurité statique application (SAST)

Les outils SAST permettent le test en boîte blanche. Ils évaluent le code d’application et l’analysent pour identifier les bogues, les vulnérabilités ou d’autres faiblesses qui peuvent créer un problème de sécurité. SAST peut s’exécuter sur un code compilé, un code non compilé ou les deux.

L’analyse SAST peut identifier des problèmes tels que :

• Conditions de concurrence
• Traversées de chemin d’accès
• Validation d’entrée manquante
• Erreurs numériques ou erreurs de type de données
• Références ou pointeurs non sécurisés

Test de sécurité dynamique application (DAST)

Les outils DAST utilisent des méthodes de test de la boîte noire pour tester les applications en cours d’exécution pour des problèmes de sécurité. Ils effectuent une analyse dynamique du code source lorsqu’il est en cours d’exécution. DAST utilise généralement des tests à données aléatoires, ce qui implique d’atteindre l’application avec un grand nombre de demandes aléatoires et inattendues.

DAST peut détecter des conditions qui indiquent des vulnérabilités de sécurité, par exemple :

• Interfaces non sécurisées ou vulnérables
• Demandes et réponses anormales
• Problèmes de script dans des langages tels que JavaScript et Python
• Injection de données ou de code
• Anomalies de session
• Problèmes d’authentification

Test de sécurité interactif application (IAST)

IAST est une approche hybride qui combine SAST et DAST. L’approche interactive des tests de sécurité combine les analyses statique et dynamique, ce qui permet d’identifier les vulnérabilités connues et de voir si elles sont réellement utilisées dans l’application en cours d’exécution et peuvent être exploitées.

Les outils IAST recueillent des informations détaillées sur le flux d’exécution de l’application et les flux de données, et peuvent simuler des modèles d’attaque complexes. Lorsqu’ils effectuent une analyse dynamique d’une application en cours d’exécution, ils peuvent vérifier les réponses de l’application et ajuster leurs tests en conséquence. Cela peut être utilisé pour créer automatiquement de nouveaux cas de test, etc (comme un testeur de pénétration humaine).

Grâce à cette approche, les outils IAST peuvent enquêter en profondeur sur des problèmes de sécurité suspectés, ce qui réduit le nombre de faux positifs. Ils s’intègrent également beaucoup plus naturellement dans un processus de développement agile avec des lancements rapides.

Rule Based Pare-feu pour applications Web (WAF)

Un WAF est une solution déployée à la périphérie du réseau, qui inspecte le trafic entrant et sortant du réseau et tente d'identifier et de bloquer le trafic malveillant.

Les WAF traditionnels, basés sur des règles, constituent un outil à maintenance élevée qui oblige les organisations à définir méticuleusement un ensemble de règles correspondant à leurs modèles de trafic et d’application spécifiques. De plus, les WAF basés sur des règles ont une couverture limitée des vecteurs d’attaque en constante évolution.

En outre, les WAF traditionnels ne peuvent pas protéger automatiquement les nouveaux microservices, car chaque nouveau microservice déployé nécessite un important travail supplémentaire de définition de nouvelles règles et politiques. En termes pratiques, cela signifie que les nouveaux systèmes déployés par l’organisation ne seront pas protégés dans de nombreux cas.

Bonnes pratiques de sécurité des applications

Voici quelques bonnes pratiques que vous pouvez utiliser pour mettre en œuvre efficacement AppSec dans votre organisation.

Commencez par une évaluation de la menace

Examinez les principaux points d’entrée que les attaquants peuvent utiliser pour violer vos applications, les mesures de sécurité qui sont en place et déterminez si elles sont adéquates. Définissez des objectifs et des jalons raisonnables au fil du temps, pour le niveau de sécurité que vous souhaitez atteindre pour chaque type de menace.

Déplacer la sécurité vers la gauche

Les tests de sécurité doivent être entièrement intégrés au cycle de vie du développement logiciel (SDLC), de l’étape de planification au développement, aux tests et au déploiement en passant par la production.

Utilisez des outils automatisés pour vous assurer que application est testé le plus tôt possible dans le processus, et à plusieurs points de contrôle tout au long du pipeline CI/CD. Par exemple, lorsqu'un développeur livre du code et déclenche une compilation, ce code devrait automatiquement subir une forme de test de sécurité, ce qui permettrait au développeur de corriger immédiatement les problèmes de sécurité dans son code.

Ce même code doit être testé de nouveau, de manière plus exhaustive, lorsqu’il est promu à un environnement de test et de production.

Établir des priorités en matière de remédiation

La sécurité des applications entraînera la découverte de vulnérabilités dans vos applications, et vous ne pourrez pas toutes les corriger. La hiérarchisation est essentielle pour assurer que les vulnérabilités critiques sont corrigées rapidement, sans nuire à la productivité des développeurs.

Votre processus de test de sécurité doit inclure des mesures automatisées indiquant la gravité et l’exploitabilité de la vulnérabilité et, si nécessaire, une évaluation manuelle indiquant si la vulnérabilité présente réellement un risque commercial. Les composants vulnérables qui ne sont pas en cours d’exécution en production ne sont pas une priorité.

Assurez-vous que les développeurs savent qu’ils travaillent sur des vulnérabilités réelles et à profil élevé, et qu’ils ont le temps de les corriger partout où elles se produisent dans le SDLC.

Suivre les résultats AppSec

Un programme AppSec nécessite un investissement majeur en temps et en ressources, ainsi que des changements culturels et organisationnels. Il est important de comprendre l’impact du programme sur la sécurité pour justifier le programme et s’assurer qu’il est soutenu par la direction.

Mesures importantes que vous pouvez suivre et partager pour démontrer le succès d’AppSec : une tendance hebdomadaire ou mensuelle peut montrer l’impact de l’introduction des mesures de sécurité des applications :

• Nombre de violations des politiques AppSec internes
• Nombre de violations de la conformité
• Nombre de défauts de sécurité détectés dans l’environnement de test
• Nombre de défauts de sécurité détectés dans l’environnement de production
• Nombre d’incidents de sécurité

Gérer les privilèges

Tout ce qui est lié à un programme de sécurité des applications est constitué de données sensibles qui pourraient être extrêmement utiles à un attaquant. Assurez-vous de gérer soigneusement les éléments suivants :

• Documentation des politiques et des processus
• Accès aux outils de sécurité
• Accès au CI/CD et aux outils de développement

Utilisez le principe du moindre privilège et veillez à ce que chaque utilisateur n'ait accès qu'aux données et aux systèmes dont il a absolument besoin pour faire son travail. Utilisez les principes de confiance zéro entre les systèmes intégrés, en veillant à ce que chaque système ne dispose que des autorisations minimales dont il a besoin pour fonctionner.

AppSec avec Check Point

CloudGuard de Check Point comprend une solution de sécurité d’application à configuration nulle qui fournit les éléments suivants :

• Prévention précise : protection contre les attaques sophistiquées, telles que les dix principales OWASP, sans générer de faux positifs.
• Administration de politique zéro : s’adapte automatiquement aux changements et aux mises à jour des applications
• Déploiement flexible et rapide : avec un déploiement pour une protection en 48 heures maximum

Alimenté par un moteur contextuel IA en instance de brevet, CloudGuard application Security est entièrement automatisé et peut être déployé dans n'importe quel environnement.