À présent, nous allons voir quels audits et contrôles vous pourrez réaliser pour aller plus loin, si votre entreprise est mature d’un point de vue cybersécurité.
Reprenons notre schéma : nous allons commencer par détailler la partie en bleu en haut à gauche.
Ce type d’audit ou de contrôle est adapté lorsque vous souhaitez avoir une approche ponctuelle.
Maîtrisez les bases des opérations Red Team
Type d’audit | Opérations Red Team |
Objectif | Réaliser une simulation d’attaque ciblée en condition réelle pour évaluer la robustesse du SI et les capacités de détection et de réponse de l’entreprise. |
Description | Réaliser une simulation d’attaque sans aucun prérequis ni connaissances préalables sur le SI audité, et tenter d’atteindre un objectif défini par le donneur d’ordre. |
Facteurs clés de succès |
|
Exemples de situations où on peut utiliser ce type d’audit |
|
Ce type d’audit ou de contrôle vous permettra de répondre aux questions suivantes :
Quel est le niveau de robustesse de mon SI face à une attaque ciblée ?
À quel point suis-je en capacité de détecter une attaque en cours sur mon SI et de bloquer l’attaquant ?
En revanche, il ne répondra pas à la question suivante :
Quels sont tous les points d’entrée possibles sur mon SI ?
Quel est le niveau de vulnérabilité global de mon SI une fois que l’attaquant s’y est introduit ?
Comment est-ce que je vais définir les personnes à prévenir et celles à ne pas prévenir ?
Cela dépendra de l’approche que vous voulez adopter :
Soit vous voulez ne pas prévenir du tout vos équipes de détection et réponse (la “Blue Team”), pour voir si elles remontent d’elles-mêmes l’incident. Cela vous permet de tester l’état de vos dispositifs de détection et réponse à un instant t ; il s’agit souvent de l’approche retenue pour une première opération Red Team.
Soit vous voulez les prévenir et adopter une approche plus “collaborative” : on parle dans ce cas d’approche “Purple Team”. Dans ce cas, la “Red Team” (les auditeurs) va présenter les actions réalisées à chaque étape de l’attaque, et la Blue Team va présenter les éléments qu’elle aura détectés. L’objectif pour la Blue Team sera d’ajuster les dispositifs de détection pour identifier le plus d’actions possibles tandis que la Red Team tentera de contourner les dispositifs supplémentaires de détection mis en place.
Même si je n’ai pas encore de dispositif de détection et réponse, ce type d’audit a l’air très intéressant ! Pourquoi est-il déconseillé ?
Ce type d’audit coûte relativement cher du fait de la complexité de l’opération à mettre en place (sans aucun prérequis ni connaissance préalable), et du niveau de compétence rare (double compétence) des profils qui peuvent le réaliser.
Je vous conseille donc de le réaliser uniquement si vos dispositifs de détection et réponse sont mis en place pour garantir un bon retour sur investissement. Si ce n’est pas le cas, un test d’intrusion correctement réalisé devrait tout à fait répondre à votre besoin.
Nous allons terminer ce chapitre en détaillant la partie en bleu en haut à droite du schéma.
Ce type d’audit ou de contrôle est adapté lorsque vous souhaitez avoir une approche continue.
Maîtrisez les bases des scans de conformité
Type d’audit | Scans de conformité |
Objectif | Vérifier que les configurations de votre SI sont conformes avec vos référentiels (internes ou externes). |
Description | Réaliser des scans avec des outils avancés permettant l’analyse automatisée de configurations et la comparaison avec des référentiels. |
Facteurs clés de succès |
|
Exemples de situations où on peut utiliser ce type d’audit |
|
Ce type d’audit ou de contrôle vous permettra de répondre à la question suivante :
Est-ce que les configurations de mes actifs sont conformes à ma politique interne et/ou à mes obligations externes ?
En revanche, il ne répondra pas à la question suivante :
L’utilisation qui est faite de cet actif respecte-t-elle les bonnes pratiques ?
Sur quels points je dois être mature pour pouvoir réaliser ce type d’audit ou de contrôle ?
Pour ce type d’audit, vous l’aurez compris, l’outillage est très important.
Mais il existe tellement d’outils que vous devez être sûr de ce que vous voulez vérifier (Quel référentiel vérifier ? sur quel composant ?) et pourquoi (Qu’est-ce qui est important pour votre entreprise ? Quel risque voulez-vous couvrir ?).
Cela nécessite aussi que les référentiels auxquels vous voulez comparer les configurations soient déjà mis en œuvre dans votre entreprise.
Ce type d’audit est particulièrement adapté par exemple si vous avez des contraintes réglementaires très fortes du fait de votre activité (paiements, SI vitaux, etc.).
Maîtrisez les bases des scans de code
Type d’audit | Scans de code |
Objectif | Vérifier que les mises à jour de vos applications n’introduisent pas de nouvelles failles dans le code. |
Description | Réaliser des scans automatisés du code avec un outil dédié du marché de type SAST. |
Facteurs clés de succès |
|
Exemples de situations où on peut utiliser ce type d’audit |
|
Ce type d’audit ou de contrôle vous permettra de répondre à la question suivante :
Mon sprint de développement ajoute-t-il de nouvelles failles de sécurité connues ?
En revanche, il ne répondra pas à la question suivante :
Quels sont les chemins d’attaque possibles sur mon application ?
J’ai compris dans la revue de code qu’il valait mieux avoir aussi une approche manuelle. Est-ce que l’approche outillée est suffisante ici ?
Oui et non.
Déjà, le fait de choisir le bon outil va grandement vous faciliter le travail. Certains outils de vérification de qualité du code peuvent aussi faire des vérifications de sécurité, mais cela peut ne pas être suffisant pour un actif critique pour votre entreprise.
Ensuite, il s’agit d’une approche continue, donc il va être très compliqué de réaliser des vérifications manuelles à chaque fois, surtout si vos sprints de développement sont très rapprochés. Mais si des failles critiques sont remontées, il faudra les traiter : de fait, les équipes vont revoir manuellement le code pour traiter les vulnérabilités et détecter les éventuels faux positifs.
Maîtrisez les bases des Bug Bounty
Type d’audit | Bug Bounty |
Objectif | Tester en continu les possibilités d’attaques sur un SI (souvent exposé sur Internet). |
Description | Attribuer des récompenses à destination de hackers éthiques qui trouvent des vulnérabilités sur le SI. |
Facteurs clés de succès |
|
Exemples de situations où on peut utiliser ce type d’audit |
|
Ce type d’audit ou de contrôle vous permettra de répondre à la question suivante :
Quelles sont les possibilités d’attaque sur mon actif en temps réel ?
En revanche, il ne répondra pas forcément à la question suivante :
Le back-office de mon application est-il sécurisé ?
Quelle récompense je dois donner au hacker qui trouve une faille sur mon SI ?
De l’argent ! :)
Les montants versés sont souvent définis à l’avance en fonction du type de faille et de la difficulté à la trouver. Si vous passez par une société spécialisée (ce que je vous conseille), elle pourra le définir avec vous en fonction de ce qui se pratique sur le marché.
Cette société pourra aussi se charger du choix des hackers, des vérifications et de l’outillage nécessaires pour vous remonter les failles, etc.
J’ai compris que les outils DAST font aussi des tests d’intrusion “boîte noire” automatisés. Mais alors, quelle est la plus-value du Bug Bounty ?
À la différence des outils DAST, le Bug Bounty est réalisé par une intelligence humaine, donc les chemins d’attaque identifiés vont souvent être plus complexes et plus proches de ce qu’un attaquant “réel” pourrait tenter de réaliser.
En résumé
Certains types d’audits et de contrôles ne seront pas adaptés si votre niveau de maturité cybersécurité est faible à moyen ; il s’agit des types suivants : Red Team, Bug Bounty, scans de code et scans de conformité.
Une opération Red Team vise à évaluer la robustesse du SI en conditions réelles, mais aussi vos capacités de détection et de réponse à un incident.
Pour les audits et contrôles continus, l’un des principaux facteurs clés de succès va être votre capacité à traiter les problèmes remontés dans des délais courts.
Et voilà ! Les audits et contrôles techniques n’ont plus de secret pour vous ! Passons maintenant aux audits et contrôles organisationnels.
