SBN

API Security: Best Practices for API Activity Data Acquisition

API data collection is the foundation for API security. Data collection has two core purposes:

  • API discovery, which is crucial for any effective API security program. More importantly, continuous API discovery is needed to find rogue and zombie APIs
  • API traffic analysis for vulnerabilities and threats, as mentioned in API10 in OWASP’s API top 10 vulnerabilities. As with any network security endeavor, the security product needs to see the right data to analyze it for threats.

This post includes four recommendations for effective API data collection.

 

1. Start with the broadest possible vantage point

Visibility breadth is essential when designing your API security approach. If you have a generally standardized API deployment and management process you will likely focus API data collection based on that standard process. But detecting the unexpected is arguably a more critical element of your API security strategy. After all, rogue APIs implemented outside of your sanctioned process – and forgotten shadow APIs created on legacy API stacks – likely pose more significant risks than new APIs on your primary stack. Make sure your API data collection mechanisms, particularly to enable continuous discovery, enable you to find all APIs

This is an area where traffic monitoring and log collection have an advantage over host-based sensors. Mirroring traffic from key points in the network, and using logs for example, from API gateways, provide by definition a broad coverage that is more likely to capture unsanctioned API activity, as long as your API security system is architected to discover them. In contrast, most types of host-based sensors, and especially code instrumentation, will only see activity for the specific API hosts equipped with sensors.

Even when taking advantage of the broader visibility that log and traffic monitoring provide, it’s still important to seek out and eliminate blind spots. Hybrid-cloud and multi-cloud environments often have API traffic flowing in many different locations, each of which must be accessed separately. Note that insufficient API activity logging and monitoring is specifically highlighted as a leading API risk on the OWASP API Top 10 and no less in the OWASP Top 10. So, if you’re relying on traffic or log data, make sure you are seeing a complete picture. Below, in the discussion on sanitizing data, you can learn how to satisfy the compliance team that sensitive data in detailed logs is protected.

2. Add depth to your primary API monitoring stack

Log and traffic data can come from many different sources. It is helpful from a coverage standpoint to collect this data from infrastructure sources, such as packet brokers, cloud platforms, API gateways, container and mesh orchestration tools, proxies, content delivery networks, web application firewalls, and centralized logging platforms. The coverage these platforms provide is excellent for baseline API discovery. But it’s also important to consider the depth and fidelity of data when designing your API data collection approach.

For example, suppose you are collecting logs directly from your API gateway. It isn’t guaranteed that your API gateway logs will include sufficient detail to perform the most advanced types of behavioral analytics. For example, even if all HTTP activity appears in the logs, request and response headers may have varying amounts of detail. And useful data like message payloads may be missing entirely depending on the vendor.

For platforms like Neosec that identify entities involved in API activity, piece together business context, and monitor for behavioral anomalies, additional data fidelity provided by API traffic mirroring technologies can be invaluable.

3. Sanitize your API activity data

Most of what we’ve covered so far is focused on collecting the broadest and deepest set of API activity data possible. Doing so ensures that your API discovery and security analysis are as comprehensive as possible and that you have the necessary foundation for the types of behavioral analytics that are needed to stay ahead of advanced API threats.

But it’s quite possible you’ve been trapped in the “insufficient logging and monitoring” OWASP API10 vulnerability hole until now, simply because properly logging and monitoring API activity requires robust data sanitization – as your compliance team keeps telling you. And that is no mean feat.

So before you allow a security vendor to analyze your API activity, it’s important to challenge them to demonstrate that they can sanitize the data before it leaves your on-premises or virtual private cloud environments.

Adopting this type of cloud security model will give you the confidence to allow your vendor’s sensors to send highly granular details to the cloud for analysis while protecting your sensitive user data and intellectual property.

 

4. Take the first step to better API discovery and advanced threat detection

Identifying the best API data collection techniques for your organization – and deciding how to best weigh the trade-offs between them – may seem daunting. But it doesn’t have to be. Our team at Neosec will guide you on this journey and ensure that your approach incorporates the latest best practices. Take the first step by starting your free trial of Neosec today.

 

 

 

*** This is a Security Bloggers Network syndicated blog from Blog authored by Neosec Team. Read the original post at: https://www.neosec.com/blog/best-practices-for-api-activity-data-acquisiton