APIs Everywhere
Size of the problem
In a recent conversation, a customer mentioned they figured they had something on the order of 6000 API endpoints in their environment. This struck me as odd, as I am pretty sure they have 1000+ HTTP-based applications running on their current platform. If the 6000 API number is correct, each application has only six endpoints. In reality, most apps will have dozens or hundreds of endpoints... that means there are probably 10s of thousands of API endpoints in their environment!
And you thought it was a pain to manage a WAF when you had a thousand apps!
But the good news is that you're not using all of them. The further good news is that you can REDUCE your security exposure.
When was the last time someone took things OFF your To-do list?
Tell me how!
The answer is to profile your application landscape. Much like the industry did in the early 20-teens with Web Application Security, understanding your attack surface is the key to defining a plan to defend it. This is what we call API Discovery.
By allowing your traffic to be profiled and APIs uncovered, you can begin to understand the scale and scope of your security journey.
You can do this by putting your client traffic through an engine that offers this, like F5's Distributed Cloud (or F5 XC). With F5 XC, you can build a list of the URIs and their metadata and generate a threat assessment and data profile of the traffic it sees.
Interactive view of API calls
This is a fantastic resource if you can push your traffic through an XC Load Balancer, but that isn't always possible.
Out of Band API Analysis
What are your options when you want to do this "Out of Band"? Out of Band (or OOB) presents challenges, but luckily, F5 has answers.
If we can gather the traffic and make it available to the XC API Discovery process, generating the above graphic for your traffic is easy.
Replaying the Traffic
Replaying, or more accurately, "mimicking" the traffic can be done using a log process on the main proxy - BIG-IP or nginx are good examples, but any would work - and then sending that logged traffic to a process that will generate a request and response that traverses an XC Load Balancer.
API Discovery traffic flow
This diagram shows using an iRule to gather the request and response data, which is then sent to a custom logging service. This service uses the data to recreate the request (and response) and sends that through the XC Load Balancer.
Both the iRule and the Logger service are available as open-source code here.
If you're interested in deploying this, F5 is here to help, but if you would like to deploy it on your own, here is a suggested architecture:
Deploying the logger as a container on F5 Distributed Cloud's AppStack on a Customer Edge instance allows the traffic to remain within your network enclave. The metadata is pushed to the XC control plane, where it is analyzed, and the API characteristics are recorded.
What do you get?
The analysis provided in the dashboard is invaluable for determining your threat levels and attack surfaces and helping you build a mitigation plan.
From the main dashboard shown here, the operator can see if any sensitive data was exposed (and what type it might be), the threat level assessment and the authorization method. Each can help determine a course of action to protect from data leakage or future breach attempts.
Drilling into these items, the operator is presented with details on the performance of the API (shown below).
endpoint details
To promote sharing of information, all of the data gathered is exportable in Swagger/OpenAPI format:
swagger export
Where to from here?
We will publish more on this in the coming weeks, so stay tuned.