La sécurisation des applications à l’ère de l’API peut être une bataille difficile. À mesure que le développement s’accélère, la responsabilisation devient floue et le fonctionnement des contrôles devient un défi en soi. Il est temps de repenser nos stratégies de sécurité des applications pour refléter les nouvelles priorités, principes et processus de l’ère API-first. Sécuriser les applications de demain commence par évaluer les risques commerciaux aujourd’hui.
Les tendances et les risques façonnent les applications d’aujourd’hui
Alors que le monde continue de devenir de plus en plus interconnecté via des appareils – et les API qui les connectent – les individus s’habituent de plus en plus à l’expérience sans friction qu’ils offrent. Si cette réalité sans friction est sans doute plus conviviale, c’est-à-dire plus rapide et plus pratique, elle nécessite également un compromis. Cette commodité exige de l’ouverture, et l’ouverture est un risque en matière de cybersécurité.
Selon Sidney Gottesman, SVP de Mastercard pour l’innovation en matière de sécurité, la situation ci-dessus conduit à l’une des plus grandes tendances qui façonnent la posture de sécurité pour les applications d’aujourd’hui : crise de confiance entre les individus et les applications qu’ils utilisent.
Une deuxième tendance majeure est celle de la chaîne d’approvisionnement. Il ne suffit pas de gérer vos propres risques, car les attaques pénètrent de plus en plus les systèmes internes via des composants tiers fournis par des fournisseurs. Dans les produits numériques et même les produits matériels connectés, les chaînes d’approvisionnement sont désormais composées de différents services regroupés dans le produit final via des API, créant un nouveau type de risque d’intégration enraciné dans la chaîne d’approvisionnement.
Si le récent pipeline colonial et JBS les attaques indiquent n’importe quoi, c’est qu’une autre tendance majeure est la abondance d’acteurs malveillants, tant au niveau individuel qu’au niveau de l’État. Les entreprises doivent désormais partir du principe qu’elles seront attaquées le plus tôt possible et qu’elles doivent être préparées.
Abondance de données Ne peut pas être ignoré. Les entreprises stockent, gèrent et permettent l’accès à tant de données, ce qui rend la couche d’application (et les API) plus attrayante pour les attaquants. En augmentant règlements visant à améliorer les postures de sécurité des entreprises publiques et privées occupent également une place particulière dans le paysage des tendances en matière de sécurité.
La sécurité des applications n’est plus ce qu’elle était
80% des entreprises autorisent actuellement l’accès externe aux données et aux fonctionnalités via les API, selon une récente enquête de l’industrie publiée par Imvision, examinant l’état actuel de l’utilisation et de l’adoption des API parmi les principales entreprises. Les résultats sont conformes à d’autres recherches sur le sujet et concluent que les entreprises sont beaucoup plus ouvertes qu’elles ne l’étaient il y a quelques années à peine – et en croissance.
Mais cela signifie que la sécurité des applications a dépassé son statut de « portier » consistant à demander « qui est autorisé à entrer ? » De nos jours, la sécurité des applications doit supposer que les utilisateurs sont déjà à l’intérieur de l’application et se concentrer sur la question « que leur permettons-nous de faire ? », « quelle est l’utilisation prévue ? et « comment arrêter les comportements indésirables ? ».
Selon Rob Cuddy, l’évangéliste mondial de la sécurité des applications chez HCL, le changement fondamental que les entreprises doivent effectuer dans leur approche de la sécurité des applications est que sécuriser le périmètre des applications contre la pénétration externe n’a tout simplement pas de sens à l’ère des API.
La création de couches de sécurité autour de l’application ne fonctionnera pas lorsque l’application est exposée via des API. Au lieu de cela, un nouveau approche à l’envers est requis. Cette nouvelle approche suppose la pénétration de l’application au service de l’utilisateur, mais met en place des mécanismes de protection au cas où l’acteur serait malveillant.
Si vous demandez aux développeurs, ils vous diront que la sécurité était là depuis le début, mais maintenant elle est devenue critique. Cependant, il ne s’agit pas d’ajouter de nouveaux outils ou automatisations, mais plutôt d’effectuer un changement fondamental dans les personnes, les processus et la culture.
Dans la course aux livraisons agiles ultrarapides, de nombreuses entreprises adoptent une approche DevSecOps qui impose l’intégration de pratiques de sécurité dans le cycle de vie du développement. Mais alors que beaucoup parlent de le faire, seulement la moitié environ font quelque chose à ce sujet – ce qui signifie qu’ils ont réellement mis en place une sécurité d’API pour le cycle de vie complet.
Gérer la sécurité entre des équipes disparates n’est pas une tâche facile
Chez Allegiant Airlines, responsable de la sécurité de l’information Rob Hornbuckle dirige une initiative intéressante pour améliorer la sensibilisation, la visibilité et la collaboration entre les équipes et le cycle de vie du développement.
Pour développer et maintenir leurs applications orientées client, ils disposent à tout moment de 10 équipes de développement permanentes. Cependant, orchestrer la sécurité entre des équipes disparates n’est pas une promenade de santé. Elle nécessite une visibilité importante et un changement de culture qui encourage l’initiative et la prise de responsabilité.
Pour maintenir la sécurité au premier plan, ils ont mis en place un programme de champion de la sécurité qui place deux personnes dans chaque équipe avec la responsabilité de garantir certaines normes de sécurité pendant le développement. Ces champions aident le reste de l’équipe à développer les connaissances et la communication dans l’ensemble du système.
Ce programme permet une visibilité sur la sécurité des applications au niveau organisationnel via des réunions mensuelles qui se concentrent sur tout ce qui se passe avec la sécurité au sein des différents groupes de programmation d’applications. Ces réunions permettent à l’organisation de fournir des mesures concernant la santé globale de la sécurité atteinte par les différentes équipes au fil du temps pour aider à obtenir l’adhésion des cadres supérieurs et des membres du conseil d’administration.
Visibilité, ou : « Être capable d’identifier ce qui doit être corrigé en premier »
Avec de nombreuses entreprises utilisant des dizaines, voire des centaines ou plus, d’outils de sécurité différents pour différents systèmes, les RSSI sont mis au défi de comprendre ce qui est d’une importance critique, afin de pouvoir hiérarchiser efficacement les vulnérabilités pour atténuer les risques.
Mais ce n’est pas nécessairement parce qu’un serveur n’est pas corrigé qu’il pose un véritable risque commercial. Ce qui est requis, ce n’est pas seulement une visibilité sur les vulnérabilités, mais plutôt sur l’exposition qu’elles créent et l’impact potentiel sur l’entreprise en cas de violation.
Pour être vraiment en mesure d’associer le risque commercial à une vulnérabilité, Rob Hornbuckle estime que la direction générale a besoin à la fois d’une solide compréhension de la programmation d’applications, ainsi que d’une connaissance formidable du fonctionnement interne du modèle commercial d’une organisation. Cela leur permet de hiérarchiser l’atténuation en fonction de l’impact commercial réel d’une violation potentielle sur leur modèle commercial unique.
Même si une vulnérabilité spécifique a pu perturber les opérations de Colonial Pipeline, par exemple, cela ne signifie pas que cette même vulnérabilité présente un risque pour les résultats d’une autre organisation, surtout si son modèle commercial est différent. Les actifs les plus importants à protéger sont les services et les applications qui exposent les fonctions métier critiques.
Développer une vision des risques applicatifs dans le contexte de la gestion des risques d’entreprise
Mobiliser l’organisation autour de la sécurité n’est pas une tâche facile, surtout lorsque leur contribution – aussi précieuse et importante soit-elle – crée souvent des retards et ajoute du travail aux équipes de développement surchargées. S’assurer que tous les niveaux de l’organisation comprennent l’importance de l’équipe de sécurité est une étape critique dans la mise en œuvre de processus de développement sécurisés.
Chez BNP Paribas, le Global Head of Technology Risk Intelligence Sandip Ouadje souligne qu’il est primordial de permettre à l’organisation de comprendre facilement l’étendue de ses surfaces d’attaque internes et externes et quelles fonctions métier critiques sont exposées.
La première étape est Découverte – savoir ce que vous avez, comment il est utilisé, pourquoi il existe. Bien que cette étape soit assez simple, dans la deuxième étape, gouvernance, les entreprises doivent chercher à comprendre les étapes qu’elles prennent en termes de développement d’applications, de maintenance et de surveillance continue. Les organisations doivent s’assurer qu’elles disposent soit d’un comité de gouvernance centralisé, soit d’une équipe de gestion des risques technologiques tierce pour superviser les mesures de sécurité internes de l’organisation.
La troisième étape est celle de assurance concernant les mesures de sécurité en cours. Une surveillance continue de la sécurité qui analyse en permanence les nouvelles vulnérabilités au fur et à mesure qu’elles sont découvertes réduit considérablement les risques, car les vulnérabilités exploitées sont souvent celles qui n’étaient pas connues de l’organisation.
Pour terminer, résilience est une autre capacité clé à développer. La mise en place de procédures concrètes de réponse aux incidents et de réduction de l’exposition est essentielle dans le cas où des vulnérabilités ont été exploitées. Comme de nombreuses organisations utilisent déjà différentes solutions de sécurité, il est essentiel de garantir une utilisation efficace de ces solutions pour protéger les applications métier critiques.
En savoir plus sur la façon de faire de votre équipe de sécurité une nécessité dans l’ère API-first.
Prenons cet exemple : chez BNP Paribas, l’équipe de sécurité a créé un schéma directeur de différentes applications pour comprendre comment chacune a été impactée par la transition vers le cloud. Ce plan est utilisé par la direction pour donner une vue des différentes charges de travail qui pourraient être migrées en toute sécurité vers le cloud.
Ils ont ensuite créé une gouvernance autour de celle-ci, tant au niveau du groupe d’entreprises, axé sur la stratégie, qu’au niveau opérationnel, axé sur l’assurance de la surveillance continue. Leur prochaine étape consistait à créer un comité de pilotage API pour hiérarchiser les services en fonction de leur capacité à monétiser les données. Enfin, ils ont mis en place un programme de gestion des risques tiers et ont inclus d’importantes parties prenantes internes pour développer leur stratégie de sécurité des applications.
L’avantage surprenant des règles de sécurité
Tout comme les individus, les équipes ont aussi une réputation. Pour les équipes de sécurité, il est très important de s’assurer qu’au fil du temps, elles ne sont pas considérées comme une nuisance empêchant des livraisons rapides, mais plutôt comme un outil commercial. C’est là que la réglementation peut contribuer grandement à garantir que ce n’est pas le cas.
En conditionnant le lancement de nouvelles initiatives au respect des mesures de sécurité, de sûreté et de conformité, les équipes de sécurité deviennent une nécessité. Une fois que les équipes de sécurité auront clairement établi des lignes entre les réglementations, les vulnérabilités qu’elles découvrent et l’impact commercial, les équipes de développement cesseront de les considérer comme une nuisance.
Cela élève la sécurité au rang de catalyseur commercial stratégique et même de différenciateur concurrentiel.
Chez Mastercard, par exemple, sous la direction d’un PDG qui s’est concentré sur la sécurité dès le départ, leur équipe de sécurité d’entreprise est au cœur de leur modèle économique et fournit des services de sécurité à tous leurs clients et à l’écosystème dans son ensemble. .
Résumé
À l’ère des API, les organisations doivent repenser leur posture de sécurité. Des tendances telles que la crise de confiance, l’interconnexion de la chaîne d’approvisionnement, les réglementations et le nombre croissant d’acteurs malveillants dictent le passage à une approche de l’intérieur vers l’extérieur en termes de cybersécurité.
Avec de plus en plus d’entreprises permettant aux utilisateurs d’accéder aux données et aux fonctionnalités via des API, la perspective de la sécurité doit passer d’une restriction d’accès à de meilleurs contrôles et autorisations.
Pour commencer, les organisations doivent d’abord assurer une visibilité claire des vulnérabilités et la capacité de prioriser en fonction de l’impact commercial. Il est également essentiel de s’assurer que l’ensemble de l’organisation comprend les menaces et les risques posés à leurs processus métier critiques.
Établir des processus formels, y compris la découverte, l’assurance, la surveillance continue et la résilience, et enfin, changer le point de vue des équipes de sécurité d’une nuisance à une nécessité est essentiel pour expédier des produits sécurisés.
*** Cet article est basé sur la première session du programme de formation des cadres par Imvision.
