Understanding eBPF for API Security

• API security is increasingly a top priority for security leaders and risk executives.
• eBPF has emerged as a potential tool for observing APIs as part of an API security strategy.
• eBPF grants direct access to the Linux kernel, which has both advantages and serious risks.
• Security leaders should carefully weigh the pros and cons of eBPF in the context of their specific technical environment and their organization’s risk tolerance.

Background

Digital infrastructure is constantly evolving, forcing security professionals to strengthen security operations at an accelerated pace to mitigate risks. With that said, organizations increasingly realize how essential API security is to their information security strategy, and are evaluating solutions that are being touted as potential tools to secure APIs.  Recently,  eBPF (an evolution of Berkeley Packet Filter) has been a topic of discussion as a method for collecting data on APIs.  eBPF has been around since the early 1990s and has evolved over the years with the changes to the Linux kernel.

Pros & Cons

Given the familiarity some administrators have with eBPF, they might consider it as a viable solution for API traffic visibility. However, they must evaluate the pros and cons of various technologies before making significant integration decisions. Failure to do so could greatly compromise their security posture and impact incident response times.  Like any technology, eBPF has its pros and cons that need to be considered:

Pros

• Proven tool for providing visibility into inter-application traffic with community support
• Visibility to encrypted traffic – Depending on the configuration, eBPF may grant visibility into the plaintext behind encrypted traffic.
• Programmability – easily augmented with Java code to customize the data collection.

Cons

• Direct connectivity/access to Linux kernel which can be a serious security issue that affects multiple applications. There are documented attacks and known vulnerabilities for certain versions.
• Ease of programmability also means that it can also be used by hackers to execute code to extract or copy off PII or other valuable data easily.

Additional considerations

Discovering API issues is crucial but just as important is the remediation of the API risks. eBPF, while great for finding API issues, isn’t designed to enable remediation of the issue. Administrators will therefore need to find another solution to resolve the issue. Notably, a true API security solution that addresses gaps in protection from code to production.

Noname delivers actionable intelligence + remediation

Noname was created to deliver industry-leading visibility into APIs and enable customers to quickly remediate the issues themselves with actionable insights. We understood that many customers had digital infrastructure spread across multiple clouds and on-prem facilities, using a mix of cloud-native and adapted legacy application services. Noname was therefore designed to both pull data from multiple sources, to build a complete picture of APIs, and push policies and remediation actions to the same infrastructure. Two especially relevant components of the Noname API Security Platform include:

• Integrations with current infrastructure, including app delivery controllers, cloud-native logging, load balancers, web application firewalls (WAFs), and firewalls. This enables Noname to see not only East-West traffic, but also North-South traffic as well for complete visibility. It also enables Noname to push out policies to block access to APIs either via HTTP header, user login, or IP address.
• The Noname Sensor, which was created to augment data observed from current infrastructure. It is a lightweight component that can be installed on any compute instance in your own environment. The sensor automatically reviews inbound/outbound traffic and sends the API transactions to the Noname engine for analysis.

By building our integrations specifically to address API security challenges, Noname is able to go beyond visibility by pushing policies to the integrated security platforms to mitigate API risks. It also allows Noname to locally analyze and correlate API traffic for customers who want to keep PII data local for compliance requirements.  Local analysis and correlation of API traffic enables Noname to offer a solution for private clouds (or on-prem deployments) where PII or similar information cannot leave the perimeter. This enables compliance with GDPR, PCI-DSS and other regulatory requirements.

To find out more about how Noname has implemented its API discovery and remediation, please review:

• Discovering and Protecting APIs Anywhere
• Remote Engine Solution Overview