SOC Integration via SIEM or ASOC? (Part 2)

Benefits of SOC and WAF Integration for API Monitoring

Here I would like to tell you how to deal with events that show anomalies in the API and how to use these events when integrating with SIEM systems. Here Sergey and I tried to analyze the most common variations. But if you have your own examples, welcome to the comments!

The main benefits for the conditional 1st line of SOC can be divided into 2 groups:

Monitoring API activity. SOC can use WAF-integrated API detection systems to monitor API interaction activity, including requests, responses, authentication, and authorization. This allows for the detection of suspicious or illegal activity, such as unauthorized access attempts or use of APIs for attacks.

Detecting anomalies in API traffic: Integration with API detection systems allows the SOC to analyze traffic and detect anomalies such as unusual or abnormally high request volumes, unusual behavior patterns, or suspicious changes in data processing. Such situations are typical for behavioral attacks such as: password brute-force attacks, session ID brute-force attacks, forced browsing, credential stuffing.

In what situations might this be important?

An anomaly in API traffic associated with a sharp increase in the number of requests to infrastructure endpoints containing authentication data, such as passwords, tokens, and secret keys. The illustration below shows a display of such endpoints in the ProAPI Structure, indicating the types of sensitive data (token, password, etc.) and the number of hits/attacks.

During the observed period, the number of requests to API endpoints increased several times compared to the usual level. This situation can be caused by various factors:

Marketing campaign. If, during the observed period, the company launched a campaign or sale, in order to participate in which users need to log in to their personal accounts, this could lead to a sharp increase in the number of requests.
Attack by intruders who are trying to gain access to accounts.
Technical Issues: There may be technical issues with your system that are causing your clients to resubmit requests multiple times.

What should be done?

The most difficult thing in this situation is to collect those parameters that will increase the probability of correct triage of events/incidents.

In simple terms “for SOCers” – how to understand when behavior is normal and when it is malicious. The following sequence of actions seems logical here:

Traffic monitoring and analysis. Its goal will be to build a request pattern to detect anomalous behavior. The next step will be to identify the API endpoints that are subject to the greatest number of attacks. Using the Threat Analysis dashboard of the WebMonitorex platform, you can visualize the request traffic.

The illustration clearly shows the peak values of the number of requests and the number of hits (attacks).

“for SOCers”: it is clear that such a dashboard can be assembled on any SIEM system, it is rather a reference for quick assembly by parameters. It is worth considering the ratio of requests to hits (attacks) identified by WAF or API protection system.

The API Structure dashboard allows you to visualize the list of the most attacked endpoints.

The traffic patterns identified as a result of monitoring become the basis for creating a definition threshold value of the number of requestsused in correlation analysis to protect against behavioral attacks. Correlation analysis is performed when a threshold is exceeded for the number of requests sent to the URL of an object with a certain identifier, the URL of a directory with resource files, or the URL for authentication or activation of users. The threshold is determined to reduce the risk of blocking legitimate requests (for example, when a user enters an incorrect password for their account several times). In our documentation You can read more about the implementation of protection against behavioral attacks using Webmonitorex products.

“for SOCers”: in this way, you can fill a multidimensional list with a fixed number of events for certain URL groups, and then add a simple alert to the logic of the correlation rules when the threshold is exceeded for a certain URL group.

During the monitoring process, it is necessary to identify the presence of potentially dangerous endpoints in the infrastructure. The specification comparison function, which is available in ProAPI Structure, will help with this. The process is organized as follows:

A. With the help of “ProAPI Structure” the structure of your endpoints, their list and parameters are validated, after which the structure is fixed as a file in the OpenAPI specification format (OAS). We will use this specification as a standard.

b. We compare the reference specification with the one built on traffic, which allows us to identify potentially dangerous APIs, such as:

Shadow API – An undocumented API that exists within an organization's infrastructure without proper permission or oversight.
Orphan API – Documented API that does not receive traffic.
Zombie API – Deprecated APIs that are considered disabled but are actually still in use.

V. The comparison results will be displayed in the “ProAPI Structure”.

For more information on comparing specifications, read our documentation.

“for SOCers”: Here you can set up additional scoring (increasing the significance of the event) in the following logic: if there is a request to the endpoint, but it belongs to the Shadow or Zombie group, then increase its scoring. Lists can be filled automatically via the API from the PRO API components Andor automatically copying URLs from events that have a field with the value Shadow\Zombie into a separate list.

API optimization. Based on the monitoring results, it would be advisable to optimize API endpoints. The goal of optimization should be to improve the security and performance of the infrastructure. The latter will help the API successfully cope with increased load during attacks or marketing campaigns. First of all, it is necessary to pay attention to potentially dangerous APIs, information about which should be transferred to the development team, as part of the DevSecOps process. In the process of API optimization, we recommend using the methods OWASPFor example, to protect against brute-force attacks, it is proposed to implement:
a. Multi-factor authentication.
b. Mechanisms for protection against brute-force attacks on credentials (In the ProWAF product, this is implemented in the form of triggers with the “Number of requests” condition).
in. Captcha.

To improve performance, you may need to scale your API. We recommend that you do this as part of the API Security approach within DevSecOps. You can find more information about enabling API management mechanics in our article.

Intermediate result “for SOCers” – With this approach, groups of rules appear:

Signaling the excess of requests in a certain period of time
Signaling unusual requests to endpoints that should not be accessed
Signaling potentially suspicious requests that fall outside the expected range for URL groups

The following order of actions is added to the playbook:

Notification to developers about the presence of Shadow\Orphan\Zombie API;
Tracking requests by URL groups, updating URL groups together with the development team
Reaction to unusual requests

Safety. Once the basic processes have been defined, you can begin tuning the platform. The following tools are available to protect against behavioral attacks:
A. Trigger for detecting brute force attack. The illustration below shows an example of setting up a trigger to block a classic brute force attack.

“for SOCers”: IP lists can be downloaded and used as part of TI feeds to enrich information about other attacks, or create a matching rule like “if an attack from this IP is recorded, add it to the list, find other attacks from the same IP”
b. Trigger for detecting BOLA/IDOR attacks. The illustration below shows an example of setting up a trigger.

“for SOCers”: This type of system event can be clearly identified as an incident, and the lists of URLs for which the event was detected can be sent to development

V. Trigger for detecting forced browsing. The illustration below shows an example of setting up a trigger.

“for SOCers”: This type of event is more difficult to uniquely identify, but the principle of action is similar to the brute force option.

API availability. Configure L7 DDoS protection. L7 DDoS protection is achieved by configuring brute force and forced browsing triggers, as well as a rate limit rule. This rule is designed to regulate the connection limit, which helps prevent excessive traffic to your API. This rule allows you to specify the maximum number of connections that can be established to a specific area, as well as ensure that incoming requests are distributed evenly. If the limit is exceeded, the incoming request will be rejected and the code selected when configuring the rule will be sent. You can read more about setting up rules in our documentationBelow is an example of setting up a rule to limit 5 POST requests per minute for each IP address.

Next, let's look at what happens after performing the actions described in points 1-4. If the configured triggers record requests containing signs of brute force or forced browsing attacks, they are displayed in the “Events” section of the platform. These events will be processed in accordance with the trigger settings, for example, the IP address will be added to the blacklist for blocking, and the user may receive a notification about this.

Since a sign of an attack is a sharp increase in the number of requests at a certain point in time, the detection of the onset of an attack must be done by comparing two similar time periods based on request statistics. If the number of requests in the period under consideration exceeds the number of requests in similar time intervals in the past, then this is a marker of the onset of an attack.

Integrating our platform components with SIEM systems is quite simple, it looks something like this:

We will consider in more detail the integration details and options for interaction with SOC\ASOC components in the next part of the article.

In the meantime, here is a brief summary of what can be obtained based on the events generated by the WAF and the API protection platform “for SOCers”:

Set up multiple groups of correlation rules to track what's happening with the API
Create regular or precedent actions when certain types of events are detected
Enrich TI lists to improve scoring of other events identified by NGFW\IPS or NTA
Set up integration of protection tools, for example: block IPs on the firewall from which the WAF identified an attack

Subscribe to our Telegram channel. All about API Security, Web Security. A little more about vulnerabilities and technical research of the Webmonitorex team. No advertising. Only useful materials.