DevSecOps se concentre trop sur la chaîne logistique du logiciel, Elizabeth Lawler (CyberArk)

C’est au printemps dernier que CyberArk s’est offert Conjur, spécialiste de la sécurité des environnements DevOps, à travers la gestion des secrets d’identification, qu’il s’agisse d’identifiants de comptes, de clés SSH, ou encore de clés d’API, notamment. De son aveu même, Elizabeth Lawler avait fondé Conjur en 2013, avec Kevin Gilpin, avec l’ambition de chasser sur les terres de CyberArk, en ciblant la gestion des comptes à privilèges ne correspondant pas à des utilisateurs humains. Cette approche de l’IAM, centrée ainsi sur les machines, les services, et le code, visait en particulier les environnements Cloud et DevOps, pour industrialiser une gestion de composants d’identités pouvant être très artisanale, avec tous les risques que c’est susceptible d’induire. Aujourd’hui vice-présidente de CyberArk, Elizabeth Lawler a accepté de faire le point, avec la rédaction, sur sa perception de la maturité des milieux DevOps en matière de sécurité.

LeMagIT : la notion de moindre privilège n’est pas nouvelle. Est-il encore bien nécessaire de la marteler ?

Elizabeth Lawler : Oui, malheureusement. Cette logique est bien implantée dans la pensée des experts en sécurité. Mais cela ne fait pas partie de l’ADN des milieux DevOps. C’est pour cela, je pense, que l’on pousse aux DevSecOps : parce qu’il est nécessaire d’avoir des gens qui pensent, sont formés, dans l’esprit du moindre privilège, au sein de ces équipes à haute vélocité. Il est crucial d’intégrer la sécurité dans ces processus de développement, dans les processus de transformation associés. Parce que l’injecter après coup, ce n’est pas viable.

Mais justement, penser administration de comptes à privilèges dans les environnements DevOps sous-entend que de tels comptes sont utilisés. C’est un héritage d’un passé où l’on ne s’en souciait pas ?

Il y a une part d’héritage. Je pense que nous avons amené, dans des environnements de production critiques, des concepts immatures de privilèges. Et parce qu’il n’y a pas de standard d’identité commun, il y a là un manque.

La manière dont un Amazon appréhende les privilèges est plutôt sophistiquée. Il y a des groupes d’IAM assignés à une machine virtuelle ou un service, lorsqu’il est lancé. Mais la plupart des outils n’ont pas même ce concept, n’ont pas la moindre notion d’identité pour les choses créées au sein de leur environnement.

Je pense que c’est un problème patrimonial transposé dans la nouvelle génération, un problème de maturité. Les systèmes de nouvelle génération ne sont pas encore assez matures pour penser sur-privilège, moindre privilège, ségrégation de tâches.

Les éditeurs, les groupes de réflexion et les experts qui réfléchissent aux bonnes pratiques essaient d’injecter ça dans la discussion. Mais je pense que là où la sécurité n’a pas bien fait son travail, c’est à faire entendre sa voix dans l’Open Source. Beaucoup d’outils DevOps sont conçus en Open Source ; la communauté discute de ces questions, mais elle n’a pas toujours l’expertise suffisante.

Et CyberArk a pris une initiative très audacieuse en versant Conjur à l’Open Source début septembre, après son rachat. Le but était de fournir un hub où les professionnels des DevOps peuvent venir, échanger, apprendre sur les questions de surface d’attaque, sur la manière de limiter les risques de sécurité liés aux privilèges, et enfin engager vraiment cette discussion DevSecOps.

Parce que pour le moment, les réflexions tournent surtout autour de la gestion des correctifs, de l’analyse de code, de la gestion de bibliothèques… de la chaîne logistique du logiciel, en somme. Mais pas problèmes de sécurité systémiques. La maturité n’est pas encore là.

Vous parlez de maturité relative à certaines questions de sécurité. Quid de la maintenance des environnements DevOps eux-mêmes, et pas seulement des applications qu’ils servent à développer ?

Par nature, les environnements DevOps sont plutôt bien outillés pour la gestion de correctifs. La manière dont ils sont maintenus a, j’en suis sûre, beaucoup à voir avec la manière dont les applications qu’ils servent à produire sont maintenues.

La compromission de ces environnements tend moins à venir de vulnérabilités non corrigées que d’opérations classiques de phishing pour collecter des identifiants administrateurs.

Nous sommes d’ailleurs capables d’aider à remédier à certains problèmes d’hygiène liés aux workflows. Par exemple, souvent, les secrets sont gérés dans des fichiers texte. Ce qui signifie qu’en cas de départ d’une personne, notamment, le changement des mots de passe repose sur une fonction manuelle. Et ce type de workflow ne profite pas forcément de la même attention que des choses comme la gestion des correctifs.

Certains éditeurs étendent leur offre d’IAM dans le monde des API. N’y voyez-vous pas là une forme de concurrence ?

Si l’annuaire Active Directory était la seule source d’identités, le socle de la gestion des accès et des racines de confiance dans le monde traditionnel du sur-site, ce n’est plus le cas. Dans ce contexte, vous avez des gens comme Okta qui viennent par l’angle de l’utilisateur, et d’autres par celui des machines, comme Illumio. Et au milieu, vous en avez d’autres, comme nous, qui prennent l’angle de la gestion des comptes à privilèges et des machines. Oui, à un moment tous ces acteurs vont se rencontrer et se concurrencer.

Mais pour l’essentiel du marché, la question sera la gestion des identités des machines, parce que l’impact est plus étendu, avec les objets connectés, par exemple, l’informatique distribuée, le Cloud, etc. C’est d’ailleurs un domaine clé pour nous, avec la gestion des comptes systèmes. Il sera intéressant de voir comment cela va évoluer.

Dois-je comprendre que vous vous préparez à aller vers le monde de l’IoT ?

Il y a clairement là de grandes opportunités pour n’importe quel service à tirer parti de définitions robustes d’identités de machines. C’est clairement un domaine qui nous intéresse.