API governance and security: Best practices to achieve your growth objectives

On May 19th, we gathered with companies and public services around the AIFE (L’Agence pour l’Informatique Financière de l’Etat – French Agency for State Financial Information Technology) to share on “API Governance and Security: best practices to reach your growth objectives” during a workshop hosted by Frédéric Simottel from BFMTV. We discussed best practices in three key areas of APIs: security, governance and API adoption.

AIFE and PISTE

Alexandre Streicher, Delegate of the Director of AIFE, first shared about the role of APIs at AIFE with the PISTE project (Plateforme d’Intermédiation des Services pour la Transformation de l’État – Service Intermediation Platform for State Transformation):

• 58 AIFE APIs and 31 partner APIs published on the platform (ten external partners have chosen to publish their API services on PISTE)
• Over 8,300 applications created
• More than 7,000 users
• Between 20 and 30 million calls every day.

PISTE started as a platform for AIFE solutions and the French Ministry of Economy, Finance, and Industrial and Digital Sovereignty, and then became an interministerial platform used by DINUM, (Interministerial Digital Direction), the Ministries of Ecological Transition, Culture, Justice and Transformation and the Civil Service.

The use cases covered by PISTE include B2G electronic invoicing, public procurement, management of city planning applications and soon B2B electronic invoicing.

API security

Following this introduction, we discussed the first topic: API security. I started with a short overview of recent API attacks, with the examples of the Facebook scrape breach last year, which exposed the passwords of 530 million people and following up with the “View As” API attack in 2019, and the Equifax API attack in 2017 that impacted 147m US citizens and caused the organization to pay back over $425m.

Unfortunately, this trend is on the rise. Attacks on APIs are growing twice as fast (+50% per quarter) as the underlying growth of APIs in use (+25% per quarter). For example, the German employment service Bundesagentur für Arbeit, an Axway customer, faces more than 5 million attacks per day!

So what should you do? First of all, Axway recommends taking an inventory of resources in a Service Registry that gathers all the APIs exposed by all the gateways of an enterprise, in order to avoid “zombie APIs” that are exposed and unprotected.

Secondly, each API must offer security “by design”, i.e. be designed from a security perspective from the OpenAPI specification, with roles that have a defined scope of access to resources. And this principle must be applied to all APIs: internal, partner, or public, with no privileges for the internal ones, following a “zero trust security” model. Finally, of course, APIs must be secured by an API gateway!

Alexandre Streicher confirmed this rising trend of security concerns, and the generalization of API security via OAuth2 and JWT tokens. He cited two examples of additional security services: following the discovery of the exposure of IP addresses to Google by captcha, the AIFE took responsibility for creating a sovereign version of the captcha with the Captch’Etat, which is made available to public entities.

Furthermore, given the sensitivity of API access authorizations, DINUM has implemented an access form that complies with government access control procedures, the datapass, which has been incorporated into PISTE.

In addition to these best practices, the working group added ongoing security training for all staff, not just developers, as well as regular pen testing.

Once our APIs were secured and ready to be exposed, we turned to the topic of API Governance introduced by my colleague, Emmanuel Methivier.

API governance

API governance has become a complex subject in companies that choose an API-first approach. Indeed, thanks to their four complementary powers, APIs bring together people from various departments: security managers (CISO), infrastructure managers (ops, devops), developers who create or consume APIs (devs), product offer managers (marketing) and more recently, with the power of the platform, partnership managers.

This means there’s a significant potential for conflicts in governance between these stakeholders. This calls for a distributed organization, with API product teams in the business lines, supported by a central organization, the platform team, ensuring the coherence of the product teams’ best practices and guidelines, the maintenance of a common API catalog, a coherent and secure architecture, and the maintenance of a common budget for the entire API program.

Given the complexity of state organizations, governance lies at the heart of the success of the AIFE API program. For AIFE and PISTE, the API program is supported by the French General Secretariat of the Ministry of Economy, Finance, and Industrial and Digital Sovereignty, and is part of DINUM’s governance.

As far as the State’s financial system (Chorus) and the connected ministerial applications are concerned, the impetus for the APIfication program comes from the Strategic Orientation Committee of the State Information System.

As for Chorus Pro (B2G electronic invoicing – processing of 68 million government invoices), digital transformation of public procurement, and B2B electronic invoicing, APIfication strategies are part of the governance and consultation mechanisms implemented.

For its ecosystem of third-party API providers, the AIFE does not currently have any specific governance, but shares its best practices and templates with its partners.

Once security and governance were in place, we could move on to the success of an API program: adoption of its APIs.

API adoption

I then took the floor again to remind the audience why API adoption has become a major issue for the companies and agencies we work with. These customers use APIs for four business models:

• to publish secure applications for their customers on the web or mobile, and provide an interactive experience based on captured information
• to enrich this customer experience with third party APIs (CRM, information, music, identification…) that would be much more expensive to develop by themselves,
• to distribute third-party services that complement their offer, and thus earn distributor commissions,
• to be distributed by third party companies and thus acquire new customers.

With this shift from security and experience concerns to ecosystem-serving platform concerns, APIs have come to the forefront of enterprise transformation strategy. Their success is measured by adoption. Here are some best practices we’ve seen from our customers:

Start adoption with internal alignment, on long-term key success factors, budget, creation of hybrid business-IT teams, with aligned interests and goods, and regular internal communication based on “quick wins.”

Once internal alignment is achieved, build APIs as a customer-centric product, with a simple and differentiated experience. If possible, a migration of users from obsolete integrations to these APIs in order to ensure startup, and permanent A/B testing.

Once the product is well established, look to develop a partner network, starting with those that enrich the experience you offer, those you can distribute and those that can distribute your API. Once identified, share your long-term vision and organize offering interoperability to make the experience of your common user community as effortless as possible.

Once – and only once – internal alignment, product, and partner ecosystem are secured, it’s time to communicate. Using growth hacking techniques, developer evangelism, and community conferences, and finally looping in internal communication to the stakeholders you aligned at the beginning.

Alexandre Streicher complemented this general view with AIFE’s good practices:

• a website/portal for developers in PISTE
• simple, self-service consumption of PISTE by developers to facilitate a reduced TTFAC (Time To First API Call), ensured by an API review by AIFE to guarantee adoption of best practices by API producers
• empowerment of API producers with the Publication Self-Service module, a sort of publication sandbox
• permanent consultation and sharing of developments with partner publishers
• the adoption of relevant technological innovations, such as asynchronous APIs, for which a POC is underway.

Conclusion

We would like to thank the AIFE, the CIOs in attendance, and BFM TV for this exchange session, which we hope will help address some of the challenges on the steep but very beneficial path of the API Platform.