La cybersécurité est un domaine particulièrement vaste, au point qu’il est aujourd’hui segmenté en trois grandes “branches”, chacune couvrant une couche informatique précise : la sécurité réseau, la sécurité système et enfin la sécurité applicative.

Ce guide vous propose une analyse de la sécurité applicative. Il s’intéressera, à ses enjeux, aux principales vulnérabilités connues ou encore aux bonnes pratiques pour la rendre plus efficace.

 

 

Qu’est-ce que la sécurité applicative ?

La sécurité applicative, aussi appelée AppSec, désigne l’ensemble de processus, de pratiques et d'outils utilisés pour protéger les applications contre les menaces et les attaques.
Point important, cette branche de la cybersécurité couvre non seulement le parc applicatif en place, mais intervient également dans le processus de développement des nouveaux outils.

Dans un monde numérique où les applications sont devenues la colonne vertébrale de bien des activités, un haut degré de sécurité est une priorité absolue.

 

 

Quels sont les piliers de la sécurité applicative ?

 

 

La sécurité applicative repose sur trois piliers fondamentaux : la technologie, les processus et les personnes. Chacun d'eux est crucial pour le succès de tout programme de sécurité applicative.

 

Pilier 1 - Technologie

La technologie est le fondement de toute application. De l’infrastructure réseau aux frameworks de développement en passant par les bases de données, toutes ces composantes doivent être sécurisées pour garantir l'intégrité des outils informatiques.

 

Pilier 2 - Processus

Les processus sont au cœur des usages visant à développer, déployer et gérer les applications. Il comprend des pratiques telles que l’intégration et le déploiement continu (CI/CD), la gestion des vulnérabilités, le monitoring de la performance, etc. Les processus doivent être conçus en gardant la sécurité à l'esprit pour minimiser les risques.

 

Pilier 3 - Personnes

Négliger le pilier humain est une erreur stratégique et pourtant courante. Il ne s'agit pas seulement des développeurs, mais de toutes les personnes qui interagissent avec l'application à un moment donné.
Il peut s'agir d'administrateurs, d'utilisateurs, de clients, etc. Les failles de sécurité étant aussi bien informatiques qu’humaines, la sensibilisation à la sécurité applicative (mais pas que) doit être prise très au sérieux.

 

La sécurité applicative, un domaine critique insuffisamment considéré

Si la sécurité réseau et la sécurité système sont aujourd’hui prises au sérieux par les entreprises, la situation est tout autre pour la sécurité applicative, où encore trop peu d’efforts sont faits. Résultat, les applications sont aujourd’hui régulièrement à l’origine des attaques.
Un récent rapport de Veracode propose des statistiques édifiantes :

• Sur 85 000 applications testées dans le cadre de l’analyse, 83 % présentent au moins une faille de sécurité ;

• Sur ces failles, 20 % sont critiques, bien que le rapport note une amélioration de 14 % par rapport à une édition réalisée il y a 10 ans ;

• Au global (indépendamment du degré de sévérité), seules 56 % des failles finissent par être sécurisées ;

• Pire, sur ces 56 %, la durée moyenne de réparation (MTTR ou Mean Time To Remediation) a triplé par rapport à il y a 10 ans, passant de 59 jours à 171 jours !

• Enfin, nous apprenons que 70 % des 85 000 applications suivies sont testées entre 0 et 6 fois par an.
  
  

Au-delà de cet enjeu structurel, l’AppSec fait face à d’autres défis : 

• Un fort héritage de vulnérabilités, les applications modernes reposant régulièrement sur du code hérité, des bibliothèques et des dépendances datant de plusieurs années. Ces composants plus anciens peuvent contenir des vulnérabilités non corrigées générant une forme de dette technique difficile à solder.

• Un manque de sensibilisation aux bonnes pratiques dans les organisations, avec des collaborateurs peu ou pas conscients des risques auxquels ils s’exposent (et exposent leur entreprise).

• Les difficultés pour attirer des profils qualifiés, avec une “crise du recrutement” qui perdure dans le domaine de la cybersécurité. L’augmentation de la quantité d’attaques accroît également la pression sur les équipes. Il en résulte un taux de turn-over de 23 % pour la France, d’après une étude de Splunk sur 2022, des difficultés à recruter donc, ainsi que des difficultés à conserver les talents.

• L'open source et les composants “third party”, souvent retrouvés dans les applications modernes, introduisent un niveau de risque additionnel. Ces vulnérabilités n’étant pas (ou très difficilement) détectables manuellement, le recours à des outils spécialisés est indispensable.
  En parallèle, les bonnes pratiques (comme celles présentées sur Open SSF) pour les projets de développement d’applications open source ne sont pas toujours prises en considération.

• La difficulté à trouver un outil pouvant centraliser les différentes informations relatives à la sécurité applicative dans un seul reporting est également un enjeu important.
  Les équipes de sécurité doivent bien souvent jongler entre plusieurs interfaces et divers tableaux pour obtenir une vue d’ensemble sur la “santé” du patrimoine applicatif.

 

Quelles sont les principales familles d’applications concernées par la sécurité applicative ?

Il existe trois principaux types d'applications, correspondant à autant de sous-branches en sécurité applicative :

Web apps

Ces applications sont accessibles via un navigateur web. Elles sont vulnérables à une multitude d'attaques, telles que le cross-site scripting (XSS), l'injection SQL et le détournement de session.

Cloud native apps

Ces applications sont spécialement conçues pour tirer parti des services de cloud computing. Elles nécessitent une approche unique en matière de sécurité, compte tenu de leur nature distribuée et de leur dépendance vis-à-vis des fournisseurs de services cloud.

API (Applicative Programming Interface)

Les API sont des interfaces qui permettent à différentes applications de communiquer entre elles. Elles sont devenues une cible de choix pour les attaquants, car une seule API peut offrir un accès à des données sensibles provenant de multiples applications.

 

Comprendre les différentes composantes de la sécurité applicative

 

La sécurité applicative comprend différentes mesures et techniques à associer pour protéger les applications informatiques.

 

Authentification

L'authentification est le processus de vérification de l'identité d'un utilisateur, d'un système ou d'une application.

Autorisation

L'autorisation est le processus qui détermine ce qu'un utilisateur, un système ou une application authentifié est autorisé à faire.

Chiffrement

Le chiffrement est essentiel pour protéger la confidentialité et l'intégrité des données. Il s'agit de rendre les données illisibles sans une clé de déchiffrement appropriée.

Logging

Le logging, ou journalisation, est le processus de suivi des événements dans une application. C'est un élément clé pour la détection des problèmes de sécurité et l'audit des activités.

Contrôle de sécurité

Le contrôle de sécurité est une vérification qui s'assure que les protections nécessaires sont en place au moment du développement de l’application.

Quelles sont les 3 catégories de sécurité applicative ?

Au niveau technique, il est possible de décomposer la sécurité applicative en 3 niveaux : 

 

Le contrôle préventif

Il vise à prévenir les attaques en identifiant et en corrigeant les vulnérabilités avant qu'elles ne soient exploitées. Cela peut inclure des activités comme l'analyse statique de code source (SAST), les tests d'intrusion et la formation en sensibilisation à la sécurité.

Le contrôle d’intrusion

Son objectif est de détecter rapidement une intrusion en cours et de l'endiguer ou de la stopper. Cela comprend l'utilisation de systèmes de détection d'intrusion (IDS), de pare-feu d'application web (WAF) et de solutions de gestion des événements et des informations de sécurité (SIEM).

Le contrôle correctif

Il est destiné à minimiser l'impact d'une attaque réussie. Cela comprend des mesures telles que l'isolement des systèmes affectés (utilisation de VM par exemple), la récupération à partir de sauvegardes et le colmatage des brèches ayant permis les attaques.

Allouer toutes vos ressources à l’un des volets au détriment des autres est une pratique dangereuse qui peut avoir un impact majeur sur la sécurité de votre parc applicatif.
En cybersécurité, la question n’est en effet pas de savoir SI une attaque va finir par percer vos défenses, mais QUAND. En l’absence de mesures correctives, une attaque réussie sera bien souvent dévastatrice.

À l’inverse, le caractère inéluctable de ce phénomène ne doit pas vous encourager à délaisser le volet préventif de la sécurité applicative, bien au contraire.
Plus vos applications seront protégées, plus les pirates informatiques auront de mal à s’y introduire, et plus il y a de chances qu’ils abandonnent et s’orientent vers des cibles moins bien défendues.

Les principales vulnérabilités en sécurité applicative

Pour protéger efficacement votre parc applicatif, une bonne connaissance des principales menaces est extrêmement importante.
Dans ce cadre, la Fondation OWASP (Open Worldwide Application Security Project) propose depuis maintenant plusieurs années des synthèses regroupant les menaces techniques les plus fréquemment identifiées.

Web Apps

1 - Lacunes dans la gestion des accès, avec la possibilité pour un utilisateur d’accéder à des ressources en dehors de son niveau d’habilitation ;

 

2 - Défaillances cryptographiques, avec des données mal ou pas chiffrées ;

 

3 - Failles d’injection (SQL, NoSQL, Mapping objet, LDAP, etc.) ;

 

4 - Failles de conception et d’architecture ;

 

5 - Failles dans les mesures de sécurité (licences pas à jour, mots de passe faibles, présence de fonctionnalités inutiles, fonctionnalités désactivées, etc.).

 

La liste complète des vulnérabilités principales pour les Web Apps est disponible ici.

 

API

1 - Accès non autorisé aux objets en contournant les mesures de sécurité ;

 

2 - Dysfonctionnement du mécanisme d’authentification ;

 

3 - Exposition excessive des données (usage de l’API mal défini en général)

 

4 - Manque de limites sur la quantité ou la taille de requêtes (DoS fréquent)

 

5 - Gestion des accès trop souple avec une séparation des droits souvent floue

 

Voici la liste complète des vulnérabilités principales pour les API ainsi que des détails additionnels

 

Cloud Native Apps

1 - Cloud, containers ou configurations insuffisamment sécurisées (cloud en accès public, permissions trop légères, etc.) ;

 

2 - Failles d’injection (SQL, XXE, NoSQL, etc.) ;

 

3 - Problèmes d’authentification et d’autorisation ;

 

4 - Failles dans le pipeline et/ou le flux de travail CI/CD ;

 

5 - Stockage d’informations confidentielles mal sécurisé.

La liste complète de l’OWASP vous donnera de plus amples informations

 

 

 

5 familles d’outils pour travailler la sécurité applicative

 

 

 

SAST (Static Application Security Testing)

Ces outils analysent le code source d'une application pour détecter les vulnérabilités potentielles. Ils sont généralement utilisés dans le cadre du processus de développement pour identifier et corriger les problèmes avant la mise en production.

Cette famille d’outil utilise la méthode “white box testing”. Il s’agit d’une approche utilisée afin d'effectuer des analyses approfondies, y compris le test de la logique interne du code, le flux de données, les contrôles de sécurité, etc. Le “white box testing” est extrêmement utile pour identifier les problèmes de sécurité potentiels avant qu'ils ne soient exploités et s'inscrit donc dans une logique de contrôle préventif.

De nombreuses informations (architecture, code source, etc.) sont mises à disposition du testeur et ce dernier connaît le fonctionnement de l’application cible.

 

DAST (Dynamic Application Security Testing)

Ces outils testent une application en cours d'exécution pour détecter les vulnérabilités qui pourraient être exploitées lors d'une attaque réelle. Un DAST est utilisé pour obtenir une “vision attaquant”.
La méthode utilisée est le “black box testing”, l’exact opposé du “white box testing” vu plus haut.
Ici, l'auditeur n'a aucune connaissance de l'infrastructure, des systèmes ou du code source qu'il teste. L'objectif est d'effectuer des tests de la même manière qu'un attaquant externe potentiel. Le test en boîte noire est utile pour identifier les vulnérabilités de sécurité à partir de la perspective de l'utilisateur final, comme les failles d'injection SQL, les problèmes de script intersite (XSS), etc.

 

IAST (Interactive Application Security Testing)

Cette famille de logiciels combine les aspects du SAST et du DAST. Les outils recourant à l’IAST sont conçus pour être utilisés dans un environnement de test et travaillent en surveillant une application lorsqu'elle est testée pour identifier les vulnérabilités.

Ces outils peuvent identifier un large éventail de vulnérabilités, y compris celles qui ne sont généralement détectées que par le SAST ou le DAST. Il peut également donner un aperçu du contexte de l'application, comme la façon dont les données circulent à travers elle et où exactement les vulnérabilités sont situées dans le code, ce qui facilite leur correction.

On parle ici de “Grey Box Testing”. Cette approche hybride combine des éléments des tests en boîte blanche et en boîte noire. L'auditeur a un accès partiel à l'infrastructure, aux systèmes et au code source. Cela peut inclure des informations de haut niveau sur le schéma de l'architecture, les documents de conception, les spécifications de l'API, etc. Le test en boîte grise est utile pour identifier les problèmes de sécurité au niveau de l'interface utilisateur et de l'API, ainsi que pour vérifier l'efficacité des contrôles de sécurité.

MAST (Mobile Application Security Testing)

Le MAST est très similaire au IAST, mais dédié aux applications mobiles. Les outils s’appuyant sur le MAST peuvent notamment réaliser des tests de sécurité statiques pour examiner le code source de l'application, des tests dynamiques pour observer le comportement de l'application lorsqu'elle est exécutée, et des tests d'interaction pour découvrir les problèmes de sécurité liés à la manière dont l'application interagit avec l'environnement de l’OS.

 

SCA (Software Composition Analysis)

Le SCA est spécialisé dans l'analyse des composants open source utilisés dans une application. Il scanne l'ensemble du code de l'application, en se concentrant sur l'identification des composants tiers, comme les bibliothèques et les frameworks open source, qui sont souvent utilisés dans le développement moderne de logiciels.

Les outils SCA peuvent identifier le code source vulnérable, les licences non conformes et les composants obsolètes. Ils peuvent également offrir une visibilité sur le risque de sécurité associé à un composant spécifique. Ils sont essentiels pour aider les organisations à gérer les risques associés à l'utilisation de logiciels open source.

 

6 bonnes pratiques pour renforcer la sécurité applicative de votre entreprise

Terminons avec quelques conseils pouvant vous aider à renforcer la sécurité de vos applications : 

 

1. Intégrer la sécurité dès la conception des apps : ne considérez pas la sécurité comme une réflexion après coup. Elle doit être réfléchie dès le début du cycle de développement d’une application.
   
   

2. Opter pour une politique d’accès Zero Trust : vos collaborateurs se voient attribuer des accès bien spécifiques à certaines applications/ressources de façon à limiter le potentiel d’intrusion.

 

3. Mapper l'ensemble des systèmes et logiciels à protéger : que ce soit dans le cloud ou sur site, il est important de connaître l'étendue complète de votre environnement pour pouvoir le protéger efficacement.

 

4. Quantifier le niveau de menace maximal : anticiper le pire scénario possible peut vous aider à allouer les ressources de manière appropriée.

 

5. Effectuer des tests de pénétration : ces tests imitent les attaques réelles et peuvent aider à identifier les vulnérabilités avant qu'elles ne soient exploitées par de vrais attaquants.

 

6. Auditer régulièrement les applications : les audits peuvent aider à détecter les nouvelles vulnérabilités et à s'assurer que les contrôles de sécurité existants sont toujours efficaces. Pour rappel, le rapport Veracode réalisé sur 85 000 applications indique que 70 % d’entre elles sont testées entre 0 et 6 fois par an !

Pour tout besoin ou problématique de sécurité applicative, n’hésitez pas à contacter un expert Redopus et obtenir une proposition personnalisée !