Proofpoint Cloud App Security Broker (Proofpoint CASB) helps you secure applications such as Microsoft Office 365, Google Workspace, Box, and more. It gives you people-centric visibility and control over your cloud apps, so you can deploy cloud services with confidence.
Configuration requirements
To run this collector, there are some configurations detailed below that you need to consider.
Configuration
Details
Configuration
Details
API access to a Proofpoint CASB
You will need a API access to a Proofpoint CASB instance configured in an environment acting as a cloud security app broker.
Configure Proofpoint CASB
Install and configure Proofpoint CASB in a cloud environment per Proofpoint instructions and guidance
Obtain API authentication details
Contact your Proofpoint customer representative to obtain your api_key, cliend_id, and client_secret
More information
Refer to the Vendor setup section to know more about these configurations.
Devo collector features
Feature
Details
Feature
Details
Allow parallel downloading (multipod)
Allowed
Running environments
Collector server
On-premise
Populated Devo events
Table
Flattening preprocessing
Yes
Data sources
Data Source
Description
API Endpoint
Collector service name
Devo Table
Available from release
Data Source
Description
API Endpoint
Collector service name
Devo Table
Available from release
Alerts
Alerts corresponding to related events
/v1/alerts
alerts
casb.proofpoint.alert
v1.0.0
Events
Cloud activity events
/v2/events
events
casb.proofpoint.event
v1.0.0
For more information on how the events are parsed, visit our page.
Flattening preprocessing
Data Source
Collector Service
Optional
Flattening Details
Data Source
Collector Service
Optional
Flattening Details
Alerts
alerts
No
Alerts are flattened on the related_events field. Each resultant record includes all the fields of the parent object, the target child object, and fields identifying the index of the target child object.
Events
events
No
Events are flattened on the additionalProperties field. Each resultant record includes all the fields of the parent object, the target child object, and fields identifying the index of the target child object.
Vendor setup
There are some requirements to set up this collector. You will require API access to a Proofpoint CASB instance configured in an environment acting as a cloud security app broker for one or more cloud applications. To achieve that, you should:
Configure Proofpoint CASB: Install and configure Proofpoint CASB in a cloud environment per Proofpoint instructions and guidance.
Obtain API authentication details: Contact your Proofpoint customer representative to obtain your api_key, cliend_id, and client_secret.
Minimum configuration required for basic pulling
Although this collector supports advanced configuration, the fields required to retrieve data with basic configuration are defined below.
This minimum configuration refers exclusively to those specific parameters of this integration. There are more required parameters related to the generic behavior of the collector. Check setting sections for details.
Setting
Details
Setting
Details
api_key
The api_key obtained from Proofpoint for authentication.
client_id
The client_id obtained from Proofpoint for authentication.
client_secret
The client_secret obtained from Proofpoint for authentication.
See the Accepted authentication methods section to verify what settings are required based on the desired authentication method.
Accepted authentication methods
Depending on how did you obtain your credentials, you will have to either fill in or delete the following properties on the JSON credentials configuration block.
Authentication Method
API Key
Client ID
Client Secret
Authentication Method
API Key
Client ID
Client Secret
OAuth
REQUIRED
REQUIRED
REQUIRED
Run the collector
Once the data source is configured, you can send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).
Collector services detail
This section is intended to explain how to proceed with specific actions for services.
Alerts
These are the alerts corresponding to related events.
Devo categorization and destination
All events of this service are ingested into the table casb.proofpoint.alert
Once the collector has been launched, it is important to check if the ingestion is performed in a proper way. To do so, go to the collector’s logs console.
This service has the following components:
Component
Description
Component
Description
Setup
The setup module is in charge of authenticating the service and managing the token expiration when needed.
Puller
The setup module is in charge of pulling the data in a organized way and delivering the events via SDK.
Setup output
A successful run has the following output messages for the setup module:
INFO InputProcess::ProofpointCasbPullerSetup(example_collector,proofpoint_casb#proofpoint_casb_1,alerts#predefined) -> Setup for module <ProofpointCasbAlertsPuller> has been successfully executed
Puller output
A successful initial run has the following output messages for the puller module:
2023-01-16T15:16:20.026 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) Starting the execution of pre_pull()
2023-01-16T15:16:20.027 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Reading persisted data
2023-01-16T15:16:20.028 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Data retrieved from the persistence: {'initial_start_time_in_utc': '2022-01-16T00:00:00Z', 'last_event_time_in_utc': '2022-01-21T00:00:00Z', 'last_ids': [], '@persistence_version': 1}
2023-01-16T15:16:20.029 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Running the persistence upgrade steps
2023-01-16T15:16:20.029 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Running the persistence corrections steps
2023-01-16T15:16:20.030 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Running the persistence corrections steps
2023-01-16T15:16:20.031 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Detected initial start time in UTC change: {'values_changed': {'root': {'new_value': '2023-01-16T00:00:00Z', 'old_value': '2022-01-16T00:00:00Z'}}}. Resetting state to {'initial_start_time_in_utc': '2023-01-16T00:00:00Z', 'last_event_time_in_utc': '2023-01-16T00:00:00Z', 'last_ids': [], '@persistence_version': 1}
2023-01-16T15:16:20.031 WARNING InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Some changes have been detected and the persistence needs to be updated. Previous content: {'initial_start_time_in_utc': '2022-01-16T00:00:00Z', 'last_event_time_in_utc': '2022-01-21T00:00:00Z', 'last_ids': [], '@persistence_version': 1}. New content: {'initial_start_time_in_utc': '2023-01-16T00:00:00Z', 'last_event_time_in_utc': '2023-01-16T00:00:00Z', 'last_ids': [], '@persistence_version': 1}
2023-01-16T15:16:20.038 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Updating the persistence
2023-01-16T15:16:20.039 WARNING InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Persistence has been updated successfully
2023-01-16T15:16:20.040 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) Finalizing the execution of pre_pull()
2023-01-16T15:16:20.040 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Starting data collection every 600 seconds
2023-01-16T15:16:20.040 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Pull Started
2023-01-16T15:16:20.042 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Retrieving/sending alerts event(s) having timestamp between 2023-01-16T00:00:00+00:00 and 2023-01-16T14:16:20.026261+00:00
2023-01-16T15:16:20.282 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Retrieved 0 alerts event(s) from 2023-01-16T00:00:00+00:00 to 2023-01-16T14:16:20.026261+00:00
2023-01-16T15:16:20.283 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> (Partial) Statistics for this pull cycle (@devo_pulling_id=1673878580026):Number of requests made: 1; Number of events received: 0; Number of duplicated events filtered out: 0; Number of events generated and sent: 0; Average of events per second: 0.000.
2023-01-16T15:16:20.283 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Statistics for this pull cycle (@devo_pulling_id=1673878580026):Number of requests made: 1; Number of events received: 0; Number of duplicated events filtered out: 0; Number of events generated and sent: 0; Average of events per second: 0.000.
2023-01-16T15:16:20.283 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> The data is up to date!
2023-01-16T15:16:20.284 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Data collection completed. Elapsed time: 0.258 seconds. Waiting for 599.742 second(s) until the next oneler(threatquotient_collector,threatquotient_data_puller#111,events#predefined) -> Data collection completed. Elapsed time: 0.483 seconds. Waiting for 4.517 second(s) until the next one
After a successful collector’s execution (that is, no error logs found), you will see the following log message:
2023-01-16T15:16:20.283 INFO InputProcess::ProofpointCasbAlertsPuller(proofpoint_casb,proofpoint_casb_1,alerts,predefined) -> Statistics for this pull cycle (@devo_pulling_id=1673878580026):Number of requests made: 1; Number of events received: 0; Number of duplicated events filtered out: 0; Number of events generated and sent: 0; Average of events per second: 0.000.
This collector uses persistent storage to download events in an orderly fashion and avoid duplicates. In case you want to re-ingest historical data or recreate the persistence, you can restart the persistence of this collector by following these steps:
Edit the configuration file.
Change the value of the initial_start_time_in_utc parameter to a different one.
Save the changes.
Restart the collector.
The collector will detect this change and will restart the persistence using the parameters of the configuration file or the default configuration in case it has not been provided.
Events
These are the events generated by the cloud activity.
Devo categorization and destination
All events of this service are ingested into the table casb.proofpoint.event
Once the collector has been launched, it is important to check if the ingestion is performed in a proper way. To do so, go to the collector’s logs console.
This service has the following components:
Component
Description
Component
Description
Setup
The setup module is in charge of authenticating the service and managing the token expiration when needed.
Puller
The setup module is in charge of pulling the data in a organized way and delivering the events via SDK.
Setup output
A successful run has the following output messages for the setup module:
Puller output
A successful initial run has the following output messages for the puller module:
After a successful collector’s execution (that is, no error logs found), you will see the following log message:
This collector uses persistent storage to download events in an orderly fashion and avoid duplicates. In case you want to re-ingest historical data or recreate the persistence, you can restart the persistence of this collector by following these steps:
Edit the configuration file.
Change the value of the initial_start_time_in_utc parameter to a different one.
Save the changes.
Restart the collector.
The collector will detect this change and will restart the persistence using the parameters of the configuration file or the default configuration in case it has not been provided.
Collector operations
This section is intended to explain how to proceed with the specific operations of this collector.
Initialization
The initialization module is in charge of setup and running the input (pulling logic) and output (delivering logic) services and validating the given configuration.
A successful run has the following output messages for the initializer module:
Events delivery and Devo ingestion
The event delivery module is in charge of receiving the events from the internal queues where all events are injected by the pullers and delivering them using the selected compatible delivery method.
A successful run has the following output messages for the initializer module:
Sender services
The Integrations Factory Collector SDK has 3 different senders services depending on the event type to delivery (internal, standard, and lookup). This collector uses the following Sender Services:
Sender services
Description
Sender services
Description
internal_senders
In charge of delivering internal metrics to Devo such as logging traces or metrics.
standard_senders
In charge of delivering pulled events to Devo.
Sender statistics
Each service displays its own performance statistics that allow checking how many events have been delivered to Devo by type:
Logging trace
Description
Logging trace
Description
Number of available senders: 1
Displays the number of concurrent senders available for the given Sender Service.
sender manager internal queue size: 0
Displays the items available in the internal sender queue.
Standard - Total number of messages sent: 57, messages sent since "2023-01-10 16:09:16.116750+00:00": 0 (elapsed 0.000 seconds
Displayes the number of events from the last time and following the given example, the following conclusions can be obtained:
44 events were sent to Devo since the collector started.
The last checkpoint timestamp was 2022-06-28 10:39:22.511671+00:00.
21 events where sent to Devo between the last UTC checkpoint and now.
Those 21 events required 0.007 seconds to be delivered.
Change log
Release
Released on
Release type
Details
Recommendations
Release
Released on
Release type
Details
Recommendations
v1.1.0
May 13, 2024
BUG FIXINGIMPROVEMENTS
Improvements
Upgraded Docker base image from 1.0.0 to 1.2.0
Update DCSDK from 1.8.0 to 1.11.1:
Updated DCSDK from 1.8.0 to 1.11.1 Updated DevoSDK to v5.1.9
Fixed some bug related to development on MacOS
Added an extra validation and fix when the DCSDK receives a wrong timestamp format
Added an optional config property for use the Syslog timestamp format in a strict way
Updated DevoSDK to v5.1.10
Fix for SyslogSender related to UTF-8
Enhace of troubleshooting. Trace Standardization, Some traces has been introduced.
Introduced a mechanism to detect "Out of Memory killer" situation
Updated DevoSDK to v5.1.9
Fixed some bug related to development on MacOS
Added an extra validation and fix when the DCSDK receives a wrong timestamp format
Added an optional config property for use the Syslog timestamp format in a strict
Bug fixing
Fixed the issue with 429 error because of number of request exceeded.
Recommended version
v1.0.1
Jun 15, 2023
BUG FIXINGIMPROVEMENTS
Improvements
Update DCSDK from 1.5.0 to 1.8.0
Bug fixing
Updated limits: The requests limits have been updated with the values recommended by the API to avoid 429 errors.
