Ceci est le troisième article d’une série consacrée aux défis liés à la transformation numérique.
- La vérité surprenante sur la transformation numérique
- La vérité surprenante sur la transformation numérique : le chaos du cloud
Négliger la sécurité.
De nombreux vétérans de l’informatique ne seront pas surpris d’apprendre que, lorsque les performances d’une application deviennent problématiques, la sécurité est souvent le premier service à être sacrifié. Le pare-feu flanche face à une attaque ? Désactivez-le. Les services sont submergés par une hausse soudaine de la demande ? Désactivez-les.
Depuis vingt ans, nous sacrifions systématiquement la sécurité dès que les performances des applications deviennent problématiques.
Il n’est donc pas surprenant que, face aux impératifs de performance des pipelines, la sécurité soit souvent négligée.
Neuf dirigeants sur dix reconnaissent subir des pressions pour commercialiser les applications plus rapidement et plus fréquemment en raison de la transformation numérique.
Que les dirigeants transmettent explicitement ou implicitement cette pression aux personnes concernées importe peu ; les équipes de développement et d’exploitation se sentent souvent sous pression lorsqu’il s’agit de déployer des applications en un temps record.
Et c’est peut-être pour cette raison qu’ils reconnaissent faire l’impasse sur la sécurité. Près de la moitié (44 %) des développeurs d’applications mobiles et d’objets connectés interrogés dans le cadre d’une enquête IBM/Arxan l’ont admis, et il est probable que les développeurs d’autres secteurs en diraient autant.
Après tout, la sécurité est complexe. La surface d’attaque est vaste, et aucune couche n’est épargnée. Du réseau à la plateforme en passant par l’application, les moyens de s’introduire dans les applications et d’exfiltrer des données sont plus nombreux que les couches du réseau.
Mais si nous examinons les plus importantes failles de sécurité de ces dernières années, nous verrons se dégager une tendance qui pourrait aider chacun à consacrer son temps limité aux risques les plus importants.
Nous avons tous entendu parler de la fuite de données d’Equifax. Nous en connaissons les détails sordides et, comme beaucoup d’autres organisations, l’entreprise a été victime de l’exploitation, via une plateforme web, d’une vulnérabilité publiée affectant un framework tiers non corrigé. La cible a probablement été repérée, sans que cela ait été confirmé, par un bot ou un script automatisé à la recherche de cibles potentielles. Cela est vraisemblable, car aujourd’hui, une grande majorité de l’activité des bots ne relève pas d’attaques, mais de missions de reconnaissance exploratoires.
Cela fait en réalité bien longtemps que quelqu’un n’a pas réussi à s’introduire via SSH ou en exploitant une vulnérabilité réseau. Aujourd’hui, les attaquants ciblent les applications et les identifiants, et utilisent des bots pour repérer des vulnérabilités lucratives — puis mener l’attaque.
Les trois principaux risques de sécurité contre lesquels vous devez protéger vos applications sont les suivants :
- Top 10 de l’OWASP. Injection SQL, XSS, injection de commandes, injection NoSQL, traversée de répertoires et ressources prévisibles
- CVE. Apache, Apache Struts, Bash, Elasticsearch, IIS, JBoss, JSP, Java, Joomla, MySQL, Node.js, PHP, PHPMyAdmin, Perl, Ruby On Rails et WordPress.
- Bots. Scanners de vulnérabilités, extracteurs de données web, outils DDoS et outils de spam sur les forums.
C’est ici que la standardisation de la plateforme et des politiques de sécurité s’allie à une architecture par application afin de fournir un moyen efficace de réduire les risques avant qu’ils ne deviennent une menace existentielle. Standardiser la plateforme permet également de standardiser les politiques. Grâce à cette combinaison, les professionnels de la sécurité peuvent créer une politique de sécurité de base commune, puis la déployer automatiquement sur chaque application afin de la protéger immédiatement contre les menaces les plus récentes. Cette approche étant propre à chaque application, des mesures de protection spécifiques peuvent être ajoutées pour renforcer la sécurité. Mais vous aurez au minimum l’assurance que les vecteurs d’attaque les plus probables sont couverts.
L’autre avantage d’une architecture par application est que les applications qui ne sont normalement pas protégées par une solution telle qu’un WAF (oui, je sais, comment est-ce possible ? Mais croyez-moi, il y en a) peuvent l’être à court terme en injectant dans le pipeline applicatif une nouvelle instance dotée des politiques appropriées, aussi longtemps que nécessaire. Ainsi, lorsque cette CVE sera publiée – et elle le sera –, les professionnels de la sécurité pourront immédiatement mettre en œuvre une politique d’atténuation et l’injecter dans le chemin de chaque application vulnérable avant qu’elle ne puisse être exploitée.
Pour éviter que les développeurs ne fassent l’impasse sur la sécurité sous la pression des impératifs de livraison liés à la transformation numérique, la solution consiste à standardiser. Adoptez une plateforme commune de sécurité des applications afin de tirer parti de sa capacité à standardiser les politiques et à les intégrer au pipeline comme un pro.
Ne manquez pas le prochain article de cette série, dans lequel nous verrons en détail comment faire face aux déséconomies d’échelle découlant de la tendance de la transformation numérique à créer plus d’applications que les équipes d’exploitation ne peuvent en gérer.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.