La surprenante vérité sur la transformation numérique : Sauter la sécurité

Il s’agit du troisième blog d’une série sur les défis posés par la transformation numérique.

• La surprenante vérité sur la transformation numérique
• La surprenante vérité sur la transformation numérique : Chaos des nuages

Sauter la sécurité.

Il ne sera pas surprenant pour de nombreux vétérans de l’informatique de savoir que lorsque les performances des applications deviennent un problème, la sécurité est souvent le premier service à disparaître. Pare-feu en panne face à une attaque ? Éteins-le. Des services débordés par une demande soudaine ? Éteignez-les.

Depuis vingt ans, nous mettons systématiquement la sécurité à la porte lorsque les performances des applications deviennent problématiques.

Il n’est donc pas surprenant que face aux performances des pipelines, la sécurité soit souvent négligée.

Neuf dirigeants sur dix admettent se sentir obligés de commercialiser leurs applications plus rapidement et plus fréquemment grâce à la transformation numérique.

Peu importe que les dirigeants transmettent explicitement ou implicitement cette pression aux responsables ; les développeurs et les responsables opérationnels se sentent souvent sous pression lorsqu’il s’agit de sortir des applications en un temps record.

Et c'est peut-être pour cela qu'ils admettent avoir sauté les contrôles de sécurité. Près de la moitié (44 %) des développeurs mobiles et IoT interrogés par IBM/Arxan l’ont fait, et il est probable que les développeurs d’autres secteurs admettraient la même chose.

La sécurité est difficile, après tout. Il existe une vaste surface d’attaque, et aucune couche n’est épargnée. Du réseau à la plateforme en passant par l’application, il existe plus de moyens d’infiltrer les applications et d’exfiltrer les données qu’il n’y a de couches dans le réseau.

Mais si nous examinons les plus grandes violations de données survenues ces derniers temps, nous verrons émerger un modèle qui pourrait aider tout le monde à concentrer son temps limité sur les risques les plus élevés.

Nous avons tous entendu parler de la violation de données d’Equifax. Nous connaissons les détails sordides et, comme de nombreuses autres organisations, ils ont été victimes d'une vulnérabilité publiée et exécutée contre un framework tiers non corrigé via une plateforme Web. La découverte a probablement été réalisée, mais non vérifiée, via un robot / script automatisé recherchant des cibles probables. Probablement parce qu’une grande majorité des activités des robots de nos jours ne sont pas des attaques, mais des missions de reconnaissance et d’exploration.

Il s’avère que cela fait longtemps que personne n’a réussi à s’infiltrer via SSH ou via une vulnérabilité réseau. Les attaquants d’aujourd’hui s’attaquent aux applications et aux identifiants, et ils utilisent des robots pour trouver des vulnérabilités lucratives et mener l’attaque.

Les trois principaux risques de sécurité contre lesquels vous devez protéger les applications sont :

• Top 10 de l'OWASP. SQLi, XSS, injection de commande, injection No-SQLi, parcours de chemin et ressource prévisible
• CVE. Apache, Apache Struts, Bash, Elasticsearch, IIS, JBoss, JSP, Java, Joomla, MySQL, Node.js, PHP, PHPMyAdmin, Perl, Ruby On Rails et WordPress.
• Les robots. Scanners de vulnérabilité, scrapers Web, outils DDoS et outils de spam de forum.

C'est ici que la standardisation de la plateforme et de la politique de sécurité rencontre l'architecture par application pour fournir efficacement un moyen de remédier au risque avant qu'il ne devienne une menace existentielle. La standardisation sur une plateforme signifie la capacité de standardiser sur une politique. Grâce à cette combinaison, les professionnels de la sécurité peuvent créer une politique de sécurité standard de base qui peut ensuite être déployée automatiquement sur chaque application, la protégeant immédiatement contre les dernières menaces. Étant donné qu’il s’agit d’une solution par application, des protections spécifiques à l’application peuvent être ajoutées pour fournir une protection supplémentaire, mais au minimum, vous serez plus sûr de savoir que les vecteurs d’attaque les plus probables sont couverts.

L’autre avantage d’une architecture par application est que les applications ne sont normalement pas protégées par quelque chose comme un WAF (ouais, je sais, pourquoi le serait-il ? Mais croyez-moi, il existe des) qui peuvent être protégés à court terme en injectant une nouvelle instance avec les politiques appropriées dans le pipeline d'application 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.

La réponse aux développeurs qui négligent la sécurité en raison des pressions liées à la transformation numérique est de normaliser. Normalisez-vous sur une plateforme de sécurité d'application commune afin de pouvoir exploiter sa capacité à standardiser les politiques et à les intégrer dans le pipeline comme un pro.

Restez à l’écoute pour le prochain article de cette série, dans lequel nous verrons comment vous pouvez gérer la déséconomie d’échelle découlant de la tendance de la transformation numérique à créer plus d’applications qu’il n’y a d’opérations.