API abuse is currently the most frequent attack on the internet, and most cloud-related breaches occur due to misconfiguration. When considering API security, options, consider how reachable they are from public-facing internet. The threat profile of public-facing
API access versus internal access means that an extra level of security on more reachable systems is a good general best practice. It’s important to keep development, deployment, and ongoing operations as simple as possible. This piece explains
how to use a three-step approach to defending APIs:
- Analyze defense capabilities from the outside in.
- Ensure assets the APIs are granting access to are properly hardened and monitored.
- Operationalize the capabilities.
Differences between Public and Private API Management
The biggest difference between public and private APIs is the attack surface—the ways in which a system can be attacked. In private APIs, the attack surface is restricted to internal actors, whereas in a public-facing system, the attack surface is anyone
on the internet. This means extra caution is warranted for public-facing APIs because there is a far larger pool of bad actors who can reach your APIs; there is less visibility and control of the API client side, and APIs provide a gateway through
which bad actors can access your back-end/private systems, thus exposing private assets. Given these additional risk factors, it does make sense to have additional layers of control on public-facing APIs.
Public and private APIs both require security scrutiny because APIs act as “glue” to provide access to core systems and functionality. If the API layer is subverted by a threat actor, it can act as a launch pad to gain illegitimate access.
In addition, API abuse is now the most frequent attack on the internet, and most cloud-related breaches occur due to misconfiguration. This means public-facing application-level API scanning is critical to close this visibility gap.
The main technical differences are at the application and identity levels. APIs use different authentication and authorization methods for identity and access control than traditional applications. So, using API identity standards can pay dividends here.
API gateways can further simplify the management of security policy of what and who is allowed to access functionality and data.
Main API Types and Security Options
In addition to aligning security policy to data classification, API security options should be dictated, in part, by how reachable they are from the public-facing internet. Figure 1 shows the pros and cons of various capabilities, as well as deployment
considerations.
API Tool Evaluation Factors
Figure 2 below shows the many considerations when assessing tools for API management.
Key API Pitfalls and Issues
For efficiency reasons, organizations should keep development, deployment, and ongoing operations as simple as possible. However, the threat profile of public-facing API access versus internal access means that an extra level of security on more reachable systems is a good general best practice.
There is a gap in the marketplace, and many vendors simply repackage web security tools as API security tools. Customers investigating the space should ask: “What does this solution deliver that is specific to APIs?” The OWASP API Security
Guide provides specific considerations to check for. This list is a good starting point to make sure your tool selection is as specific as it can be to the API threat environment.
3 Steps to API Defense
A general recommendation for defending APIs is to use a three-step approach:
Step One: Analyze defense capabilities from the outside in. Public-facing APIs exist at a higher threat level, so these should be given extra consideration because the APIs are reachable by anyone. Private APIs benefit from all the internal
controls that your organization uses on the private network, desktops and servers. This outside-in analysis process (see Evaluation Factors for specific examples) seeks to identify assets and security capabilities that harden, detect events, and enable
the security team to respond and recover efficiently, where necessary. Outside-in analysis begins with the same things a developer would use to access the APIs to identify and remediate security gaps.
Step Two: Ensure the assets that the APIs are granting access to are properly hardened and monitored. This step is an inside-out analysis, typically starting with back-end data sources and applications to identify any gaps that allow
for issues arising from misconfiguration or lateral movement. In particular, any trust relationships between the public-facing environment and the private environment should be scrutinized to ensure access control, scanning, and monitoring are in
place.
Step Three: Operationalize the capabilities. This should include, at a minimum:
- Update identity and access controls for the APIs
- Consider if an API gateway is appropriate to reduce attack surface and centralize security management.
- Implement API-level attack surface and vulnerability scanning.
- Update SIEM monitoring for API-specific attacks.
Underlying these steps, organizations should look to use AI to scale efforts in identifying and responding to anomalous behavior. The ways that APIs are used mean that intelligently scaling
policies through AI is a very attractive proposition.
API Security Recommendations
External, public-facing APIs need an additional level of security. In this blog, we’ve provided some ideas for how to achieve an extra layer of assurance through scanning, access control, monitoring, and other methods. Finding the best fit among
these options depends on the exact deployment scope. Figure 3 below shows the starting points.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.