Équipes cyber 

Extrait d'une revue mensuelle entre FinOps et SOC :

« Votre ferme de 10 serveurs a 1000€/mois chacun juste pour traiter des logs, est-ce vraiment nécessaire ?  
« Il y a 3 ans de logs réseaux qui trainent sur des SSD. Vous comptez vous en servir un jour ? »

Le FinOps dans sa mission de contrôle/réduction des coûts d’infrastructure va souvent être en opposition avec les équipes en charge de la cybersécurité (SOC, gouvernance) qui cherchent à sécuriser l’entreprise à n’importe quel prix. Cet article a pour but de présenter certains points de friction existant mais aussi de montrer ce que peut apporter la démarche FinOps à la démarche cyber. Les exemples seront principalement basés sur Azure mais s’applique de la même manière à AWS ou GCP.

Le FinOps dans sa mission de contrôle/réduction des coûts d’infrastructure va souvent être en opposition avec les équipes en charges de la cybersécurité (SOC, gouvernance) qui cherchent à sécuriser l’entreprise à n’importe quel prix. 
Cet article a pour but de présenter certains points de friction existant mais aussi de montrer ce que peut apporter la démarche finops à la démarche cyber. Les exemples seront principalement basés sur Azure mais s’appliquent de la même manière à AWS ou GCP.

Points de friction 

L'activation de fonctionnalités 

La plupart des entreprises vont demander à leurs équipes cyber de produire des bonnes pratiques pour l’utilisation de chaque service des clouders (il faut activer tel configuration, ce paramètre est interdit car non conforme à la politique de sécurité, …). Souvent vus du seul point de vue sécurité, ces guides vont activer toutes les fonctionnalités possibles et imaginables pour peu qu’elles augmentent la sécurité de l’infrastructure. Par exemple, AWS QuickSight (service de BI) propose 2 versions, standard et entreprise, qui vont délivrer presque les mêmes fonctionnalités métiers. La version entreprise va, elle, rendre possible l’accès privé au niveau réseau et améliorer l’intégration AD entre autres. Sans surprise, cette version est plus chère. La sécurité va donc interdire le déploiement de la version standard. C’est logique et cohérent mais dans l’analyse, le ratio risque sécurité/coût n’a pas été vu/traité. L’apport de sécurité par la version entreprise justifie t’il son surcoût ?

Les logs

Outils majeurs des équipes de sécurité, les logs seront les prémices d’une attaque ou la seule trace laissée par un attaquant. Sur Azure, nous allons retrouver différents types de logs souvent incorporés dans Sentinel :
 

• Log AAD (log les connexions des utilisateurs)
• Log Azure Activity (log les activités sur le portail/API/CLI Azure au niveau du control plane)
• Diagnostic log (propre à chaque type de ressource, mais on retrouve souvent les logs d’audit qui peuvent toucher le data plane)
• Log AD (remontée des logs de l’AD on-premise)
• Log des solutions M365 (Defender, Purview, O365….)
• Log network watcher (log tous les échanges réseau sur Azure)

L’inclusion des logs AD dans Sentinel permet d’avoir un contrôle inégalé sur son Active Directory mais on peut être également noyé sous le nombre d’évènements. L’infrastructure AD est une des plus verbeuses qui soit. Il est vital de ne pas capturer tous les logs/évènements mais de filtrer sur les évènements correspondants à des incidents de sécurité : Azure Monitor Agent (remplaçant du log analytic agent) inclut cette fonctionnalité, il faut utiliser des DCR (Data Collection Rules) pour ne capturer que des évènements pertinents (basé sur des eventid connus comme problématique (4766 par exemple) ou sur un niveau de criticité).
À noter l’apparition de l’agent Defender for Identity qui ne remonte pas directement des events mais va reconnaitre des comportements (golden ticket…) et les remonter. Cela va permettre de réduire les coûts de stockage mais c’est une licence supplémentaire.

Les logs network watchers peuvent également être particulièrement volumineux, si toutes les fonctionnalités sont activées en permanence et partout.

• Traffics analytics permet que ses logs soient plus facilement lisibles
• La version des logs, la version 2 contient des statistiques de session des flux (octets et paquets) donc plus volumineux
• La rétention (qui peut être infini)

Sur des grands environnements on peut très facilement arriver à des téraoctets de données qui peuvent dormir pendant très longtemps et être sous-utilisées. Traffic Analytics est extrêmement puissant et permet de répondre facilement aux questions suivantes :
- Quels hôtes subissent le plus de blocage ? (statistiques du trafic autorisé/bloqué)
- Où la bande-passante de nos liaisons (SKU) est-elle adaptée ?

L’équipe FinOps peut et doit challenger le paramétrage des équipes Sécurité pour obtenir un paramétrage pertinent et rentable pour l’organisation (la rétention peut être plus faible sur les environnements non production/critiques…).

Le risque avec une sécurité open-bar (activant toutes les fonctionnalités) est qu'au bout d'un moment, le business ne veuille plus payer la facture et coupe de manière brutale des outils très pertinents pour la sécurité de l’organisation.

Symbiose entre les équipes FinOps et Cybersécurité

La réduction de la surface d'attaque

Une des premières missions des équipes FinOps va être la traque et la suppression des ressources inutilisées mais facturées par le clouder. Ce sont autant de possibles portes d’entrée (IP publiques non relâchées et toujours attachées à une VM de dev reliée au réseau de l’entreprise) ou de relais pour des mouvements latéraux (function app) qui sont supprimés.

Les équipes Sécurité vont pouvoir remarquer ces ressources (car elles ne sont plus maintenues à jour par exemple) mais très souvent ils ont plus de difficultés à être écoutées par les ops métiers (« on ne sait jamais cela pourrait toujours servir »). L’équipe FinOps, s’adressant directement au business avec des arguments précis et factuels (« cette ressource, c’est 500€/mois de jeter par la fenêtre ») entraine une réaction des équipes business qui vont s'assurer des suppressions le plus rapidement possible, à la différence d’un hypothétique risque de sécurité qui ne les motivera pas forcément à agir.

IMAGE SCHEMA BLEU

Une autre tâche va être la mise en place d’automatismes pour l’arrêt/démarrage des ressources durant nuit/weekend/jours fériés (60-70% d’économie en moyenne par rapport à une ressource toujours disponible) pour les environnements de développement/recette…

Cela permet de diminuer le temps de vulnérabilité de ces ressources et de faciliter le travail des équipes cyber en limitant les évènements/logs sur les périodes non-ouvrées durant lesquelles il y a généralement moins de personnel de sécurité pour les traiter.

Diminuer les cibles potentielles de vol de données

Une autre mission va être de diminuer les coûts de stockage (20-40% de la facture clouder) soit en demandant la suppression des données (qui sont en doublon ou dont la durée de rétention est excédée ou non pertinente) ou en les faisant passer sur du stockage moins performant mais moins cher (très efficace pour les données peu accédées). Les clouders proposent des automatismes pour gérer le cycle de vie des données, cela peut aider vos équipes de compliance pour le respect des durées de rétention : document légaux, PII…

Changer de niveau de stockage peut être efficace mais à condition de bien maitriser la consommation des données. Passer en archive peut diviser votre facture par 10 ou la multiplier par 2000 suivant votre usage.

Azure BackUp est la solution de sauvegarde des ressources de type VM. Dans son fonctionnement, si 1 VM a été sauvegardée une fois, il n’effacera jamais son dernier snapshot et le conservera pour toujours, même si la VM a été supprimée. Cela peut représenter un risque de sécurité (données gardées au-delà de leur durée de rétention, restauration par admin malveillant…). Heureusement, Azure facture le stockage des sauvegardes et l’équipe FinOps mettra en place un automatisme de purge pour s’assurer que seulement les snapshots pertinents soient conservés, limitant ainsi le risque de fuite de données.

Ces actions des FinOps permettent aux équipes Cyber de protéger uniquement des ressources pertinentes et d’en limiter le nombre.

IMAGE BACKUP INSTANCES 

Tableau de bord d’Azure BackUp Center, le surcout peut rapidement atteindre plusieurs milliers d’€/mois

Diminuer les ressources disponibles sur un système compromis

Une autre mission va être de s’assurer que les ressources, notamment de type compute (VM, app service, ASE), ont juste la taille nécessaire et suffisante pour effectuer leurs tâches avec des performances acceptables. En cas de compromission du système par un ransomware, cela permet d'avoir moins de puissance de calcul à disposition pour ralentir le chiffrement de vos données.

Arrêter des éléments de production en période non-ouvrée peut être risqué (Microsoft ne s’engage pas sur un redémarrage immédiat de la ressource, cf début du 1^er confinement où la demande de ressources cloud était telle que Microsoft ne pouvait pas honorer les démarrages). Une autre solution peut être de les retailler à la volée (pour les ressources PaaS) via une function app.

Identifier les propriétaires des ressources

Une autre activité des FinOps va être de s’assurer que chaque ressource a un owner pour pouvoir lui refacturer le coût de sa ressource, notamment via les tags. Cela facilitera le travail des équipes Cyber qui pourront rapidement identifier un contact en cas d’incident sur une ressource.

Conclusion

Piloter par les coûts

Pour l’ISO/CEI 2700, la sécurité informatique consiste à garantir que les ressources matérielles ou logicielles d'une organisation soient uniquement utilisées dans le cadre prévu.

La sécurité informatique consiste également à garantir des coûts supérieurs plus élevés pour l’attaquant pour exécuter avec succès son attaque, que le gain envisageable. Ce que l’on peut transformer en notre défense ne doit pas coûter plus cher que ce que l’on doit protéger.

D’une approche par les risques, on passe à une approche par les coûts. L’environnement cloud public permet d’avoir une estimation de la facturation immédiatement, ou après une période de test de chacun des paramétrages. Les RSSI ont pu faire passer des budgets plus facilement sur les dernières années car les CODIR ont la menace cyber en priorité. Une tendance qui risque de ne pas durer, les RSSI vont donc devoir prouver qu’ils dépensent à bon escient.

La plupart des projets de compliance GDPR ont pu passer facilement avec la menace d’amende de 4% du CA. Il faut arriver à présenter les projets cyber avec le même type d’argument afin qu’ils soient budgétisés !

Travailler avec les équipes cybersécurité

À noter que nous nous retrouvons face à une nouvelle opportunité pour des attaquants : la modification de la configuration des ressources cloud pour en augmenter sa facture afin de nuire à l’entreprise. Les outils de contrôles des configurations, une gestion rigoureuse de l’IAM et la surveillance des opérations sont on ne peut plus d’actualités…

Les automatismes mis en place par les équipes finops (arrêt/démarrage, purge…) sont vitaux et peuvent représenter des cibles de choix pour un attaquant voulant déstabiliser le fonctionnement de la société (des centaines de dev peuvent perdre une matinée si leurs machines de travail ne sont pas démarrées). Ils doivent être revus par les équipes cyber et surveillés en tant que telle.

Les tags vont être très importants pour les finops, ils vont porter les infos de propriétaires, BU, type d’environnement, plage de fonctionnement (pour l’automatisme d’arrêt/démarrage). Un soin particulier doit être mis sur la gestion des droits pour modifier ces tags. (Azure ne permet pas encore de donner des droits sur un seul type de tag au contraire d’AWS). La stratégie de tagging (quel tag utiliser, qui les modifie) doit être discutée et approuvée par toutes les parties-prenantes de l’entreprise.

Équilibre à trouver

À noter que dans la discussion coût/sécurité va se rajouter la résilience avec les SRE (Site Reliability Engineering), les organisations doivent fournir à leurs équipes métiers un guide/cadre d’utilisation pour les différents services des clouders couvrant ces 3 aspects (et les mettre à jour régulièrement).

La capacité des équipes finops à challenger de façon pertinente les équipes cyber sur leur coût sera primordiale pour assurer le soutien de la direction aux initiatives cyber sur la durée. Le DevSecOps doit évoluer vers sa forme finale : le DevSecFinOps

Matthieu GAILLARD-MIDOL
Practice Leader DevSecOps, Squad