Temps de lecture : 12 minutes

Make Love, Not War. Si le mois de février est traditionnellement celui de la fête des amoureux, cette année, il aura tragiquement été aussi le témoin de l’invasion de l’Ukraine par la Russie. Cette offensive s’accompagne d’un renforcement d’une cyberactivité hostile de la Russie contre l’Ukraine, soulevant des inquiétudes sur le risque d’une cyberguerre généralisée. A ce jour (26/02/2022), l’ANSSI n’a observé aucun impact sur les organisations françaises.

Néanmoins, lorsque l’on a eu vent au moins une fois des effets d’une attaque ransomware, on tombe vite d’accord sur l’adage “mieux vaut prévenir que guérir”, n’est-ce pas ?

Dans cette édition #6 de la revue de presse Sécurité, nous vous proposons quelques articles qui ont attiré notre attention, en lien avec la sécurité sur le Cloud.

Nouveaux services AWS sécurité

Dans ce contexte de tensions internationales, une passe sur les configurations des ressources dans les infrastructures cloud peut être salvatrice. Alors débutons par un rappel des principaux nouveaux services AWS côté sécurité qui sont sortis en 2021.

Si vous êtes passés à côté du re:Inforce 2021 et autres annonces au fil de l’eau, voici la première partie d’un récapitulatif de ces nouveaux services sur le blog d’AWS.

Au programme : focus sur Amazon GuardDuty, Amazon Inspector, AWS Security Hub, Amazon Macie, Amazon Detective, AWS Key Management Service (KMS), AWS Secrets Manager et Amazon CodeGuru.

Je vous encourage vivement à avoir dans vos équipes des ingénieurs qui les connaissent et savent les utiliser avec pertinence. Stay tuned pour la partie 2.

Avez-vous remarqué qu’il n’y a pas de mention d’AWS IAM dans cette liste ? Si cela vous attriste, peut-être que vous pourrez vous réconforter avec ces conseils sur IAM issus d’une discussion entre Stephen Kuenzli et Andreas Wittig sur cloudonaut.io, au format texte, vidéo et/ou podcast. Certaines de ces suggestions vous paraîtront (je l’espère !) familières, mais deux précautions valent mieux qu’une : c’est comme le MFA :).

En parlant de MFA, voici un guide du gouvernement qui date d’octobre 2021 sur les moyens et processus d’authentification, et qui, au-delà des 42 recommandations proposées relatives à l’authent’, est agréable à consulter sur la forme. Pro’ tip, vous avez le sommaire des recommandations page 43.

Le guide des recommandations relatives à l’authentification multifacteur et aux mots de passe approuve ce message.

Gestion des secrets

Si l’on (je) insiste tellement sur les recommandations sur l’authentification, c’est bien parce que la gestion des secrets reste cruciale dans le département de la sécurité.

Si vous n’en êtes pas convaincus après la lecture du guide ci-dessus, peut-être le serez-vous après avoir lu la liste de post-mortems sur ce repo git. Celui-ci répertorie les incidents de sécurité publiquement révélés sur des infrastructures de clients AWS dont l’origine est connue.

Comptez le nombre de fois où il y a “credentials” ou “keys” dans la colonne “Root Cause”. Vous apprécierez également le lien vers les détails de l’histoire de l’incident qui amènent du contexte et du recul.

Les secrets, il faut croire que c’est un hot topic, en particulier d’après cet article de blog AWS. Voici des recommandations, des scénarios, des questionnements, des éléments à prendre en compte…pour tokeniser et éventuellement de-tokeniser des données sensibles. Dans la pratique, la tokenisation peut être inclue dans vos stratégies de data protection et gestions des secrets afin d’en assurer la confidentialité et de réduire l’étendue de vos audits.

Transition audit : je vous invite à consulter ce repo git qui regroupe un nombre relativement impressionnant de guides, bonnes pratiques, checklists, benchmarks et autres ressources pour vérifier et consolider les configurations de vos ressources, vos infras, OS, outils, etc. WIP : n’hésitez pas à y contribuer si le cœur vous en dit.

APIs

Tant qu’on est sur le front des configurations de ressources, quelles sont celles de vos APIs ? Voici 10 points à contrôler pour la sécurité de vos APIs, détaillés dans cet article du journaldunet :

1. Vérifier les autorisations au niveau de chaque objet
2. Soigner l’authentification utilisateur
3. Sélectionner les données à afficher
4. Limiter les ressources et le débit
5. Modérer la granularité des accès
6. Éviter les affectations de masse
7. Vérifier la configuration de la sécurité
8. Anticiper les injections de code
9. Bien gérer et inventorier ses actifs
10. Mettre en place une gestion des logs efficace

Toujours dans la série des suggestions pour renforcer la sécurité, je vous propose une comparaison de 4 outils d’analyse statique (scans) de code Terraform à intégrer dans des pipelines CI/CD. Si vous voulez vous faire votre propre idée sur les critères choisis et conclusions auxquelles les auteurs ont abouti, c’est par ici sur revolgy.com.

Enfin, voici un bel article de blog d’AWS sur les best practices pour l’implémentation de SCP (Service Control Policies) à mettre en place dans une AWS Organizations multi-comptes (ça existe les AWS Organizations mono-compte ? :)). Le cas d’étude est celui d’un client dans l’industrie de la finance.

Suggestion de structure d’OUs pour un client AWS dans l’industrie de la finance

Protection des données

Changement de sujet ou presque, on passe plutôt du côté confidentialité et protection des données, avec le Québec qui se dote d’un ministère de la Cybersécurité et du Numérique, comme rapporté dans usine-digitale. Cet événement souligne l’importance de la sécurité à l’heure de la transition numérique, et n’est pour moi pas sans rappeler la remontée de la sécurité dans les processus #DevSecOps. On ne vérifie pas la sécurité à la fin du développement, on l’inclut au plus tôt dans le design.

A ce jour et à ma connaissance, un tel ministère n’est pas prévu en France.

Et dans notre beau pays cocorico, nous dit lemondeinformatique.fr, nous avons un plan d’action pour une souveraineté numérique européenne : “La France injectera 300 millions d’euros dans le PIIEC (projet important d’intérêt européen commun) sur le cloud et 12 États membres participeront également à ce PIIEC”, dixit Bruno Le Maire. L’opération cloud souverain de confiance se poursuit : la suite au prochain épisode.

On reste côté cloud et Europe, toujours dans lemondeinformatique.fr, la CNIL va s’assurer que le recours au cloud ne vienne pas violer le RGPD en expatriant des données personnelles en dehors de l’UE. Sur le même thème, l’Europe a décidé d’aller un peu plus loin, nous partage huntonprivacyblog, en entamant l’élaboration d’un Data Act pour harmoniser les règles sur l’accès et l’usage équitable des données générées en Europe.

Entre nous, en plus de la louable initiative de la CNIL et de l’Europe, on peut aussi déjà commencer par revérifier que l’on n’expose pas soi-même nos données, personnelles ou pas, en Europe ou ailleurs.

En effet, dans ce long article de propublica, Cezary Podkul résume à quel point de nombreuses données sensibles sont exposées sur internet, notamment à travers des cas connus de leaks. Il raconte aussi l’histoire d’un ancien Hacker, Ngô Minh Hiếu, qui a commencé à collecter et vendre des données parce qu’il le pouvait, tout simplement. Le skill set du hacker débutant ? Une connexion internet, une capacité à chercher sur Google et à regarder des vidéos youtube, tellement il y a d’outils à disposition, et que de nombreux stockages de données en ligne sont en mode open bar.

Alors, est-ce que vos DBs sont bien dans des subnets privés ? La gestion de vos identités et accès est-elle bien documentée et auditée ? Vos buckets S3 sont-ils (aïe) publics ?

On peut avoir l’impression que c’est le B-A BA de la sécurité. Oui, ça l’est. Et en même temps, cela reste une des raisons principales pour lesquelles des données sensibles se retrouvent leakées sur la toile. Cela n’arrive malheureusement pas qu’aux autres.

L’humain, toujours l’humain…

Pourquoi observe-t-on encore tellement de configurations vulnérables qui amènent à des incidents de sécurité ? L’humain au cœur des enjeux, avec un manque de formation et de sensibilisation ?

Il y a fort à parier qu’un grand nombre d’entreprises en aient conscience. Certainement en partie motivées par le covid et ses conséquences, de nombreuses fusions et acquisitions (M&A) d’entreprises spécialisées dans la sécurité du cloud ont été observées en 2021 pour des sommes impliquant des centaines de millions voire des milliards de dollars : « In terms of field of expertise, many M&A deals in 2021 involved governance, risk management and compliance (GRC), managed security services provider (MSSP), network security, identity, and cloud security firms. », comme rapporté par Eduard Kovacs dans cet article de securityweek.com.

Autre indicateur clé, la cybersécu’, c’est tendance, et ça recrute : voyez les 5 profils les plus recherchés en France pour faire face à la multiplication des cyberattaques, dans cet article de silicon.fr, d’après le cabinet de recrutement Robert Half.

#PubRecrutementRevolve nous recrutons d’ailleurs des cloud security architects et des consultants gouvernance sécurité cloud, entre autres profils, mais chuuut, ne dites pas que je vous l’ai dit…et si vous le dites quand même, et bien mentionnez-moi, ça me fera une cooptation.

Un classique dont je ne me lasse pas.

Policies

En lien avec les buckets S3 publics, je vous partage une pépite que j’ai trouvée funky : AWS Zelkova, qui connait ? Certes, Zelkova est le nom d’un genre d’arbres de la famille des Ulmaceae. Mais c’est aussi un service AWS, comme présenté par Arnaud Alcabez, qui permet de faire du raisonnement automatique (fancy math) pour valider une policy en fonction de ses conséquences.

Si le sujet vous intéresse, rendez-vous sur ce blog ! En voici un extrait :

At AWS, we focus on achieving security at scale to diminish risks to your business. Fundamental to this approach is ensuring your policies are configured in a way that helps protect your data, and the Automated Reasoning Group (ARG), an advanced innovation team at AWS, is using automated reasoning to do it.

What is automated reasoning, you ask? It’s a method of formal verification that automatically generates and checks mathematical proofs which help to prove the correctness of systems; that is, fancy math that proves things are working as expected. If you want a deeper understanding of automated reasoning, check out this re:Invent session. While the applications of this methodology are vast, in this post I’ll explore one specific aspect: analyzing policies using an internal Amazon service named Zelkova.

Fun fact, dans la console AWS, si vous pouvez voir si vos buckets S3 sont publics ou non, c’est grâce à AWS Zelkova.

Enfin, sur un versant plus connecté avec les individus et la sécurité, voici un fait divers peut-être pas si divers que ça, que cela soit en ce mois de mars ou depuis l’invasion Russe en Ukraine.

Hack3rz

Dans cet article de wired.com, Andy Greenberg raconte comment des hackers nords-coréens ont attaqué et tenté de voler des outils de hack d’un américain indépendant. Ce dernier, surnommé P4x, a alors lui-même contre-attaqué en affectant le trafic entrant sur le réseau de la Corée du Nord et en provoquant des pannes de services à l’échelle du pays.

L’histoire peut faire sourire lorsque l’on contemple la prouesse d’une seule personne en pyjama face à un état qui bafoue les droits de l’homme, mais elle met également en lumière d’autres questions.

Quid de la responsabilité des services gouvernementaux (le FBI en l’occurrence) sur la protection des citoyens, P4x déclarant qu’il n’a reçu aucun soutien de leur part malgré une prise de contact de leur part ? Dans quelle mesure P4x a-t-il pu lui-même perturber les activités secrètes d’un gouvernement opposé à la Corée du Nord ?

En tout cas, si cette cause vous parle, vous pouvez rejoindre le FUNK Project établi par P4x, qui visent à fédérer ceux qui veulent lutter contre les activités malicieuses de la Corée du Nord.

Uniforme neuf de hacker indépendant.

Et si vous êtes un white hat invétéré, vous pouvez aussi choisir une voie à la mode, et peut-être plus opportuniste. Voyez plutôt dans cet article de 01net.com, qui mentionne un rapport de recherche qui revient aux origines de la recherche de failles de sécurité. Ce document fait le constat que l’esprit libertaire d’antan a été remplacé par une “uberisation” du hacking : désormais, les géants de la tech’ paient pour la découverte des failles de leurs produits, et en retirent ainsi un bénéfice majeur aisé.

Cet article, que j’ai beaucoup apprécié au demeurant, est un peu l’histoire de la culture du hack et l’avènement des programmes bug bounty : la transformation des hackers anarchistes désormais au service des grandes entreprises.

Cyberassurance

Dans ces programmes, les grandes entreprises ont tout à y gagner, et par définition, on peut facilement déterminer qu’elles ne font pas partie des “60% des PME victimes d’une cyberattaque [qui] mettent […] la clé sous la porte dans les 18 mois qui suivent.”, selon Stéphane Blanc, président d’Antemeta, un fournisseur de cloud et de solutions de sécurité, dont les propos sont rapportés dans usine-digitale.fr.

Dans cet article, on découvre que les entreprises ont un problème pour trouver des cyberassurances, car celles-ci ne sont notamment plus rentables pour les assureurs.

Une autre explication serait que les assureurs arrêteraient de proposer des cyberassurances au nom de la lutte contre les ransomwares, comme affirmé ici dans cet article de BFM par Régis Lemarchand de General, qui rejoint Axa dans les assureurs qui ne couvrent plus les cyberattaques.

Et pour conclure…

Et pour finir sur le volet centré humain, voici une analogie de Keith Ibarguen dans securityweek, avec le système de gestion des patients de la Mayo Clinic (quelqu’un pour faire une blague sur le nom ? ;-)). Keith Ibarguen évoque le mantra de cette clinique Think Big, Start Small, Move Fast, en rappelant que comme tout mantra, il s’agit davantage d’une guideline plutôt que d’une recette procédurière à appliquer sans dérogation (cf. kanjis ci-dessous).

En résumé, penser grand/gros/large facilite la couverture d’un large domaine et par ce biais, de pouvoir capitaliser, réutiliser et standardiser l’utilisation de certains produits de sécurité dans une entreprise ; commencer petit nécessite d’apprendre à itérer, en faisant des petits pas, et permet d’éviter l’inhibition liée à la crainte de la trop grande tâche. L’auteur ne le dit pas, mais je glisse ici que dans start small, il y a start. Par expérience, attention à l’excès de réflexion qui nuit à l’action : dans certaines équipes, se lancer peut déjà être un challenge en soi. Enfin, bouger vite, c’est faire attention au choix des métriques sur lesquelles on indexe la vitesse. Si l’on a la tête dans le guidon à vélo et que l’on regarde le sol, on aura l’impression d’aller plus vite que si on lève la tête pour regarder droit devant soi. L’auteur encourage à aller vite par rapport aux objectifs globaux.

Avec la légende, c’est plus facile : Shu Ha Ri

Et pour finir, si la lecture, ce n’est pas votre tasse de thé, mais que vous êtes parvenus jusqu’à la fin de cet article, bravo : voici une sélection de 9 TED Talks sur la cybersécurité. Je suis prêt à parier qu’il y en aura bien un dont la description vous fera de l’œil, puis de l’oreille.

Contributions et remerciements : Christine Grassi, David Dupin, Julien Lemarchal, Régis Brion, Erwan Simon