Issue 191: API insecurity causing rising incidents, policy-as-code for API security

This week, we have a report from Imperva on the increasing security incidents caused by unsecured APIs. We also have articles on using policy-as-code to improve API security, views on how common assumptions may prevent effective API protection, and how open APIs are improving cloud-based security.

Report: One in thirteen incidents blamed on API insecurity

First up is PortSwigger’s coverage of a recent report sponsored by Akamai, in which over 117,000 cybersecurity incidents were analyzed to understand trends and patterns in them.

The first finding of report is that the occurrence of API-related incidents varied between 4.1% and 7.5%, with the likelihood directly proportional to the size of the organization: the bigger the company, the bigger the chances for API-related security incidents.

The researchers provided insight into the nature of API attacks โ€” these range from distributed denial-of-service (DDoS) attacks, to machine-in-the-middle (MitM) attacks exfiltrating sensitive data, account takeovers, and tampering with API data. Unsurprisingly, the authors cited two primary reasons for API insecurity: the rapid proliferation of APIs, and a lack of visibility into the exposed APIs and/or their security posture.

The other interesting takeaway from the report is the occurrence of API-related incidents across various industry verticals. In information technology industry, up to 23% of incidents can be traced back to APIs โ€” presumably, this is in large part because of the use of APIs for the interconnection of platforms, services, and cloud infrastructure. Professional services were next highest on the list, followed by manufacturing, transport, and utilities. The healthcare industry reported the lowest occurrence of API-related incidents at 1%, presumably due to the increased rigor of software development in this industry, and stringent compliance requirements.

The original report is worth a read for deeper insights into the research.

Article: Using policy-as-code to improve API security

The emergence of the practice of “everything-as-code” has led to significant improvements in how IT systems are built โ€” just think of the ease with which complex infrastructure can be composed with Terraform. Using code as the single source of truth provides improvements in auditability and readability, and allows the adoption of code development best practices, such as version control.

This week, we have views from Mark Cassetta of Axiomatics on how policy-as-code can be applied to APIs to improve security. Cassetta describes how authorization and access control policies are typically implemented as ad-hoc policies managed in different business units across the organization. The net result is APIs with inconsistent policy enforcement and access control, often a root cause of API security problems.

By opting for a policy-as-code approach, a policy can be applied in a uniform fashion across disparate teams in an organization. By leveraging code development practices, savvy teams can benefit from version control, testing, validation, and automated injection of policies through CI/CD pipelines.

The author cites three main advantages of using policy-as-code:

  • Establishing best practices: By using policy-as-code, organizations can adopt best practices for authorization and access control, and ensure these are considered as first-class elements of the development lifecycle.
  • Shift-Left: Using a policy-as-code approach ensures that security requirements are injected into the development process as early as possible, avoiding security being seen and added as an afterthought.
  • Focus on policies: Finally, by focusing on policies expressed as code and stored in a central repository, teams are able to learn from one another and cross-pollinate ideas for complex, dynamic policies. In addition, by going for a centralized approach, organizations can use a central policy decision point (PDP) to enforce policy rather than relying on a distributed model where each API implements policies separately. Developers can focus on functionality and offload policy decisions to a central PDP.

Previously, I’ve presented on the topic of “security as code” for API protection. I feel the ability to centrally apply policies and removing the burden from the API development teams are massive benefits of this approach.

Article: Four assumptions preventing effective API protection

One hotly debated topic in API security is whether existing protections are sufficient for robust API security, or if dedicated solutions are required. This week, Radware has contributed their thoughts on the topic and provided four common assumptions that may be preventing effective API security:

  • WAF protects applications and the associated APIs: Whilst web application firewalls (WAFs) are somewhat effective for web applications, they perform poorly with APIs because they lack the context of the payloads and contract, meaning that they cannot distinguish the expected behavior from the unexpected. WAFs also operate based on a negative security model (attempting to block known bad content) which leads in high number of both false positives and negatives.
  • API gateway manages and protects my APIs: API gateways provide a level of protection for APIs by enforcing transport security, rate limiting, quotas, and authentication. However, API gateways have significant limitations, such as the lack of a positive security model engine, bot protection capabilities, behavioral analysis, and application DoS protection. Do leverage API gateways, but be aware of gaps in protection.
  • APIs are well documented, enabling effective protection: API protection technologies are dependent on well-documented APIs, however in many organizations, this documentation is incomplete or non-existent. Ensure that you have a strategy for discovering undocumented APIs and enrolling them in a managed API program.
  • Using dedicated API protection solutions provides perfect security: Avoid being complacent even when you are using a dedicated API protection product. Remember that there are other elements to comprehensive API security, like threat intelligence, bot detection, and DDoS defense.

As is ever true in cybersecurity, the best approach is a layered defense-in-depth strategy.

Article: Open APIs improving cloud-based security

Finally this week, we have some interesting thoughts on how open APIs can improve cloud-based security systems.

Firstly, open APIs allow greater interoperability between disparate systems: instead of designing a bespoke API, vendors are increasingly adopting a relevant open API standard. This results in shorter times to market, and higher levels of integration into security platforms and portals.

Secondly, adopting open APIs and open-source software vendors can achieve higher levels of manageability in security systems, either through the use of management platforms or remotely located service teams.

Adopt the lessons of open-source software and avoid (re-)inventing an API that may already exist out there in an open format.

Get API Security news directly in your Inbox.

By clicking Subscribe you agree to our Data Policy