Application programming interfaces (APIs) are a common approach for commercial aerospace engagement, but when APIs are left under-protected companies leave themselves vulnerable to attack. The risk is so heightened that the Open Web Application Security Project (OWASP) added Underprotected APIs to their OWASP Top 10 2017. But by adopting an API Gateway with a few special security considerations, risk can be greatly reduced.
Because systems of record, upon which APIs are exposed, typically reside within a company’s trusted network, additional considerations need to be made to expose them for consumption from outside of the trusted network in order to avoid security risks. Organizations can mitigate many of these security risks by using an API Gateway to facilitate these requests. API Gateways act as a specialized proxy server that controls the requested traffic, detects and defends against distributed denial-of-service attacks, and leverages existing investments in malware/antivirus scanners.
Consider these seven key best practices when designing a secure architecture needed to implement a trusted API Gateway:
Controlling Requests into the Agency’s Trusted Network (ATN): The API Gateway should not permit connections directly into the ATN that originate from the network’s demilitarized zone (DMZ). Instead, an internal gateway component in the ATN should connect outward to the API Gateway in a tunneled fashion. This approach removes the need to open incoming firewall ports from the DMZ into the ATN, preventing any connections from servers in the DMZ should they become compromised. Additionally, connections from the ATN to the API Gateway should be persistent so that encryption handshakes are not continually re-established, which can negatively impact performance.
Establishing Filtering Rules and Alerts: The API Gateway should be configurable to actively filter requests based on agency security and operating policies. Filters should include the ability to block specific IP address ranges, and to act dynamically based on request type, endpoint name, request payload size, and authentication. Automated alerts should be sent to system administrators and management dashboards when requests violate filter rules.
Implementing Protective Caching: Depending on the data and use case, the API Gateway should be employed to store and serve frequently accessed data directly from caches of Random Access Memory (RAM). This provides a high-performance buffering layer that can insulate the internal endpoint from spikes in volume. In addition to protecting the internal endpoint, this technique increases API service performance, facilitates scalability, and decreases internal network traffic. For example, a weather API might only deliver updated data every 5 minutes, but during a hurricane the API might be inundated with concurrent requests. In this use case, protective caching could provide an extremely affordable scaling mechanism that helps the data provider avoid sizing their architecture to handle the often-unpredictable spikes in utilization.
Operationalizing Cyber Threat Information: The API Gateway itself should provide flexible Administrative APIs to allow for fast, automated, and scripted configuration. With a dynamically configurable API Gateway, agencies will be able to quickly operationalize actionable threat indicators from the National Cybersecurity and Communications Integration Center (NCCIC). Additionally, certain rule violations or alerts triggered on the agency’s API Gateway may reveal threats that should be shared with the cyber community through the Department of Homeland Security’s Automated Indicator Sharing (AIS) service.
Identity and Access Management: The API Gateway should provide a robust “Identify & Authenticate Consumer” policy action to effectively identify and validate clients, with the ability to support a wide variety of identification and authorization options. This allows your agency flexibility to identify clients who are trying to access the APIs. At a minimum, the Gateway’s supported identification options should include: Hostname Address, API Key, IP Address Change, SSL Certificate, OAuth2 token, XPath expression, WSS Username Token and WSS X.509 Certificate.
Payload Threat Protection: Another important factor is how the API Gateway should block attacks coming through JSON or XML in string lengths and payloads by several ways including:
- Maximum number of entries allowed in an object.
- Maximum string length allowed for a property name within an object
- Maximum number of elements allowed in an array
And limit XML attributes such as:
- Maximum number of characters permitted in the namespace prefix
- Character limit for any namespace URIs present in the XML document
- Maximum number of child elements allowed for any element
- Maximum node depth allowed in the XML
SQL Injection Filter: The API Gateway should include the ability to block SQL query requests based on custom blacklisted items. A blacklist could include such items as invalid special characters. The ability to dynamically configure rules gives agency’s maximum flexibility to adjust as new threats are identified.
Employing an API Gateway and following these steps is a pro-active way for aerospace companies to address specific security challenges. This is essential when company data and applications require open, public access. Although no security solution is ever complete, given the growing and changing threat environment, companies must deploy the latest security techniques to reduce their risk profile. An API that fails to deliver the expected level of security, reliability, and performance can have tremendous mission impacts – to both the organization producing it and those consuming it.
The views expressed here are the writer’s and are not necessarily endorsed by Homeland Security Today, which welcomes a broad range of viewpoints in support of securing our homeland. To submit a piece for consideration, email [email protected]. Our editorial guidelines can be found here.
