L’article suivant est basé sur un série de webinaires sur la sécurité des API d’entreprise par Imvision, avec des conférenciers experts d’IBM, Deloitte, Maersk et Imvision discutant de l’importance de centraliser la visibilité d’une organisation sur ses API afin d’accélérer les efforts de remédiation et d’améliorer la posture de sécurité globale.
La centralisation de la sécurité est un défi dans l’écosystème ouvert d’aujourd’hui
Lorsqu’on aborde la visibilité des API, la première chose que nous devons reconnaître est que les entreprises d’aujourd’hui évitent activement de gérer toutes leurs API via un seul système. Selon Tony Curcio, directeur de l’ingénierie d’intégration d’IBM, bon nombre de ses entreprises clientes travaillent déjà avec des architectures hybrides qui exploitent une infrastructure sur site classique tout en adoptant SaaS et IaaS auprès de divers fournisseurs de cloud.
Ces architectures visent à augmenter la résilience et la flexibilité, mais sont bien conscientes qu’elles compliquent les efforts de centralisation » pour : « Ces architectures visent à augmenter la résilience et la flexibilité, mais au prix de compliquer les efforts de centralisation. Emplacement de l’API avec déploiement dans chacun de ces emplacements, pour assurer une plus grande visibilité et une meilleure gestion des activités commerciales liées à l’API.
Le défi pour les équipes de sécurité est qu’il n’y a pas un endroit central où toutes les API sont gérées par l’équipe de développement – et avec le temps, cette complexité ne fera probablement qu’empirer. De plus, cette complexité ne s’arrête pas au niveau de l’infrastructure, mais se prolonge jusqu’à la couche applicative.
Moe Shamim de Deloitte, cadre supérieur de la technologie et RSSI adjoint de US Consulting, considère que le développement d’applications non monolithiques est essentiel. Il affirme que les entreprises doivent désormais décomposer ces millions de lignes de code en processus et systèmes modulaires basés sur des API afin de rester compétitives, tout en veillant à ce que les vecteurs de menace soient réduits au minimum. Cela nécessite une refonte importante car il faut désormais prendre en compte les passerelles API, les IAM, la limitation et plus encore, ce qui signifie un temps et des ressources importants.
L’empreinte API des organisations n’augmente plus de manière organique au fil du temps. Il se compose désormais de diverses API dont les origines proviennent de fusions et acquisitions, de la gestion des versions, d’API internes, d’API tierces, d’une dérive par rapport à l’utilisation prévue d’origine, à des fins de développement, de test, de débogage et de diagnostic, etc. Cela fait de la complexité un problème encore plus important, car de nombreuses API ne sont ni documentées ni gérées, et il va sans dire – non protégées.
D’où viennent les « API fantômes » ? |
L’application d’un programme cohérent dans chacun des différents environnements où se trouvent les actifs de l’entreprise est un défi dans cette réalité de cloud hybride. Il faut tenir compte de ce défi de cohérence lors de la sélection des piles technologiques, de sorte que l’application des politiques et des programmes de gouvernance partout ne soit pas un problème.
Mais c’est plus facile à dire qu’à faire, en particulier dans les entreprises prospères qui fusionnent et acquièrent d’autres organisations : chaque entreprise utilise des technologies différentes, imposant un processus de sécurité API personnalisé et sur mesure pour chaque nouvel environnement ajouté.
Cycle de vie des API ? Mode de vie API !
Selon Moe Shamim, le cycle de vie de l’API peut se résumer aux piliers trouvés dans l’image ci-dessous. Lors de l’élaboration d’une stratégie de sécurité des API, il faut prendre en compte l’architecture, la distribution, la conception et toute une série d’autres aspects qui ont un impact sur la façon dont une organisation développe son approche des API. Vous pouvez examiner chacun de ces aspects en tant que contrôles que vous injectez à chaque étape du cycle de vie de l’API. Et cela est essentiellement lié à la visibilité et à la centralisation discutées ci-dessus.
Une image des piliers du style de vie de l’API |
Planification détermine des problèmes tels que l’utilisation des API uniquement dans le pare-feu du réseau ou publiquement, ainsi que des problèmes tels que l’authentification. Il abordera également des problèmes plus techniques tels que les versions, les types de passerelles et les langages de programmation que vous utiliserez. L’important – et cela vaut pour chaque décision que vous prenez concernant votre posture de sécurité – est de faire un choix qui s’aligne avec votre écosystème d’outils et prend en compte votre modélisation des menaces.
Dans le Construire pilier, l’analyse des problèmes OWASP Top 10 est un must, et les outils SAST sont parfaits pour cela. Le pentest et la gestion des versions ne sont pas nécessairement intégrés à votre posture de sécurité, mais ce sont deux mécanismes puissants qui profiteront sûrement à votre arsenal de sécurité.
Les Fonctionner pilier inclut des problèmes tels que la limitation, la mise en cache et la journalisation. Un mécanisme de journalisation et de surveillance robuste est indispensable dans la phase de correction, car il vous permet de corriger les vulnérabilités d’une version à l’autre.
Enfin, nous arrivons au Se retirer pilier du cycle de vie. La suppression des points de terminaison qui ne sont plus utilisés est une bonne pratique essentielle ; en gros, si vous n’avez plus besoin d’un service, ne le laissez pas activé. Et si vous n’avez plus du tout besoin d’une API, mettez-la simplement hors ligne ; il en va de même pour les comptes cloud.
Tony Curcio affirme que l’un des principes clés de la gouvernance des programmes d’API est la coordination entre les producteurs d’API, la gestion des produits et les consommateurs. L’examen de la disposition de sécurité de chacun de ces personas et la coordination des politiques d’API qui garantissent une utilisation sécurisée pour chacun est un aspect fondamental de la posture de sécurité d’une organisation.
Avoir une mentalité API-first au sein de l’organisation aide certainement. Chez IBM, par exemple, ils créent leur propre technologie de gestion des API qui leur permet d’exposer, de sécuriser et de protéger plus facilement leurs API. Avoir la technologie de pointe derrière vous–comme Imvison–va aussi un long chemin. Leur technologie d’IA nous aide à mieux comprendre les vecteurs d’attaque, y compris les problèmes critiques tels que leur source.
Adopter une approche de réponse de sécurité fondée sur le renseignement
Gabriel Maties, architecte de solutions senior chez Maersk, offre une autre perspective. Maersk étant depuis trois ans dans un programme API et suite à une brèche grave, la cybersécurité est constamment prise en compte comme un moyen de rester au moins aussi bon que les attaquants, sinon meilleur.
Partageant son point de vue sur l’observabilité, Gabriel considère la gestion des API comme une discipline multi-acteurs dès le départ car elle partage les ressources et les expose en interne. Par conséquent, chaque point d’entrée dans votre système et ses mécanismes de soutien doivent être soigneusement observés et surveillés de manière centralisée.
Cette centralisation est importante car l’observabilité est multidimensionnelle dans le sens où il n’y a jamais un seul aspect à surveiller. Cela nécessite une vue holistique des API qui vous permet de comprendre facilement où les API sont déployées, à qui elles appartiennent, qui les consomme, comment elles sont consommées, à quoi ressemble la consommation normale et comment chacune est protégée. La centralisation vous permet également de mieux comprendre à quoi ressemble le cycle de vie de chaque API, combien de versions existent, quelles données sont partagées, où elles sont stockées et qui les utilise.
La centralisation est le seul moyen de gérer cet écosystème complexe d’une manière qui assure un maximum d’avantages et un minimum de risques.
Une image des couches de visibilité de l’API |
Avoir une observabilité centralisée permet en outre des informations, ce qui vous permet de prendre des mesures sur vos observations. L’observabilité vous permet d’examiner les attaques actives en cours dont vous n’êtes peut-être même pas au courant et même de formuler des stratégies qui tirent parti des actions entreprises sur la base des informations que vous tirez de vos observations.
La sécurité basée sur des règles est très efficace, et l’apprentissage automatique et l’apprentissage en profondeur sont deux technologies qui l’automatisent et la rationalisent. Il n’y a tout simplement pas d’autre option car la quantité de données à gérer est écrasante, sans parler du fait que ces technologies permettent une protection adaptative contre les menaces qui aide à faire face aux nouvelles menaces.
La mauvaise nouvelle est que les pirates informatiques utilisent également ces mêmes technologies, et y faire face nécessite une maturité organisationnelle importante pour prendre les mesures nécessaires pour gérer cela. Nous parlons ici de certaines actions lourdes, telles que la désactivation des équilibreurs de charge, le basculement des pare-feu et d’autres changements d’infrastructure effectués de manière automatique et rapide. Cela ne peut se faire sans un niveau élevé de maturité dans l’ensemble de l’organisation.
L’apprentissage automatique supervisé peut aider les organisations à développer cette maturité. Il vous permet de gérer un grand nombre d’ensembles de règles et d’informations afin que vous puissiez concevoir des flux d’action automatiques. La science des données offre un savoir-faire important en termes de suivi du comportement spécifique des attaquants, ce qui est essentiel lorsqu’il existe différentes sources et des menaces avancées et persistantes.
Cette réponse de sécurité basée sur le renseignement permet une réponse adaptative et réflexive continue qui s’appuie sur des preuves quantifiées lors de la modification et de la mise à jour des règles et des processus. C’est le seul moyen de faire face aux attaques de plus en plus sophistiquées auxquelles nous assistons.
Les écrans sont devenus noirs : une histoire d’attaque réelle
Gabriel a parlé d’un vraie attaque qu’il a vécu en travaillant à la chez Maersk. Un jour, environ neuf mois après son arrivée, leurs écrans se sont éteints. Les actions de déconnexion et de déconnexion n’ont pas aidé, il était déjà trop tard et en quelques minutes, des milliers d’ordinateurs ont été rendus inutilisables.
Il ne s’agissait pas d’une attaque pour incitations financières, mais plutôt d’une attaque destructrice destinée à mettre la chez Maersk à genoux. Le seul choix de Gabriel et de son équipe était de reconstruire, car les attaquants utilisaient un cryptage à sens unique. De toute évidence, lors de la reconstruction du système, la cybersécurité était une priorité majeure. L’analyse dynamique était considérée comme primordiale pour leurs efforts afin qu’ils puissent effectuer une analyse en temps réel pour renforcer l’apprentissage continu et l’adaptation aux menaces. Leur objectif était d’apprendre à quoi ressemblaient les comportements internes normaux et anormaux, car 80% des attaques sont internes.
Après l’attaque, Gabriel a proposé 4 niveaux d’observabilité, des contrôles de santé et un moyen de déterminer si la santé d’un système a été compromise. Tous les processus et décisions d’architecture sont désormais soumis à une évaluation de la cybersécurité et doivent passer un certain nombre de contrôles et d’équilibres. Cela ne signifie pas que toutes les cases doivent être cochées pour obtenir l’approbation d’un nouveau processus ou d’une nouvelle décision, car le point principal ici est de connaître vos lacunes et vos faiblesses afin que vous puissiez tirer parti des capacités et des fournisseurs appropriés pour votre philosophie de sécurité. .
Au cours des 2 dernières années, nous avons vu une tendance croissante des organisations à adopter des outils d’API spécifiques qui aident à surveiller, découvrir et désinstaller les API fantômes pour mieux comprendre leurs risques. C’est un grand développement, car les API sont totalement différentes du monde des applications d’où nous venons. La seule façon de protéger les API est d’adopter des outils et des processus uniques qui ont été spécialement conçus pour elles.
Sécurité de l’API : embarquer la carte
La prolifération et la gravité des attaques de cybersécurité dans notre paysage incitent les conseils d’administration et les dirigeants de nombreuses entreprises à s’intéresser davantage à la protection des API. Une visibilité accrue est un autre moyen d’amener les dirigeants à comprendre les risques auxquels ils sont exposés. Si vous pouvez trouver un moyen de montrer facilement à vos dirigeants combien de données non protégées sont en danger, vous avez gagné la moitié de la bataille.
Cette visibilité permettra, à son tour, une posture de cybersécurité plus adaptative et réflexive qui vous permettra d’apprendre en permanence, de tirer des enseignements et de modifier votre posture en réponse à de nouveaux types d’attaques.
Développer une posture de sécurité cohérente et visible sur tous les actifs de votre entreprise est un principe central de toute stratégie de cybersécurité robuste. Cette posture de sécurité doit prendre en compte les quatre piliers du cycle de vie de l’API : planifier, créer, exploiter et retirer. Pour le faire correctement, vous devez choisir les technologies qui vous permettront d’appliquer les politiques, les outils et la gouvernance que vous avez choisis au début de votre parcours de sécurité API.
Il est tout aussi important de développer une stratégie holistique et centralisée qui offre la visibilité dont vous avez besoin pour protéger vos actifs. Les technologies avancées de ML et d’apprentissage en profondeur fournies par des entreprises innovantes comme Imvision peuvent certainement vous aider à y parvenir.