De la sécurité pour une entreprise sans équipe sécurité
Les bases faites correctement, la conformité que vous pouvez prouver, et un plan d'incident assez court pour être lu.
Presque rien de ce qui arrive aux entreprises de votre taille ne relève d'une attaque astucieuse. C'est un mot de passe réutilisé, un e-mail de facture qui avait l'air juste, un compte administrateur appartenant à quelqu'un parti en mars, ou une sauvegarde que personne n'a jamais restaurée. Le travail qui évite cela est peu glorieux, fini, et se fait généralement une fois.
Ce que nous traitons en premier
- Les identités. Double authentification sur tout compte capable de déplacer de l'argent, de changer un DNS, de déployer du code ou de lire des données clients. Ce seul point retire l'essentiel du risque réaliste.
- Les départs. Une liste de qui accède à quoi, et un processus qui retire l'accès le jour où quelqu'un s'en va. Les comptes dormants sont la porte d'entrée la plus discrète.
- Les sauvegardes, restaurées. Nous effectuons une restauration, la chronométrons et notons ce qui a été perdu. Tant que ce n'est pas fait, vous avez des fichiers, pas un plan de reprise.
- Le moindre privilège sur les systèmes qui comptent, pour qu'un compte compromis soit un incident et non une catastrophe.
- Les secrets sortis des endroits où ils dérivent : dépôts de code, documents partagés, historiques de messagerie.
Sur les logiciels que nous construisons
- Des mises à jour de dépendances par habitude planifiée plutôt qu'en urgence, puisqu'un framework arrive en fin de vie tous les deux à trois ans.
- Les bases web ennuyeuses : validation des entrées, contrôle d'accès sur chaque point d'entrée et pas seulement dans l'interface, gestion saine des sessions, en-têtes de sécurité.
- Un contrôle d'accès appliqué là où la donnée est lue, pas dans l'écran qui l'affiche. Un bouton masqué n'est pas une permission.
- Des journaux qui permettent de répondre à « que s'est-il passé », conservés assez longtemps pour être utiles et assez peu pour être licites.
Une conformité que vous pouvez montrer
Pour la plupart des entreprises, l'exigence porte sur les preuves, pas sur une certification : un registre de ce que vous détenez comme données personnelles et pourquoi, les contrats avec les sous-traitants que vous utilisez, une règle de conservation réellement appliquée, et un plan de notification de violation que vous espérez ne jamais envoyer. Nous les produisons comme des documents qui vous appartiennent, en langage clair, plutôt qu'un PDF de politique qui contredit ce que fait le système.
- 1-2 semaines pour l'audit et une liste de correctifs priorisée
- 1 page le plan d'incident, car un long n'est pas lu
- 0 risque que nous vous cachons
Une sécurité qui n'existe que dans un document de politique est une histoire que vous vous racontez.
Questions fréquentes
Sommes-nous trop petits pour être une cible ?
Rien de ce qui vous atteint ne vous visait. Le bourrage d'identifiants, l'hameçonnage et le balayage automatisé sont indifférents : ils trouvent ce qui répond. Être petit ne réduit pas la probabilité, cela réduit la chance que quelqu'un ait regardé au moment où c'est arrivé. C'est pourquoi la première chose que nous examinons est de savoir si vous le sauriez seulement.
Faut-il un test d'intrusion ?
Pas avant que les bases soient en place. Un test sur un environnement sans double authentification, sans mises à jour et sans sauvegardes testées produit un rapport qui confirme ce que vous soupçonniez, à un certain prix. Une fois les fondamentaux tenus, un test ciblé sur l'application qui traite l'argent ou les données personnelles vaut la peine, et nous le cadrerons honnêtement plutôt que de le vendre par défaut.
Notre hébergeur ne s'en occupe-t-il pas ?
Il sécurise l'infrastructure ; vous restez responsable de vos comptes, de vos permissions, de vos données et de votre code. Ce partage surprend les gens pendant un incident, c'est-à-dire au pire moment pour l'apprendre. Nous écrivons de quel côté de la ligne tombe chaque risque, pour que personne ne suppose qu'il est couvert.