Cloud native applications, based on the microservice architecture, interact with each other by sending requests or response through APIs. Arguably, API communications play an essential role in interactions of cloud native applications. Therefore, API security is an indispensable part of cloud native application security. API-related security issues shown below have a direct impact on security of cloud native applications: Which API services are exposed in the system? What are API invocations made? Are all these invocations essential service interactions to address a requirement? Does API probing or API misuse exist? Are there denial-of-service attacks against a service? How to identify abnormal invocation requests amid a great number of normal service invocation logics?
To ensure API security of applications under the cloud native architecture, we can implement API monitoring and protection throughout the API lifecycle, including API identification, API vulnerability detection, API invocations tracing, and abnormal API invocations monitoring.
API Identification and Discovery
APIs are frequently invoked among complicated and extensive microservices. For security assurance of these APIs, we need to first identify APIs to ascertain the followings:
- What APIs are exposed by services in the entire system?
- How are APIs designed, including what is the API URL and what arguments are used by APIs?
- How are APIs authenticated?
Answering these questions, we can sort out APIs as a kind of asset for security protection by associating them with pods, services, applications, and tenants.
API Analysis and Assessment
We need to conduct security analysis and assessment of all obtained API information, including API design vulnerability assessment, service logic security, and compliance assessment.
For vulnerability assessment, we can apply traditional API security solutions or leverage API security detection tools like 42Crunch or commercial API security scanning products to implement detections on encrypted connections, authentication and authorization, parameter checks, and response contents.
The service logic compliance detection involves the followings: Whether extra APIs other than those necessary for service access are exposed; whether these exposed APIs help expand the attack surface; whether the access control logic is implemented on the network side. For instance, a service is supposed to only access a certain GET API of another service, but actually it also has access to POST API, PUT API, and the like. To prevent such issues, an L7 firewall is usually deployed on the network layer for compliance detection and analysis at the application layer.
API Invocation Monitoring
The above mentioned API “asset” identification and API vulnerability and compliance detection can be seen as static security analysis of individual APIs. On the basis of static analysis, we will collect API invocations among all services in the entire system.
Upon API identification, we will continue to monitor and collect API invocation behaviors. During the identification phase, we will determine what APIs are provided by each service and what vulnerabilities exist in each API. By contrast, our monitoring phase, as with the distributed tracing, is conducted from the angle of a complete request execution process, i.e., a trace, focusing on which API invocation chain is requested by the trace and which request trace a certain invocation belongs to.
API Behavior Pattern Learning
After collecting API invocation data, the distributed tracing system will first preprocess data to pick out useful data fields and then use machine learning or statistical methods to analyze historical data so as to train API invocation behaviors in the business system, including the API invocation chain, invocation time, response time, and invocation parameters. Finally, the system will generate the normal API invocation behavior profile and signatures matching normal behaviors of the business system.
According to our previous experience, most of the numerous behaviors in the business system are normal and only a few are abnormal. During the training process, we will check the training results based on expertise and adjust parameters of the training model accordingly.
API Anomaly Detection
At this point, with normal API invocation behavior data of the business system in hand, we will match the current data against data in the signature database through retrieval and use the sequence similarity calculation method to find the best match.
The detection engine will compare the similarity between signatures and current data with the baseline. If the deviation falls within the baseline range, the API invocation behavior is deemed normal; otherwise, it is abnormal.
When it comes to the baseline, we need to first define the appropriate initial baseline based on expertise, which is adapted to different scenarios or automatically adjusted using an unsupervised learning model, or manually maintained by O&M personnel.
Related links:
Security Risks and Threats of Containerized Infrastructure
Security Visibility Augmented by Cloud Native
Zero-Trust Cloud Native Network Security Enabled by Micro-segmentation
