LabPlus: Exploring API Security

TL;DR

Because APIs are central to our work, the Service Innovation Lab has been working closely with the Government Enterprise Architects Group in the Department of Internal Affairs (DIA) to explore future security and control models for APIs (Application Programming Interfaces) that allow greater resilience, flexibility and ability to adapt quickly to genuine risks in a rapidly changing environment. We are running a "Tech Check" event tomorrow and we welcome you to join us in this discussion.

This article presents a simple method for categorising the security needs of an API, including:

• An overview of consumable government (APIs) and security from a technical / API team perspective.
• Simple models intended to assist the practitioner in making quick API accessibility & security decisions.
• A core notion, that is essentially: ‘if something needs to be private then secure it using different layers of control, otherwise make it open (but still follow and keep up with current web security guidelines)’.

So what we think is needed is a simple approach the API team can use to quickly categorise their API. An approach aligned and complementary with the two NZ Government API standards documents (released 27/May/2017), namely the API Standards and guidelines Part A - Business, and Part B - Technical.

“APIs” - the cornerstone of digital government

For the purpose of this work, we use APIs as a broad term for all programmatic interfaces to modular systems. The promise of APIs, when used and secured correctly, is transformational. The ability to more easily make authoritative data accessible, to have business rules readily available, and access government transactional services from user experiences all over the internet is profound. The opportunities for dynamic and integrated services based on user needs from myriad providers creates an exponential response to the increasing complexity in society.

There's a tendency when moving into a digital world to try to make everything as secure as it possibly can be but inappropriate barriers to the adoption of the APIs undermine the opportunities for reuse and innovation. We must find the appropriate balance, in line with the commercial sector, and that balance must lean towards minimum viable barriers when deploying APIs, especially when they are interfaces to open information or systems. e.g. For business rules, public data, or simple transaction services like reporting a pothole, it will serve both the agency and society better to have open APIs available for reuse, and for more complex transactions such as renewing a passport to have and use a series of agreed and consistent security measures.

Categorising API security needs

We think that APIs are one or more of the following, they:

• Tell you something
• Tell you something that if it is told to the wrong person, it could cause harm
• Do something
• Do something that if it is asked for by or returned to the wrong person, it could cause harm.

These categories (mapped into security types in the schematic below) provide a simple rule of thumb for judging if an API falls into a harm category. If the API is in a harm category, then a risk assessment should be completed. This assessment will take into account the context on how the service or information is currently available in a non-digital world. This will assist in shaping an API ecosphere that is open by default, but actively identifies and minimises harm, rather than over-complicating security requirements or simply performing a compliance activity. It also makes a distinction between the identity needs of the intermediary software, and of the end user.

API Provider Security Controls (the funnel)

API Provider security controls are typically provided by a proxy or gateway – the place where new work traffic traverses to get where it needs to go. This point, or funnel, is a ‘point of control’ where the API provider can apply a generic series of security controls. Typically an agency will use a gateway type device to perform these functions to get consistency across APIs but sme products will have these controls built in. At a minimum these controls should be:

• Request Rate Limiting
• Logging & Realtime Analytics
• Threat Protection
• Transport Security

Cloud native APIs (or microservices) should use a cloud based gateway (or funnel) in the following instances:

• From end user device to the ‘end point’ or microservices application
• Between microservice components hosted in a different subnets or DNS realms

Mitigating Controls - The Wider Picture

Internet based threats are constantly evolving. Being serious about having APIs means adopting new ways of working and keeping up with changing controls and practices. APIs are now developed within a devops organisational structure. This introduces a cross functional team (the API team) that is designing, developing and operating the APIs. This provides a number of benefits from a security perspective:

• With Analytics and Monitoring in place the API team can respond to trends and alerts in real time
• The API product owner works directly with the team to conduct risk assessments
• Quick turnaround on design, develop & deploy
• With an easy to use and find feedback loop in place consumers can report on vulnerabilities

Development (DX) Controls

Essentially these controls relate to best practices, good house-keeping and development hygiene.

• All Private & Moderated data needs to be masked (or cleaned)
• Good API key security - use a vault!
• Established continuous code review processes
• 12 point code design techniques
• Use of a ‘soft identifier’ or tag to enable tracking and analytics of the API