Tufin : « la question consiste à savoir comment automatiser la sécurité sans perdre le contrôle »

LeMagIT : On parle aujourd’hui d’orchestration des politiques de sécurité, d’orchestration et d’automatisation de la sécurité (SAO), voire de la réponse (SAOR)… Cela peut paraître un peu confus, non ?

Reuven Harrison : Je ne sais pas exactement qui utilise ces termes. Tufin s’est lancé dans l’orchestration des politiques de sécurité il y a 4 ans. Nous avons observé une évolution de l’IT en général vers l’orchestration, qui consiste en la capacité à administrer de vastes centres de calcul de manière totalement automatisée, en passant par un système centralisé assurant seul l’orchestration de tous les composants. La sécurité est là toujours un peu en retard. C’est toujours le dernier domaine à être automatisé, parce que la sécurité est d’abord question de contrôle. Et il peut y avoir un sentiment de perte de contrôle sur ce qui n’est pas fait manuellement : la sécurité consiste à prévenir l’occurrence de certaines choses, et donc à les contrôler, à dire si elles sont acceptables ou non, après examen. Parce qu’il s’agit toujours d’accorder le moindre privilège possible requis par l’activité. Et que tout le reste devrait être bloqué ou prévenu.

Mais voilà, plus on automatise l’IT, plus l’entreprise est agile. Et si la sécurité reste manuelle, elle ralentit l’IT. Pour réaliser la pleine promesse de l’agilité, il est nécessaire d’automatiser aussi la sécurité. Mais la question est de savoir comment le faire sans perdre le contrôle. Nous avons su convaincre des clients, dont certains sont très conservateurs, en proposant un système qui permet d’automatiser les changements liés à la sécurité, mais en contrôlant leur respect de politiques prédéfinies.

Donc vos concurrents ne sont pas ces spécialistes de l’automatisation de la remédiation ?

Le terme d’orchestration de la sécurité recouvre beaucoup de choses, dont la réponse à incident automatisée. Mais nous nous positionnons sur un marché différent : nous automatisons le processus du changement. Dans une grande entreprise, il y a généralement beaucoup de contrôles de sécurité différents, comme les pare-feu de nouvelle génération. Chacun fonctionne selon des règles différentes. Certains prennent la forme d’une plateforme Cloud, avec ses politiques de sécurité, comme pour les centres de calcul à définition logicielle (SDDC). Mais les clients veulent pouvoir disposer d’une interface, d’un point d’administration unique, où opérer des changements très rapidement, sans avoir à se pencher sur la topologie du réseau, des interfaces utilisateur différentes, etc.

Une plateforme comme la vôtre doit donner sa pleine valeur avec des environnements DevOps, ou des architectures de micro-services, notamment ?

Oui, la valeur est dans l’agilité métier gagnée sans perte en sécurité, parce que chaque changement est automatisé. Dans de nombreuses entreprises aux architectures traditionnelles, chaque changement peut prendre des semaines, ou des mois. Ce n’est pas acceptable lorsque l’on passe aux DevOps, aux micro-services ou à l’intégration continue, parce que tout est alors très rapide. Mais tout se trouve ralenti si des interventions manuelles sont requises sur un pare-feu, par exemple.

Et puis une approche comme celle que nous permettons d’adopter peut contribuer à l’intégration de la sécurité dans les approches DevOps, alors que, généralement, elle en est largement absente.

Pour que cela fonctionne, une intégration étroite avec éditeurs et équipementiers paraît nécessaire. Tous jouent le jeu ?

Il y a dix ans, l’intégration avec les pare-feu était très difficile. Mais aujourd’hui, les équipementiers comprennent l’enjeu ; ils savent qu’il faut pouvoir s’intégrer si l’on ne veut pas être remplacé. Check Point ou encore Fortinet misent beaucoup sur l’intégration. Même les FirePower de Cisco sont pleinement automatisables via des API. Désormais, proposer des interfaces pour l’intégration est devenu standard, et cela vaut aussi dans le Cloud.

Mais chacun a des modèles et des interfaces différentes. Il n’y a rien de comparable entre ce que propose là un Palo Alto Networks et un Fortinet, par exemple. L’une des choses que nous apportons, est une couche d’unification. Les équipementiers ne sont pas encouragés à standardiser : ils préfèrent chercher à fidéliser leurs clients. Et là encore, cela vaut pour le Cloud. C’est la règle du jeu. Mais dans le monde des pare-feu, cela va très loin. Chaque pare-feu est très différent des autres. Le modèle unifié que nous apportons nécessite beaucoup de travail, en continu. Les équipementiers présentent régulièrement des nouveautés. Mais ce sont de bons partenaires. Nous avons accès à leurs versions béta et nous travaillons avec eux en amont pour être prêts à la sortie des nouvelles versions de leurs logiciels embarqués.

Les réseaux à définition logicielle doivent là apporter un changement considérable…

Oui, et cela que l’on parle de SDN en cloud public ou privé. Ils apportent une automatisation, une agilité bien plus grandes. Vous pouvez déployer une machine virtuelle et configurer le réseau en conséquence automatiquement. L’administration et l’agilité de l’IT y gagnent considérablement. Mais il y a un défi : les entreprises ont des environnements hybrides, avec réseau traditionnel, SDN privé, mais aussi infrastructure Cloud publique… Les entreprises auront toujours un environnement hybride et voudront l’administrer aussi simplement que possible. Nous apportons une couche d’abstraction indispensable à cela. D’ailleurs, d’ici la fin de l’année, nous annoncerons le support de l’automatisation pour les environnements NSX ; ce sera une première sur le marché.