Accueil Cybersécurité Rohde & Schwarz Cybersecurity : cap sur le “Security as code”

Rohde & Schwarz Cybersecurity : cap sur le “Security as code”

La configuration avancée du "WAF R&S Web Application Firewall" peut être réalisée via ses graphes visuels. L’éditeur vient de dévoiler un connecteur Redis qui doit permettre d’aller encore plus loin en termes d’automatisation.

L’éditeur fait évoluer son offre WAF afin de s’adapter à des systèmes d’information de plus en plus hybrides et des pratiques d’exploitation qui tendent désormais vers le Security as code. Edouard Viot, chef de produit chez Rohde & Schwarz Cybersecurity, donne des précisions à Solutions Numériques.

Alors que, selon une enquête Markess, 51 % des DSI déclarent aller vers le multicloud d’ici à 2021, Rohde & Schwarz Cybersecurity pousse ses pions. L’objectif est de faire de son offre “R&S Web Application Firewall” le WAF unique pour ces divers environnements Cloud qui offrent leurs propres firewalls. « Nous poussons en faveur du côté agnostique de notre WAF (Web Application Firewall) » résume à Solutions Numériques Edouard Viot, chef de produit chez Rohde & Schwarz Cybersecurity.

« Chaque fournisseur cloud pousse ses propres briques de sécurité, c’est le cas d’AWS, Azure ou GCP, et les entreprises sont bien évidemment tentées d’utiliser ces briques directement sachant qu’elles s’appuient sur d’autres solutions, sur leurs infrastructures on-premise ou sur un Cloud privé. » Cette diversité de solutions coûte cher notamment en temps de formation et de paramétrage, puis dans le traitement des faux positifs.

Un niveau de sécurité uniforme quel que soit le lieu où est hébergée l’application

Avec une console de management unique pour un WAF qu’il est possible de déployer chez les trois grands hyperscalers du Cloud public, l’éditeur cherche à séduire ces entreprises pour qui le Cloud hybride est une réalité. « Si on prend l’exemple d’un grand groupe qui gère 5 000 applications dont 400 dans le Cloud public et 600 dans un Cloud privé et ses applications legacy dans ses propres datacenters. Il va avoir une façon unique de déployer sa politique de sécurité, indépendamment de ces modes de déploiement différents. De plus, cela permet d’assurer un niveau de sécurité homogène, ce qui veut dire que l’entreprise n’aura plus à tolérer des applications moins bien sécurisées selon l’endroit où elles sont déployées. »

Une même console d’administration permet d’administrer le parc de WAF quel que soit le Cloud mis en œuvre. En outre, Rohde & Schwarz a implémenté des capacités d’autoscaling dans son logiciel afin que celui-ci puisse réagir aux pics de trafic de la même façon que la plateforme d’exécution de l’application va effectuer un scale-up, puis un scale-down pour faire face au pic. Enfin, outre ce volet purement technique, l’éditeur propose son WAF sur les marketplaces des fournisseurs Cloud en paiement à l’usage, en parallèle à la vente de licences classiques. « Nous avons adopté le “Pay as You Go” des plateformes cloud publiques, mais nous savons aussi marier ce modèle aux licences classiques et, par exemple, facturer les WAF permanents en Capex et les instances de débordement en Opex. »

Edouard Viot
Edouard Viot 

« L’homogénéité de la sécurité est un souci pour le RSSI. celui-ci ne devrait jamais avoir à tolérer un niveau de sécurité inférieur pour une application parce que celle-ci est déployée sur Azure ou AWS »,

Un WAF taillé pour le Security as code

L’autre grand chantier pour Rohde & Schwarz Cybersecurity est d’inscrire son WAF dans l’approche DevSecOps et plus particulièrement dans l’approche Security as code. « Une bonne partie de notre roadmap de développement porte aujourd’hui sur des fonctionnalités orientées développeur et sur l’intégration dans le pipeline CI/CD. Nous travaillons sur l’intégration avec les outils DevOps, notamment GitLab, des plugins Jenkins, etc. » Les DevOps peuvent effectuer les “commits” des fichiers de configuration, mais l’ambition de l’éditeur est bien de pousser le développeur lui-même à définir le fichier de configuration du WAF en même temps qu’il développe le code source de son application.

« L’approche “Security as Code” pousse le concept un cran plus loin que DevSecOps. Le développeur, qui est celui qui connaît le mieux son application, va donner des informations de contexte, définir par exemple quels types de données attend son API, s’il s’agit d’un nom, d’un prénom, et supprimer tous les caractères hors alphabet, donner une taille maximale de la réponse de l’API, etc. » Le développeur n’a pas à être un expert en cybersécurité, n’a pas à connaître les différents types d’attaque. Ill va indiquer ce qu’il considère comme le fonctionnement normal de son application et le WAF va agir en conséquence pour protéger l’application.
Toujours dans cette approche, L’éditeur a développé un connecteur vers Redis afin d’intégrer des données stockées dans cette base de donnée dans les workflows du WAF. Ainsi, des briques de sécurité, scripts ou les opérateurs d’un SOC peuvent modifier à chaud la politique de sécurité appliquée par les firewalls en temps réel. Une démarche qui vise à améliorer encore l’agilité des briques de sécurité.

 

 

Auteur : Alain Clapaud