HackTheBox - Vulnerability Assessment - Security Assessment

Informations sur le module

Ce module présente les différents types d’évaluations de sécurité qu’une organisation peut effectuer pour protéger ses systèmes. Chaque type d’évaluation a son utilité et s’adapte à différents niveaux de maturité en sécurité.

Lien : Security Assessments

Objectifs d’apprentissage

Ce module couvre les compétences suivantes :

• Distinguer les différents types d’évaluations de sécurité
• Comprendre quand utiliser chaque type d’évaluation
• Identifier les différences entre vulnerability assessment et pentest
• Découvrir les concepts de red team, purple team et bug bounties

---

Types d’évaluations de sécurité

Pourquoi faire des évaluations de sécurité

Chaque organisation doit tester la sécurité de ses systèmes régulièrement. L’objectif principal est de trouver et confirmer la présence de vulnérabilités pour pouvoir les corriger.

Pour les débutants : Une vulnérabilité est une faille dans un système qui pourrait être exploitée par un attaquant. Penser à une porte mal verrouillée dans une maison.

Ce qui m’a appris ce module, c’est que toutes les organisations n’ont pas besoin du même type d’évaluation. Ça dépend de plusieurs facteurs :

• La maturité sécurité de l’entreprise (à quel point leur programme de cybersécurité est développé)
• Les réglementations qu’elles doivent respecter
• Le type de réseau et d’applications utilisées
• Les menaces auxquelles elles font face

Vulnerability Assessment - L’évaluation de base

Un vulnerability assessment (évaluation de vulnérabilités) est approprié pour toutes les organisations, peu importe leur taille.

Comment ça fonctionne :

L’évaluateur utilise un standard de sécurité comme référence et vérifie si l’organisation respecte ce standard. C’est essentiellement une checklist :

• Est-ce que nous respectons ce standard ?
• Est-ce que nous avons cette configuration ?
• Est-ce que cette vulnérabilité est présente ?

Mon observation : Pendant un vulnerability assessment, l’évaluateur va typiquement lancer un scan de vulnérabilités avec des outils comme Nessus, puis valider manuellement les vulnérabilités critiques, hautes et moyennes.

La différence importante : l’évaluateur confirme que la vulnérabilité existe (ce n’est pas un faux positif), mais il ne va pas essayer de l’exploiter pour faire de l’escalation de privilèges ou du mouvement latéral.

Les vulnerability assessments sont la base. Toute organisation devrait commencer par là avant de penser aux pentests plus avancés.

Penetration Test - La simulation d’attaque

Les pentests sont ce qu’on pratique le plus sur HackTheBox. C’est une simulation d’attaque cybernétique où le testeur agit comme un vrai attaquant pour voir s’il peut pénétrer le réseau.

La différence cruciale avec une vraie cyberattaque : le pentest est fait avec le consentement légal complet de l’entreprise cible. Le pentester signe un document juridique détaillé qui décrit ce qu’il peut faire et ne pas faire.

Les trois types de pentests selon la connaissance

Black box pentesting :

• Aucune connaissance du réseau
• Perspective d’un attaquant externe
• On te donne soit un accès réseau (ou un port ethernet), soit juste le nom de l’entreprise
• Tu dois tout découvrir toi-même

Mon expérience : C’est le type de pentest le plus proche d’une vraie attaque. Le client te montre généralement les IP découvertes pour confirmer qu’elles lui appartiennent et noter celles qui sont hors périmètre.

Grey box pentesting :

• Un peu de connaissance du réseau
• Perspective d’un employé non-IT (réceptionniste, service client)
• Le client te donne les plages réseau ou IP individuelles dans le périmètre

White box pentesting :

• Accès complet à tous les systèmes, configurations, documentation
• Inclut le code source si des applications web sont dans le périmètre
• Objectif : trouver le maximum de failles possibles

Le white box est particulièrement utile pour découvrir des failles qui seraient difficiles ou impossibles à trouver en mode aveugle dans un temps raisonnable.

Les spécialisations en pentesting

Ce qui m’a surpris, c’est que les pentesters se spécialisent souvent dans un domaine spécifique :

Application pentesters :

• Testent les applications web, applications lourdes (thick-client), APIs, applications mobiles
• Maîtrisent la revue de code source
• Peuvent faire du black box ou white box (code review sécurisé)

Network/Infrastructure pentesters :

• Évaluent tous les aspects d’un réseau informatique
• Testent les équipements réseau (routeurs, firewalls), workstations, serveurs, applications
• Doivent comprendre : networking, Windows, Linux, Active Directory, et au moins un langage de scripting

Mon observation importante : Les scanners de vulnérabilités comme Nessus sont utiles mais ne remplacent pas l’expertise humaine. Ils ne sont utilisés que dans les pentests non-évasifs où l’objectif est de trouver le maximum de failles. Le scanning n’est qu’une petite partie d’un vrai pentest.

Physical pentesters :

• Exploitent les failles de sécurité physique
• Tentent d’accéder à des installations (data centers, bureaux)
• Questions typiques : Peut-on ouvrir une porte de manière non prévue ? Peut-on suivre quelqu’un dans le data center ? Peut-on ramper dans une ventilation ?

Social engineering pentesters :

• Testent l’élément humain
• Techniques : phishing, vishing (phishing par téléphone), autres arnaques
• Exemple : Se présenter à la réception en disant “oui, je travaille ici”

Quand faire un pentest

Ce qui est crucial à comprendre : les pentests sont appropriés pour les organisations avec un niveau de maturité sécurité moyen ou élevé.

Pour les débutants : La maturité sécurité mesure le développement du programme de cybersécurité d’une entreprise. Ça prend des années à construire.

Une bonne maturité sécurité inclut :

• Personnel cybersécurité qualifié
• Politiques de sécurité bien conçues et appliquées
• Standards de durcissement pour tous les types d’appareils
• Conformité réglementaire forte
• Plans de réponse aux incidents bien exécutés
• CSIRT (équipe de réponse aux incidents) expérimentée
• Processus de gestion des changements établi
• CISO (responsable de la sécurité) et CTO (responsable technique)
• Tests de sécurité fréquents sur plusieurs années
• Culture de sécurité forte

Mon observation : La culture de sécurité concerne l’attitude et les habitudes des employés envers la cybersécurité. Tout le monde, des secrétaires aux sysadmins jusqu’aux dirigeants, doit être conscient de la sécurité.

Les organisations avec une faible maturité sécurité devraient se concentrer sur les vulnerability assessments. Un pentest pourrait trouver trop de vulnérabilités et submerger le personnel chargé de la remédiation.

Avant de considérer le pentesting, il devrait y avoir un historique de vulnerability assessments et d’actions prises en réponse.

Vulnerability Assessment vs Pentest - Les différences clés

Ce qui m’a aidé à comprendre : ce sont deux évaluations complètement différentes.

Aspect	Vulnerability Assessment	Penetration Test
Approche	Checklist basée sur des standards	Simulation d’attaque réelle
Exploitation	Validation uniquement (preuve que la vulnérabilité existe)	Exploitation complète avec escalation et mouvement latéral
Techniques	Principalement automatisées (scans)	Mix de techniques manuelles et automatisées
Coût	Plus abordable	Plus coûteux, nécessite expertise spécialisée
Fréquence recommandée	Mensuelle ou trimestrielle	Annuelle ou semi-annuelle
Approprié pour	Toutes les organisations	Organisations avec maturité sécurité moyenne/élevée

Mon analyse : Les vulnerability assessments donnent une vue d’ensemble des problèmes connus. Les pentests vont plus loin en montrant comment ces problèmes peuvent être chaînés pour créer une vraie attaque.

Un pentest peut illustrer une chaîne d’attaque réelle qu’un attaquant pourrait utiliser pour accéder à l’environnement de l’organisation.

Important : Même les organisations qui font des pentests annuels doivent continuer à faire des scans de vulnérabilités internes réguliers pour identifier les nouvelles vulnérabilités dès leur publication.

Autres types d’évaluations de sécurité

Security Audits - Les audits obligatoires

La différence avec les vulnerability assessments :

• Les vulnerability assessments sont volontaires (l’organisation choisit de les faire)
• Les security audits sont obligatoires (mandatés par des agences gouvernementales ou associations industrielles)

Exemple concret : PCI-DSS

Tous les commerçants qui acceptent les cartes bancaires majeures (Visa, MasterCard, AMEX) doivent respecter la norme PCI-DSS (Payment Card Industry Data Security Standard).

Si une entreprise n’est pas conforme lors d’un audit PCI-DSS, elle risque des amendes et pourrait ne plus pouvoir accepter les paiements par carte.

Mon observation : C’est la responsabilité de l’organisation de faire des vulnerability assessments pour s’assurer d’être conforme avant un audit surprise.

Pour en savoir plus sur PCI-DSS : PCI Security Standards Council

Bug Bounties - La chasse aux bugs ouverte

Les programmes de bug bounty invitent le grand public (avec certaines restrictions) à trouver des vulnérabilités dans leurs applications.

Comment ça marche :

• Les chasseurs de bugs peuvent gagner de quelques centaines à des centaines de milliers de dollars pour leurs découvertes
• Restrictions typiques : pas de scanning automatisé
• C’est un petit prix à payer pour éviter qu’une vulnérabilité critique tombe entre de mauvaises mains

Organisations appropriées pour les bug bounties :

• Grandes entreprises avec larges bases clients
• Haute maturité sécurité
• Équipe dédiée au triage et à l’analyse des rapports de bugs
• Capable d’endurer que des externes cherchent des vulnérabilités dans leurs produits

Exemples : Microsoft et Apple sont idéales pour avoir des programmes de bug bounty à cause de leurs millions de clients et de leur maturité sécurité robuste.

Red Team Assessment - L’attaque simulée avancée

Les red teams sont composées de professionnels en sécurité offensive avec une expérience considérable en pentesting.

Caractéristiques d’une red team assessment :

• Type de pentest black box évasif
• Simule tous types d’attaques cybernétiques du point de vue d’un acteur de menace externe
• A typiquement un objectif final (atteindre un serveur critique, une base de données, etc.)
• Les évaluateurs ne rapportent que les vulnérabilités qui ont mené à l’accomplissement de l’objectif

Mon observation : Contrairement à un pentest classique qui cherche le maximum de vulnérabilités, une red team assessment est focalisée sur l’objectif et ne rapporte que ce qui était nécessaire pour l’atteindre.

Red team interne vs externe :

Si une entreprise a sa propre red team interne :

• Elle effectue des pentests plus ciblés avec une connaissance interne du réseau
• Devrait constamment être engagée dans des campagnes de red teaming
• Campagnes basées sur de nouveaux exploits découverts par des APTs (Advanced Persistent Threat groups)
• Peut cibler des types spécifiques de vulnérabilités en profondeur

Idéalement, une entreprise devrait : faire des vulnerability assessments réguliers en interne, contracter des tiers pour les pentests/red team assessments, et si possible construire une red team interne pour du grey/white box pentesting avec des paramètres spécifiques.

Purple Team Assessment - La collaboration offensive/défensive

Comprendre les couleurs :

• Red team = sécurité offensive (attaque)
• Blue team = sécurité défensive (défense)
• Purple team = rouge + bleu = collaboration

Qu’est-ce qu’une blue team ?

La blue team consiste en spécialistes de sécurité défensive :

• Travaillent souvent dans un SOC (Security Operations Center) ou CSIRT
• Ont de l’expérience en forensique numérique
• Apprennent des problèmes trouvés par la red team et travaillent à les corriger

Purple team assessment :

C’est comme une red team assessment, mais la blue team est impliquée à chaque étape.

Exemple de scénario :

“Nous devons améliorer notre conformité PCI-DSS. Alors regardons la red team pentester nos systèmes de point de vente et fournissons des retours actifs pendant leur travail.”

La blue team peut même jouer un rôle dans la conception des campagnes.

Mon analyse : C’est l’approche la plus collaborative. Les équipes offensives et défensives travaillent ensemble avec un objectif commun : améliorer la sécurité du réseau.

---

Vulnerability Assessment en profondeur

Ce qu’est vraiment un Vulnerability Assessment

Un Vulnerability Assessment vise à identifier et catégoriser les risques liés aux faiblesses de sécurité des actifs dans un environnement.

Point crucial à comprendre : Il y a peu ou pas d’exploitation manuelle pendant un vulnerability assessment. L’objectif est de comprendre et catégoriser les risques des problèmes les plus apparents sans les exploiter pour obtenir un accès supplémentaire.

Le Vulnerability Assessment fournit également des étapes de remédiation pour corriger les problèmes identifiés.

Ce qui varie selon le périmètre

Selon le périmètre de l’évaluation, j’ai appris que les clients peuvent demander différentes approches :

Option 1 : Validation minimale

• Valider autant de vulnérabilités que possible
• Effectuer une exploitation minimalement invasive
• Confirmer les résultats du scanner
• Éliminer les faux positifs

Option 2 : Rapport complet

• Rapport de toutes les découvertes identifiées par le scanner
• Sans validation manuelle supplémentaire

Comme pour toute évaluation, il est essentiel de clarifier le périmètre et l’intention du vulnerability assessment avant de commencer.

Mon observation : La gestion des vulnérabilités est vitale pour aider les organisations à identifier les points faibles de leurs actifs, comprendre le niveau de risque, et calculer et prioriser les efforts de remédiation.

Un point important que j’ai retenu : les organisations devraient toujours tester les correctifs substantiels avant de les déployer dans leur environnement pour éviter les perturbations.

Méthodologie d’un Vulnerability Assessment

Voici une méthodologie que j’ai étudiée et que la plupart des organisations peuvent suivre avec succès. Les méthodologies peuvent varier légèrement d’une organisation à l’autre, mais cette approche couvre les étapes principales.

Les 8 étapes pour effectuer un Network Vulnerability Assessment :

1. Conduire l’identification et l’analyse des risques
2. Développer des politiques de scan
3. Identifier les types de scan
4. Configurer le scan
5. Effectuer le scan
6. Évaluer les risques
7. Interpréter les résultats
8. Créer un plan de remédiation

Mon analyse : Cette méthodologie suit une progression logique : on commence par comprendre ce qu’on doit protéger, on planifie comment scanner, on exécute, puis on analyse et on agit sur les résultats.

Comprendre les termes clés

Avant d’aller plus loin, j’ai dû bien comprendre ces termes essentiels que tout professionnel IT ou Infosec devrait pouvoir expliquer clairement.

Vulnerability - La vulnérabilité

Une vulnérabilité est une faiblesse ou un bug dans l’environnement d’une organisation (applications, réseaux, infrastructure) qui ouvre la possibilité de menaces provenant d’acteurs externes.

Pour les débutants : Penser à une vulnérabilité comme une fenêtre mal fermée dans une maison. Ce n’est pas encore une effraction, mais ça crée l’opportunité pour un cambrioleur d’entrer.

Comment les vulnérabilités sont enregistrées :

Les vulnérabilités peuvent être enregistrées dans la base de données CVE (Common Vulnerability Exposure) de MITRE et reçoivent un score CVSS (Common Vulnerability Scoring System) pour déterminer leur sévérité.

Le système de scoring CVSS :

Ce système est fréquemment utilisé comme standard par les entreprises et gouvernements pour calculer des scores de sévérité précis et cohérents. Les scores aident à :

• Prioriser les ressources
• Déterminer comment répondre à une menace donnée

Les scores vont de 0 à 10 et sont calculés en utilisant ces métriques :

• Type de vecteur d’attaque : réseau, adjacent, local, physique
• Complexité de l’attaque
• Privilèges requis
• Interaction utilisateur nécessaire ou non
• Impact sur la confidentialité, l’intégrité et la disponibilité des données de l’organisation

Exemple concret : SQL Injection

L’injection SQL est considérée comme une vulnérabilité puisqu’un attaquant pourrait exploiter des requêtes pour extraire des données de la base de données d’une organisation.

Cette attaque aurait un score CVSS plus élevé si :

• Elle peut être effectuée sans authentification sur internet

Elle aurait un score plus bas si :

• L’attaquant a besoin d’un accès authentifié au réseau interne
• ET d’une authentification séparée à l’application cible

Ces types de considérations doivent être prises en compte pour toutes les vulnérabilités que nous rencontrons.

Pour en savoir plus sur le CVSS : CVSS Specification Document

Threat - La menace

Une menace est un processus qui amplifie le potentiel d’un événement adverse, comme un acteur de menace exploitant une vulnérabilité.

Mon observation : Certaines vulnérabilités soulèvent plus de préoccupations que d’autres en raison de la probabilité d’exploitation.

Facteurs qui augmentent la probabilité :

• Plus la récompense est élevée → plus l’exploitation est probable
• Plus l’exploitation est facile → plus l’exploitation est probable

Exploit - L’exploitation

Un exploit est tout code ou ressource qui peut être utilisé pour tirer parti de la faiblesse d’un actif.

Où trouver des exploits :

De nombreux exploits sont disponibles sur des plateformes open-source :

• Exploit Database
• Rapid7 Vulnerability & Exploit Database
• GitHub et GitLab

Pour les débutants : Un exploit est comme un outil spécialisé créé pour exploiter une fenêtre mal fermée spécifique. Chaque vulnérabilité peut avoir un ou plusieurs exploits.

Risk - Le risque

Le risque est la possibilité que des actifs ou des données soient endommagés ou détruits par des acteurs de menace.

Définition ISO 31000 : Le risque est l’effet de l’incertitude sur les objectifs. Un effet peut être positif (opportunité) ou négatif (menace). Pas d’objectifs, pas de risque.

Pour différencier les trois concepts :

• Risk (Risque) : quelque chose de mauvais qui pourrait arriver
• Threat (Menace) : quelque chose de mauvais qui est en train de se produire
• Vulnerability (Vulnérabilité) : des faiblesses qui pourraient mener à une menace

La formule du risque

Menace + Vulnérabilité = Risque

Les vulnérabilités, menaces et exploits jouent tous un rôle dans la mesure du niveau de risque en déterminant la probabilité et l’impact.

Exemple concret :

Une vulnérabilité qui a un code d’exploit fiable et qui est susceptible d’être utilisée pour accéder au réseau d’une organisation augmenterait considérablement le risque à cause de l’impact.

Si un attaquant avait accès au réseau interne, il pourrait potentiellement :

• Voir des documents sensibles
• Éditer des documents critiques
• Supprimer des documents essentiels aux opérations commerciales

Matrice de risque qualitative

On peut utiliser une matrice de risque qualitative pour mesurer le risque basé sur la probabilité et l’impact :

Probabilité	Impact Faible	Impact Moyen	Impact Élevé
Élevée	Risque Moyen (3)	Risque Élevé (4)	Risque Critique (5)
Moyenne	Risque Faible (2)	Risque Moyen (3)	Risque Élevé (4)
Faible	Risque Minimal (1)	Risque Faible (2)	Risque Moyen (3)

Mon analyse :

• Une vulnérabilité avec faible probabilité + faible impact = niveau de risque minimal (1)
• Une vulnérabilité avec haute probabilité + impact élevé = risque le plus élevé (5)

Les vulnérabilités avec le score le plus élevé devraient être priorisées pour la remédiation.

Asset Management - La gestion des actifs

Quand une organisation (peu importe son type, son industrie ou sa taille) doit planifier sa stratégie de cybersécurité, elle devrait commencer par créer un inventaire de ses actifs de données.

Si vous voulez protéger quelque chose, vous devez d’abord savoir ce que vous protégez !

Une fois les actifs inventoriés, on peut commencer le processus de gestion des actifs. C’est un concept clé en sécurité défensive.

Asset Inventory - L’inventaire des actifs

L’inventaire des actifs est un composant critique de la gestion des vulnérabilités. Une organisation doit comprendre quels actifs sont dans son réseau pour fournir la protection appropriée et mettre en place des défenses adaptées.

L’inventaire devrait inclure :

• Technologie de l’information (IT)
• Technologie opérationnelle (OT)
• Actifs physiques
• Logiciels
• Appareils mobiles
• Actifs de développement

Mon observation : Les organisations peuvent utiliser des outils de gestion d’actifs pour suivre leurs actifs. Ces actifs devraient avoir des classifications de données pour assurer une sécurité et des contrôles d’accès adéquats.

Application and System Inventory - L’inventaire complet

Une organisation devrait créer un inventaire complet et détaillé des actifs de données pour une gestion appropriée en sécurité défensive.

Les actifs de données incluent :

1. Toutes les données stockées sur site

• Disques durs (HDD) et SSD dans les endpoints (PC et appareils mobiles)
• HDD et SSD dans les serveurs
• Disques externes dans le réseau local
• Médias optiques (DVD, Blu-ray, CD)
• Médias flash (clés USB, cartes SD)
• Technologies legacy : disquettes, lecteurs ZIP (relique des années 1990), lecteurs à bande

Pour les débutants : “Legacy technology” désigne les anciennes technologies encore utilisées dans certaines organisations, bien qu’obsolètes.

2. Tout le stockage de données que leur fournisseur cloud possède

Les fournisseurs cloud les plus populaires :

• Amazon Web Services (AWS)
• Google Cloud Platform (GCP)
• Microsoft Azure

Ce qui m’a surpris : Parfois les réseaux d’entreprise sont multi-cloud, ce qui signifie qu’ils ont plus d’un fournisseur cloud. Chaque fournisseur cloud fournira des outils pour inventorier toutes les données stockées.

3. Toutes les données stockées dans diverses applications SaaS

Pour les débutants : SaaS signifie “Software-as-a-Service” - des logiciels accessibles via internet plutôt qu’installés localement.

Ces données sont aussi “dans le cloud” mais pourraient ne pas toutes être dans le périmètre d’un compte de fournisseur cloud d’entreprise.

Exemples de services SaaS :

• Google Drive
• Dropbox
• Microsoft Teams
• Apple iCloud
• Adobe Creative Suite
• Microsoft Office 365
• Google Docs

4. Toutes les applications nécessaires pour l’opération normale

Incluant :

• Applications déployées localement
• Applications déployées via le cloud
• Applications Software-as-a-Service

5. Tous les équipements réseau sur site

• Routeurs
• Firewalls
• Hubs
• Switches
• Systèmes IDS/IPS dédiés (détection et prévention d’intrusion)
• Systèmes DLP (prévention de perte de données)

Mon observation importante : Tous ces actifs sont très importants. Un acteur de menace ou tout autre type de risque pour n’importe lequel de ces actifs peut causer des dommages significatifs à la sécurité de l’information d’une entreprise et à sa capacité d’opérer au jour le jour.

Une organisation doit prendre son temps pour évaluer tout et être prudente pour ne pas manquer un seul actif de données, sinon elle ne pourra pas le protéger.

Maintenir l’inventaire à jour

Les organisations ajoutent ou retirent fréquemment :

• Ordinateurs
• Stockage de données
• Capacité de serveurs cloud
• Autres actifs de données

Règle critique : Chaque fois que des actifs de données sont ajoutés ou retirés, cela doit être soigneusement noté dans l’inventaire des actifs de données.

---

Standards d’évaluation

Pourquoi des standards sont nécessaires

Les penetration tests et les vulnerability assessments doivent tous deux se conformer à des standards spécifiques pour être accrédités et acceptés par les gouvernements et autorités légales.

Mon observation : Ces standards aident à garantir que l’évaluation est effectuée de manière approfondie et selon une méthode généralement acceptée. Ça augmente l’efficacité de ces évaluations et réduit la probabilité d’une attaque sur l’organisation.

Compliance Standards - Les standards de conformité

Chaque organisme de conformité réglementaire a ses propres standards de sécurité de l’information que les organisations doivent respecter pour maintenir leur accréditation.

Les grands acteurs de la conformité en sécurité de l’information :

• PCI (Payment Card Industry)
• HIPAA (Health Insurance Portability and Accountability Act)
• FISMA (Federal Information Security Management Act)
• ISO 27001 (International Organization for Standardization)

Pourquoi ces accréditations sont nécessaires

Deux raisons principales :

1. Certification tierce : Ça certifie qu’une organisation a fait évaluer son environnement par un vendeur tiers
2. Opérations commerciales : Certaines entreprises ne feront pas affaire sans accréditations spécifiques de la part d’organisations

Pour les débutants : Une accréditation est comme un certificat de qualité qui prouve qu’une entreprise respecte certains standards de sécurité. Sans ces certifications, elle peut perdre des clients ou partenaires commerciaux.

PCI DSS - Payment Card Industry Data Security Standard

Le PCI DSS est un standard couramment connu en sécurité de l’information qui implémente des exigences pour les organisations qui traitent des cartes de crédit.

Point important : Bien que ce ne soit pas une réglementation gouvernementale, les organisations qui stockent, traitent ou transmettent des données de porteurs de cartes doivent quand même implémenter les directives PCI DSS.

Exemples d’organisations concernées :

• Banques
• Magasins en ligne qui gèrent leurs propres solutions de paiement (ex : Amazon)

Exigences PCI DSS :

Les exigences incluent le scanning interne et externe des actifs.

Concept clé : Cardholder Data Environment (CDE)

Toutes les données de cartes de crédit qui sont traitées ou transmises doivent l’être dans un Cardholder Data Environment (CDE).

Caractéristiques du CDE :

• Doit être adéquatement segmenté des actifs normaux
• Environnement séparé de l’environnement régulier de l’organisation
• Protège les données des porteurs de cartes contre la compromission lors d’une attaque
• Limite l’accès interne aux données

Les 6 objectifs PCI DSS :

1. Construire et maintenir un réseau sécurisé
2. Protéger les données des porteurs de cartes
3. Maintenir un programme de gestion des vulnérabilités
4. Implémenter des mesures de contrôle d’accès fortes
5. Surveiller et tester régulièrement les réseaux
6. Maintenir une politique de sécurité de l’information

Pour plus d’informations : PCI Security Standards

HIPAA - Health Insurance Portability and Accountability Act

HIPAA est utilisé pour protéger les données des patients dans le secteur de la santé.

Ce qui m’a surpris : HIPAA ne requiert pas nécessairement des scans ou évaluations de vulnérabilités. Cependant, une évaluation des risques et une identification des vulnérabilités sont requises pour maintenir l’accréditation HIPAA.

Pour les débutants : HIPAA est la loi qui protège vos informations médicales. Votre médecin ou hôpital ne peut pas partager vos données de santé sans votre permission grâce à HIPAA.

FISMA - Federal Information Security Management Act

Le FISMA est un ensemble de standards et directives utilisés pour sauvegarder les opérations et informations gouvernementales.

Exigences FISMA :

L’acte requiert qu’une organisation fournisse :

• Documentation d’un programme de gestion des vulnérabilités
• Preuve de maintien de la disponibilité, confidentialité et intégrité appropriées des systèmes de technologie de l’information

FISMA s’applique principalement aux agences fédérales américaines et aux contractants qui travaillent avec le gouvernement.

ISO 27001 - Standard mondial de sécurité de l’information

ISO 27001 est un standard utilisé mondialement pour gérer la sécurité de l’information.

Exigences : ISO 27001 requiert que les organisations effectuent des scans externes et internes trimestriels.

Mon observation importante : Bien que la conformité soit essentielle, elle ne devrait pas piloter un programme de gestion des vulnérabilités. La gestion des vulnérabilités devrait considérer l’unicité d’un environnement et l’appétit au risque associé à une organisation.

Contexte de l’ISO :

L’International Organization for Standardization (ISO) maintient des standards techniques pour pratiquement tout ce qu’on peut imaginer. Le standard ISO 27001 traite de la sécurité de l’information.

Conformité ISO 27001 :

La conformité dépend du maintien d’un Information Security Management System (ISMS) efficace. Pour assurer la conformité, les organisations peuvent effectuer des penetration tests de manière soigneusement conçue.

Pour en savoir plus : ISO 27001 Information Security

Penetration Testing Standards

Les penetration tests ne devraient jamais être effectués sans règles ou directives.

Règles absolues pour le pentesting :

1. Périmètre défini : Il doit toujours y avoir un périmètre spécifiquement défini
2. Contrat légal signé : Le propriétaire du réseau doit avoir un contrat légal signé avec les pentesters
3. Ce qui est permis/interdit : Le contrat décrit ce qui est autorisé et ce qui ne l’est pas
4. Dommages minimaux : Le pentesting doit être conduit de manière à causer un tort minimal aux ordinateurs et réseaux de l’entreprise

Bonnes pratiques pour minimiser les dommages :

• Éviter les changements quand possible (comme changer un mot de passe de compte)
• Limiter la quantité de données retirées du réseau du client
• Exemple : Au lieu de retirer des documents sensibles d’un partage de fichiers, une capture d’écran des noms de dossiers devrait suffire pour prouver le risque

En plus du périmètre et des aspects légaux, il existe aussi divers standards de pentesting selon le type de système informatique évalué.

Voici les standards les plus courants qu’on peut utiliser en tant que pentester.

PTES - Penetration Testing Execution Standard

Le PTES peut être appliqué à tous types de penetration tests. Il décrit les phases d’un pentest et comment elles devraient être conduites.

Les 7 sections du PTES :

1. Pre-engagement Interactions (Interactions pré-engagement)
2. Intelligence Gathering (Collecte de renseignements)
3. Threat Modeling (Modélisation des menaces)
4. Vulnerability Analysis (Analyse des vulnérabilités)
5. Exploitation
6. Post Exploitation
7. Reporting (Rapport)

Mon observation : Le PTES fournit un cadre complet qui couvre tout le cycle de vie d’un pentest, de la planification initiale jusqu’au rapport final.

OSSTMM - Open Source Security Testing Methodology Manual

OSSTMM est un autre ensemble de directives que les pentesters peuvent utiliser pour s’assurer qu’ils font leur travail correctement. Il peut être utilisé aux côtés d’autres standards de pentest.

Les 5 canaux de l’OSSTMM :

1. Human Security : Les êtres humains sont sujets aux exploits de social engineering
2. Physical Security : Sécurité physique des installations
3. Wireless Communications : Incluant mais non limité à WiFi et Bluetooth
4. Telecommunications : Communications téléphoniques
5. Data Networks : Réseaux de données

Mon analyse : OSSTMM est particulièrement utile car il reconnaît que la sécurité ne concerne pas seulement les aspects techniques, mais aussi les humains et la sécurité physique.

Pour en savoir plus : OSSTMM Resources

NIST - National Institute of Standards and Technology

Le NIST est bien connu pour leur NIST Cybersecurity Framework, un système pour concevoir des politiques et procédures de réponse aux incidents.

NIST a aussi un Penetration Testing Framework.

Les 4 phases du framework NIST :

1. Planning (Planification)
2. Discovery (Découverte)
3. Attack (Attaque)
4. Reporting (Rapport)

Ce qui m’a surpris : Le framework NIST est plus simple et plus direct que le PTES, avec seulement 4 phases contre 7. Il est souvent utilisé par les organisations gouvernementales américaines.

Pour plus d’informations : NIST Cybersecurity Framework

OWASP - Open Web Application Security Project

OWASP est typiquement l’organisation de référence pour définir les standards de test et classifier les risques pour les applications web.

Pour les débutants : OWASP est une ressource incontournable pour quiconque travaille avec la sécurité des applications web. Leurs guides sont gratuits et constamment mis à jour.

OWASP maintient plusieurs standards et guides utiles :

1. Web Security Testing Guide (WSTG)

• Guide complet pour tester la sécurité des applications web
• Couvre toutes les vulnérabilités web majeures

2. Mobile Security Testing Guide (MSTG)

• Standards de test pour applications mobiles (iOS et Android)
• Méthodologie complète pour la sécurité mobile

3. Firmware Security Testing Methodology

• Méthodologie pour tester la sécurité des firmwares
• Particulièrement utile pour l’IoT (Internet of Things)

Mon observation personnelle : En tant qu’apprenti pentester, je consulte régulièrement les ressources OWASP. Leur OWASP Top 10 (liste des 10 vulnérabilités web les plus critiques) est un excellent point de départ pour comprendre les risques web.

Pour accéder aux ressources : OWASP Projects

Cours complété