Explanation of How to Expand API Security From Defense-in-Depth to Zero Trust Model “The pandemic placed immense urgency on businesses to get all kinds of digital transformation projects live as quickly as possible, and that is almost certainly a driving factor behind this surge in attacks,” — , Director of Technology at . Peter Klimek Imperva DYKT APIs have been used for more than 20 years. Since then, APIs have evolved drastically — from a limited set of companies using APIs to tackle specific needs to, recently, an endless collection of use cases in DevOps environments of all sizes. APIs can be found across App Developments — agile development, connecting customers and partners with services, and powering digital transformation initiatives. But regarding cybersecurity, according to research by , . Yet, with broader adoption, APIs expose more sensitive data today than ever, making them a valuable target for attacks. ProgrammableWeb an average of 220 new APIs have been added every month since 2019 This post is an introduction to how to map the requirements of API Security, from Defense-in-Depth to Zero Trust Model. Background -The State of API Security Before entering how to secure the API, let's look at the current threat landscape of API Security. According to the State of API Security Report by Salt Security: API Attacks Increased by 681% in the Last 12 Months 95% of respondents have experienced an API security incident within the last year 34% of respondents lack any API security strategy 62% of survey respondents acknowledged slowing down the rollout of a new application because of API security concerns In short, we can tell that most enterprises are unprepared for an API-based attack. Also, reliance on existing security and API management tools, e.g., web application firewalls (WAFs) and API gateways, could have effectively prevented security incidents and provided a false sense of security. What About Shift-Left? The report highlights that shift-left tactics are not helping, at least on API security. Over 50% of respondents said that developers, DevOps, or DevSecOps teams are responsible for API security. Companies that spend more on pre-deployment efforts include: secure coding best practices, code scanning, and manual test However, - Proving that these DevOps security practices, while important, are not enough. 85% acknowledged that their security tools are ineffective in API attack prevention So, what protection should an organization build or adopt to defend against API attacks? To answer this question, first, we need to understand the common attacks against API. The Current Threat Landscape In the recent report on , the sources of API security threats are: API security by Google Cloud Misconfigured APIs (40%), Outdated APIs, Data, and Components (35%), Spam, Abuse, Bots (34%). “Misconfigured APIs” or “security misconfigurations,” as a category, are the most identified threat source. According to another study by , which jumped by 271%. Hackers use RCE or RFI attacks to steal company information, compromise servers and website defacement, or even take control of the websites. Imperva Research Labs the most significant attack rises Remote Code Execution (RCE) or Remote File Inclusion (RFI) Other API vulnerabilities are, according to OWASP API Security's top 10: API DDOS fan-out, zero-day API attacks, stolen credentials, perimeter breaches, lateral movement of breaches, data leak at the egress, or resource hijacking Cybersecurity: API is the New Endpoint As mentioned above, the first reason for the increased security risk of APIs - many APIs in an environment. For example, a Kubernetes application has hundreds of pods and microservices. Each of them is managing half a dozen or more APIs. (That's a typical scenario in a DevOps environment). is the explosion of adoption Now add that these microservices workloads (and hence the API calls) are temporary, run across clouds, are written in a multilingual fashion, and use different protocols. Or in short, APIs create a complex environment and challenging for the security team to oversight the API operation. Secondly, APIs were never meant to be exposed to the outside world. Yet, this is what we faced with the vulnerabilities found inside network protocol stacks. Those developers would never imagine their works would be adopted on the scale today. As a result, APIs have innate vulnerabilities and risks built within them. Thirdly, attacks and breaches have gotten increasingly sophisticated, especially those executed in the post-authentication and authorization phase. They are also more profound within the API data payload. Therefore, there is a need to look at security beyond authentication and authorization, also the application and API data payload layer. One way to do that is to think of API Security as analog to our traditional Endpoint security. DiD (Defense-in-Depth), Again! Security problems also happen in our daily life outside of computers. From the early stage of human history, various countries have been exploring and practicing multiple defense mechanisms and fortifications. These experiences and ideas also apply to endpoint, network, and API security. Let's say Endpoint Software is analogous to the castle: Identity authentication is equal to the commanders' ID proof, and Honeypots (or decoys at war) lure attackers away from high-profile targets. Among these war strategies, one of the most effective ways is Defense-in-Depth (DiD). The DiD approach can be divided into two areas: Boundary Defense (Anti-malware Signatures) Intrusion Detection/ Prevention (IDS/ IPS/ EDR) I'll explain API security with these DiD areas one by one. 1# Boundary Defense Boundary defense is the most basic type of defense. Almost all companies invest in boundary defenses. In endpoint security, we use signatures and IP denylists to defend against known attack methods. As the front line of protection, this layer aims to stop 90% of all attacks, non-targeted and initiated by unskilled individuals who do not have solid technical know-how or a hacker mindset. In this scenario, boundary defense can resist these indiscriminate attacks well enough. In API Security, WAF is doing an excellent job in this area. It offers standard features for boundary defense: ·         IP allowlists and denylists, ·         WAF rules engine, ·         Rate limiting, and ·         fault injection/ fuzzing. When in combination, it can block almost all commodity attacks. 2# Intrusion Detection (++) Security visibility is a critical element of attack prevention. After a hacker has breached the perimeter, we need a proper way to identify which file/ process/ traffic is likely related to the malicious attack. In Endpoint Software, we have to inspect all requests passing through the front gate. host-based IDS/ IPS Some other detection methods, such as APT detection and machine learning, could be more intuitive to evaluate against targeted attacks. Other typical ways of implementing behavior analysis are: ·         Honeypots, ·         EDR (Endpoint Detection and Response), and ·         Threat intelligence (file & process). Among all those methods, honeypots are one of the oldest (since the beginning of wars). By luring some high-value targets into traps/ decoys, they can analyze the enemy’s behaviors and even help locatei them. Nowadays, we adopt these tactics and turn them into deception techs. In the modern world, API security solutions provide combinations of the mentioned techniques; for example, artifacts collected in honeypots can then send into the threat intelligence feed for WAF or Web Application and API Protection (WAAP) consumption. In this layer, we have similar techniques to enhance visibility and the speed to stop an attack: ·         Network Honeypots ·         NDR (Network Detection and Response), and ·         Threat intelligence (payload & network). Using bots to execute "credential-stuffing" attacks is another common attack tactic. It attempts to steal high-value assets. The strategy is to find a way to get login information, such as leaked emails/passwords, and then try to access network locatons in batches (lateral movement). By far, the most efficient defense to combat credential stuffing is from the source: identify the bot from real users to intercept all requests made by the bot. As such, some AppSec tools also equip anti-bots features, a specific type of behavior detection as part of API security. When API Security Meet Zero Trust I am not saying DiD is useless. API and Application Security solutions such as WAF protection for organizations from commodity attacks. However, as mentioned, API creates a complex environment, and misconfiguration worsens the problem. With an uncleared perimeter, there may need to be more than DiD approach. Zero Trust essentially puts obstacles everywhere for the attackers, making it impossible for them to move laterally within the environment. Zero trust is a comprehensive security framework and strategy. It requires strict and unified verifying steps for all terminals, BYODs (Bring Your Own Devices), servers, APIs, microservices, data storage, and internal services. The main idea of Zero Trust is , including APIs. Whether it is an internal access external request, a mobile phone or a PC, an API call or HTTP request, an ordinary employee or a CEO, none can be trusted. to turn the centralized enforcement point into multiple micro checkpoints in every path of your applications To effectively achieve such a goal without stopping or slowing your applications, would be the critical determining steps. orchestration and automation Why Orchestration and Automation are Crucial for Zero Trust API Security? ZTA, NIST SP800–207 | Image by the author To explain the necessity of the two, let’s take a closer look at one pillar of Zero Trust Architecture — . This defense method is similar to showing your passport at the airport checkpoint and your ID cards to purchase alcohol. User/ Device access trust Without the corresponding identity and authority, it is impossible to enter the related system. This is where an API Gateway comes in strong, as it provides some key authentication features: Automatic rotation of keys Integrating with multiple authentication systems such as OKTA and Auth 2.0 Support TLS and mTLS encryption of traffic There are two core components of User and Device Trust: Identity and Access Management API Gateway with integrated security , such as airports and high-speed railways. You must also understand all the routes to and from all transportation hubs and implement safeguards. Imagine adding identification equipment in all transportation hubs In a large enterprise, there will be hundreds of systems, tens of thousands of APIs and microservices, and hundreds of thousands of clients. Unless we have unlimited resources and time, the DevOps, Security, or Application team can’t define and manually add hundreds of thousands of micro-identification checks in modern applications. All the other pillars of Zero Trust also require the same logic for adoption. The need is a solution that: Architecture, Application, Workload, and Data It uses modern architecture, Works in heterogeneous environments, Mitigates these risks (not just the commodities), and Does all this in an automated manner across multi-cloud environments (optional) open-source, such that to enable technology agility and creativity. What’s the Idea Zero Trust API Security Look like? To adopt the complex and heterogeneous environments in API, the Zero Trust API Security solution , for example: must be able to be deployed as multiple formats and thus support different settings Docker Container, A standalone reverse proxy, Agent for web/ application server, or Embedded in Kubernetes Ingress Controller. With the support of the cloud and modern application architecture, automation and scalability would be taken care of. But to maintain orchestration, the “agent” (or micro-enforcement point) must be able to be deployed while ensuring minimal latency and maximum control. on top of an existing application without changing existing architecture After considering the deployment and architecture form factors, it is also essential that the security level is not degraded. To be genuinely Zero Trust adopted, without transmitting to other clouds or engines, such as a cloud sandbox for analysis. security processing should be done locally If external parties are not in our control, verifying the Data / Network access trust is difficult. There are some other benefits of doing such locally, such as: Sensitive data does not leave the protected environment. You don’t need to share certificates and private keys with third parties. No dependency on 3rd party uptime for processing traffic. Ideally, we need a solution that can infuse into the application environment while an orchestrator can manage those agents and take care of the following operations: The last part is to consider orchestration. agents registration/ deregistration policy update configuration update software update logging and Data synchronization. In short, Zero Trusted API Security should be in various forms to infuse into modern app environments. Meanwhile, the best solution should be able to provide orchestration and all the security functions that traditional solutions can provide. So as you know, zero trust is not flawless. Zero-trust solutions cannot fully defend against zero-day or social engineering attacks, although they can significantly reduce the attack surface and impact. To learn about Zero Trust Architecture: . Introduction to the Zero Trust Security Architecture — a Concept, Not A Product Final Words APIs have become the central nervous system of modern applications, bringing critical information and data from one part of the application to another or from one application to another. As a result, API security should be the priority when securing applications. This is particularly true for public APIs, with users worldwide accessing software components and sensitive data. Adopting Zero Trust Framework shifts the focus from a single safeguard to different pillars (Users, Devices, Networks, Applications, and Data). That can help you ensure that every part of API access, whether inside or outside the perimeter, is under the least privileges approach and continuously monitored. Thank you for reading. May InfoSec be with you🖖.

This story contains new, firsthand information uncovered by the writer.

Stacks

Different

Google

ProgrammableWeb

Target

Cloud Phishing: New Tricks and the Crown Jewel

AppSec: SecDevOps or DevSecOps? Do We Need to Choose? Guide to the What and the Why

2021 - HackerNoon Contributor of the Year - CULTURE

Support Me on Coil

2021 - HackerNoon Contributor of the Year - PERSONAL-DATA

Nominated for 2022 - HackerNoon Contributor of the Year - Cybersecurity

Nominated for 2022 - HackerNoon Contributor of the Year - Security

Nominated for 2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Beginners Guide

Nominated for 2022 - HackerNoon Contributor of the Year - Containers

Nominated for 2022 - HackerNoon Contributor of the Year - Data Privacy

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

How to Use Zero Trust Framework for  API Security

How to Use Zero Trust Framework for API Security

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

10 Best Practices for Securing Your API

The Noonification: How AI/ChatGPT Dreams in 2022 (12/7/2022)

21 API Monitoring Tools That Will Make You a Developer Superhero in 2023!

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

10 Best Practices for Securing Your API

The Noonification: How AI/ChatGPT Dreams in 2022 (12/7/2022)

21 API Monitoring Tools That Will Make You a Developer Superhero in 2023!

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps