Mis à jours 2 novembre 2017 Le test d’intrusion : la pratique consistant à tester un système informatique, un réseau ou une application hébergée pour découvrir les vulnérabilités qui pourraient être exploitées par des pirates, est un mal nécessaire aujourd’hui, lorsque les failles de sécurité font que les nouvelles nationales et les entreprises piratées telles que Home Depot doivent payer une grande somme pour régler ces problèmes.
La valeur de ce type de test est qu’il maintient l’équipe de sécurité sur ses gardes et lui permet de comprendre les problèmes au fur et à mesure qu’ils surviennent. Comparé au coût des règlements récents, le test d’intrusion est une assurance bon marché que sa sécurité est la meilleure possible et que toutes les vulnérabilités seront identifiées et corrigées dès que possible.
La croissance du cloud a conduit à des angles intéressants sur le test d’intrusion. Les applications basées sur le cloud doivent être testées, tout comme le font leurs homologues sur le site. Cependant, les applications de test d’intrusion qui s’exécutent dans des cloud publics présentent certaines complexités auxquelles vous devez faire face, y compris des obstacles juridiques et techniques. Pour aider à relever les défis, voici cinq étapes sur la façon d’aborder le test d’intrusion dans le cloud.
Étape 1 : Comprendre les politiques du fournisseur de cloud
En mettant de côté les cloud privés pour l’instant, les cloud publics ont des politiques liées au test d’intrusion. Dans de nombreux cas, vous devez informer le fournisseur que vous effectuez un test, et il impose des restrictions sur ce que vous pouvez réellement faire pendant le processus de test d’intrusion. Donc, si vous avez une application qui fonctionne sur un cloud public et que vous souhaitez la tester, vous devrez d’abord faire des recherches sur le processus recommandé par votre fournisseur de cloud. Ne pas suivre ce processus pourrait entraîner des problèmes. Par exemple, votre test d’intrusion ressemblera beaucoup à une attaque DDoS, et il peut fermer votre compte.
Tous les fournisseurs de cloud contrôlent de manière proactive leur infrastructure pour détecter les anomalies. Dans certains cas, ils peuvent vous appeler pour savoir ce qui se passe. Mais, dans la plupart des cas, les fournisseurs de services cloud ont mis en place des procédures automatisées qui arrêtent le système sans avertissement lorsqu’ils perçoivent une attaque DDoS. Imaginez que vous pouvez arriver au bureau le jour suivant et constater que vos systèmes de stockage, vos bases de données et vos applications livrés dans le cloud sont hors ligne et que vous aurez des explications à faire pour les remettre en service.
Un autre problème est celui d’être un voisin bruyant : votre test d’intrusion pourrait utiliser autant de ressources qu’il affecte les autres sur le cloud. Les cloud publics sont multitenant et doivent donc gérer les ressources entre les locataires. Si votre test d’intrusion sature le système, vous allez recevoir un appel de votre fournisseur de cloud qui vous demande de le supprimer, ou encore, il pourrait simplement fermer votre compte.
Tout ça pour dire qu’il y a des règles de la route lorsqu’il s’agit de cloud publics. Vous devez comprendre les exigences légales du test d’intrusion, ainsi que les politiques et les procédures, sinon vous vous retrouvez rapidement hors du système cloud.
Étape 2 : Créer un plan de test d’intrusion
Ceux qui prévoient d’effectuer un test d’intrusion d’application cloud doivent d’abord créer un plan de test d’intrusion. Les éléments couverts dans le plan doivent inclure :
- Application(s) : Identifier et inclure les interfaces utilisateur ainsi que les API.
- Accès aux données : Identifier la façon dont les données seront testées à l’aide de l’application ou directement dans la base de données.
- Accès réseau : Identifier dans quelle mesure le réseau protège l’application et les données.
- Virtualisation : Identifier dans quelle mesure les machines virtuelles isolent votre charge de travail.
- Conformité : Identifier les lois et les règlements que vous devez respecter dans l’application ou la base de données.
- Automatisation : Identifier les outils de test d’intrusion automatisés (basés sur le cloud ou non) qui seront utilisés pour le test d’intrusion.
- Approche : Identifier les administrateurs de l’application à inclure ou à exclure dans le test d’intrusion. En cas d’exclusion, il pourrait être plus révélateur de voir comment ils réagissent, en pensant que c’est une attaque réelle. Toutefois, la plupart des administrateurs d’application sont contrariés par cette approche.
Le plan de test doit être approuvé par l’équipe de test d’intrusion, et chaque partie du plan doit être suivie. Toutes les exceptions qui surviennent vont vraiment avoir un impact sur les résultats, par exemple un administrateur d’application voit le test d’intrusion se produire et supprime l’accès pour l’équipe de test d’intrusion.
Étape 3 : Sélectionnez vos outils pour le test d’intrusion
Il existe de nombreux outils de test d’intrusion sur le marché. Alors que réaliser le test d’intrusion des applications basées sur le cloud avec des outils sur les sites est une approche populaire, il existe désormais des outils de test d’intrusion basés sur le cloud qui peuvent être plus rentables. De plus, ils ne nécessitent pas d’énormes empreintes matérielles. C’est un cloud qui effectue le test d’intrusion d’un cloud.
Ce qui est important à propos de l’outil, c’est qu’il peut simuler une attaque réelle. De nombreux pirates informatiques utilisent des processus automatisés pour trouver des vulnérabilités, telles que deviner les mots de passe à plusieurs reprises ou rechercher des APIs fournissant un accès direct aux données, et vous essayez réellement de simuler ces types de procédures.
Il se peut que vos outils de test d’intrusion ne puissent pas répondre à vos exigences. Si vous rencontrez ce problème, vous pouvez, en dernier recours, écrire votre propre système pour le test d’intrusion. Cela doit être évité si possible, car vous serez responsable de la maintenance de ce système, ce qui coûtera beaucoup plus cher que si vous utilisiez un outil existant.
Étape 4 : Observer la réponse
Lorsque vous exécutez le(s) test(s) d’intrusion, recherchez les éléments suivants :
- La réponse humaine : comment l’équipe d’administration de l’application et les utilisateurs de l’application répondent-ils au test d’intrusion ? Si le test n’est pas révélé, les réponses seront plus révélatrices. Beaucoup peuvent réagir en fermant simplement le système, tandis que d’autres peuvent diagnostiquer le problème en premier, avant d’identifier et d’élever la menace. Cela inclut également les humains chez votre fournisseur de client. Connaître leur façon de réagir est tout aussi important.
- La réponse automatisée : comment le système de sécurité lui-même peut-il repérer et répondre aux tests d’intrusion ? La réponse doit être hiérarchisée, allant du simple blocage d’une adresse IP qui génère le test d’intrusion à la fermeture complète de l’application. Dans tous les cas, les administrateurs de la sécurité et des applications doivent également être alertés, et des descriptions doivent être envoyées sur les mesures correctives qui ont été prises.
Les réponses humaines et automatisées doivent être documentées. C’est là que vous trouverez les déficits dans la façon dont le système et les humains ont réagi à la menace, et donc, à quel point le système est sécurisé.
Étape 5 : Trouver et éliminer les vulnérabilités
Bien que ce soit une étape évidente, le résultat de tout ce processus est une liste de vulnérabilités découvertes par le test d’intrusion. La liste peut dépasser une centaine de problèmes, ou seulement deux ou trois. S’il n’y en a pas, votre test peut ne pas être aussi efficace qu’il devrait l’être, et vous voudrez peut-être réévaluer et refaire le test.
Les vulnérabilités détectées lors de la réalisation du test d’intrusion des applications basées sur le cloud ressemblent généralement à ceci :
- Accès aux données de l’application autorisé grâce à l’API xxxxx.
- Accès API accordé après 10 tentatives.
- La machine virtuelle n’isole pas correctement la charge de travail.
- Mot de passe d’application deviné en utilisant le générateur de mot de passe automatisé.
- Le VPN permet un accès extérieur si le DNS est désactivé.
- Chiffrement non conforme aux nouvelles réglementations.
- D’autres problèmes
Bien sûr, les types de problèmes que vous trouverez varieront en fonction du type d’application et du type de test que vous exécutez.
Aussi, gardez à l’esprit qu’il existe différentes couches. L’application, le réseau, la base de données, le système de stockage, etc., qui doivent être testés séparément alors, les problèmes doivent être signalés séparément. Ensuite, les couches doivent également être testées ensemble pour voir comment elles interagissent et vérifier s’il y a également des problèmes. Signaler ce qui s’est passé à chaque couche, de manière holistique ; c’est une bonne pratique.
Assurez-vous de travailler avec votre fournisseur de cloud en ce qui concerne non seulement les problèmes légaux et politiques qui font partie des tests d’intrusion, mais également sur la façon dont il vous recommande d’effectuer des tests d’intrusion de vos applications dans son cloud. La plupart auront un processus à suivre qui donnera les meilleurs résultats de vos efforts.
Suggestions finales de test d’intrusion
Un autre point à considérer est celui qui fait le test d’intrusion. Si c’est fait en interne, comptez sur le fait que certains problèmes ne seront pas détectés. Les équipes de tests internes, peu importe leur qualité, semblent toujours manquer des choses. Ils sont trop près des arbres et trop familiers avec l’application, ce qui peut provoquer une complaisance et mener à la surveillance. Une alternative serait d’embaucher des pirates en chapeau blanc qui peuvent rendre vos applications basées sur le cloud très compétitives.
Recherchez les meilleures pratiques qui s’appliquent à votre fournisseur de cloud, les types d’applications que vous allez tester et les exigences de conformité à respecter. Utiliser les approches que d’autres ont adoptées est un bon point de départ, mais vous devez comprendre que vos approches et vos outils de test d’intrusion doivent être adaptés à vos besoins spécifiques.
Le test d’intrusion n’est pas une option ces jours-ci. C’est le seul moyen de prouver que vos applications ainsi que vos données basées sur le cloud sont suffisamment sécurisées pour permettre le maximum d’accès utilisateur avec un minimum de risques.
