J’ai un secret à vous révéler aujourd’hui. Parmi la demi-douzaine de postes de responsable de la sécurité des systèmes d’information (RSSI) que j’ai occupés au cours des 20 dernières années, un seul m’a recruté à la suite d’une faille de sécurité. Un seul.
Les cinq autres postes étaient devenus vacants soit à la suite d’un départ, soit parce que le titulaire avait été remplacé après avoir perdu la confiance des principales parties prenantes. Dans la moitié des cas, le remplacement était dû à une perte de confiance, et non à une faille de sécurité.
Pourquoi les RSSI doivent comprendre leur environnement d’API
Dans le domaine de la sécurité des API, la nécessité pour les RSSI de comprendre leur exposition aux risques liés aux API peut se résumer en quelques affirmations.
Tout d’abord, pour créer un modèle de menace pour un environnement donné, vous devez connaître quatre éléments : vos actifs, les acteurs, les interfaces et les actions. Autrement dit : « Qui fait quoi, sur quoi et par quel moyen ? »
Deuxièmement, le « I » d’API signifie « interface ». Les interfaces de programmation d’applications sont largement utilisées sur de multiples plateformes, avec différents langages et frameworks, et la quasi-totalité des développements logiciels modernes privilégient désormais les API. Votre environnement comporte forcément des API.
Troisièmement, si, en tant que RSSI, vous ne disposez pas d’un inventaire des interfaces qui exposent et fournissent vos données sensibles, que ce soit en interne ou à vos applications web et mobiles, votre modèle de menace est incomplet et comporte donc des angles morts là où les services et les données sont exposés.
Enfin, les modèles de menace incomplets ne permettent ni une supervision exhaustive de la sécurité ni la démonstration de la diligence requise, deux aspects essentiels dont les auditeurs et les autorités de réglementation doivent garantir la mise en œuvre. Il leur incombe de veiller à ce que les actifs, les acteurs, les interfaces et les actions au sein d’un environnement donné soient bien compris et gérés.
Évaluer votre exposition aux risques de sécurité des API
Chez F5, nous tenons à ce que nos clients soient toujours les personnes les mieux informées. Nous avons donc dressé une courte liste de questions qui vous permettront d’évaluer l’état actuel de votre écosystème d’API. En y répondant dès maintenant, vous serez prêt si elles vous sont posées ultérieurement lors d’un examen sur le terrain ou d’un audit externe.
“En démontrant que vous maîtrisez et faites évoluer votre posture de sécurité des API, vous conserverez la confiance que vous avez eu tant de mal à gagner.”
J’ai personnellement soumis ces questions à des régulateurs et à des contrôleurs de plusieurs organismes. Maintenant que la Commission fédérale des communications des États-Unis a commencé à infliger des amendes et à conclure des accords amiables visant spécifiquement les problèmes liés aux API, et que la version actuelle de la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS) 4.0+ exige expressément la conformité des API lors du développement, le moment n’a jamais été aussi propice pour que les équipes de défense disposent de ces réponses à portée de main.
Même si vous ne pouvez pas répondre à toutes ces questions, il est essentiel pour les RSSI de savoir où vous en êtes et de faire preuve d’une démarche proactive. En montrant que vous maîtrisez et faites évoluer votre posture de sécurité des API, vous conserverez la confiance que vous avez eu tant de mal à gagner.
Voici la liste, du plus simple au plus difficile. Si vous ne parvenez pas à aller aussi loin dans la liste que vous le souhaiteriez, contactez votre équipe F5. Nous sommes là pour vous aider.
- Qui est responsable de la sécurité des API dans notre entreprise ?
- Des responsables sont-ils désignés pour nos API ?
- Quelle part de notre chiffre d’affaires provient des API ?
- Combien d’API avons-nous ?
- Combien d’entre elles sont activement utilisées, et combien sont inactives ?
- Combien sont vulnérables aux 10 problèmes d’API les plus courants ?
- Nos tests d’intrusion couvrent-ils suffisamment les vulnérabilités des API et les attaques visant la logique métier en production ?
- Lesquelles de nos API transmettent ou reçoivent des données soumises à des exigences légales ou réglementaires ?
- Observons-nous du trafic malveillant ? Sur quels points de terminaison d’API ?
- Quel est notre niveau global de risque en matière de sécurité des API ? S’est-il amélioré ou dégradé par rapport à la même période l’année dernière ?
- Certaines équipes de développement génèrent-elles davantage de problèmes liés aux API que d’autres ? Comment sont-elles formées et informées des problèmes de sécurité des API ?
- Existe-t-il un processus de validation des modifications apportées au code et aux API avant leur mise en production ?
- Qui reçoit les alertes concernant les événements de sécurité détectés sur nos API ?
- Quel est le délai de réponse moyen, en minutes, lorsqu’une attaque par défaut d’autorisation au niveau des objets (BOLA) est détectée contre l’une de nos API de production ?
- Et enfin, revenons au premier point fondamental de la liste : les personnes que nous considérons comme responsables de la sécurité des API savent-elles et reconnaissent-elles qu’elles en sont responsables ?
Renforcer votre posture de sécurité
Évaluer votre environnement d’API et la menace potentielle que représentent les API constitue la première étape pour mettre au jour les angles morts et renforcer votre posture de sécurité.
Rejoignez F5 cette semaine à l’événement « API World » à Santa Clara, en Californie, pour tout savoir sur les API. J’interviendrai jeudi à 13 h (heure du Pacifique) aux côtés de deux de mes collègues lors d’une session ouverte intitulée « Un monde d’IA est un monde d’API : sécuriser les applications les plus modernes ». Cette même session se tiendra également en ligne le jeudi 14 novembre à 13 h.
F5 organisera également la session virtuelle « API CTF : découvrez les fondamentaux de la sécurité des API » le mardi 12 novembre à 9 h.
Vous ne vous rendez pas à API World ? Découvrez notre démo sur la sécurité des API.
À propos de l’auteur
Articles 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.