A Simple Guide to Oracle CASB Cloud Service Integrations with SIEM Providers

Oracle CASB Cloud Service (hereafter referred to as CASB) quickly gives you visibility into security of your cloud applications and services to help ensure that your critical data is secure. CASB provides these capabilities by frequently pulling in audit log information from various supported cloud services, analyzing them, running machine learning algorithms on them and generating risk events. Customers’ SOC could view and analyze these risk events to take appropriate corrective action.

CASB classifies the risks that it detects into one of these categories:

• Weak or noncompliant Security control
• Policy alert
• Anomalous behavior
• Suspicious behavior

You can find more information on each type of risk events created by CASB here.

Customers could view and analyze the risk events in CASB console. Some customers instead prefer to consolidate such events in a central SIEM system so that their SOC has to refer to only one system instead of multiple independent systems. Such customers could choose to export out these risk events to third party SIEM systems.

There are a couple of ways that customers can export risk events from CASB to upload into a SIEM system of their choice.

If the target SIEM system provides capabilities to import data in CSV format, customers can manually export events out of CASB console to a CSV file. Obviously, this is not a scalable approach and is useful only for ad hoc purposes. First let me show you how to perform this manual export and then I will describe at a high level, how to build an automated and scalable solution.

On the Risk Events UI page use the various attributes to select the desired data and click search. Once you have the results from this search operation, click the “Export to CSV” button as shown in the following screen capture:

Please note that in case the number of records to be exported exceed 1000, the export runs as a job and you can download the file once the job completes. Detailed steps for doing a CSV export are documented here.

With that out of our way, lets move on to how to build an automated solution. CASB provides a REST API that could be used to export events out of CASB. It is fairly straightforward to build an automated solution that could be used to periodically extract the risk events out of CASB and load them into a SIEM system. In the remainder of this blog post, I will describe the steps for building such a solution at a high level. This outline is language/platform agnostic. Customers could use anyone of the popular languages/frameworks to build this solution.

Let’s start by looking at the API exposed by CASB to extract the risk events. This API is called “Get all risk events” (API end point - "/api/v1/events/riskevents") and is documented here.

Following are the salient features of this API:

• The API allows for rich filtering capabilities via query parameters like “startDate”, “endDate”, “applicationInstanceName”, “applicationInstanceType”.
• As you might have guessed, the response could potentially contain a large number of entries. The API provides pagination feature to iterate through pages of response data.

Please refer to the official documentation link above for detailed information. It has some examples of requests, responses, commonly useful filters as well as a sample code snippet to illustrate the pagination feature.

Before you could call this API, you need to obtain a valid API access token from CASB. Following is a sequence of high level steps needed: Detailed steps are documented here.

• The base end-point for accessing CASB is “https://api-<CASB-STACK>.palerra.net” - where <CASB-STACK> is the name of the Oracle CASB Cloud Service stack that you are accessing (obtain this from your Oracle CASB Cloud Service tenant administrator):
  • trial: the trial environment for all regions.
  • loric: the production environment for North America south of Canada, and for Latin America.
  • loric-ca: the production environment for Canada.
  • loric-eu: the production environment for Europe, Africa, and the Middle East
• Get the CASB Tenant Access Key and Secret Key
• Use the Access Key and Secret Key to Retrieve the Access Token: The access token and tenant ID are required for each API call in order to access the CASB Service. You provide these parameters in request headers:
  • X-Apprity-Tenant-Id : "<tenant_ID_string>"
  • Authorization : Bearer "<access_token_string>"
• Call the desired REST API

Now that we know how to get a CASB access token for making an API call and various features of “Get all risk events” API like – filtering and pagination, lets’ look at a solution design for building an automated solution (an agent, if you will) to periodically extract the risk events from CASB and import them into a SIEM solution. Because a picture is worth thousand words, following is a design schematic of this solution:

Following are high-level details of this solution design:

• The CASB-SIEM integration agent should be implemented as a daemon process, so that it can periodically poll CASB and extract the risk events. Instead, it can also be scheduled via facilities like Linux/Unix cron. The agent should be designed in a flexible manner so that it could also be used in non-polling (for one time operations) mode, if desired.

• If this integration agent is running inside a customer’s own perimeter, there is no need to open up any firewall ports. The agent initiates traffic to CASB. Corporate firewalls typically allow response traffic for requests originating from inside corporate firewalls.

• Typically, SIEM systems expose a syslog receiver at a certain port. The integration agent, reads/extracts risk events data from CASB, maps the CASB risk event fields to the target SIEM system event format and writes/loads information to SIEM using the syslog receiver.

• The sample code in the official documentation located here describes how a combination of “startDate”, “endDate” and “markerPosition” could be used to paginate through a set of risk events. They could also be used to maintain state in the agent so that in polling mode, we could resume from the position where we left off.

• We could map CASB risk events fields to popular syslog formats like Common Event Format (CEF) or Log Event Extended Format (LEEF). For example, here is a sample mapping from CASB format to LEEF format:

And following is a sample mapping from CASB format to CEF format:

Hopefully this provides a good starting point and some direction for designing your CASB-SIEM integration solutions.