Beyond certifications: take a holistic approach to security for API-enabled IT 

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.