En 2018, les employés de Microsoft ont publié une lettre controversée affirmant que l’entreprise devrait refuser une opportunité commerciale de 10 milliards de dollars. Les auteurs se sont opposés à l’offre de Microsoft sur le contrat cloud d’infrastructure de défense commune du ministère de la Défense, arguant qu’ils avaient rejoint Microsoft pour avoir un « impact positif sur les personnes et la société », et non pour augmenter la létalité de l’armée américaine. La même année, un groupe d’employés d’Amazon a emboîté le pas, fustigeant le soutien de leur entreprise à la technologie de surveillance à des fins de défense et de sécurité intérieure. Plus particulièrement, Google en 2019 a mis fin à ses travaux d’intelligence artificielle pour le département du projet Maven en raison de l’opposition de ses employés.
Bien que ces histoires soient troublantes, pour de nombreuses entreprises technologiques américaines, en particulier les petites startups, les véritables obstacles à la coopération avec le ministère de la Défense ne résident pas dans un techno-moralisme malavisé, mais plutôt dans les barrières bureaucratiques auto-imposées du ministère, en particulier sa cybersécurité byzantine. processus de conformité. Dans l’approche actuelle du département en matière de cybersécurité, des exigences confuses et qui se chevauchent sont continuellement ajoutées par des acteurs bureaucratiques tels que le Bureau du sous-secrétaire à la Défense pour l’acquisition et le maintien en puissance à un ensemble déjà long d’exigences avec un souci insuffisant de la convivialité et de l’efficacité globale. Ce n’est pas un problème nouveau : les hauts dirigeants du ministère de la Défense ainsi que ceux du secteur privé ont passé la majeure partie d’une décennie à souligner la nécessité d’améliorer et de rationaliser les réglementations en matière de conformité et de développement de logiciels à l’appui de la défense nationale. Bien que l’adoption continue de processus et de pratiques de développement, de sécurité et d’exploitation Agile ait conduit à des améliorations progressives, les changements d’époque nécessaires pour suivre les adversaires proches restent insaisissables en raison de l’aversion au risque et des barrières institutionnelles auto-imposées.
Parmi ces barrières institutionnelles, celles de l’appareil de cybersécurité sont particulièrement intimidantes pour les startups de logiciels, qui se spécialisent dans le prototypage rapide et le développement itératif mais manquent de ressources pour naviguer dans le labyrinthe des exigences de conformité. Ce n’est qu’en comprenant ces points douloureux du point de vue des petites et moyennes entreprises que le ministère de la Défense sera en mesure de résoudre les bons problèmes et d’exploiter pleinement le pouvoir de transformation offert par les startups de logiciels de pointe mais pauvres en ressources. Faire honte publiquement aux entreprises privées parce qu’elles sont insuffisamment patriotiques ne persuadera pas ces entreprises de travailler avec l’armée. Au lieu de cela, le Pentagone devrait se concentrer sur la réduction de la bureaucratie tout en maintenant des normes de cybersécurité rigoureuses. Cela serait dans l’intérêt national et dans l’intérêt commercial des entreprises américaines.
Une culture d’aversion au risque
Le ministère de la Défense d’aujourd’hui a un degré généralement élevé d’aversion au risque qui affecte tous ses efforts d’approvisionnement. Parlant des défis posés par l’ascension technologique de la Chine, le général John Hyten, vice-président des chefs d’état-major interarmées, a récemment déclaré que « nous avons décidé que l’échec est mauvais … si vous voulez revenir à la vitesse … cela signifie prendre des risques… échouer vite et aller vite. Mais nous ne l’avons pas fait. Bien que ses remarques concernent l’aversion au risque américain dans le développement de missiles hypersoniques, elles sont également pertinentes pour le développement de logiciels dans l’ensemble du gouvernement fédéral et en particulier du ministère de la Défense.
Pour de nombreuses sociétés de logiciels souhaitant vendre leurs produits au gouvernement américain, la partie la plus difficile du processus n’est pas de développer la substance du produit, mais plutôt de naviguer dans le labyrinthe déroutant des exigences de conformité avant qu’il ne puisse être déployé de manière opérationnelle. Ces exigences ont été mandatées par le gouvernement pour réduire les risques de cybersécurité. Bien que de nombreux contrôles individuels soient réfléchis et efficaces, dans l’ensemble, ils présentent deux obstacles majeurs à l’entrée pour les startups de logiciels. Premièrement, un grand nombre de règles sont fragmentées entre plusieurs ensembles d’exigences qui se chevauchent, ce qui nécessite plus de savoir-faire bureaucratique que technique pour s’y retrouver. Deuxièmement, ils adoptent une approche unique, imposant aux candidats des listes de contrôle épuisantes pour des problèmes qui ne s’appliquent tout simplement pas au logiciel examiné. En conséquence, de nouvelles capacités opérationnelles sont empêchées d’être déployées, posant des risques différents mais tout aussi importants que ceux qu’elles sont censées atténuer.
Le labyrinthe de la conformité
Pour les entreprises qui entrent pour la première fois sur le marché du gouvernement américain, le plus grand défi consiste à déterminer où commence le labyrinthe de la conformité. Un bon point de départ est la publication 800-171 du National Institute of Standards and Technology Special (NIST), qui explique comment les informations contrôlées non classifiées doivent être stockées. Ceci, et ses publications sœurs (à savoir la publication spéciale 800-171a, manuel 162), comprennent 375 pages de conseils dans 14 domaines couvrant 110 contrôles (environ 362 pratiques, telles que la complexité des mots de passe et la manière dont les salles de serveurs doivent être physiquement sécurisé).
Si une entreprise travaille pour le ministère de la Défense, elle sera bientôt soumise à la certification Cybersecurity Maturity Model. Ce cadre vieux de deux ans, qui a déjà fait l’objet d’une révision majeure, vise à «[protect] informations sensibles non classifiées qui sont partagées par le Ministère avec ses entrepreneurs et sous-traitants », en renforçant les exigences de cybersécurité tout au long de la chaîne d’approvisionnement, et pas seulement pour le fournisseur principal. Si une entreprise souhaite atteindre le niveau « expert » pour cette certification, elle doit non seulement satisfaire à la norme 800-171, mais également à la publication spéciale NIST 800-172, qui impose des exigences plus strictes pour se défendre contre les menaces persistantes avancées.
En outre, les entreprises fournissant des services cloud ou un support opérationnel au sein des réseaux départementaux sont également soumises à la publication spéciale 800-53 du NIST. couvrant 212 commandes et 173 améliorations.
Passer par le gant de la conformité n’est que le début. Plusieurs de ces exigences ne sont que des conditions préalables aux autorisations réelles nécessaires pour déployer et exploiter un système logiciel. Si le système doit être déployé dans un environnement cloud fédéral (par exemple, Amazon Web Services Government Cloud ou Azure Government), il faut ensuite obtenir l’autorité du programme fédéral de gestion des risques et des autorisations pour fonctionner, qui se décline en deux versions (parrainé par l’agence ou conjoint délivré par le Conseil d’autorisation) et contient trois niveaux de conformité et des contrôles supplémentaires, qui se chevauchent avec les contrôles NIST 800-53 déjà rencontrés. C’est le point du processus avec lequel la plupart des startups ont le plus de difficulté, car le processus pour faire fonctionner une autorité n’est pas bien défini ou compris. Si le système est déployé dans un cadre plus traditionnel (par exemple, une location autonome ou partagée sur site), l’entreprise doit alors passer par une évaluation de la loi fédérale sur la gestion de la sécurité de l’information pour les agences civiles. Pour le ministère de la Défense, une entreprise doit obtenir une autorisation d’opérer auprès de la Defense Information Systems Agency en satisfaisant aux 461 guides d’informations techniques sur la sécurité. Comme si cela ne suffisait pas, il y a encore plus d’exigences, d’autorisations et d’exceptions à retenir, telles que le certificat sur le terrain, l’autorité intérimaire pour tester / exploiter, l’Organisation internationale de normalisation, le cadre d’atténuation des risques et le cadre de contrôles sécurisés, pour ne citer que ceux-là. quelques. Naviguer avec succès dans ces exigences, pour les entreprises chanceuses qui ont le savoir-faire bureaucratique, est souvent trop coûteux pour les startups en démarrage, ce qui constitue une barrière insurmontable à l’entrée.
Le monstre dans le labyrinthe
Ce qui rend la conformité si difficile, c’est que les entreprises doivent déterminer quels ensembles de contrôles spécifiques s’appliquent même à elles. Ensuite, ils doivent rassembler des preuves et soumettre une écriture significative à l’ordonnateur. Ces articles peuvent compter des centaines de pages et prendre des semaines à rédiger. Plusieurs réglementations exigent également une vérification par un organisme d’évaluation tiers, ce qui ajoute plus de temps et d’argent aux coûts. Étant donné que la cybersécurité est relativement distincte du développement logiciel traditionnel, la plupart des startups ne disposent pas de l’expertise requise pour effectuer ces tâches en interne. Et même ceux qui le font doivent toujours supporter le coût de la réalisation des tâches.
Comme on pouvait s’y attendre, la situation actuelle a donné naissance à une industrie artisanale d’outils de bricolage ; consultants en évaluation, audit et remédiation ; et les fournisseurs de conformité en tant que service. Bien que ma startup actuelle n’ait pas encore obtenu la pleine autorité pour fonctionner, nous sommes suffisamment avancés dans le processus pour apprécier le coût de ces outils et solutions. Pour faire passer notre entreprise (environ 30 personnes) et notre tout premier produit (une application Web avec une architecture modérément complexe) via NIST 800-171 uniquement, les frais que nous avons engagés étaient d’environ 40 000 $ pour la licence d’outils, 30 000 $ pour le conseil et 30 000 $ pour un service de conformité géré. De plus, la mise en œuvre des changements de produit selon les recommandations des consultants impliquait une année complète de travail à temps partiel de la part de plusieurs ingénieurs, que je qualifierais approximativement d’un seul ingénieur à temps plein pour cette durée, soit environ 200 000 $, pour un total combiné de 300 000 $ pour l’ensemble du processus.
En termes absolus, 300 000 $ n’est pas un chiffre exorbitant, et je m’attends à ce que nos dépenses liées à la conformité diminuent à mesure que nous progressons vers une pleine autorité pour opérer pour notre premier produit, et certainement pour les produits de suivi. D’une part, de nombreuses exigences sont satisfaites au niveau de l’entreprise, se transmettant d’une étape à l’autre et d’un produit à l’autre. Et pour les exigences qui ne se prolongent pas, nous pouvons effectuer notre première série de corrections en tenant compte des réglementations sur la voie de la conformité afin de réduire les coûts lors des étapes ultérieures. Sur environ une douzaine de startups dans mon cercle de connaissances, j’en connais trois qui suivent des trajectoires similaires à leurs autorités pour fonctionner (dont aucune n’a encore complètement obtenu), donc je pense que l’expérience de mon entreprise est typique.
Malgré tout, dans le contexte des startups, même le montant modéré de 300 000 $ présente encore des défis importants. D’une part, les contrats dans lesquels les startups en phase de démarrage s’engagent, par le biais de véhicules tels que le programme Small Business Innovation Research, sont petits : environ 1 million de dollars. Les entreprises avisées peuvent essayer d’intégrer des dépenses de conformité dans leurs contrats, mais les projets sont souvent plafonnés et même lorsqu’ils ne le sont pas, les clients soucieux des coûts (oui, ils existent même au sein du gouvernement) peuvent rechigner face aux dépenses supplémentaires. En conséquence, plus d’un quart des revenus d’une startup provenant du contrat sont liés aux coûts de mise en conformité.
Deuxièmement, le fait de consacrer les ressources les plus précieuses d’une entreprise (son personnel) à des tâches de conformité trop complexes et redondantes entraîne des coûts d’opportunité importants. Même avec une aide extérieure, le personnel technique de l’entreprise doit encore investir beaucoup de temps, comme c’était le cas pour mon entreprise, et la nature du travail exige qu’il s’agisse de personnel informatique senior ou d’ingénieurs de développement, de sécurité et d’exploitation. Les petites startups n’auront généralement pas le premier, et les derniers sont parmi les ingénieurs les plus chers du marché qui travailleraient autrement sur les composants de base du produit. En d’autres termes, les ressources affectées aux processus de conformité actuels nuisent à l’innovation de fond et au développement de produits.
Un troisième problème majeur avec le statu quo est que la réalisation d’un ensemble d’exigences ou même une pleine autorité pour opérer ne se traduit pas automatiquement en d’autres exigences équivalentes. En d’autres termes, il n’y a pas de réciprocité entre les entités qui ont effectivement les mêmes protocoles de conformité. Pour les ensembles d’exigences individuelles, les agences peuvent adhérer à différents protocoles en fonction de leur affiliation bureaucratique, quelle que soit leur similarité en substance. Et bien que le fait d’avoir mis en œuvre l’un facilite la tâche de réaliser le suivant, il n’en reste pas moins que le temps et les ressources doivent être consacrés à la répétition des tâches plutôt que de se voir automatiquement conférer l’équivalence. Dans le cas d’une pleine autorité pour opérer, théoriquement, il existe des mécanismes de réciprocité entre les agences. Pourtant, sur la base des conversations avec les ordonnateurs, ce processus n’est pas garanti, en grande partie dépendant de l’ordonnateur individuel en charge du processus.
Enfin, et c’est peut-être le plus problématique, alors que de nombreux contrôles peuvent être traités en même temps que le développement du logiciel, les processus nécessitant une évaluation par un tiers ne peuvent commencer qu’une fois le produit terminé. Étant donné que le délai d’examen et d’approbation standard pour chacune de ces normes est de six mois ou plus, et que plusieurs d’entre elles doivent être effectuées de manière séquentielle plutôt qu’en parallèle, le concept de développement rapide des capacités est mort à l’arrivée. Cela peut avoir de graves conséquences opérationnelles négatives. Un exemple poignant : mon entreprise a développé une application pour aider une organisation du ministère de la Défense à gérer le suivi des cas COVID-19 dans les trois mois suivant le début de la pandémie. Nous avons ensuite passé les neuf mois suivants à suivre le processus de conformité, au moment où le logiciel n’était plus nécessaire. Même si les utilisateurs finaux de notre organisation cliente faisaient l’éloge de notre application après l’avoir testée dans notre environnement informatique commercial, nous étions légalement tenus de les empêcher de l’utiliser de manière opérationnelle en raison des exigences de conformité. Les startups de logiciels développent rapidement des produits innovants, mais trop souvent, comme dans ce cas, elles sont incapables de fournir leur plus grande valeur en raison d’exigences de conformité bien intentionnées mais mal adaptées.
Pour être clair, toute personne fournissant un logiciel au ministère de la Défense devrait être tenue de s’assurer que son produit ne compromet pas la sécurité des réseaux du ministère de la Défense. Cependant, les processus actuels sont pesants au point qu’ils entravent l’acquisition et le déploiement des capacités innovantes nécessaires pour maintenir l’avantage concurrentiel de l’Amérique en matière de technologie. Si le ministère veut prendre au sérieux l’exploitation de l’écosystème de démarrage de logiciels, il doit d’abord résoudre le problème des processus de conformité byzantins.
Des pas dans la bonne direction
Heureusement, le ministère de la Défense a pris des mesures pour rompre le nœud gordien de la conformité. Le département a simplifié la version la plus récente de la certification du modèle de maturité en matière de cybersécurité. Ces changements ont été motivés par « plus de 850 commentaires publics… [and] la nécessité d’améliorer [Cybersecurity Maturity Model Certification] en réduisant les coûts, en particulier pour les petites entreprises. De toute évidence, il y a une bouffée de syndrome de Stockholm à être reconnaissant d’avoir simplifié un autre obstacle à la conformité qui n’existait pas il y a un an. Mais c’est un développement positif que le ministère de la Défense ait directement reconnu que la version 1.0 de la certification du modèle de maturité de la cybersécurité a injustement empêché les petites et moyennes entreprises de participer à la base industrielle de la défense et a décidé de simplifier plutôt que de compliquer davantage.
De plus, des organisations spécifiques au sein du ministère de la Défense ont montré comment les pratiques modernes de développement, de sécurité et d’opérations peuvent contribuer à la solution et aider à soutenir les innovateurs. La plate-forme 1 de l’armée de l’air, conçue par Nicolas Chaillan (ancien responsable des logiciels de l’armée de l’air) et Will Roper (ancien secrétaire adjoint de l’armée de l’air pour les acquisitions, la technologie et la logistique), a introduit le concept d’usines de logiciels au ministère de la Défense, qui permet aux développeurs de se décharger du fardeau de la conformité et de se concentrer sur la tâche d’innovation. La valeur de Platform One est qu’elle fournit une plate-forme où les startups et autres développeurs de logiciels peuvent déployer leurs produits sans sauter à travers la myriade de cercles de conformité décrits ci-dessus. Il le fait lui-même après avoir franchi tous les obstacles pour obtenir une autorité d’exploitation, permettant ensuite aux développeurs d’obtenir un certificat à mettre en place sur sa plate-forme à condition qu’ils mettent en œuvre un ensemble de contrôles beaucoup plus simple. Tous ces contrôles sont validés en continu et automatiquement via un pipeline moderne d’intégration continue et de déploiement continu, réduisant ainsi davantage les coûts et les délais de remédiation et d’évaluation. Alors que les récents changements de personnel de direction ont quelque peu entravé l’adoption de Platform One et les pratiques fantastiques qu’elle incarne, son existence même et son succès jusqu’à présent sont des étapes majeures dans la bonne direction.
Enfin, en guise de dernier contrôle contre la queue proverbiale qui remue le chien, des moyens existent pour que les entreprises obtiennent des exceptions aux exigences de conformité, bien que leur utilisation soit naturellement rare. Des réglementations remplaçantes telles que l’instruction 5000.81 du ministère de la Défense permettent parfois de déroger aux exigences de cybersécurité, en particulier dans les cas où elles bloquent des besoins opérationnels urgents. De plus, des agences telles que le Defense Digital Service sont habilitées à « demander des dérogations aux exigences des réglementations du ministère de la Défense … ou à d’autres politiques » et l’organisation de blocage « doit statuer sur tout [Defense Digital Service] demande de dérogation dans les 4 jours suivant la réception », ce qui est une autorité extraordinaire à la fois dans sa portée et sa célérité (Directive du ministère de la Défense 5105.87). Nonobstant le leurre facile d’utiliser des exceptions, elles ne devraient être utilisées qu’exceptionnellement et non comme une routine, et les autorités chargées de l’autorisation doivent soigneusement peser les risques par rapport aux avantages apportés par la renonciation à des réglementations trop zélées mais efficaces.
Ce sont tous certainement des pas dans la bonne direction, mais le fait est que la barrière de conformité à l’entrée reste élevée pour la grande majorité des startups de logiciels entrant sur les marchés publics. À une époque de concurrence entre pairs avec des adversaires technologiquement sophistiqués tels que la Russie et la Chine, le ministère de la Défense ne peut plus supposer qu’il peut maintenir son avantage concurrentiel sans prendre des risques et tirer parti de tous les moyens à sa disposition, y compris en ouvrant la voie à de hautes performances. startups à haut risque et à haut rendement. Les adversaires américains ne reculent certainement pas devant le risque, le ministère de la Défense devrait donc être prêt à accepter encore plus de risques.
Daniel K. Lim, Ph.D. est le cofondateur et directeur technique de Geosite, une startup de logiciels fournissant des outils géospatiaux aux clients gouvernementaux et commerciaux. Auparavant, il était officier des cyberopérations (17A) pour l’armée américaine et consultant au Center for Strategic and International Studies. Il est diplômé de l’Université de Yale et de l’Université de Californie à Los Angeles.
Image : U.S. Air Force (photo du sergent-chef Renae Pittman)