Économie de la sécurité du décalage vers la gauche

J'ai travaillé avec des dizaines de SecOps et une Détection et réponse équipes au cours des dernières années et il est devenu clair pour moi à quel point il est important de résoudre autant de problèmes de sécurité que possible en amont. Ou comme on l'appelle plus communément, "Décalage à gauche de la sécurité". En gros, je vois trois camps sur "Décalage à gauche de la sécurité" — 1) ne le comprends pas, 2) l'obtiens, ne l'exécute pas, 3) l'obtiens, l'exécute. Vous pourriez être dans ce troisième camp et penser que le déplacement vers la gauche est évident et de notoriété publique. Permettez-moi de vous rappeler humblement que le monde est vaste et que l'organisation moyenne est terriblement immature en matière de sécurité. Autrement dit, les camps un et deux combinés sont largement plus nombreux que le camp trois.

Pourquoi donc? Bien "Décalage à gauche de la sécurité" est nouveau, mais plus important encore, il est difficile. C'est comme manger constamment des légumes face à d'autres tentations sucrées. Les fournisseurs de sécurité disent tous que le déplacement vers la gauche permet une livraison plus rapide et des coûts réduits, mais à mon avis, ils ne le quantifient jamais de manière significative. Dans cette analyse, je vais tenter d'armer les praticiens avec des données sur la « sécurité du décalage vers la gauche » que chaque dirigeant et contrôleur du budget comprendra - l'économie d'entreprise. Cela s'inscrit dans un thème plus large important de la nécessité d'encadrer la sécurité pour générer des résultats commerciaux - développer votre TAM, accélérer les cycles de vente, expédier les produits plus rapidement - et pas seulement agir comme un exercice de réduction des risques.

Tout d'abord, une définition à level set. Faire "Décalage à gauche de la sécurité" signifie faire progresser la sécurité tôt et souvent dans le cycle de développement de l'organisation, que je définirais comme un sur-ensemble du cycle de développement logiciel habituel. Cela inclut tout ce qui concerne les employés, les fournisseurs, les contrôles de sécurité et l'empreinte numérique d'une organisation. Les problèmes de sécurité évités ou découverts plus tôt, avant qu'ils ne se propagent dans une organisation, sont plus faciles et moins coûteux à mettre en œuvre.

Passons maintenant à l'analyse. À mon avis, ce sujet est trop compliqué pour faire une analyse de haut niveau et prétendre quelque chose comme « décaler vers la gauche vous rend 10 % plus rapide et vous fait économiser 30 % », il y a trop de variables. Mon approche consistera à modéliser des micro-exemples très spécifiques d'une organisation hypothétique se déplaçant vers la gauche, et à voir ce que l'on peut en tirer.

Sur les paramètres des modèles ci-dessous, il existe des estimations très approximatives (ou même des estimations complètes par endroits) que j'essaie de rassembler lorsque les données disponibles sont médiocres. Lisez les sources de mon commentaire et faites-moi savoir si vous connaissez des recherches plus fiables ! De plus, les "violations de données" ne sont pas la seule forme d'événements cybernétiques dont il faut s'inquiéter, je me suis ancré sur eux car il existe des recherches solides sur les coûts par rapport aux effets plus nébuleux de la marque, de la confiance, etc.

Modèle 1 - MFA mis en œuvre dans toute l'organisation

Démarrage simple. Si vous pensez "chaque organisation a activé MFA partout", vous avez besoin d'une vérification de la réalité. Néanmoins, MFA en tant que contrôle unique déployé dans une organisation est un excellent exemple intuitif. La MFA est considérée comme un déplacement vers la gauche car elle empêche de nombreux comportements d'identification à risque d'être possibles en premier lieu. Ce modèle compare une organisation hypothétique avec MFA déployé partout correctement, par rapport à une organisation qui n'utilise que 1FA.

Coûts du modèle :

• SOC Frais de personnel = (Alertes de connexion par utilisateur et par jour liées à l'authentification à un facteur uniquement) * (Taille de l'organisation) * (Moyenne annuelle SOC Coût de l'analyste) / (Alertes triées par analyste et par jour)
• SOC Coûts logiciels = (Alertes de connexion par utilisateur et par jour liées à 1FA uniquement) * (Taille de l'organisation) * (Coût du logiciel par alerte pour faciliter l'enquête) * (365 jours)
• Perte de productivité en dollars = (Nombre moyen d'AMF par jour et par utilisateur) * (Taille de l'organisation) * (Délai avant l'AMF en secondes) / (1 minute / 60 secondes) / (1 heure / 60 minutes) / (1 jour / 24 heures) * ( Coût annuel moyen des employés)
• Valeur attendue du coût de la violation = (Coût moyen de violation de données) * (Probabilité de violation de données)

Paramètres du modèle:

• Taille de l'organisation : 10000 Employés (Utilisateurs)
• Délai avant MFA (Google Auth ou équivalent) : 10 secondes [1]
• Nombre moyen de MFA par jour et par utilisateur : 1 [2]
• Coût annuel moyen des employés : $100,000
• Alertes de connexion par utilisateur et par jour liées à 1FA uniquement (accès anormal, partage de mot de passe, etc.) : 0.01 [3]
• Alertes triées par analyste par jour : 100 [4]
• Moyenne annuelle SOC Coût de l'analyste : $100,000
• Coût par logiciel d'alerte pour faciliter l'enquête : 0.10 5 $ [XNUMX]
• Pourcentage de violations de données à la suite d'informations d'identification volées ou compromises : 19 % [6]
• Coût moyen d'une violation de données : 4.35 millions de dollars [7]
• Probabilité de base de violation de données : 1.13 % [8]
• Probabilité de violation de données avec MFA : 0.92 % [9]

Honnêtement, j'ai été un peu surpris de voir à quel point la friction de l'AMF traditionnelle s'est ajoutée en termes de dollars à partir de cette analyse. Raison de plus pour adopter des solutions MFA invisibles.

Modèle 2 — DevSecOps correctement exécuté

DevSecOps est probablement la catégorie la plus développée de "Décalage à gauche de la sécurité", et il existe un certain nombre d'excellents outils axés sur l'application ou sécurité de l'infrastructure essai. Super ici ressemble à des outils intégrés dans le flux de travail du développeur sans friction. Mauvais, ou sécurité gardée à droite, ressemble à une équipe de sécurité disjointe du développement et trouvant des problèmes de sécurité après que les choses ont été expédiées en production. Ce modèle compare une organisation réalisant le développement de logiciels avec DevSecOps déployé au maximum, par rapport à celui qui adopte une approche purement réactive pour logiciel de sécurité.

Coûts du modèle :

• Coûts du développeur = (Applications de production distinctes développées par organisation) * (Nombre moyen de vulnérabilités par application de production) * (Heures de développement moyennes pour remédier à la vulnérabilité en heures) * (1 an / 52 semaines) * (1 semaine / 40 heures travaillées) * (Moyenne annuelle Coût développeur)
• Coûts des analystes de sécurité = (Applications de production distinctes développées par organisation) * (Nombre moyen de vulnérabilités par application de production) * (Moyenne des heures d'équipe de sécurité pour corriger la vulnérabilité trouvée en production en heures) * (1 an / 52 semaines) * (1 semaine / 40 heures travaillées) * (Coût annuel moyen de l'analyste de la sécurité)
• Valeur attendue du coût de la violation = (Coût moyen de violation de données) * (Probabilité de violation de données)

Paramètres du modèle:

• Applications de production distinctes développées par organisation : 17 [10]
• Nombre moyen de vulnérabilités par application de production : 30.59 [11]
• Nombre moyen d'heures de développement pour remédier à chaque vulnérabilité détectée dans le développement : 3.61 heures [12]
• Nombre moyen d'heures de développement pour remédier à chaque vulnérabilité détectée en production : 10.71 heures [13]
• Coût annuel moyen du développeur : $150,000
• Heures moyennes de l'équipe de sécurité pour corriger chaque vulnérabilité trouvée en production : 3.10 [14]
• Coût annuel moyen d'un analyste de sécurité : $100,000
• Temps moyen moyen pour corriger les vulnérabilités - Fréquence d'analyse faible - 1 à 12 analyses par jour (sécurité décalée vers la droite) : 217 jours [15]
• Temps moyen moyen pour corriger les vulnérabilités - Fréquence d'analyse élevée - Plus de 260 analyses par jour (sécurité décalée vers la gauche) : 62 jours [15]
• Réduction supposée des vulnérabilités par une fréquence d'analyse élevée : 71 % [16]
• Pourcentage de violations de données résultant de vulnérabilités applicatives : 43 % [17]
• Coût moyen d'une violation de données : 4.35 millions de dollars [6]
• Probabilité de base de violation de données : 1.13 % [7]
• Probabilité de violation de données avec une fréquence de balayage élevée : 0.79 % [18]

DevSecOps a d'excellentes recherches à l'appui sur le coût de la correction des failles de sécurité à différents stades de développement (tests unitaires, tests d'intégration, tests système, mise en scène, production, etc.), il n'était donc pas surprenant de voir les différences dramatiques entre le déplacement à gauche et à droite dans ce modèle. Il n'y a vraiment aucune excuse en 2022 pour ne pas être champion de DevSecOps - cela vaut pour toutes les tailles d'organisations de développement de logiciels (ces organisations peuvent être des unités au sein d'organisations plus larges).

Modèle 3 - Intégration et départ robustes des employés et des actifs

L'intégration et le départ des employés et des actifs sont des flux de travail de sécurité extrêmement sous-estimés. Bien fait, il offre la possibilité de créer des données propres et de garantir un contrôle strict (EPDR, VPN, Email Security, disque crypté, navigateur contrôlé par l'organisation, etc.) et d'accéder aux états au moment de l'embarquement et du débarquement. Mal fait, cela crée du travail supplémentaire et laisse les choses au hasard ou aux flux de travail manuels humains. Il existe de nombreux systèmes qui aident à mettre des rails sur ces processus. Ce modèle compare une organisation avec une intégration et une désintégration de sécurité parfaites, par rapport à une organisation avec des flux de travail manuels et sujets aux erreurs.

Coûts du modèle :

• Coûts du temps de configuration de l'outil d'intégration des employés = (Taille de l'organisation) * (Taux de roulement de l'organisation) * (Temps d'intégration manuelle de l'informatique en minutes) * (1 heure / 60 minutes) * (1 semaine / 40 heures de travail) * (1 an / 52 semaines) * (moyenne annuelle des employés Coût)
• Facturable SOC Coût  = (Organisation SOC Taille) * (Moyenne annuelle) SOC Coût de l'analyste) * (Gains d'efficacité applicables)
• Valeur attendue du coût de la violation = (Coût moyen de violation de données) * (Probabilité de violation de données)

Paramètres du modèle:

• Taille de l'organisation (constante pendant un an) : 10000 Employés (Utilisateurs)
• Taux de roulement annuel de l'organisation : 47.2 % [19]
• Coût annuel moyen des employés : $100,000
• Il est temps d'installer et de configurer manuellement EPDR et VPN sur de nouveaux ordinateurs portables : 20 minutes [20]
• Organisation SOC Dimensions 3 FTE
• Moyenne annuelle SOC Coût de l'analyste : $100,000
• SOC Gains d’efficacité grâce à une cartographie claire des « propriétaires de quoi », résultant de l’intégration des employés et des actifs : 10 % [21]
• Pourcentage de violations de données à la suite d'un hameçonnage : 16 % [22]
• Pourcentage de violations de données à la suite d'un départ abusif d'employés : 10 % [23]
• Coût moyen d'une violation de données : 4.35 millions de dollars [6]
• Probabilité de base de violation de données : 1.13 % [7]
• Probabilité de violation de données avec des contrôles corrects garantis sur chaque ordinateur portable des employés et une délocalisation automatisée : 0.85 % [24]

Les humains font des erreurs; confiez les tâches répétitives aux machines. Même si vous supposez que dans une tâche comme l'intégration et la désintégration, les humains ne font des erreurs que 5 % du temps, cela représente 472 erreurs dans ce modèle, ce qui représente tous ces employés qui intègrent et quittant. C'est beaucoup de risques de fruits à portée de main à retirer de la table. Investissez dans un outil robuste qui gère cela pour votre organisation, il sera rentabilisé.

Conclusions

La sécurité est un réseau complexe de compromis, le déplacement de la sécurité vers la gauche n'est pas différent. J'ai surtout exploré cet exercice d'analyse parce que je ne peux pas croire que je vois encore des alertes dans la nature uniquement possibles parce qu'une organisation n'implémente pas MFA. Je comprends cependant, les bases peuvent être difficiles, entre la lutte contre la dette informatique héritée ou la bureaucratie. Quel que soit votre rôle, j'espère que cela vous a donné de nouvelles munitions sur la façon dont "Shift Left Security" peut générer des résultats commerciaux et payer tout nouvel outillage requis par la seule économie.

Allez maintenant et mangez vos légumes.