D’après le Rapport Mandiant 2018, un attaquant passe en moyenne 175 jours à l’intérieur des réseaux de sa victime (en zone EMEA) avant qu’une première évidence de l’attaque soit trouvée, chiffre en augmentation par rapport à 2016 où la moyenne était de 106 jours. 56% de ces attaques ont été détectées en interne et 44% en externe.
Le Cloud et la sécurité orientée événements (Event Driven Security)
Les Etats-Unis, eux, se portent mieux avec une diminution du temps moyen qui est passé de 106 jours à 99 jours entre 2016 et 2017.
Ces statistiques montrent que le périmètre de défense traditionnel (firewalls, antivirus, etc.), bien qu’indispensable, ne semble plus être suffisant pour protéger complètement les ressources (informations, données personnelles, etc.) des entreprises.
La prévention se révèle donc indispensable, mais une réaction rapide aux événements est également critique : en effet, il devient indispensable de réduire ce nombre de 175 jours à quelques heures, voire minutes.
Comment atteindre cet objectif ?
Les fournisseurs Cloud offrent un ensemble de services qui permettent de mettre en place de manière automatisée une surveillance réactive du périmètre Cloud, en complément de la défense traditionnelle.
Ainsi, la Sécurité Orientée Événements (Event Driven Security) consiste à réagir aussi rapidement que possible aux événements dans l’infrastructure cloud liés à la sécurité.
Ceci est possible en accédant en temps réel (ou quasi temps réel) à des données fiables, relatives à l’activité du réseau et infrastructure cloud, pour y réagir de manière automatisée.
La plupart des fournisseurs Cloud mettent à disposition dans leurs services les informations et les mécanismes (APIs, interfaces) qui permettent de déclencher ces actions automatisées de surveillances de l’infrastructure.
Les principes de la sécurité Orientée Événements
Les services s’exécutent dans la couche de gestion du Cloud (Management Plane): ils sont au-delà de la portée d’une intrusion ou d’un élément du réseau compromis par une attaque. Si un serveur est compromis, feriez-vous confiance à l’antivirus qui y est installé ?
Quand un événement arrive dans l’infrastructure Cloud que l’on souhaite surveiller, le service associé déclenche du code spécifiquement écrit pour cet événement (language python parmi d’autres) en lui passant les informations associées, lambda functionschez AWS et Background functions chez Google pour ne nommer que deux fournisseurs. Ces functions sont automatiquement authentifiées dans les services, et les droits d’accès sont configurés en fonction du périmètre d’action du code.
Typiquement, le code est associé à des événements enregistrés dans le système des logs (AWS CloudWatch, CloudWatch Logs and CloudWatch Events, Google Logs), la messagerie (AWS SNS, AWS SQS, Google Messaging), les informations de télémétrie (AWS CloudTrail et Google StackDriver Logging) telles que utilisation CPU, RAM, etc.
Il est aussi possible de s’assurer de la conformité de l’implémentation de certaines règles, présentes dans les procédures de sécurité, en comparant les configurations réelles et en surveillant les changements avec ce qui a été défini dans le système de sécurité.
Par exemple, une surveillance peut être mise sur les droits d’accès pour les utilisateurs d’un groupe qu’uniquement des superutilisateurs autorisés peuvent modifier. Dès qu’un nouvel utilisateur est créé, on déclenche du code qui va vérifier que la personne qui l’a créé appartient bien au groupe autorisé (AWS Config et AWS Config Rules).
Conclusion
A l’aide de ces services et en particulier avec l’utilisation du code Serverless et son grand pouvoir de configuration, les implémentations cloud pourront mettre en place des actions automatiques en réponse à des événements dans leur infrastructure avec pour objectifs la détection d’incidents de sécurité, le renforcement des directives de sécurité, la conformité et l’audit, et finalement la diminution de la probabilité d’une attaque et/ou de son temps de détection.