Les microservices, les conteneurs et Kubernetes ont créé des angles morts en matière de cybersécurité.

89 % des RSSI pensent que les microservices, les conteneurs et Kubernetes ont créé des angles morts en matière de sécurité des applications, selon une récente étude de Dynatrace

Selon une nouvelle étude publiée par Dynatrace, les RSSI sont de plus en plus préoccupés par le fait que l'adoption croissante des architectures natives du cloud et des pratiques DevSecOps pourrait avoir brisé les approches traditionnelles de la sécurité des applications.

L'étude révèle que 89 % des RSSI pensent que les microservices, les conteneurs et Kubernetes ont créé des angles morts en matière de sécurité des applications. En outre, 71 % d'entre eux admettent qu'ils ne sont pas totalement convaincus que le code est exempt de vulnérabilités avant sa mise en production.

En outre, l'enquête mondiale menée auprès de 700 RSSI montre que 97 % des organisations ne disposent pas d'une visibilité en temps réel des vulnérabilités d'exécution dans les environnements de production conteneurisés. Près des deux tiers (63 %) des responsables de la sécurité informatique affirment que les méthodes DevOps et le développement agile ont rendu plus difficiles la détection et la gestion des vulnérabilités logicielles, et 74 % déclarent que les contrôles de sécurité traditionnels, tels que les scanners de vulnérabilités, ne sont plus adaptés à l'univers natif du cloud.

Pièce jointe 600163

"L'utilisation accrue des architectures cloud-natives a fondamentalement brisé les approches traditionnelles de la sécurité des applications", déclare Bernd Greifeneder, fondateur et directeur technologique de Dynatrace. "Cette étude confirme ce que nous avions prévu depuis longtemps : les analyses de vulnérabilité et les évaluations d'impact manuelles ne sont plus en mesure de suivre le rythme des changements dans les environnements cloud dynamiques et les cycles d'innovation rapides d'aujourd'hui. L'évaluation des risques est devenue presque impossible en raison du nombre croissant de dépendances de services internes et externes, de la dynamique des runtime, de la livraison continue et du développement de logiciels polyglottes qui utilisent un nombre toujours plus grand de technologies tierces. Des équipes déjà très sollicitées sont obligées de choisir entre la vitesse et la sécurité, exposant ainsi leurs organisations à des risques inutiles."

Parmi les autres conclusions, citons qu'en moyenne, les organisations doivent réagir à 2 169 nouvelles alertes de vulnérabilités potentielles de la sécurité des applications chaque mois. Mais 77 % des RSSI affirment que la plupart des alertes de sécurité et des vulnérabilités sont des faux positifs qui ne nécessitent pas d'action, car il ne s'agit pas d'expositions réelles. En outre, 68 % d'entre eux affirment que le volume d'alertes rend très difficile la hiérarchisation des vulnérabilités en fonction du risque et de l'impact.

Source : Dynatrace

Et vous ?

:fleche: Trouvez-vous cette étude pertinente ?

Voir aussi :

:fleche: Les opérations de cybersécurité ont du retard : comment le manque de ressources affecte les analystes de sécurité, une étude mondiale réalisée par Trend Micro

:fleche: Un rapport révèle que le chiffrement des premiers réseaux téléphoniques a été délibérément affaibli, certains appareils sortis même ces dernières années utilisent toujours les mêmes algorithmes

:fleche: La police démantèle un gang de ransomware en Ukraine, qui a piraté un certain nombre de cibles américaines et sud-coréennes

C'est une évidence !

D'autres questions se posent :

- Quel est le pourcentage de projets qui dédient un busget à la sécurité (post création / formation des développeurs) ?
- si il existe un budget sécurité, quel est son pourcentage par rapport au budget total du projet (et de sa maintenance) ?

Et quand on entend parler d'extraction de données cloud parce que les bases elastic search avaient des accès par défaut, on met ça sur le dos du "cloud" ?

My 2cents ;-)

Des tests de sécurité existent , comme les bonnes pratiques , donc pas d 'excuses

Il y a aussi la question du choix des technos. Je serais très curieux de savoir combien de systèmes utilisent Kubernetes alors qu'ils n'en ont absolument pas besoin. J'ai le sentiment que bien souvent c'est le bazooka pour tuer la mouche, lequel bazooka requiert des compétences spécifiques pour bien l'utiliser qui ne sont pas innées même si on est un bon technicien. Dans des TPE/PME je doute qu'une personne principalement dédiée à l'infrastructure soit systématiquement embauchée.

Mon précédent projet c'était le maintien en conditions opérationnelles d'une plateforme de traitement de messageries. Manque de bol, il y avait 2 bibliothèques compilées dont le code source a été perdu. Et donc obligé de mettre le produit dans un container Docker. C'est bien un container docker, le système est resté opérationnel avec ses 2 libs. Par contre, la couche SSL, j'ai utilisé celle du système hôte parce que la couche SSL de l'ancien système vieux de 13 ans, oui mais non... De même, ces 2 libs, plus de code source donc pas moyen de les auditer ou de les mettre à jour. J'aurais préféré les ré-écrire mais malheureusement je n'avais ni les ressources ni le temps ni le budget. Donc en conclusion, les containers c'est bien mais ça crée des failles de sécurité

Le problème de docker/kubernetes, c'est la facilité avec laquelle ça permet de construire des usines à gaz à base de boites noires.

certains créent des containers comme on créerait des fonctions dans un dev normal.

Quand on a qu'un martaud, tout problème est un clou....
quand tu vois un système de LB/HA devant un cluster de containers tomcat qui créent un webservice dont le seul role est de traduire du latin1 en utf-8 pour un morceau de l'app principale... :aie: C'est que visiblement, quelqu'un est devenu fan un peu trop vite.