Construire un programme de sécurité à partir de zéro

Se faire embaucher comme première personne en charge de la sécurité dans une entreprise est une forme particulière de chaos. Il n'y a pas de queue de tickets, pas d'outils établis, et généralement pas de ligne budgétaire qui vous attend. Ce qui suit est une carte approximative de comment ces premiers 90-180 jours se déroulent généralement, et ce qui fait réellement la différence par rapport à ce qui se sent simplement productif.

Ce que « rien » veut généralement dire

Quand les gens disent qu'une entreprise n'a pas de fonction de sécurité, ils veulent rarement dire zéro contrôles. Ils veulent dire pas de propriétaire dédié. L'équipe d'engineering a probablement activé quelques politiques AWS IAM basiques, l'IT a un antivirus déployé via un outil MDM, et quelqu'un en finance a des opinions sur SOC 2 parce qu'un client a posé la question. Votre premier travail est l'inventaire, pas l'implémentation. Avant d'écrire une seule politique, découvrez ce qui tourne déjà : les comptes cloud (et combien que personne ne se souvient d'avoir créés), les outils SaaS avec accès administrateur au code source, et s'il existe une source unique de vérité pour le départ des employés. Un tableur convient pour cela. Une plateforme GRC n'est pas une priorité pour le moment.

Les 30 premiers jours : la visibilité plutôt que le contrôle

Résistez à l'envie d'écrire une politique d'utilisation acceptable à la première semaine. Personne ne la lira et elle n'arrêtera pas les risques réels. À la place, obtenez la visibilité sur trois choses :

• Identité : extrayez une liste d'utilisateurs complète de votre fournisseur d'identité (Okta, Google Workspace, Azure AD) et croisez-la avec la liste des employés actifs des RH. Vous trouverez des comptes fantômes.
• Empreinte cloud : lancez quelque chose comme aws organizations list-accounts si vous êtes sur AWS, ou consultez l'Asset Inventory de GCP, pour voir combien d'environnements existent par rapport à combien quelqu'un peut nommer de mémoire.
• Exposition du code et des secrets : lancez gitleaks detect ou trufflehog filesystem . sur vos dépôts principaux. Trouver une clé API en dur dans l'historique des commits d'il y a deux ans est quasi garanti et c'est un moyen rapide de démontrer votre valeur.

Documentez les résultats, mais ne transformez pas cela en un rapport de 40 pages que personne n'ouvre. Un résumé des risques d'une page avec cinq points est lu par un CTO. Un long PDF ne l'est pas.

Choisir vos trois premiers contrôles

Sans effectifs et sans budget d'outils, vous ne pouvez pas tout faire à la fois. L'ordre des opérations qui tend à fonctionner :

1. L'authentification multifacteur partout où elle n'existe pas déjà, en commençant par le fournisseur d'identité, puis GitHub/GitLab, puis les consoles cloud. Cela seul ferme le chemin de prise de contrôle de compte le plus courant.
2. Une journalisation centralisée pour les événements cloud et d'authentification. Même un niveau gratuit d'un outil semblable à un SIEM, ou simplement envoyer les journaux CloudTrail/GCP audit à un bucket avec rétention, c'est mieux que rien quand un incident se produit.
3. Un plan de réponse aux incidents écrit et court, même s'il ne fait que deux pages : qui être appelé, qui parle aux clients, qui a le pouvoir d'arrêter quelque chose. Personne ne pense à construire cela avant le jour où ils en ont besoin, et à ce moment-là il est trop tard.

Notez qu'aucun de ceux-ci ne nécessite un contrat avec un grand fournisseur. Ils nécessitent des décisions et du suivi.

Obtenir l'adhésion sans une ligne budgétaire de sécurité

Le moyen le plus rapide de perdre la crédibilité en tant que premier responsable de la sécurité est de se montrer avec une liste de souhaits d'outils avant de montrer des résultats. À la place, rattachez chaque demande à quelque chose de concret : « nous avons trouvé trois utilisateurs IAM avec des clés d'accès non renouvelées depuis 2021 » fonctionne mieux que « nous avons besoin d'un outil CSPM. » Formulez les demandes en termes dont l'équipe d'engineering et la finance se soucient déjà : rayon d'explosion réduit, audits plus rapides, moins de pages à 2 heures du matin. Si l'entreprise poursuit SOC 2 ou ISO 27001, cette date limite de conformité est souvent votre meilleur levier pour obtenir des ressources, même si la conformité elle-même n'est pas l'objectif.

Erreurs courantes au cours de la première année

Acheter une plateforme coûteuse (SIEM, EDR, CSPM) avant d'avoir le processus ou les effectifs pour l'exploiter réellement est le gaspillage le plus courant du budget initial. Un outil de 50k$ que personne ne configure génère du bruit, pas de détection. De même, écrire des politiques copiées à partir d'un modèle sans les adapter à la façon dont l'entreprise fonctionne réellement garantit qu'elles sont ignorées la première fois que quelqu'un a besoin d'une exception. Et essayer de tout diriger seul après les six premiers mois est un chemin vers l'épuisement ; au moment où il y a de la traction, l'embauche suivante devrait généralement être quelqu'un qui peut se charger de la détection et de la réponse afin que vous puissiez continuer à construire la structure du programme.

La sécurité à partir de zéro consiste surtout à mettre les choses en ordre : voir ce qui existe, fermer les lacunes les plus bruyantes, construire assez de processus pour que les décisions ne reposent pas sur votre mémoire, et à partir de là.

Si ce genre de construction de programme au niveau du terrain vous intéresse, Korra Studio a des segments connexes sur les fondamentaux de la réponse aux incidents et la posture de sécurité cloud qui s'associent bien à celui-ci.