Quelles sont les 5 portées PASSI ?
Le cabinet Avangarde Consulting est qualifié PASSI RGS.
Que signifient les cinq portées, et quels sont les avantages de faire appel à un prestataire ayant obtenu cette qualification ?
1. Audit Organisationnel et Physique
Il s’agit pour le prestataire d’audit, d’analyser l’organisation de la sécurité des systèmes d’information. L’objectif est de constater au travers des référentiels techniques existants chez l’audité, si les niveaux de sécurité et de conformité sont respectés. Cet exercice doit permettre l’identification des vulnérabilités organisationnelles majeures du SI audité.
Sur la partie « physique », il s’agit d’analyser le niveau de sécurité apporté sur les SI concernant la protection et les accès des locaux hébergeant les SI et les données sensibles. Par exemple, la capacité ou non à isoler et protéger l’accès aux baies de datacenter hébergeant des données sensibles (système de caméra de surveillance, porte sécurisée avec accès limité, etc.).
2. Audit de Configuration
Cette portée d’audit nécessite une préparation entre l’auditeur et l’audité. Les éléments de configuration des cibles auditées doivent d’être transmis à l’auditeur en amont de l’audit. Ces éléments peuvent être fournis sous forme de fichier de configuration ou de captures d’écran. Lors de l’audit de configuration, l’auditeur contrôle les configurations:
-
Des équipements réseau filaire ou sans fil de type switch ou routeurs,
-
Des équipements de sécurité (FireWall), en particulier les règles de filtrage, les chiffreurs, etc.
-
Des systèmes d’exploitation,
-
Des systèmes de gestion de bases de données,
-
Des services d’infrastructure,
-
Des serveurs d’applications,
-
Des postes de travail,
-
Des équipements de téléphonie,
-
Des environnements de virtualisation.
3. Audit d’Architecture
Lors de l’audit d’architecture, plusieurs points seront passés en revue. Tout d’abord, le corpus documentaire suivant doit être fourni :
- Schéma d’architectures de niveau 2 et 3 du modèle OSI (Informations qui peuvent être incluses dans les DAT – Document d’Architecture Technique),
- Matrices de flux (Firewall et tout autre qui démontre les entrées et sorties du SI),
- Règles de filtrage (segmentation et micro-segmentation),
- Configuration des équipements réseaux (routeurs, switch),
- Les interconnexions avec des réseaux tiers ou Internet (VPN, Informations qui peuvent être incluses dans les DAH – Dossier d’Architecture d’Hébergement),
- Analyses de risques,
- Les DAT, DAH, HLD, LLD et toute information liée à la cartographie du SI permettant d’identifier les risques et vulnérabilités d’un point de vue architectural.
Ensuite des entretiens seront organisés avec le personnel technique du SI audité et spécifiquement le personnel ayant des droits d’administration sur les systèmes audités.
Ces entretiens doivent permettre à l’auditeur de comprendre les éléments complémentaires qui ne seraient pas clairement définis à travers le corpus documentaire.
De plus, cela permet d’évaluer avec un niveau de détail les risques portés sur les systèmes d’information.
4. Audit de Code
L’audit de code, a pour objectif de valider le code source, la documentation, les méthodes et rapports de tests, les configurations de compilation et d’exécution. Ces informations doivent être fournies à l’auditeur dans les limites des droits dont disposent l’auditeur et l’audité. Par exemple, le niveau d’accès aux environnements de production, d’homologation et de développement.
Pour une meilleure compréhension du code source par le prestataire d’audit, des entretiens seront menés avec les développeurs ou responsables de la mise en œuvre du code source audité. De plus, tout outil automatisé spécialisé et utilisé lors de l’audit de code, apparaitra dans le rapport d’audit et sera identifié dans les livrables. L’exercice de cet audit peut également être réalisé manuellement.
Seront évalués lors de cet audit de code :
Le contexte applicatif du code- Emplacement de l’application et ses interconnexions dans un contexte d’architecture logicielle,
- Considération du type d’application, contexte métier et fonctionnel,
- Evaluation du niveau de risque de l’application,
- L’architecture logicielle du code (MVC, MVP, MVMM, etc.),
- Interactions avec les autres applications (gestion des appels entre applications et limites de cloisonnement),
- Relations avec les systèmes de gestion des BDD – Bases De Données (mutualisation ou BDD dédiée, fournir les schémas relationnels de BDD).
- Les mécanismes d’authentification – MFA, SSO, AD, etc.
- Les mécanismes cryptographiques – Respect et mise en œuvre de politiques de mots de passe, cryptage des fichiers, utilisation de coffres forts, etc.
- Gestion des utilisateurs (différenciation entre un utilisateur classique et un administrateur),
- Contrôle d’accès aux ressources,
- La conformité à des exigences de sécurité relatives à l’environnement de déploiement (production, homologation, développement),
- Fuites d’information et intrusion.
- Respect des mises à jour et de la documentation,
- Compréhension du code,
- Mise en place des bonnes pratiques et hygiène de code.
Afin de réaliser l’exercice efficacement sans perte de temps, il est nécessaire de cibler l’audit sur les parties critiques du code. Une analyse de risque de l’application auditée est nécessaire et doit prendre en considération les altérations possibles au fonctionnement du SI. Des tests visant à rechercher des vulnérabilités logicielles doivent être réalisés par l’auditeur et notamment :
- Cross-site scripting,
- Injection SQL,
- Cross-site request forgery,
- Erreurs de logique applicative,
- Débordement de tampon,
- Exécution de commandes arbitraires,
- Inclusion de fichiers (locaux ou distants).
5. Audit d’Intrusion (Pentests)
Cet audit doit permettre d’apprécier le niveau de sécurité contre l’intrusion du SI, via la réalisation de tests de pénétration (pentests). Cette phase d’audit doit être préparée en amont avec les responsables d’audit et l’auditeur. Toute action pouvant créer un déni de service se doit d’être évaluée et maîtrisée par les parties prenantes. La cible à tester doit être clairement identifiée. Un profil spécifique d’attaquant simulé doit être créé pour la réalisation des tests d’intrusion.
Tous risques et/ou vulnérabilités connus par l’audité doivent être communiqués au prestataire d’audit. Lorsqu’il s’agit de vulnérabilités connues et causant une instabilité sur la cible, voire un déni de service, l’auditeur doit avoir l’accord de l’audité pour exploiter cette faille. Si l’audité refuse l’exploitation de la vulnérabilité, il est nécessaire de justifier les raisons dans le rapport d’audit. Toute vulnérabilité non publique découverte lors de l’audit sera communiquée à l’ANSSI.
Il existe plusieurs types de tests d'intrusion :
- Méthode boîte noire : L’audité ne fournit à l’auditeur que les adresses IP et URL associées à la cible. L'auditeur procède alors à :
-L’identification de la cible par interrogation des services DNS,
-L’identification de la cible par balayage des ports ouverts,
-L’identification de la cible par la découverte d’équipements de filtrage,
-D’autres modes d’identifications de la cible portées à la main de l’auditeur.
- Méthode boîte grise : L’audité ne fournit à l’auditeur que les connaissances d’un utilisateur standard du SI (authentification légitime, poste de travail « standard », etc.) L’auditeur procède alors à :
-Des tests de modification de privilèges afin d’apprécier le niveau de sécurité des différents rôles et droits d’accès (RBAC, etc.).
- Méthode boîte blanche : L’audité fournit à l’auditeur des informations techniques et un contact technique lié à la cible (architecture, code source, contacts téléphoniques, identifiants, etc.) L’auditeur procède alors à :
- L’analyse des informations et la réalisation des tests d’intrusion à la main de l’auditeur.
Ces 5 portées permettent à l’audité d’avoir une vision complète de la sécurité du SI. L’audité doit à l’issue de cet audit, remédier ou accepter les risques ou vulnérabilités identifiés.
Contactez directement nos consultants cyber avec le formulaire plus bas.
Revenir à la page principale du blog ici