The announcement of Axway’s Amplify Platform receiving Common Criteria EAL4+ certification has been welcomed by the API community as a major step forward in securing information systems. This certification, the highest level for civilian software, is a guarantee that your information system’s perimeter security will be strengthened.  

The platform exposing your APIs is much like a castle drawbridge, guaranteeing the security of the fortress’s entrances and exits – in this case, your information system. It acts as a “digital fuse box” from which you should absolutely expect the highest quality and security. 

That being said, even if EAL4+ certification is an essential component of this security brick (API management), and even though this APIM security brick is absolutely required for the security of your IT, it is not sufficient alone to ensure the complete security of an open information system. 

Security requires more than certifications 

When you are dealing with an extended information system, exposed via APIs, you need to look at Availability, Integrity, Confidentiality, and Proof differently. 

In contrast to a closed system, controlled from end to end, an open system allows external developers to build applications for your customers, without you being able to control the code and therefore all the functions. 

What would happen if, as a healthcare operator, one of your external developers hid a backdoor to exfiltrate your customers’ data? 

What would happen if, as a bank, your customers’ data was exposed through a flaw in an application you did not control? 

The legal liability argument doesn’t hold for long. They are YOUR customers, they entrusted YOU with this data, so you are ultimately responsible – at the very least in terms of image. 

In the context of an open IT, it is therefore essential to understand end-to-end security and consider a “zero trust” approach, especially on this external development brick over which you cannot have complete control. 

This requires several steps in addition to traditional security. 

Consider a zero trust approach to secure open systems 

Identity management 

First of all, you need to ensure the identity of the external developer who uses your services and digital products (APIs). This requires strict management of your external developer partners’ digital identities. 

But it’s also crucial to control the applications developed by these developers. A token per application version ensures that your services won’t be consumed by just any code. 

This double identity is managed by a double exchange of developer token/application version. 

Once this identity has been validated, it is necessary to ensure that the process is not corrupted. How to ensure that a developer does not push a modified application version with a flaw to your customers. 

Sandboxing 

To ensure the integrity of the process, it is necessary to go through a sandbox in which the application will run until it is validated by your security & compliance services. This sandbox will also allow your developers to test the applications. 

It is the tested application that must be offered in the store (google play or apple store), because otherwise, it is impossible to ensure that the application has not been modified between the time of validation and use by your customers.  

Once validated, you change the state of the application token so that the application can run with the real production data. You’ll notice we are reversing the classic process (going into production after security testing) since the application will be delivered to the production stores before testing.  

With this system of secure tokens and sandbox/production routing, you can not only ensure security at any given moment, but above all, you keep control and can at any time disconnect an application that no longer complies with guidelines. 

A robot detecting any modification of an application version in the store is the ideal complement to ensure that there is no new version / new flaw. If it detects a new untested version, a token blocking process will send it back into the sandbox.  

Manage complexity 

Another essential step for an API-enabled IT is to control the proliferation of APIs. As we have seen, these are the entry/exit points of your systems, and their explosive growth causes growing complexity.  

APIs must therefore be meticulously inventoried to guarantee their governance; you cannot manage or secure what you do not know exists. 

These steps are complementary to classic security measures; they do not replace them. 

Axway offers expertise beyond solutions to keep you open and secure  

To help you ensure successful and secure APIs for your information system, Axway can provide you with the essential building blocks to guarantee not only perimeter security but also all aspects of governance, including implementation advice based on the sensitivity of your data and services. 

Don’t hesitate to contact us to discuss how we can help. 

Au-delà des certifications : adoptez une approche holistique pour sécuriser les SI ouverts  

L’annonce de la certification « Common Criteria EAL4+ » de la plateforme Amplify d’Axway a été accueilli par la communauté API comme une avancée majeure dans la sécurisation des systèmes d’informations. Cette certification, la plus haute certification pour un logiciel civil, est un gage de renforcement de la sécurité périmétrique de votre système d’information.  

En effet, il faut considérer la plateforme exposant vos API comme le « pont-levis garant de la sécurité des entrées-sorties de la forteresse », en l’occurrence votre système d’information. Une sorte de « boite à fusible digital », pour laquelle il est normal d’exiger la plus haute qualité et la plus grande sécurité. 

Et pourtant, même si la certification EAL4+ est indispensable à cette brique de sécurité (l’APIM), et même si cette brique de sécurité APIM est absolument nécessaire à la sécurité de votre SI, elle n’est pourtant pas suffisante pour assurer la sécurité complète d’un système d’information ouverts, à travers quatre axes : Disponibilité, Intégrité, Confidentialité et Preuve (DICP). 

Au-delà des certifications 

Ces axes DICP (Disponibilité, Intégrité, Confidentialité et Preuve) doivent s’appréhender différemment pour un SI étendu, ouvert par des API. 

En effet, contrairement aux SI fermés, maitrisés de bout en bout, un SI ouvert permet à des développeurs externes de construire des applications pour vos clients, sans que vous ne puissiez en maitriser le code et donc l’ensemble des fonctions. 

Que se passerait-il si, en tant qu’opérateur de santé, un de vos développeurs externes ne cachait une backdoor pour exfiltrer les données de vos clients ? 

Que se passerait-il si, en tant que banque, les données de vos clients se retrouvaient exposées par le biais d’une faille dans une application que vous ne maitrisez pas ? 

L’argument de la responsabilité juridique ne tient pas longtemps. Ce sont VOS clients, ces données ils VOUS les ont confiées, vous avez donc forcément une responsabilité, au moins d’image. 

Dans le contexte d’un SI ouvert, il est donc indispensable d’appréhender la sécurité de bout en bout, en considérant le « zéro trust » notamment sur cette brique de développement externe dont vous ne pouvez pas avoir la complète maitrise. 

Cela passe par plusieurs étapes complémentaires à une sécurisation classique. 

La sécurisation des SI ouverts exige une approche « Zéro Trust » 

Gestion d’identité 

Il faut en premier lieu s’assurer de l’identité du développeur externe consommateur de vos services, de vos produit digitaux (API). Cela passe par une gestion stricte des identités digitales de vos partenaires développeurs externes. 

Mais il est aussi nécessaire de contrôler les applications développées par ces développeurs. Un jeton par version applicative permet de s’assurer que n’importe quel code ne va pas consommer vos services. 

Cette double identité est gérée par un double échange de jeton développeur / version de l’application. 

Une fois cette identité validée, il faut s’assurer que le processus n’est pas corrompu. Comment s’assurer qu’un développeur ne pousse pas à vos clients une version d’application modifiée comportant une faille. 

Sandboxing 

Pour s’assurer de l’intégrité du processus, il est nécessaire de passer par une sandbox dans laquelle tournera l’application tant qu’elle ne sera pas validée par vos services de sécurité / compliance. Cette Sandbox permettra aussi à vos développeurs de tester les applications. 

L’application testée devra nécessairement être celle présente en store (google play ou apple store), car sinon, il est impossible de s’assurer de la non-modification de l’application entre le moment de la validation et l’utilisation par vos clients. Une fois validée, on modifie l’état du jeton applicatif pour que l’application puisse tourner avec les données de production réelles. 

Comme vous pouvez le voir, on inverse donc le processus classique (passage en production après test de sécurité) puisque l’application sera livrée dans les stores de production avant les tests. Grace à ce système de jetons sécurisés et de l’aiguillage sandbox/prod, vous pourrez vous assurer non seulement de la sécurité à un instant T mais surtout, vous gardez la maitrise et pouvez à tout moment débrancher le fonctionnement d’une application qui ne respecterait plus les guidelines. 

Un robot détectant toute modification d’une version des applications en store est le complément idéal pour vous assurer qu’il n’y a pas de nouvelle version / nouvelle faille. S’il détecte une nouvelle version non testée, un processus de blocage du jeton la fera retourner dans la sandbox.  

Maitrisez la complexité  

Autre étape indispensable à un SI APIsé, la maitrise du foisonnement des API. Comme nous l’avons vu, celle-ci sont les portes d’entrée / sortie du SI, et leur croissance explosive entraîne une complexité croissante.  

Elles doivent donc être parfaitement inventoriées afin d’en garantir la gouvernance ; impossible de gérer ou sécuriser ce dont on ignore l’existence. 

Ces étapes sont complémentaires aux sécurisations classiques, elles ne les remplacent pas. 

Axway offre une expertise au-delà des solutions, pour un SI ouvert et sécurisé  

Pour vous accompagner sur une APIsation réussie et sécurisée de votre SI, Axway peut donc vous fournir les briques essentielles pour garantir non seulement la sécurité périmétrique mais aussi s’assurer de l’ensemble de cette gouvernance, allant jusqu’au conseil d’implémentation en fonction de la sensibilité de vos données et services. 

N’hésitez-pas à nous contacter pour en discuter.