Il ne se passe plus de semaine sans entendre parler de cyberattaques ayant impacté des organisations de toutes tailles.
Les compagnies d’assurance ne sont évidemment pas épargnées. La menace pouvant survenir via l’intermédiaire du maillon faible (comme par exemple une filiale récemment acquise), les comités d’Audit, des Risques et ORSA1 doivent être encore plus vigilants en s’assurant que l’intégration d’autres sociétés dans leur réseau n’induise pas de risques non maîtrisés.
La réalisation d’un audit de sécurité informatique de filiale devient nécessaire avec comme enjeux, la protection de cette dernière contre le risque d’indisponibilité du Système d’information (SI), d’accès non autorisés (intrusions), de perte, d’altération ou de divulgation d’informations, pour n’en citer que quelques-uns.
Cette étude peut être menée en tenant compte des différentes interactions avec la maison-mère mais également avec les assureurs partenaires.
- L’audit peut porter sur les thématiques de la fonction informatique de la filiale (liste non exhaustive s’appuyant sur des référentiels communément admis) :
- L’existence et la pertinence de la politique de sécurité SI au regard de la stratégie et des besoins de la filiale et du groupe,
- La gouvernance de la sécurité des SI (rôle et responsabilité du conseil d’administration, de la direction générale, de la DSI, du management opérationnel),
- L’efficacité des tests de sécurité et la pertinence des indicateurs,
- Les canaux de reporting et les suites données aux constats de vulnérabilité,
- L’efficience des systèmes de sécurité (l’adéquation des moyens de détection et de protection avec les enjeux métier et la valeur de l’information),
- La gestion de crise en cas d’incident de sécurité,
- Le plan de continuité de l’activité (partie technique).
Différentes activités d’audit technique de sécurité peuvent intégrer l’audit afin d’obtenir une cartographie plus précise de la situation. Par exemple :
- Le test d’intrusion : son principe est de découvrir des vulnérabilités dans le système d’information audité, et de vérifier leur exploitabilité et leur impact dans les conditions réelles d’une attaque du système d’information à la place d’un attaquant potentiel. Cette activité peut être réalisée soit depuis l’extérieur du système d’information audité (notamment depuis Internet), soit depuis l’intérieur.
- L’audit de configuration : il a pour vocation de vérifier la mise en œuvre de pratiques de sécurité conformes à l’état de l’art et aux exigences et règles internes de la structure auditée en matière de configuration des dispositifs matériels et logiciels déployés dans un système d’information. Ces dispositifs peuvent être des équipements réseau, des systèmes d’exploitation, des applications ou des produits de sécurité.
- L’audit de code source : il consiste à analyser tout ou partie de code source ou des conditions de compilation d’une application dans le but d’y découvrir des vulnérabilités liées à de mauvaises pratiques de programmation, ou des erreurs de logique pouvant avoir un impact en matière de sécurité.
- L’audit d’architecture : il permet de vérifier la conformité des pratiques de sécurité relatives au choix, au positionnement et à la mise en œuvre des dispositifs matériels et logiciels déployés dans un système d’information à l’état de l’art, et aux exigences et règles internes de l’entité auditée. L’audit peut être étendu aux interconnexions avec des réseaux tiers, comme Internet.
Nos experts sectoriels peuvent accompagner les compagnies d’assurance dans l’évaluation du niveau de sécurité des filiales et maisons-mères, en combinant différentes expertises stratégiques, tactiques et opérationnelles.
Abdel Farid ALE, Directeur Cybersécurité au sein du Département PEPS-FS de Grant Thornton.
1 ORSA Own Risk and Solvency Assessment
