Securing government APIs

Government agencies have embraced standards-based application programming interfaces (APIs) as a simple and economical way to share information with citizens and contractors as well as with other agencies and stakeholders. API technology can create security vulnerabilities, however. Securing APIs is a process that must begin at the development stage and continue across the entire API lifecycle. In this context, automation of API security is emerging as a best practice.

A brief overview of standards-based APIs

APIs enable software applications to share data and procedural calls with each other. This isn’t new technology. Computers have been able to talk to each other since the 1960s. Until about 10 years ago, though, such software interoperation was cumbersome and costly, requiring custom coded or proprietary connectors.

The new generation of APIs is built with open standards like Representational State Transfer (REST). These universally free standards make it possible for an application to interoperate easily and inexpensively with virtually any other piece of software or data source. People use APIs all the time without realizing it. When users look up stock prices through a banking app on their phone, for example, the bank app is calling on the stock exchange’s API to get the requested data.

What government APIs do

Government agencies use APIs to streamline processes and improve service to citizens. The federal government now has an estimated 500 public APIs in operation and a countless number of private APIs. The Census Bureau, for example, has published 24 APIs. These enable software developers to write API calls that retrieve information from the Bureau’s international trade datasets and geocoding services, as well American Community Survey datasets.

At this point, most government APIs reside on-premises at government data centers. This is about to change, however, as agencies' software and data assets move to the cloud in response to the 2019 Federal Cloud Computing Strategy, known as Cloud Smart.

Federal CIO Suzette Kent put it this way: “Cloud Smart embraces best practices from both the federal government and the private sector, ensuring agencies have the capability to leverage leading solutions to better serve agency mission, drive improved citizen services and increase cyber security.”

What the government risks by exposing APIs

As with all industries, agencies need education about cybersecurity and the most vulnerable API attack vectors as their assets move to the cloud.

With weak encryption standards and unauthenticated and insufficient authorization, APIs can expose an agency to security risk. The direct data access APIs provide also makes it easier for malicious actors to extract potentially sensitive information. For instance, a hacker could create an API call that pulls out classified data because the government API is not configured to block such a request. Or, it may not have any limits on data retrieval API calls, so a hacker could abuse an API to extract records without being challenged.

A recent Gartner report on API security highlighted the looming threat. Exposed APIs today account for 40% of attack surface area, but by 2021, Gartner predicted that 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs than the user interface. The research group further predicted that by 2022, API abuses will move from being an infrequent attack vector to become the most frequent -- resulting in data breaches for enterprise web applications.

Why are APIs projected to be such a source of risk? The cloud is a significant factor here. While any API can be insecure if it’s not managed properly, at least on-premises there is a more methodical and trackable process to develop and deploy an API. In the cloud, developers can quickly throw APIs up on cloud platforms using ephemeral serverless architectures, containers or microservices.

This creates two security problems. One is the inherent complexity of the environment, which may make it hard to determine how secure any given API is at a moment in time. Also, system admins can spin resources up and down so rapidly that it becomes hard to keep track of the APIs being hosted in the cloud. Further, a developer could create an API without telling anyone, put it up on the cloud, and expose government data to unauthorized access in the process. This is known as a “shadow API.”

The pace of development causes trouble for APIs, too. The risk of an API getting deployed without proper access controls or monitoring becomes quite high as agencies switch to DevOps and the continuous integration/continuous deployment (CI/CD) practices. In addition, commercial off-the-shelf software products frequently come with ready-to-go APIs. An admin who installs the software might inadvertently leave APIs open to unauthorized external access.

The need to secure APIs across their entire life cycles

It is possible for government agencies to develop secure APIs and keep them secure across their entire lifecycle. API security must be a continuous process; it is not effective to check an API for malicious code content, add some access controls, deploy it and revisit it only to prepare for audits. Rather, it is essential to monitor that API’s behavior continuously. Then, as it nears the end of its life (which might be as little as 72 hours after it was created), the best practice is to conduct rigorous vulnerability analysis with remediation steps to address problems that could lead to a data breach.

Automation makes effective API security possible

Security process automation combined with automated API discovery are the two key success factors for effective API security programs in the government context. API security is sufficiently complicated that automation is essential for keeping SecOps or DevSecOps team members on top of their APIs. In parallel, automated API discovery inventories all deployed APIs relevant to the agency – including both permitted and shadow APIs – and identifies that that must be controlled under security policies.

Conclusion

APIs have the potential to improve government functioning and service delivery. Agencies are moving to cloud computing, a step that will lead to exponential growth of APIs and their security risks. Innovations like microservices and serverless architectures, along with new methodologies like DevOps and CI/CD, all promise great benefits to IT, but they create new API risk exposure. Government agencies, especially those working the cloud, need rigorous API security countermeasures. To this end, the best practice is to employ automated API security processes and continuous API detection and monitoring across the full API lifecycle.