Entrez dans presque n'importe quelle entreprise de logiciels et demandez où vit sa sécurité. La réponse est rarement une personne dotée d'un mandat clair. C'est un tableur des constats du dernier test d'intrusion, une file de tickets que quelqu'un épuise lentement, et une case de conformité qu'il faut cocher avant le lancement. Rien de tout cela n'est faux, à proprement parler - ce n'est juste pas une stratégie de sécurité. C'est un tas de choses qui se sont produites et qui se règlent désormais avec retard.
La différence compte parce que le modèle du ticket a un plafond. Il ne peut que réagir à ce qui a déjà été trouvé, et il traite la sécurité comme un centre de coûts dont le seul travail est de refermer des brèches a posteriori. Une fonction, au contraire, est quelque chose que vous concevez, nommez, cadrez, construisez et - c'est essentiel - mesurez. On n'atteint pas la deuxième sorte en émettant des tickets.
Pourquoi le modèle du ticket échoue avec retard
Un arriéré de constats d'audit rassure parce qu'il produit de l'activité : des tickets sont créés, assignés, fermés. Mais cette activité regarde en arrière. Elle nettoie ce que l'audit le plus récent a remarqué par hasard, ce qui n'est pas la même chose que savoir à quoi un attaquant déterminé pourrait réellement accéder. Les listes de constats parlent du passé. Un modèle de menaces parle du présent - et du futur qui compte, celui où votre produit change.
Pire : le modèle du ticket n'a pas de responsable naturel au-delà de celui qui tient la souris quand arrive le prochain audit. La sécurité devient la chose qui appartient à tout le monde, ce qui en pratique signifie qu'elle n'appartient à personne. L'équipe publie un changement qui élargit en silence une règle d'accès, et personne ne le remarque jusqu'au prochain scan trimestriel. Le constat est consigné, le cycle recommence, et le système dérive un peu plus à chaque fois.
La responsabilité vit chez un propriétaire, pas dans une file
La première étape pour faire de la sécurité une fonction est de lui donner un propriétaire nommé, doté d'un mandat qui survit à une mise en production. Pas un service sécurité qui audite à distance - mais une personne ou une équipe dont la fiche de poste contient les mots « secure by design » et qui est dans la pièce quand l'architecture et le périmètre se décident, pas seulement quand une échéance est manquée. Quand un développeur a une question sur une décision de contrôle d'accès, il y a une personne sans ambiguïté à qui aller, et cette personne a le pouvoir de dire non.
La propriété fait la différence entre une liste de contrôle que l'on consulte et une liste que l'on accuse. Sur le papier, les deux sont identiques. La différence apparaît la première fois qu'il faut prendre une décision d'appréciation sous pression, et la réponse à « qui décide ? » est une personne, pas une réunion.
Partez d'un modèle de menaces, pas d'une liste de conformité
Les listes de conformité sont des plafonds déguisés en planchers. Elles disent le minimum qu'un auditeur veut voir, et un attaquant déterminé se moque de votre auditeur. Ce qui prédit réellement les dégâts qu'un attaquant peut causer est un modèle de menaces : un récit écrit de ce qu'un attaquant voudrait de votre système, des routes qu'il pourrait prendre pour l'obtenir, et desquelles de ces routes vous feraient le plus de mal.
Le modèle n'est pas un document que l'on classe une fois pour toutes. C'est un artefact vivant, mis à jour chaque fois que le système change d'une manière qui modifie une surface d'attaque - un nouveau type de données, une nouvelle intégration, un nouveau rôle. Si une route change, les contrôles qui la protègent changent aussi. Une liste répond à « que sommes-nous tenus de montrer ? » Un modèle de menaces répond à la question qui vous empêche vraiment de dormir : « quelle est la pire façon dont cela peut échouer, et avons-nous décidé que ce risque est acceptable ? »
La conformité vous dit ce qu'un auditeur vérifiera. Un modèle de menaces vous dit ce qu'un attaquant tentera. Un seul des deux vous protège.
Mesurez les contrôles, pas la case
Un contrôle que vous ne pouvez pas mesurer est une case. « L'API exige une authentification » sonne comme une affirmation et se comporte comme un espoir. La sécurité mesurée se voit autrement : combien de justificatifs exposés y a-t-il dans le code, et ce nombre baisse-t-il ? Combien de temps faut-il pour détecter qu'une règle d'accès a été élargie sans approbation, et cette durée peut-elle passer de mois à minutes ? Quel pourcentage de secrets est tourné selon un calendrier, et quelle est l'exception la plus ancienne ?
Choisir les métriques est déjà du travail de conception. Une fonction de sécurité se mesure comme n'importe quelle fonction : vous vous mettez d'accord sur le résultat, vous l'instrumentez et vous regardez la tendance entre les versions plutôt qu'un réussi/échoué binaire sur un seul jour. Quand la sécurité est mesurée, elle devient quelque chose que vous pouvez diriger, budgéter et améliorer - ce qui est exactement ce qu'est une fonction, et ce que n'est pas un ticket.
Prixez la sécurité comme une fonction, pas comme une taxe
Les équipes qui traitent la sécurité comme une taxe la compressent dans les cinq derniers pour cent d'un sprint, précisément quand la pression pour livrer est maximale, ce qui garantit qu'elle reçoit le travail le moins réfléchi. Les équipes qui la traitent comme une fonction la cadrent comme toute autre capacité : une allocation de temps explicite, son propre propriétaire, et un point de revue où son efficacité est questionnée plutôt que supposée. La différence n'est pas l'effort - c'est le point du cycle auquel cet effort se pose.
C'est aussi une décision de prix. Un partenaire qui inclut la sécurité en passant n'a aucune raison de la rendre mesurable, car son coût est caché dans un montant forfaitaire et sa qualité n'est jamais inspectée. Un partenaire qui traite la sécurité comme un chantier cadré vous donne les deux choses que le modèle du ticket ne donne jamais : une ligne visible dont vous pouvez exiger des comptes et un moyen de savoir - pendant que le travail se fait, pas après un incident - si vous obtenez ce pour quoi vous payez.
Questions pour votre prochain prestataire
Qui est propriétaire de la sécurité dans votre équipe, et cette personne est-elle dans la pièce quand le périmètre est convenu - ou seulement quand quelque chose casse ? À quoi ressemble votre modèle de menaces actuel et quand a-t-il été mis à jour pour la dernière fois ? Expliquez-moi un contrôle de sécurité que vous mesurez entre les versions, et ce que montre la tendance. Quand je demande un audit de sécurité, qui subit les conséquences des constats - vous ou moi ? Si les réponses sont vagues, la sécurité est vague, et les tickets seront les vôtres.
La sécurité comme fonction est la façon dont le logiciel reste quelque chose que vous possédez plutôt que quelque chose dont vous êtes simplement redevable. En toute honnêteté, ce n'est pas plus cher - cela investit l'effort plus tôt et de façon visible, là où il peut être mesuré et orienté, au lieu de plus tard et de façon invisible, où il ne peut qu'être payé. La prime que vous payez n'est pas pour plus de sécurité. Elle est pour savoir, à tout moment, exactement à quel point vous êtes en sécurité.