# System Integrations
**Can't find your integration?**
No worries, if your desired integration isn't listed, you can [create a support ticket](https://support.cytechint.io/) and let us know what you need. Our team will check your request and get back to you with updates or alternatives.
***Tip:** *Share details like the integration name, platform, and how you plan to use it to help us assist you faster.**
# 1 Password Integrations
##### **Introduction**With 1Password Business, you can send your account activity to your security information and event management (SIEM) system, using the 1Password Events API.Get reports about 1Password activity, such as sign-in attempts and item usage, while you manage all your company’s applications and services from a central location.With 1Password Events Reporting and Elastic SIEM, you can:
- Control your 1Password data retention
- Build custom graphs and dashboards
- Set up custom alerts that trigger specific actions
- Cross-reference 1Password events with the data from other services
##### **Events**
**Sign-in Attempts**
Use the 1Password Events API to retrieve information about sign-in attempts. Events include the name and IP address of the user who attempted to sign in to the account, when the attempt was made, and – for failed attempts – the cause of the failure.
**Item Usages**
This uses the 1Password Events API to retrieve information about items in shared vaults that have been modified, accessed, or used. Events include the name and IP address of the user who accessed the item, when it was accessed, and the vault where the item is stored.
##### **Requirements**You can set up Events Reporting if you’re an owner or administrator.Ready to get started?
##### **1Password Integration Procedures**Please provide the following information to CyTech:The 1Password Events API Beat returns information from 1Password through requests to the Events REST API and sends that data securely to Elasticsearch. Requests are authenticated with a bearer token. [Issue a token](https://support.1password.com/events-reporting-elastic/#issue-a-bearer-token) for each application or service you use.To connect your 1Password account to Elastic:
1. Download and install [the 1Password Events API Elastic Beat ](https://github.com/1Password/events-api-elastic/releases) from the 1Password GitHub repository.
2. Download [an example eventsapibeat.yml file ](https://github.com/1Password/events-api-elastic/blob/main/eventsapibeat-sample.yml).
3. [Configure the YAML file for the Beat](https://support.1password.com/events-reporting-elastic/#appendix-elastic-beat-yaml-file-schema) to include:
- The bearer token you saved previously in the auth\_token fields for each [1Password event type](https://support.1password.com/events-reporting-elastic/#appendix-list-of-1password-event-types) you plan to monitor.
- The output for events (sent directly to Elasticsearch, or through Logstash).
- Any other configurations you want to customize.
4. Run the following command:./eventsapibeat -c eventsapibeat.yml -e
You can now use Elasticsearch with the 1Password Events API Beat to monitor events from your 1Password account. The returned data will follow the [Elastic Common Schema (ECS)](https://support.1password.com/events-reporting-elastic/#appendix-elastic-common-schema) specifications.
##### **Collect events from 1Password Events API**
1. URL of 1Password Events API Server - options: https://events.1password.com, https://events.1password.ca, https://events.1password.eu, https://events.ent.1password.com. path is automatic
2. 1Password Authorization Token - Bearer Token, e.g. "eyJhbGciO..."
# Active Directory Integrations
##### **Introduction**
Elastic Stack security features can be configured to authenticate users through Active Directory by using LDAP to communicate with the directory. Active Directory realms are similar to LDAP realms, as they both store users and groups in a hierarchical structure, which includes containers such as organizational units (OU), organizations (O), and domain components (DC).
The security features support authentication based on Active Directory security groups, but not distribution groups. When authenticating users, the username entered must match the sAMAccountName or userPrincipalName, not the common name (cn). The realm authenticates users via an LDAP bind request, searches for their entry in Active Directory, and retrieves their group memberships from the tokenGroups attribute to assign appropriate roles.
---
##### **Requirements**
Elastic Agent must be installed. For more details and installation instructions, please refer to the [Elastic Agent Installation Guide](https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html).
**Installing and managing an Elastic Agent:**
There are several options for installing and managing Elastic Agent:
**Install a Fleet-managed Elastic Agent (recommended):**
With this approach, you install Elastic Agent and use Fleet in Kibana to define, configure, and manage your agents in a central location. We recommend using Fleet management because it makes the management and upgrade of your agents considerably easier.
**Install Elastic Agent in standalone mode (advanced users):**
With this approach, you install Elastic Agent and manually configure the agent locally on the system where it’s installed. You are responsible for managing and upgrading the agents. This approach is reserved for advanced users only.
**Install Elastic Agent in a containerized environment:**
You can run Elastic Agent inside a container, either with Fleet Server or standalone. Docker images for all versions of Elastic Agent are available from the Elastic Docker registry, and we provide deployment manifests for running on Kubernetes.
Please note, there are minimum requirements for running Elastic Agent. For more information, refer to the [Elastic Agent Minimum Requirements](https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html#elastic-agent-installation-minimum-requirements).
---
##### **How to add configurations to Elastic Integration**
**I**. **Active Directory Base DN**
- **Definition**: The Base DN (Distinguished Name) specifies the starting point in the Active Directory hierarchy for user and group searches.
- **Format**: It typically represents the container or organizational unit (OU) where your user accounts are located.
- **Example**: If your AD users are in the "Users" OU under the domain "example.com", the Base DN might look like:
- `CN=Users,DC=example,DC=com`
**Note:** Refer to Step **I. Active Directory Information Lookup** for information on how to properly setup the configuration.
**II**. **Active Directory URL**
- **Definition**: The URL of your Active Directory server, specifying either an unsecured LDAP or secure LDAPS connection.
- **Format**:
- **LDAP (insecure)**: `ldap://your-ad-server.example.com:389`
- **LDAPS (secure)**: `ldaps://your-ad-server.example.com:636`
- **Example**:
- `ldap://ad.example.com:389`
**Note:** Refer to Step **II. Finding Active Directory URL for information on how to properly setup the configuration.
**III**. **Active Directory User**
- **Definition**: The username of the service account that Elastic Stack will use to authenticate and query AD. This account should have sufficient privileges to search for users and groups.
- **Format**:
- It can be in the form of a **fully qualified domain username**: `username@example.com`
- Or a **Distinguished Name (DN)**: `CN=ServiceAccount,OU=ServiceAccounts,DC=example,DC=com`
- **Example**:
- `CN=serviceaccount,OU=ServiceAccounts,DC=example,DC=com`
**Note:** Refer to Step **III. Navigate to Users for information on how to properly setup the configuration.
**IV**. **Active Directory User Password**
- **Definition**: The password for the AD user account used for the connection.
- **Example**:
- `MySecurePassword123`
---
##### **I. Active Directory Information Lookup**
Finding the Base DN (Distinguished Name)
Method 1: Using Active Directory GUI
1. Open "Active Directory Users and Computers"
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/pLtHwTEyMKdZDnw9-image.png)
2\. Right-click on your domain
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/WQMXNjY3mq5AROMI-image.png)
3\. Select "Properties"
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/wmZeP90KhCJ7G1g5-image.png)
4\. Look for the "Distinguished Name" field
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/K4Sbr4VizYM6T31g-image.png)
Method 2: Using PowerShell
1. Open PowerShell with administrator privileges
2. Run the command: Get-ADDomain | Select-Object DistinguishedName[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/vNlVjoxfLr4licpe-image.png)
3. The output will be in the format: "DC=company,DC=local"
---
##### **II. Finding Active Directory URL**
Method 1: PowerShell
1. Open PowerShell as administrator
2. Run the command: Get-ADDomainController | Select-Object Hostname
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/4TClLTUnGWNY1GFU-image.png)
3. Take the DC name from the output
- [LDAP://servername.domain.com](LDAP://servername.domain.com)
- [LDAP://server-IP](LDAP://server-IP)
---
##### **III. Navigate to Users**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/XvrzZ1bldTcI5OyY-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/AEO9NavbNuio7GqR-image.png)
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Add Windows Integrations
##### **Introduction**The Windows integration allows you to monitor the Windows OS, services, applications, and more.
Use the Windows integration to collect metrics and logs from your machine. Then visualize that data in Kibana, create alerts to notify you if something goes wrong, and reference data when troubleshooting an issue.For example, if you wanted to know if a Windows service unexpectedly stops running, you could install the Windows integration to send service metrics to Elastic. Then, you could view real-time changes to service status in Kibana's \[Metrics Windows\] Services dashboard.
##### **Data streams**The Windows integration collects two types of data: logs and metrics.Logs help you keep a record of events that happen on your machine. Log data streams collected by the Windows integration include forwarded events, PowerShell events, and Sysmon events. Log collection for the Security, Application, and System event logs is handled by the System integration. See more details in the Logs reference.
Metrics give you insight into the state of the machine. Metric data streams collected by the Windows integration include service details and performance counter values. See more details in the Metrics reference.
Note: For 7.11, security, application and system logs have been moved to the system package.
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### **Requirements**You need Elasticsearch for storing and searching your data and Kibana for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your own hardware.Each data stream collects different kinds of metric data, which may require dedicated permissions to be fetched and which may vary across operating systems.
**Setup**
For step-by-step instructions on how to set up an integration, see the Getting started guide.
Note: Because the Windows integration always applies to the local server, the hosts config option is not needed.
##### **Ingesting Windows Events via Splunk**This integration allows you to seamlessly ingest data from a Splunk Enterprise instance. The integration uses the httpjson input in Elastic Agent to run a Splunk search via the Splunk REST API and then extract the raw event from the results. The raw event is then processed via the Elastic Agent. You can customize both the Splunk search query and the interval between searches. For more information see Ingest data from Splunk.
Note: This integration requires Windows Events from Splunk to be in XML format. To achieve this, renderXml needs to be set to 1 in your inputs.conf file.
##### **Logs reference**
**Forwarded**
The Windows forwarded data stream provides events from the Windows ForwardedEvents event log. The fields will be the same as the channel specific data streams.
**Powershell**
The Windows powershell data stream provides events from the Windows Windows PowerShell event log.
##### **System Integration Procedures****Collect events from the following Windows event log channels: (Enable Yes/No)******
1. Preserve original event (Enable Yes/No)
- Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
6. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
7. Synthetic source (Enable Yes/No)
##### **Powershell (Enable Yes/No)******
1. Preserve original event(Enable Yes/No)
- Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
6. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
7. Synthetic source(Enable Yes/No)
##### **Powershell Operational(Enable Yes/No)**
1. Preserve original event(Enable Yes/No)
- Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
6. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
7. Synthetic source(Enable Yes/No)
##### **Sysmon Operational** **(Enable Yes/No)**
1. Preserve original event(Enable Yes/No)
- Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
6. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
7. Synthetic source(Enable Yes/No)
##### **Collect Windows perfmon and service metrics(Enable Yes/No)******
1. Perfmon Group Measurements By Instance(Enable Yes/No)
- Enabling this option will send all measurements with a matching perfmon instance as part of a single event
2. Perfmon Ignore Non Existent Counters(Enable Yes/No)
- Enabling this option will make sure to ignore any errors caused by counters that do not exist
3. Perfmon Queries
- Will list the perfmon queries to execute, each query will have an object option, an optional instance contiguration and the actual counters
4. Period
5. Synthetic source(Enable Yes/No)
##### **Windows service metrics(Enable Yes/No)**
1. Period
2. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
3. Synthetic source(Enable Yes/No)
##### **Collect logs from third-party REST API (experimental)(Enable Yes/No)******
1. URL of Splunk Enterprise Server
- i.e. scheme://host:port, path is automatic
2. Splunk REST API Username
3. Splunk Authorization Token
- Bearer Token or Session Key, e.g. "Bearer eyJFd3e46..." or "Splunk 192fd3e...". Cannot be used with username and password.
4. SSL Configuration
- i.e.certificate\_authorities, supported\_protocols, verification\_mode etc.
##### **Windows ForwardedEvents via Splunk Enterprise REST API(Enable Yes/No)******
1. Interval to query Splunk Enterprise REST API
- Go Duration syntax (eg. 10s)
2. Preserve original event(Enable Yes/No)
- Preserves a raw copy of the original event, added to the field event.original
3. Splunk search string
4. Tags
5. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
6. Synthetic source(Enable Yes/No)
##### **Windows Powershell Events via Splunk Enterprise REST API(Enable Yes/No)**
1. Interval to query Splunk Enterprise REST API
- Go Duration syntax (eg. 10s)
2. Preserve original event(Enable Yes/No)
- Preserves a raw copy of the original event, added to the field event.original
3. Splunk search string
4. Tags
5. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
- Preserves a raw copy of the original event, added to the field event.original
3. Splunk search string
4. Tags
5. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
- Preserves a raw copy of the original event, added to the field event.original
3. Splunk search string
4. Tags
5. Processors
- Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
6. Synthetic source(Enable Yes/No)
# AQUILA - 1Password Integration
## **1Password Events Reporting Integration Manual**With **1Password Business**, you can forward account activity to your SIEM system using the **[1Password Events API](https://support.1password.com/events-reporting/)**. This enables centralized monitoring, improved visibility, and enhanced response to security-related events across your organization.
---
### **Key Benefits**When integrated with your SIEM, 1Password Events Reporting allows you to:
- **Retain 1Password event data** according to your organization's policies
- **Build custom dashboards** and visualizations for insights
- **Configure custom alerts** to automate responses
- **Correlate 1Password events** with data from other systems and services
---
### **Permissions Required**You must be an **Owner** or **Administrator** of your 1Password Business account to configure Events Reporting.
---
### **Supported Event Types**
#### **Sign-In Attempts**Track authentication activity including:
- **Username and IP address** of the user
- **Timestamp** of the sign-in attempt
- **Success or failure status**
- **Cause of failure** (for failed attempts)These logs help monitor account access patterns and detect unauthorized access attempts.
---
### **How to Set Up**To begin configuring the integration, refer to the official 1Password guide:**[Set up Elastic Events Reporting Integration](https://support.1password.com/events-reporting/)**The 1Password Events API supports JSON-formatted log delivery, which can be ingested by your SIEM using a collector or custom integration script.*If you need further assistance, kindly contact our support at **support@cytechint.com**for prompt assistance and guidance.*
# AQUILA - Atlassian Account Integration
##### **What are API token scopes?**Scopes define what actions an API token is allowed to perform in Atlassian apps such as Jira and Confluence. They provide security by limiting the permissions of the token. You can create tokens with scopes (recommended) or without scopes (for apps that do not support scoped tokens).
##### **Creating an API token with scopes:**
1. Log in to [https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens)
2. Select "Create API token with scopes"
3. Enter a descriptive name for the token (for example: AQUILA - Monitoring)
4. Choose an expiration date for the token (between 1 and 365 days)
5. Select the application (Jira or Confluence)
6. Select the scopes or permissions the token should have
- Example for Jira: **read:audit-log:jira**
- Example for Confluence: **read:audit-log:confluence**
7. Click "Create"
8. Copy the token and save it securely. You cannot view it again after this step. If you lose it, you will need to generate a new token.
**Required credentials for Jira Integration access:**
- **API URL**: Base Jira API URL without the path
- **Jira User Identifier**: Your Atlassian email address
- **Jira API Token**: The API token you created*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - AWS Integration
#### **Overview**The AWS Integration enables the collection of logs and metrics from your Amazon Web Services (AWS) environment. This integration helps centralize security and operational data for monitoring, investigation, and reporting.
#### **Data Streams**
The AWS integration collects two main types of data:
1. **Logs** – Records of events that occur within your AWS account.Examples:
- Every request received by CloudFront
- Actions performed by AWS users or roles
- API activity captured by CloudTrail
2. **Metrics** – Real-time insights into the performance and health of AWS services.Examples:
- CPU utilization of EC2 instances
- S3 storage usage
- RDS performance metrics
- AWS cost and usage breakdowns
#### **Requirements**
Before configuring the AWS integration, ensure you have:
1. **AWS Credentials** – To connect to your AWS account.
2. **AWS Permissions** – To grant access to the necessary AWS services.
##### **Step 1. Create IAM User and Custom Policy**
1. **IAM User**
-an identity you create in **AWS Identity and Access Management (IAM)** that represents a person or application which needs to interact with your AWS resources.
2. **User Policy and Permissions**The IAM User must be granted the following permissions:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ce:GetCostAndUsage",
"cloudwatch:GetMetricData",
"cloudwatch:ListMetrics",
"ec2:DescribeInstances",
"ec2:DescribeRegions",
"iam:ListAccountAliases",
"inspector2:ListFindings",
"logs:DescribeLogGroups",
"logs:FilterLogEvents",
"organizations:ListAccounts",
"rds:DescribeDBInstances",
"rds:ListTagsForResource",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"sns:ListTopics",
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:ListQueues",
"sqs:ReceiveMessage",
"sts:AssumeRole",
"sts:GetCallerIdentity",
"tag:GetResources"
],
"Resource": "*"
}
]
}
```
##### **Step 2: Create Access Key
**
Long-term credentials associated with an IAM user or the AWS root account.
- 1. **Access Key ID** – First part of the access key
2. **Secret Access Key** – Second part of the access key
##### **Step 3: Create a CloudTrail Trail and Send Logs to S3**
Set up an AWS CloudTrail trail to record account activity and deliver log files into an S3 bucket for secure storage, auditing, and compliance monitoring.
1. **Open CloudTrail** > Create a **New Trail**
2. **Trail Settings**
- Trail name: Enter a unique name.
- Apply trail to all accounts in my organization.
3. Choose an S3 Bucket
- **Storage location** → Select **Create new S3 bucket** or **Use existing bucket**.
If using **new bucket**:
- Enter a bucket name.
- CloudTrail will create the bucket and add the correct permissions.
If using **existing bucket**:
- Select your bucket from the dropdown.
- CloudTrail will prompt you to allow access. Click **Yes** to let CloudTrail update the bucket policy.
4. Additional Settings
- **Enable for all accounts in my organization**
- **Log file SSE-KMS encryption:** Enable if you want encryption with a KMS key(optional).
- **Log file validation:** Enable to verify log integrity.
5. Choose Log Events
1. **Event Type**
- **Management events** - Capture management operations performed on your AWS resources.
- **Data events** - Log the resource operations performed on or within a resource.
- **Insights events** - Identify unusual activity, errors, or user behavior in your account.
- **Network activity events** - Network activity events provide information about resource operations performed on a resource within a virtual private cloud endpoint.
2. **Management events:**
- Check **Read**(default is usually All).
6. Review and Create
- Review your configuration summary.
- Click **Create trail**.To configure the AWS Integration:
**Please provide the following information to CyTech Support:**
*If you need further assistance, kindly contact our support at **[support@cytechint.com](mailto:info@cytechint.com)** for prompt assistance and guidance.*
# AQUILA - Azure Logs Integration
The **Azure Logs integration** enables you to collect logs from specific Azure services such as:
- **Microsoft Entra ID** (Sign-in, Audit, Identity Protection, Provisioning logs)
- **Azure Spring Apps**
- **Azure Firewall**
- **Microsoft Graph Activity**
- **Activity and Platform logs**
- Additional supported Azure services
#### **Example Use Cases**
- **Brute force sign-in detection**: Collect **Microsoft Entra ID sign-in logs** and configure an alert in the Observability Logs app to notify you if failed sign-in attempts exceed a defined threshold.
- **Capacity planning**: Collect **Azure Activity logs** to track when virtual machines fail to start due to quota limits, helping plan resource scaling.
---
#### **Data Streams**The Azure Logs integration collects **log data streams** from the following sources:
- Activity Logs
- Platform Logs
- Microsoft Entra ID Logs (Sign-in, Audit, Identity Protection, Provisioning)
- Microsoft Graph Activity Logs
- Azure Spring Apps LogsLogs provide a complete record of events that occur in your Azure environment, allowing you to detect threats, troubleshoot issues, and plan capacity.
---
#### **Azure Setup Prerequisites**To successfully forward Azure logs, you will need:
1. **Diagnostic Settings**
- Configure diagnostic settings in Azure to export metrics and logs from source services (e.g., Entra ID, Activity Logs).
- Logs must be sent to a supported destination for analysis and storage.
2. **Event Hubs**
- One or more **Event Hubs** to temporarily store and stream logs exported by Azure services.
- Log Collector will use Event Hubs as the ingestion point.
3. **Storage Account Container**
- A **Storage Account container** to store checkpoint information about logs consumed by Log Collector.
- This ensures logs are ingested reliably without duplication or loss.
---
#### **Step 1: Create an Event Hub for Microsoft Entra ID Logs**
1. **Go to Azure Portal > Event Hubs > Create Namespace**
- Select **Resource Group** or create a new one.
- Choose a **Region** and a **Pricing Tier (Standard or Premium)**.
- Click **Review + Create** → **Create**.
2. **Create an Event Hub** inside the namespace
- Navigate to the **Namespace** → Click **+ Event Hub**.
- Set **Name**: entra-id-logs (Example)
- Set **Partitions**: At least **2** (for redundancy).
- Click **Create**.
3. **Create a Consumer Group (Optional)**
- Go to **Event Hub > Consumer Groups**.
- Add a new group (e.g., aquila-agent-group).
4. **Generate Connection String**
- Navigate to **Event Hubs Namespace > Shared Access Policies**.
- Click **+ Add Policy**.
- Set Name: AquilaAgentPolicy.
- Select **"Listen"** permission.
- Copy **Primary Connection String** (used in the next steps).
---
#### **Step 2: Enable Diagnostic Settings for Microsoft Entra ID**
1. **Go to Azure Portal > Microsoft Entra ID**.
2. Navigate to **Monitoring > Diagnostic Settings**.
3. Click **+ Add Diagnostic Setting** and configure:
- **Name**: entra-logs-to-aquila
- **Log Categories**:-Sign-in logs-Audit logs-Identity Protection logs-Provisioning logs
- **Destination**: Select **Event Hubs**.
- **Choose the Event Hub Namespace** created earlier.
- **Select the Event Hub (entra-id-logs)**.
- Click **Save**.
---
#### **Step 3: Configure Azure Storage for Checkpointing**
1. **Create a Storage Account**
- Navigate to **Azure Portal > Storage Accounts > Create**.
- Select **Resource Group** (same as Event Hub).
- Set **Storage Account Name**:
- **Disable Hierarchical Namespace** and **Enable TLS 1.2**.
- Click **Create**.
2. **Create a Blob Container**
- Open the **Storage Account > Containers**.
- Click **+ Container**.
- Set **Name**:
- Set **Public Access Level**: Private.
3. **Copy Storage Account Keys**
- Go to **Storage Account > Access Keys**.
- Copy **Storage Account Name & Key** for integration configuration.
---
**Please saved and provide this values to AQUILA Support Team.**
- **Event Hub Name**:
- **Consumer Group**:
- **Event Hub Connection String**:
- **Storage Account Name**:
- **Storage Account Key**:
- **Storage Container Name**:
- **Resource Manager Endpoint(optional)**:
---
*If you need further assistance, kindly contact **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Cisco Meraki Integration
Cisco Meraki provides a centralized cloud management platform for devices like MX Security Appliances, MR Access Points, and more. Its cloud-based architecture enables secure, scalable networks manageable from anywhere via the Meraki Dashboard or Mobile App. Each Meraki network generates events that can be collected and analyzed.
---
##### **Integration Overview**This integration supports event collection through:
- **Syslog** messages from Meraki devicesEvents can be searched, observed, and visualized.
---
##### **Compatibility**
- Supports event collection from **MX Security Appliances** and **MR Access Points** via syslog.
- **MS Switch** events are **not supported** and will not be recognized.
---
##### Syslog Setup:1. I**dentify Syslog-ng IP Address**Access the log collector virtual machine and open a terminal. Run the following command to determine the IP address of the syslog-ng server:
```
ifconfig -a
```
Please take note of the IP address, as this will be referenced during the configuration.
2. **Install Syslog-ng**Install syslog-ng along with its required dependencies using the following command:
```
sudo apt-get install syslog-ng
```
3. **Configure Syslog-ng**Edit the syslog-ng configuration file:
```
sudo nano /etc/syslog-ng/syslog-ng.conf
```
Add the configuration below it, ensuring that Server\_IP\_Address and <MERAKI\_IP\_ADDRESS> are replaced with the appropriate values:
```
# Define syslog source
source s_net { udp(ip(Server_IP_Address) port(5140)); };
# Create filter to match traffic (this filter will catch all syslog messages from the MX)
filter f_meraki { host(""); };
# Define a destination for syslog messages
destination df_meraki { file("/var/log/cisco_meraki.log"); };
# Bundle the source, filter, and destination rules together
log { source(s_net); filter(f_meraki); destination(df_meraki); };
```
4. **Restart Syslog-ng**After saving the configuration, restart the syslog-ng service to apply the changes:
```
sudo /etc/init.d/syslog-ng restart
```
---
##### **Configuring the Cisco Meraki Integration**Once the syslog-ng server is configured, please proceed with the following steps in the Cisco Meraki dashboard:1. **Log in to the Cisco Meraki dashboard.**2. **Navigate to Network-wide > Configure > General.**3. **Click Add a syslog server.**4. **Populate the required fields as follows:**
- Server Address: Syslog server IP address
- Port: 10514
- Protocol: UDP5. Under Roles, enable**:**
- Switch Event Log
- Wireless Air Marshal Events
- Wireless Flow
Optional: Configuration Verification
To verify successful log ingestion, access the syslog server and run:
```
cd /var/log/
ls
```
If the file **cisco\_meraki.log** is present, the configuration has been successfully applied and logs are being received.
---
##### **Log Rotation Configuration**
To manage log growth and prevent disk space issues, please configure log rotation as follows:
Create a logrotate configuration file:****
```
sudo nano /etc/logrotate.d/meraki
```
**Add the following content:**
```
/var/log/cisco_meraki.log {
daily
missingok
rotate 1
compress
delaycompress
notifempty
create 0640 root root
postrotate
# Optional commands, such as reloading syslog services
# /etc/init.d/syslog-ng reload
endscript
}
```
---
##### **Log Events**Enable this option to collect Cisco Meraki log events across all applications configured for the selected log stream.
---
##### **Logs Dataset**
- The `cisco_meraki.log` dataset contains events collected from the configured syslog server.
- All Cisco Meraki specific syslog fields are available under the `cisco_meraki.log` field group for detailed analysis.
---
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Cisco Secure Endpoint Integration
##### **Introduction**
Cisco **Secure Endpoint** is a cloud-delivered, advanced **endpoint detection and response (EDR)** solution. It provides visibility and protection across multiple control points, enabling organizations to rapidly detect, contain, and remediate advanced threats.
---
##### **Assumptions**The procedures in this guide assume that a **Log Collector** has already been set up.
---
##### **Requirements**This integration is designed for collecting **Cisco Secure Endpoint logs**.
##### **Supported Dataset**
- **event dataset** → Supports Cisco Secure Endpoint **event logs**, either:
- Received over **syslog**
- Read from a **file**
---
##### **Generating Client ID and API Key**
To collect logs via the **Secure Endpoint API**, you must first generate API credentials:
1. Log in to your **AMP for Endpoints Console**.
2. Navigate to **Accounts > Organization Settings**.
3. Under **Features**, click **Configure API Credentials**.
4. Generate and copy the **Client ID** and **Secure API Key**.
**Important:** You can only copy your **API Key** at the time of creation. It cannot be retrieved later. Store it securely.
---
##### **Secure Endpoint Logs**
- The **event dataset** collects Cisco Secure Endpoint event logs.
---
##### **Secure Endpoint API Capabilities**The **Secure Endpoint API** can be used to retrieve and manage detailed information, including:
- Generate a list of **organizations** a user has access to.
- Generate a list of **policies** for a specified organization.
- Retrieve detailed information about a specific policy, such as:
- General policy data
- Associated network control lists
- Associated computers
- Associated groups
- Proxy settings
- Policy XML
- Generate a list of all **policy types** and supported **operating systems** for an organization.
---
##### **Top Use Cases**
- **Reporting:** Generate reports on policy settings across an organization.
- **Inspection:** Review a particular policy’s detailed settings.
- **Policy Auditing:** Query for policies that match specific criteria to determine which should be updated.
---
##### **API Response Format**
The Secure Endpoint API provides responses in three key objects:
- **Data** → Requested content.
- **Meta** → Metadata describing the request/response.
- **Errors** → Error details if the request fails.
---
To enable log collection from the Cisco Secure Endpoint API, provide the following information to **CyTech Support**:
- **Client ID** → Cisco Secure Endpoint Client ID
- **API Key** → Cisco Secure Endpoint API Key*If you need further assistance, kindly contact **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - CISCO Umbrella Integration
##### **Introduction**Cisco Umbrella is a cloud-delivered security platform that provides an additional layer of defense against malicious threats on the internet using Cisco’s threat intelligence. It helps block access to:
- **Malware**
- **Adware**
- **Botnets**
- **Phishing attacks**
- **Known malicious websites**
##### **Assumptions**The procedures described in this guide assume that a Log Collector has already been set up.
##### **Prerequisites**
- Full Admin access to Cisco Umbrella to create and manage Umbrella API keys.
- Umbrella API KeyAdmin access (if managing API key scopes and expirations).
---
##### **Requirements**
**This integration supports log ingestion from Cisco Umbrella. Data is collected from:**
- AWS S3 buckets using an SQS notification queue
- Cisco-managed S3 buckets without SQS
##### **Supported Dataset**
- log dataset: Collects Cisco Umbrella logs.
---
##### **Umbrella Logs**
**When using Cisco-managed S3 buckets without SQS:**
- Load balancing across multiple agents is not supported.
- A single agent must be configured to poll the S3 bucket.
- Vertical scaling can be applied by configuring the number of workers.
**The log dataset is responsible for collecting all Cisco Umbrella logs.**
---
##### **Advantages of the Umbrella API Integration**
**The Umbrella API introduces several improvements over older versions (v1 and Reporting v2 APIs):**
- Intuitive base URI
- API paths defined by top-level scopes
- Granular, intent-based API key scopes
- API key expiration support
- Updated API administration dashboard
- Programmatic API key administration
- Authentication & authorization via OAuth 2.0 client credentials flow
- Portable, programmable API interface for integrations
** Before sending requests to the Umbrella API, create Umbrella API credentials and generate an access token.**
**More details: [Cisco Umbrella API Authentication](https://developer.cisco.com/docs/cloud-security/authentication/#authentication)**
---
##### **Authentication**
- The Umbrella API provides a **REST interface**.
- Supports **OAuth 2.0 client credentials flow**.
**Steps:**
1. Log in to Umbrella at: [https://dashboard.umbrella.com](https://dashboard.umbrella.com)
2. Create a new **API Key (ID + Secret)**.
- Keys can only be copied once at creation.
- Lost secrets cannot be retrieved.
3. Generate an **API Access Token** using your credentials.
**Important:** API keys, passwords, and tokens grant access to private customer data. **Never share them** with external users or organizations.
---
#### **Managing Umbrella API Keys****Create a New API Key**
1. Navigate to **Admin > API Keys**
- For MSP/MSSP: **Console Settings > API Keys**
2. Click **Add Key**.
3. Enter a **Name** (≤256 characters) and optional **Description**.
4. Select **Scopes** (Read-Only or Read/Write).
5. Configure an **Expiry Date** (or select *Never Expire*).
6. (Optional) Add **Network Restrictions** (up to 10 public IPs or CIDRs).
7. Click **Create Key** → Copy and save **Key + Secret**.**Refresh an API Key**
1. Go to **Admin > API Keys**.
2. Expand the target key → Click **Refresh Key**.
3. Copy and save the new **Key + Secret**.**Update an API Key**
1. Expand an existing key.
2. Update **Name, Description, Scopes, Expiry, or Network Restrictions**.
3. Click **Save**.
---
To integrate Cisco Umbrella logs into AQUILA, provide the following details to **CyTech Support**:
- **Queue URL**
- AWS SQS queue URL where messages will be received.
- For Cisco-managed S3 without SQS, use **Bucket ARN** instead.
- **Bucket ARN**
- Required for Cisco-managed S3.
- Example: `arn:aws:s3:::cisco-managed-eu-central-1`
- [List of Cisco-managed S3 buckets](https://docs.umbrella.com/mssp-deployment/docs/enable-logging-to-a-cisco-managed-s3-bucket)
- **Bucket Region**
- The AWS region where the bucket is located.
- **Bucket List Prefix**
- The root folder of the S3 bucket to be monitored (visible in the S3 UI).
- Example: `1235_654vcasd23431e5dd6f7fsad457sdf1fd5`
- **Number of Workers**
- Number of workers to process S3 objects (min = 1).
- **Bucket List Interval**
- Time interval for polling the S3 bucket. Default = 120s.
- **Access Key ID**
- **Secret Access Key***If you need further assistance, kindly contact **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Cloudflare Integration
#### **Introduction**
Cloudflare logs provide detailed insights into client connections, request paths through the Cloudflare network, and origin server responses. These logs help track activity, identify issues, and support security and performance analysis.
---
#### **Authentication Options**You can configure log retrieval using the following authentication methods:
1. **Auth Email**
2. **API Token**
3. **Account ID and Zone ID**For detailed information on authentication, refer to the **[Cloudflare API documentation](https://developers.cloudflare.com/api/)**.
---
#### **1. Configure Using Auth Email and Auth Key**To set up using this method, you need:
- **Auth Email**: The email address associated with your Cloudflare account.
- **Auth Key**: Your global API key, available on the My Profile page.
- **Zone ID**: The unique identifier of your **Cloudflare zone**, available in the zone's dashboard.
- **Account ID:** The unique identifier of your entire **Cloudflare account**, not just a specific zone (domain).These credentials must be included in the request headers:
- `X-Auth-Email`: Your account email.
- `X-Auth-Key`: Your global API key.For more details, refer to Cloudflare’s authentication headers guide.
---
#### **2. Configure Using API Token**To set up using an API token, you need:
- **API Token**: A token with appropriate permissions.
- **Account ID & Zone ID**: As noted above, can be found in your Cloudflare zone dashboard.**Cloudflare Permissions for the API Token**:
- `Account.Access:Audit Logs:Read`
- `Account.Account:Settings:Read`
- `Account WAF – Read`
- `DDoS Protection – Read`
- `Intel – Read`
- `API Gateway - Read`
- `DNS - Read`
- `Zone Settings - Read`
- `Analytics - Read`
- `FirewallServices - Read`
- `Zone WAF - Read`
- `Zone - Read`
- `Logs - Read`API Tokens are preferred for security as they support fine-grained access control. Create and manage tokens via the API Tokens dashboard.Manage Account>Account API Tokens>Custom Token>Get Started
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/S9182GuszsiqVnWA-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/Z6OZe0frH96MPSA9-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/ZmQwl21RBq8SR7QU-image.png)
```python
curl -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
-H "Authorization: Bearer " \
-H "Content-Type: application/json"
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/ATiOTiGP9Lom8Psr-image.png)
---
#### **3. How to get the Account ID and Zone ID**
1. Login to your **Cloudflare** account.
2. Head over to your **Dashboard** [https://dash.cloudflare.com/](https://dash.cloudflare.com/ "https://dash.cloudflare.com/").
3. Click your existing **Domain**.
4. The **Account ID** and **Zone ID** located in the **right side** after you clicked the existing Domain.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/YrA5bIztXuf3yRkl-image.png)
---
**Audit Logs**
Audit logs provide a record of configuration changes within your Cloudflare account, including:
- Logins/logouts
- DNS setting changes
- Modifications to Firewall, Caching, Page Rules, Speed, Network, and Traffic featuresThese logs are essential for tracking administrative activity and detecting unusual behavior.
---
To enable log collection from the Cloudflare API token, provide the following information to **CyTech Support**:
- **Auth Email**
- **API Token (Auth Key)**
- **Account ID**
- **Zone ID**
*If you need further assistance, kindly contact **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Digital Guardian Integration
##### Integrating **Digital Guardian (DG)** with **AQUILA** for security log ingestion typically involves exporting logs from DG and then parsing and ingesting them into **AQUILA.**
##### **Digital Guardian** is a Data Loss Prevention **(DLP)** and endpoint protection tool. It logs:
- ##### Data access
- ##### File operations (copy, move, print, etc.)
- ##### Application usage
- ##### User behavior analytics
##### **Goal:** Extract these logs and ingest them into **AQUILA** to enable searching, visualization, and alerting.
##### **Digital Guardian**'s native integration with **Aquila Agent** requires:
- ##### ARC Server URL
- ##### Authorization Server URL
- ##### ARC Export Profile ID
- ##### Client ID
- ##### Client Secret
##### Working with the **Digital Guardian ARC Cloud API** (Advanced Reporting & Correlation), which is used to export events via a secure API.
##### **Steps on getting the required information before integrating it to AQUILA**
##### **1. ARC Server URL**
- ##### This is the base URL for the **Digital Guardian ARC cloud instance**.
- ##### It looks like:
- ##### **https://arc.digitalguardian.com**
- ##### Sometimes it's region-specific (e.g., EU or US ARC instance).
##### **2. Authorization Server URL**
- ##### This is the OAuth2 token server used for authenticating API calls.
- ##### It may look like:
- ##### **https://auth.digitalguardian.com**
- ##### Or it may be included in your API documentation.
##### **3. ARC Export Profile ID**
- ##### This is a **profile ID** that determines which logs (event types, time windows, etc.) are exported via the API.
- ##### It is **configured by a DG admin** inside the **DG Management Console** under the **ARC export profiles** section.
- ##### Steps for the DG Admin:
- ##### Log in to the **Digital Guardian Console**.
- ##### Go to **ARC > Export Profiles**.
- ##### Create or view an export profile with appropriate filters.
- ##### Copy the **Export Profile ID** from the profile details.
##### **4. Client ID & Client Secret**
- ##### These are **OAuth2 credentials** used to authenticate your API access.
- ##### Generated via the **API client registration** feature in the DG admin interface.
- ##### Steps for the DG Admin:
- ##### Log into the **Digital Guardian ARC Console**.
- ##### Navigate to **ARC > API Clients / Applications**.
- ##### Register a new application.
- ##### Assign the **Export Profile ID**.
- ##### Set appropriate scopes (usually “read:events”).
- ##### A **Client ID** and **Client Secret** will be generated.
- ##### **IMPORTANT:** The **Client Secret** is shown **only once**, so it must be secure.
##### **Sample Information needed from DG Admin**
##### **Integration to AQUILA**
##### 1. Log in to **CyTech - AQUILA.** Choose **Cyber Monitoring -> Cyber Incident Management -> Settings.**
##### 2. Click **Log Source.** In the text box type **Digital Guardian,** the log source will show up and click the **Add to Agent.**
##### 3. Choose the **Log Collector** name you installed. Click the **+** sign.
##### 4. Enable the **Collect Digital Guardian logs via API.**
##### 5. Paste the information you gather on each text box. **ARC Server URL, Authorization Server URL, ARC Export Profile ID** and **Client ID.** Then scroll down.
##### 6. Paste the information you gather on each text box. **Client Secret,** then click the **Tags** text box, it will show 2 tags you will need to add.
##### 7. Then click **Next** so that the integration will process the information you inputted.
##### 8. Wait for the **Successful** window to display, this will confirm the successful integration.
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Fortinet FortiGate Integration
Please follow these instructions:
Step 1: Log in to your Fortinet FortiGate Admin portal and navigate to CLI console. Please refer to the images below.
**To configure FortiGate to send logs to the syslog server, we need you to provide the following details:**
1. **Server IP(Log Collector - Elastic Agent Host)** – This is the IP address of your remote syslog server where the logs will be sent.
2.
**Source IP(Fortinet FortiGate Device)**– This is the specific IP address on the FortiGate device that will be used to send the logs.
Since these values depend on your network setup, we require you to provide them so we can proceed with the configuration.
Please execute these commands.
**For Syslog Setting:**
config log syslogd setting
set status enable
set server <Address of remote syslog server - Log Collector>
set facility user
set source-ip <Source IP address of syslog - Fortinate Device>
set port 10514
set mode tcp
set format default
end
**We recommend using port 10514 if 514 is already used.
**For Syslog Filter:**
config log syslogd filter
set anomaly enable
set forward-traffic enable
set local-traffic enable
set multicast-traffic disable
set netscan-discovery enable
set netscan-vulnerability enable
set severity warning
set sniffer-traffic enable
set voip disable
set ztna-traffic enable
end
**NOTE:** In your **Server IP**, please allow inbound and outbound for the specified **Port** and **Protocol**.
For the **Source IP**, allow the outbound for the specified **Port** and **Protocol**.
**Important!!**
**Please provide screenshots of the configurations after executing the commands.**
**For our integration we need the** **Server IP** **and** **Port number****.**
**\*\*\*Please provide screenshots of the configurations after executing the commands.**
**For our integration we need the Server IP and Port number.**
*Source Link for full Documentation Manual:*
*[https://docs.cytechint.io/books/system-integrations/page/fortinet-fortigate-syslog-setting-and-syslog-filter](https://docs.cytechint.io/books/system-integrations/page/fortinet-fortigate-syslog-setting-and-syslog-filter "https://docs.cytechint.io/books/system-integrations/page/fortinet-fortigate-syslog-setting-and-syslog-filter")*
*Source Link Documentation for Syslog Setting:*
*[https://docs.fortinet.com/document/fortigate/6.4.4/cli-reference/444620/config-log-syslogd-setting](https://docs.fortinet.com/document/fortigate/6.4.4/cli-reference/444620/config-log-syslogd-setting "https://docs.fortinet.com/document/fortigate/6.4.4/cli-reference/444620/config-log-syslogd-setting"):*
*Source Link Documentation for Syslog Filter:*
*[https://docs.fortinet.com/document/fortigate/7.0.9/cli-reference/456620/config-log-syslogd-filter](https://docs.fortinet.com/document/fortigate/7.0.9/cli-reference/456620/config-log-syslogd-filter "https://docs.fortinet.com/document/fortigate/7.0.9/cli-reference/456620/config-log-syslogd-filter")*
*[https://help.fortinet.com/fgt/handbook/cli52\_html/index.html#page/FortiOS%205.2%20CLI/config\_log.16.17.html](https://help.fortinet.com/fgt/handbook/cli52_html/index.html#page/FortiOS%205.2%20CLI/config_log.16.17.html "https://help.fortinet.com/fgt/handbook/cli52_html/index.html#page/FortiOS%205.2%20CLI/config_log.16.17.html")*
*Source link to better understand Log Priority Level:*
*[https://help.fortinet.com/fweb/551/log/Content/FortiWeb/fortiweb-log/Priority\_level.htm](https://help.fortinet.com/fweb/551/log/Content/FortiWeb/fortiweb-log/Priority_level.htm "https://help.fortinet.com/fweb/551/log/content/fortiweb/fortiweb-log/priority_level.htm")*
# AQUILA - GitLab Integration
**Purpose**
This document explains, in a clear and practical way, how to locate **GitLab log files** on the host (or in **Kubernetes**), confirm access, and connect those logs to **AQUILA**. It covers common GitLab installation types (**Omnibus/Linux** package, **self‑compiled**, and **Helm** chart deployments) and troubleshooting tips.
**Audience**
This guide is written for system administrators, DevOps engineers, and security/observability operators who will configure log collection from **GitLab** into **AQUILA**.
**Assumptions & prerequisites**
- You have administrative access to the **GitLab** host(s) or **Kubernetes** cluster where GitLab runs.
- You have access to AQUILA site.
- Basic familiarity with **Linux shell commands** and **Kubernetes** (`kubectl`) for **Helm** deployments.
**Step 1: Overview of required GitLab logs**
The following GitLab logs are commonly consumed by security/observability platforms. Confirm their presence on the host (or in the pods) before configuring **AQUILA**. If you moved any files to different paths, provide the updated absolute paths to **AQUILA**.
- **api\_json.log**
- Linux package (Omnibus) installations: `/var/log/gitlab/gitlab-rails/api_json.log`
- Self‑compiled installations: `/home/git/gitlab/log/api_json.log`
- Helm chart (Kubernetes): Webservice pods, `subcomponent="api_json"`.
- **application\_json.log**
- Linux package: `/var/log/gitlab/gitlab-rails/application_json.log`
- Self‑compiled: `/home/git/gitlab/log/application_json.log`
- Helm chart: Sidekiq and Webservice pods, `subcomponent="application_json"`.
- **audit\_json.log**
- Linux package: `/var/log/gitlab/gitlab-rails/audit_json.log`
- Self‑compiled: `/home/git/gitlab/log/audit_json.log`
- Helm chart: Sidekiq and Webservice pods, `subcomponent="audit_json"`.
- **auth\_json.log**
- Linux package: `/var/log/gitlab/gitlab-rails/auth_json.log`
- Self‑compiled: `/home/git/gitlab/log/auth_json.log`
- Helm chart: Sidekiq and Webservice pods, `subcomponent="auth_json"`.
- **Pages logs**
- Linux package: `/var/log/gitlab/gitlab-pages/current`.
- **production\_json.log**
- Linux package: `/var/log/gitlab/gitlab-rails/production_json.log`
- Self‑compiled: `/home/git/gitlab/log/production_json.log`
- Helm chart: Webservice pods, `subcomponent="production_json"`.
- **Sidekiq logs**
- Linux package: `/var/log/gitlab/sidekiq/current`
- Self‑compiled: `/home/git/gitlab/log/sidekiq.log`
> If you have moved or renamed any of the above logs, please add the new absolute path(s) to the **Changed Paths** table in the Appendix below before proceeding.
**Step 2: Install Log Collector Agent**
On the device where **GitLab** is installed, you must also install the **AQUILA Log Collector Agent**. This agent is responsible for collecting the GitLab logs and forwarding them to AQUILA for processing.
Please refer to the official manuals for installing the **AQUILA Log Collector Agent** on different operating systems:
- **Linux:** [Log Collector Installation - Linux Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-linux-manual)
- **Windows:** [Log Collector Installation - Windows Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-windows-manual)
- **Mac:** [Log Collector Installation - Mac Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-mac-manual)
Ensure that after installation, the Log Collector service is running properly.
**Step 3: Integrate GitLab on AQUILA**
1. Log in to the **AQUILA** site.
2. Navigate to **Cyber Monitoring → Cyber Incident Management (CIM) → Settings**.
3\. In **Settings for CIM**, go to **Log Source**. In the **Search Integration** textbox, type **"GitLab"** and click **Add to Agent**.
4\. Choose a **Log Collector** and click the **+** button.
5\. In the **GitLab** section, select the radio button **Collect GitLab logs via filestream**.
6\. For the following logs, enter the specific paths gathered earlier:
1. - **GitLab API logs** (ex. /var/log/gitlab/gitlab-rails/api\_json.log)
- **Application logs** (ex. /var/log/gitlab/gitlab-rails/application\_json.log)
- **Audit logs** (ex. /var/log/gitlab/gitlab-rails/audit\_json.log)
- **Auth logs** (ex. /var/log/gitlab/gitlab-rails/auth\_json.log)
- **GitLab Pages logs** (ex. /var/log/gitlab/gitlab-pages/current)
- **GitLab Production logs** (ex. /var/log/gitlab/gitlab-rails/production\_json.log)
- **GitLab Sidekiq logs** (ex. /var/log/gitlab/sidekiq/current)
7\. In the **Tags** field, click the textbox and include all provided tags.
8\. Once all paths and tags have been entered, click **Next** to continue.
9\. Wait for the **Successful** window to display, this will confirm the successful integration.
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Google Workspace Integration
### Google Workspace Integration OverviewThe Google Workspace integration collects and parses data from various **[Google Workspace audit reports APIs ](https://developers.google.com/admin-sdk/reports/reference/rest)**using a service account authorized via the **Admin SDK API**.
### RequirementsTo ingest data from the Google Reports API, the following must be completed:
- An **administrator account** in Google Workspace.
- Enable the **Admin SDK API** in GCP.
- Create and configure a **Service Account**.
- Enable **Domain-Wide Delegation** for the service account.
- Configure the **OAuth Consent Screen**.
### 1.Enable Admin SDK APIOur AQUILA agent will eventually use our GCP service account, which uses the [Workspace Admin SDK](https://developers.google.com/admin-sdk) to interact with the GW admin console REST API, therefore it needs to be enabled in GCP. To keep your mind at ease, we will only be enabling read access to the Reports API for this admin SDK.Complete the following steps:
- Select the Google Cloud navigation menu > **APIs & Services** > **Enabled APIs & Services**
- Search and enable “**Admin SDK API**” from the **API library page**When finished, you will have enabled the Admin SDK API within your project, where your service account will have access to pull data from GW.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/xj1heCkKEmxFRvw0-image.png)
### 2.Configure OAuth Consent ScreenWe next need to set up the [OAuth consent screen](https://developers.google.com/workspace/guides/configure-oauth-consent) for our service account and application when they create API requests to GW, as it will include the necessary authorization token.Complete the following steps:
1. Select the Google Cloud navigation menu > **APIs & Services** > **Enabled APIs & Services** > **OAuth Consent Screen**
2. User Type > Internal > Create
3. Fill out the following information in subsequent steps
4. App name:
5. User support email:
6. Authorized domains:
7. Developer contact information:
8. Save and Continue
9. Save and Continue
10. Back to Dashboard
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/Wb5ntsAc3GFF6vzC-image.png)
When finished, we will now have a registered application using OAuth 2.0 for authorization and the consent screen information set. Please note, the default token request limit for this app daily is 10,000 but can be increased. We recommend setting your agent’s pull rate to every 10 minutes which should not come close to this reaching this threshold. Setting the agent’s pull rate will be done at a later step.
### 3.Create a Service AccountFor the AQUILA agent to ingest data from GW, we will need to create a [service account](https://cloud.google.com/iam/docs/service-accounts) for the agent to use. This account is meant for non-human applications, allowing it to access resources in GW via the Admin SDK API we enabled earlier.To create a service account, do the following:
1. Select the navigation menu in Google Cloud > **APIs & Services** > **Credentials** > **Create Credentials** > **Service Account**
2. Enter the following information:
3. Service account name: a
4. Service account ID:
5. Leave the rest blank and continue
6. Select your new **Service Account** > **Keys** > **Add Key** > **Create New Key** > **JSON**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/idneceejFxjgkglB-image.png)
By default, the Owner role will be applied to this service account based on inheritance from the project, feel free to scope permissions tighter as best seen fit. When finished, you should have a service account, credentials for this service account in a JSON file saved to your host. We will enter this information during our GW integration setup.
### 4.Enable Domain-Wide DelegationOur service account will need [domain-wide delegation](https://developers.google.com/admin-sdk/directory/v1/guides/delegation) of permissions to access APIs that reach outside of GCP and into GW. The important data necessary for this has already been established in earlier steps where we need an API key, service account and OAuth client ID.To enable domain-wide delegation for your service account, do the following:
1. In your GW Admin Console select > **Navigation Menu** > **Security** > **Access and data control** > **API controls**
2. Select **Manage Domain Wide Delegation** > **Add New**
3. Client ID: OAuth ID from Service Account in GCP
4. Google Cloud Console > **IAM & Admin** > **Service Accounts** > **OAuth 2 Client ID** (copy to clipboard)
5. **OAuth Scopes**: [https://www.googleapis.com/auth/admin.reports.audit.readonly](https://www.googleapis.com/auth/admin.reports.audit.readonly)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/iME4GsGjhRnpwodR-image.png)
Our service account in GCP only needs access to admin.reports.audit.readonly to access GW [Audit Reports](https://developers.google.com/admin-sdk/reports/v1/get-start/overview) where these are converted into ECS documents.If you made it this far, CONGRATULATIONS you are doing outstanding! Your GW and GCP environments are now set up and finished. At this point you are almost done.
**Please provide the following information to CyTech Support:**
- **Delegated Account - **the email of the administrator account, and not the email of the ServiceAccount.
- **Jwt JSON** - The JSON credentials file downloaded from GCP. Raw contents of the JWT file. Useful when hosting a file along with the agent is not possible. NOTE: Please use either JWT File or JWT JSON parameter.
*Reference link: [https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two](https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two)*
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Host Isolation
#### **Overview**
Host Isolation Exception allows isolated endpoints to maintain connectivity to specific IP addresses while remaining isolated from the rest of the network. This feature is useful when you need to isolate potentially compromised hosts for security purposes while still allowing them to communicate with specific trusted resources. It is also a key cybersecurity practice used primarily in incident response to segregate a potentially compromised device (such as a laptop, server, or workstation) from the rest of the network. This prevents threats like malware, ransomware, or active intruders from spreading laterally or communicating with command-and-control servers. It creates a controlled "quarantine" state while maintaining a secure forensic channel for remote investigation and remediation.
It works through automated or manual triggers from tools like Endpoint Detection and Response (EDR) platforms. Upon detecting suspicious activity (e.g., via behavioral analysis or signatures), the system enforces isolation using:
#### **Prerequisites**
- Administrator permissions
- Access to the Control Panel section
##### **Option 1: Endpoint Detection and Response (EDR) - Endpoints**
**1. Navigate to Endpoint Sub-module in Endpoint Detection and Response (EDR)**
- **Step 1: Log in to CyTech - AQUILA. *click here -->* [usdc.cytechint.io](https://usdc.cytechint.io/)**
- **Step 2: In the left column click Cyber Monitoring -> Endpoint Detection and Response (EDR) -> Dashboard**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/mb2r0W3bIELVHdZt-frame-1-4.png)
**2. Access the Endpoint Section**
- **By pressing the eye icon, it will transfer the user to the Endpoint Section where it shows system details, alert rules, alerts, and events.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/gj82JtCFMhUF7M5r-frame-1-3.png)
**3. Isolate Host**
- **By Pressing the Respond button, it will show Isolate host where the user can isolate their endpoint or a specific workstation.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/LIGV2LNWDpwVNypj-frame-1-2.png)
**4. Isolate Endpoint**
- **In this section, the user can disable their endpoint and provide a reason for the isolation.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/78N57oWwfAkLwvZO-frame-1-1.png)
##### **Option 2: Endpoint Detection and Response (EDR) - Control Panel**
##### 1. Navigate to Endpoint Management
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/xB9PgxaZZLLUu7dq-frame-1-5.png)
1. From the AQUILA main dashboard, locate the left sidebar menu
2. Under the **DOMAINS** section, click on **Cyber Monitoring**
3. Select **Endpoint Detection and Response (EDR)**
4. Click on **Control Panel**
This will open the endpoint management interface.
##### **2. Access the Manage Endpoints Section**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/Dcv6EOKVF8yr2tlN-image.png)
1. In the Control Panel, click on **Manage Endpoints** from the Policy Settings menu. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/LzJq0msYlP0EGDCC-image.png)
2. You'll see a table displaying all registered endpoints with the following information:
- Operating System
- Status (healthy, unhealthy, offline, isolated)
- Date Added
- Available Actions
##### **3. Isolate an Endpoint**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/Lxpse2fLqCaPg8b5-image.png)
If you need to isolate an endpoint first:
1. Locate the target endpoint in the list
2. Click the **Isolate Host** button in the Action column
3. In the **"Isolate Endpoint"** dialog box:
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/zli5njPStB6XXdv8-image.png)
4. Click the **Confirm** button to proceed
5. The endpoint status will change to **Isolated**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/vcb0U03c0BVgbqO8-image.png)
**Note:** Once isolated, the endpoint will be disconnected from the network and unable to access external resources except those specified in the Host Isolation Exception list.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/nIEBHsP8xH7Mt8Ct-image.png)
**Testing connection status:**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/aiLyYurpe7M3gdKW-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/SIb5U9mswhd25n09-image.png)[ ](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/KhX5tJUe1saR9TPG-image.png)
##### **4. Verify Isolation Status**
After isolation, you can verify the endpoint's network status:
1. Open Command Prompt on the isolated endpoint
2. Test connectivity by pinging a public IP address:
3. You should see **General failure** messages, confirming the host is isolated
4. The ping statistics should show **100% loss**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/9uDYHvjCGIusatl7-image.png)
##### **Pros and Cons**
Aspect
Pros
Cons
**Threat Containment**
Rapidly halts malware propagation and lateral movement, limiting breach scope to one device and reducing overall network risk.
If the isolating agent (e.g., EDR software) is compromised, it could fail, creating a single point of failure.
**Response Efficiency**
Buys critical time for forensic analysis, remediation, and recovery—especially useful off-hours or in automated setups. Enables precise logging and process termination without physical access.
Manual containment can require human escalation, leading to delays; automation risks over-isolation on false positives, disrupting business-critical systems.
**Security Posture**
Enhances visibility into isolated incidents for better threat hunting; integrates with zero-trust models to enforce granular controls.
Generates potential alert fatigue if tied to detection systems; narrow focus on single hosts may miss multi-device attacks.
**Operational Impact**
Minimizes downtime compared to full network shutdowns; supports staged recovery to restore operations quickly.
Can cause immediate productivity loss (e.g., blocking remote work); resource-intensive on endpoints, potentially slowing performance.
**Management & Scalability**
Cost-effective with open-source tools; flexible for mobile/remote devices across environments.
Complex to deploy and maintain consistently in large networks; high risk of misconfiguration leading to security gaps or unintended blocks.
##### **Conclusion**
In summary, host isolation is a proactive "firebreak" in cybersecurity, excelling in speed and precision for containing incidents but demanding robust testing and policy integration to mitigate its operational trade-offs. For high-stakes environments like enterprises, combining it with tools like EDR or NAC maximizes benefits while addressing limitations.
# AQUILA - Host Isolation Exception
#### **Overview**
Host isolation exceptions (also called endpoint isolation exclusions) are configurable rules in Endpoint Detection and Response (EDR) systems—such as Elastic Security, Microsoft Defender for Endpoint, or Cortex XDR—that allow specific IP addresses, processes, services, or endpoints to bypass network isolation restrictions. While full isolation blocks nearly all inbound and outbound traffic to quarantine a potentially compromised host, exceptions carve out secure "whitelists" for essential communications. This ensures critical functions like remote remediation, security telemetry, or business tools (e.g., Microsoft Teams or Outlook) remain operational without fully severing the device from the network. Exceptions must be defined cautiously, as they create controlled openings in an otherwise locked-down state.
These features are implemented via policy-based rules in EDR consoles, often supporting wildcards for flexibility (e.g., allowing all processes to reach a specific management IP). They complement host isolation by balancing security with usability, particularly in regulated environments like PCI DSS where partial connectivity is needed for compliance or operations.
#### **Prerequisites**
- Administrator permissions
#### **Step By Step Guide**
##### **1. Navigate to Endpoint Management**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/TtdYFKy7u1Z3Tusd-image.png)
##### **2. Configure Host Isolation Exception**
To allow isolated endpoints to connect to specific IP addresses:
In the Control Panel left sidebar, under **Event Filters**, click on **Host Isolation Exception**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/fQupJgOyZZyOT5wx-image.png)
1. Click the **+ Add Host Isolation Exception** button (top right, blue button)
2. In the "**Add Host Isolation Exception**" dialog box, fill in the following fields:
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/bjSjX2BWCrY46ISj-image.png)
**3. Enter IP Address:**
- - Enter the IPv4 address you want to whitelist
- You can only enter one IP address per exception
4. Click the **Add Host Isolation Exception** button to save
##### **3. Verify the Exception is Active**
5. Return to the Host Isolation Exception page
6. Verify your newly created exception appears in the list
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/NyH4Qk780SHJ5zMA-image.png)
##### **4. Test the Exception**
To confirm the exception is working:
7. Return to the isolated endpoint
8. Open Command Prompt
9. Test connectivity to the whitelisted IP address:
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/vfMi6pQpTkxdSwSv-image.png)
10. You should now see successful replies:
- - Reply from 8.8.8.8: bytes=32 time=18ms TTL=117
11. Ping statistics should show **0% loss** with round trip times
This confirms that the isolated endpoint can now communicate with the specified IP address.
##### **5. Unisolate an Endpoint.**
- When you need to restore full network connectivity:
12. Navigate back to **Manage Endpoints** 13. Locate the isolated endpoint (Status: **Isolated)**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/7TVA2El43tUAXLKE-image.png)
14. Click the **Unisolate Host** button
15. In the "**Unisolate Endpoint**" dialog box:
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/CBxwUOJ2O7PKY47z-image.png)
- Click **confirm**.
- After that it will load while releasing
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-11/DTCLmoZTKrPVeSRC-image.png)
After refreshing, the endpoint action will go back to Isolate Host after releasing, meaning, the **Unisolate** is done.
##### **Pros and Cons**
Aspect
Pros
Cons
**Operational Continuity**
Enables essential tools (e.g., email, collaboration apps like Teams) to function during isolation, minimizing downtime and user disruption. Supports remote management without physical access.
Overly broad exceptions can inadvertently allow threat persistence or lateral movement, undermining isolation's core purpose.
**Security Effectiveness**
Maintains secure channels for EDR telemetry and remediation (e.g., to Cortex XDR or Defender agents), ensuring ongoing monitoring and response without full blackout.
Increases vulnerability if exceptions target untrusted IPs or processes; attackers could exploit misconfigurations to bypass controls.
**Flexibility & Scalability**
Customizable rules (e.g., by IP, process path, or service) adapt to diverse environments, with wildcards for efficient management across large fleets. Reduces false positives in automated isolation.
Prone to human error in rule creation—e.g., typos in paths or IPs—leading to ineffective exclusions or security gaps; requires rigorous auditing.
**Compliance & Response Efficiency**
Facilitates adherence to standards like PCI DSS by allowing controlled access (e.g., to secure VLANs), while speeding up incident resolution through partial connectivity.
Adds complexity to incident response workflows; poor management can create a false sense of security or alert fatigue from repeated testing.
**Resource Impact**
Low overhead when narrowly defined; preserves productivity for non-critical functions without needing full network recovery.
Potential performance hit from constant rule evaluation; in high-volume environments, unoptimized exceptions can strain endpoint resources.
##### **Conclusion**
In essence, host isolation exceptions are a vital refinement for real-world deployment, promoting a "secure by design" approach that avoids the pitfalls of rigid isolation. However, their success hinges on least-privilege principles: limit to verified, high-trust endpoints and integrate with automated validation tools. For implementation guidance in tools like Microsoft Defender, best practices emphasize starting with defaults (e.g., excluding only EDR agents) and layering in business needs via testing.
# AQUILA - Microsoft Office 365 Integration
#### **Overview**This integration with Microsoft Office 365 supports the ingestion of user, administrator, system, and policy-related events. It leverages the Office 365 Management Activity API to retrieve activity logs from both Office 365 and Azure Active Directory (Azure AD).This guide outlines the required steps to integrate with **Microsoft Office 365 and Azure AD** using the **Office 365 Management Activity API**. It covers application registration, permission setup, audit log configuration, and retrieval of key credentials for secure API access.
---
#### **Summary of Actions Required:**
1. **Register an Application** in Microsoft Entra ID (formerly Azure AD) to establish identity and enable API access.
2. **Configure API Permissions** for Microsoft Graph and Office 365 Management APIs to authorize required data access.
3. **Grant Admin Consent** to ensure permissions are applied tenant-wide.
4. **Collect Key Credentials** such as Application ID, Tenant ID, and Client Secret for use in your integration.
5. **Verify if Unified Audit Logging is Enabled** in Microsoft 365 to ensure activity data is available via the API.
---
#### **Action Items Before Proceeding:**
- Ensure you have **Global Admin** access to your Azure/Microsoft 365 tenant.
- Prepare to create or use an existing **App Registration** in Microsoft Entra ID.
- Confirm that **Unified Audit Logging** is enabled; otherwise, prepare to activate it via the Microsoft 365 portal or PowerShell.
- Take note of your **admin email address** for PowerShell commands if using CLI to manage audit log settings.
---
#### **Steps to Configure Office 365 Integration for the Client**
##### **Step 1: Microsoft Entra ID - App Registration****Register Your Application in Microsoft Entra ID:**
- - Log in to your Azure Account, click here - **[Azure Portal Link](https://portal.azure.com/#home)**.
- Navigate to Azure Active Directory > **App registrations**.
- Click **New Registration**.
- Provide a Name for the application, we can suggest "**CyTechAQUILA-Monitoring**".
- Click **Register**.
##### **Step 2: API Permissions****Microsoft Graph API Permissions:**If **User.Read** permission under **Microsoft Graph** tile is not added by default, add this permission.
- - Navigate to **App registrations** in the Azure Portal.
- Select the App you just created, then go to **API Permissions**.
- Search for **Microsoft Graph.**
- Click **Add a permission**.
- Select **Microsoft Graph** **>** **Delegated permissions**.
- Search for and add **User.Read**.
**Office 365 Management API Permissions:**
- - Search for **Office 365 Management APIs** and add the required permissions.
- In **Application Permissions**, look for permissions.
- Under ActivityFeed select: **ActivityFeed.Read**
- Optionally, select **ActivityFeed.ReadDLP** to read DLP policy events.
**Grant Admin Consent:**
- - In API Permissions, click **Grant admin consent** for <tenant name>.
- **Confirm** the action.
- - Go to **App registrations** > **Select your application**.
- Copy the **Application (client) ID** from the overview page.
**Directory (Tenant) ID:**
- - In the Azure Portal, navigate to **Azure Active Directory** > **Overview**.
- Copy the **Directory (tenant) ID**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/cxxxBJdvPcIbiMHV-image.png)
**Create New Client Secret (Value):**
- - In **App registrations > Select your application**, go to **Certificates & secrets**.
- Click **New client secret**.
- Add a description and expiration period, then click Add.
- Copy the **Value** **(displayed only once)**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/fjoxX4o659L9qigQ-image.png)
##### **Step 4: Verify Unified Audit Logging is Enabled**Unified Audit Logging must be enabled before accessing data via the Office 365 Management Activity API.**Method 1: Using Microsoft 365 Security & Compliance Center**
1. Sign in to Microsoft 365:
- Go to [https://admin.microsoft.com](https://admin.microsoft.com/) and sign in with your Global Admin credentials.
2. Access the Security & Compliance Center:
- In the left-hand menu, under Admin centers, click on Security (or go directly to [https://security.microsoft.com](https://security.microsoft.com/)).
3. Navigate to Audit Log Search:
- In the Security & Compliance Center, go to Search in the left-hand menu and click on Audit log search.
4. Check Audit Log Status:
- If you see an option to search the audit log, then audit logging is already enabled.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/WHIm6mw3MmYsEzmv-image-2.png)
- - If you see a banner that says "Start recording user and admin activity" or a prompt to enable auditing, it means that audit logging is not yet enabled.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/iouUelw3mFkmCdPj-image.png)
5. Enable Audit Logging:
- If audit logging is not enabled, you can click on the prompt to enable it. This will enable auditing for all activities within your Microsoft 365 environment. The process may take a few hours to be fully operational.
**Method 2: Using Powershell**1.Install and Update Exchange Online Management Module
- Open PowerShell as Administrator.
- Install the module:
```
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
```
#### **AQUILA – Microsoft 365 Integration Requirements**Please saved and provide this values to AQUILA Support Team.
1. **Directory (tenant) ID: **
2. **Application (client) ID:**
3.
**Client Secret Value:**
#### **AQUILA – Microsoft 365 Integration****1.** Log in to AQUILA click here - **[CyTech - AQUILA](https://cytechint.io/)**. Choose **Cyber Monitoring** and click the **small arrow icon** to redirect you to the Cyber Monitoring Dashboard.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/QUruqc4qZzjj39A2-image.png)2. In the dashboard, choose **Cyber Incident Management (SIEM and XDR)**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/i68EMO7YfIStKeyl-image.png)3. Navigate through the leftmost top and click **Cyber Incident Monitoring**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/KgRo0wYa67PKNCws-image.png)4. Navigate through **Settings>Log Source>Search Bar>Add to Agent**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/fWvdjNBxjAB77OEo-image.png)
5. Choose your **Log Collector**. *(If you not yet installed your **Log Collector** please refer to this link -* [**Log Collector** **Installation.**](https://docs.cytechint.io/books/log-collector-installations))[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/1VIERSAN80moG8fG-image.png)6. In the integration settings follow the instructions given below.
- Click the **drop arrow** to display the contents needed for the integration setup.
- In the **Office 365 logs section** > **Disable** > **Collect Office 365 audit logs****[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/exwrKGAswsASVPAr-image.png)**
- Scroll down and go to **Microsoft Office 365 audit logs section**.
- Input the credentials for **Directory(tenant) ID, Application(client) ID and the Client Secret Value**.
- Finally, click **Next** to install the log source integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/Tbrp2u6d1RtjobOm-image.png)
7. Wait for the **Successfull** window to display, this will confirm the successfull integration.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/CNFzJRIuFuvZIEdI-image.png)*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - Mimecast API v2 Integration
### **Mimecast Integration Guide**
Integrate **Mimecast** with your security platform via API to collect email threat data, archive logs, DLP events, and other security-related logs for centralized visibility and incident response.
**API 2.0 is the current standard** - It's been generally available for over a year and is what Mimecast recommends for new integrations
#### **Credentials & API Access Setup (Mimecast API v2)**
Before configuring the integration, prepare your API credentials from the Mimecast Admin Console.
Needed Credentials:
- **API URL**
- **Client ID**
- **Client Secret**
##### **Creating an API 2.0 Application**:
**To create an API 2.0 Application, follow the steps below:**
1. Log in to ***Mimecast Administration Console***
2. Navigate to ***Integrations | API and Platform Integrations***
3. Locate the following ***Mimecast API 2.0*** tile and click on ***Generate Keys.***
***[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/rBSxoLyzOZzCIIZV-mimecast1.png)***
4.
After reading the ***Terms & Conditions***, complete the ***I accept*** check box to enable the ***Next*** button to progress onto the next step.
5.
Complete the ***Application Details*** section.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/AwHf7pOPYvohGct1-image.png)
> - We highly recommend creating a dedicated custom role with ***only*** the permissions required for the Application to function.
> - Select the minimum set of Products the App needs to access to function.
6. Should we need to contact you regarding this API application, please provide details for a ***Technical Point of Contact.***
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/UoNpggyWtQCY1t4a-image.png)
> Mimecast recommends a group rather than an individual contact.
7. Review the Summary information for the API application and click on ***Add*** if you are happy to proceed with creating the application.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/4JKQu1krMKlvDmMq-image.png)
8. The wizard completes and displays a pop-up window including your Client ID and Client Secret key data, where you can copy and save the credentials for the API application.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/RGHA38BGBhwInynP-image.png)
#### **Base URL (Mimecast API v2)**
To transition from your current API 1.0 URLs to API 2.0, we provide three API gateway options tailored to fulfill your performance, compliance, and data residency requirements:
- **Global URL**: The global API URL api.services.mimecast.com which serves traffic from the nearest instance ensuring reduced latency and enhanced performance.
- **UK Instance URL**: For compliance and data residency requirements, customers can choose to process traffic via the UK instance using the regional URL: uk-api.services.mimecast.com. This ensures API traffic is only processed within the UK instance of the Apigee Gateway.
- **US Instance URL**: Similarly, customers with compliance or residency requirements in the US can use us-api.services.mimecast.com to process API traffic exclusively through the US instance of the Apigee Gateway.
Factor
Global URL
UK Instance URL
US Instance URL
URL Details
api.services.mimecast.com
uk-api.services.mimecast.com
us-api.services.mimecast.com
Availability
✅Auto failover for high uptime
 No failover - requests fail if UK instance is down
 No failover - requests fail if US instance is down
#### **Aquila Integration Configuration**
##### **AQUILA – Mimecast Integration**
**1.** Log in to AQUILA click here - **[CyTech - AQUILA](https://cytechint.io/)**. Choose **Cyber Monitoring -> Cyber Incident Management (CIM) -> Settings**.
2\. Navigate through **Log Source -> Search Bar (Search the Source to Add) -> Add to Agent**.
3\. Choose your **Log Collector**. *(If you not yet installed your **Log Collector** please refer to this link -* [**Log Collector** **Installation.**](https://docs.cytechint.io/books/log-collector-installations))
**4. In the integration settings follow the instructions given below.**
- Click the **drop-down arrow** to display the contents needed for the integration setup.
- Upon clicking the drop-down arrow, disable the **v1 API.**
- This integration we will use the **v2 API**. Input the required Fields: **Client ID, Client Secret** and API URL (Mimecast API v2 base URL).**
- Click the drop-down arrow on all the other fields**.**
****
- Click the Tags text field and add the 2 examples**.**
- Finally, click **Next** to install the log source integration.
5\. Wait for the **Successful** window to display, this will confirm the successful integration.
**Reference Links:**
[**API & Integrations - Managing API 2.0 for Cloud Gateway**](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000360548755-API-Integrations-Managing-API-2-0-for-Cloud-Gateway#h_01JK62GWQ91FX2VPS7EWE3M9RX)
[**Update Base URL**](https://developer.services.mimecast.com/api-1-0-to-2-0-migration-guide)
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - Nginx Integration (Ubuntu or Linux Platform) (OLD)
#### **Overview**
The **Nginx Integration** provides comprehensive monitoring and observability for **Nginx servers**, enabling visibility into both **logs** and **metrics** data. This integration ensures effective tracking of server performance, user activity, and error occurrences, supporting proactive management and troubleshooting of Nginx environments.
It collects two main types of data:
- **Logs** — Capture and record events occurring within the Nginx server. These include access logs (client requests) and error logs (issues encountered during request handling). Log data helps in auditing activities, identifying issues, and analyzing request patterns.
- **Metrics** — Provide real-time performance insights into Nginx server operations. Metrics include details such as the total number of **active client connections**, connection states, request counts, and other performance indicators essential for capacity planning and system optimization.
By utilizing this integration, administrators gain visibility into both operational and performance aspects of Nginx, enabling effective monitoring, troubleshooting, and optimization of web infrastructure.
#### **Prerequisites**
Before setting up the **Nginx Integration**, ensure that the following requirements are met:
1. **Nginx Server Installed and Running**
- A functioning **Nginx server** must be installed on your host system.
- Verify that the Nginx service is active and accessible.
2. **Access Permissions**
- Administrative or root privileges are required to configure log file paths and enable the Nginx status module.
- Read permissions must be granted for Nginx log files (e.g., `access.log` and `error.log`).
3. **Nginx Status Module Enabled**
- The **stub\_status** module should be enabled to allow collection of server metrics such as active connections and request rates.
- Add or verify the following configuration in your Nginx configuration file (usually located in `/etc/nginx/sites-enabled/default.conf`):
```
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1; # restrict access as needed
allow ; # e.g. 192.172.10.0/24
deny all;
}
```
- Restart Nginx after making changes:
```bash
sudo systemctl restart nginx
```
4\. **Network Connectivity**
- Ensure that the system where monitoring is configured can connect to the Nginx host via the appropriate network ports (typically port **80** or **443**).
5\. **Log File Availability**
- Confirm that standard Nginx log files are present in their default or custom locations:
- Access logs: `/var/log/nginx/access.log`
- Error logs: `/var/log/nginx/error.log`
#### **Step 1: Install Log Collector Agent**
On the device where **Nginx Server** is installed, you must also install the **AQUILA Log Collector Agent**. This agent is responsible for collecting the Nginx access and error logs and forwarding them to AQUILA for processing.
Please refer to the official manuals for installing the **AQUILA Log Collector Agent** on different operating systems:
- **Linux:** [Log Collector Installation - Linux Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-linux-manual)
- **Windows:** [Log Collector Installation - Windows Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-windows-manual)
- **Mac:** [Log Collector Installation - Mac Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-mac-manual)
Ensure that after installation, the Log Collector service is running properly.
#### **Step 2: Integrate Nginx on AQUILA**
1. Log in to the **AQUILA** site.
2. Navigate to **Cyber Monitoring → Cyber Incident Management (CIM) → Settings**.
3\. In **Settings for CIM**, go to **Log Source**. In the **Search Integration** textbox, type **"Nginx"** and choose **Nginx logs and metrics** and then click **Add to Agent**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/7GeNXll3qJ1snfq0-image.png)
4\. Choose the **Log Collector** that was installed earlier and click the **+** button.
5\. In the **Nginx Logs and Metrics** section, **disable** the option to *Collect logs from third-party REST APIs*, and ensure that *Collect logs from Nginx instances* remains **enabled**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/ftlm54TN3ND8R5NZ-image.png)
6\. Scroll down and ensure that **Collect metrics from Nginx instances** is **enabled**. In the **Hosts** field, enter the **Loopback IP address** of the device where both the **Nginx Server** and **Log Collector Agent** are installed. By default, this address is **127.0.0.1**, unless it has been modified.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/9Ko1MDgMwsXhEvWV-image.png)
7\. For the following log types, specify the exact file paths:
- **Access Logs:** e.g., `/var/log/nginx/access.log*`
- **Error Logs:** e.g., `/var/log/nginx/error.log*`
**Note:** Ensure that each path ends with an asterisk (`*`) to include all relevant log files.
- Navigate to **Nginx access logs** and **error logs** sections and input the paths.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/p26smGSPZBp0RaHv-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/QX2cuxPxZIsVhNEo-image.png)
- For the **Tags** configuration, click the text field and select the default options:
- **Access Logs:** `nginx-access`
- **Error Logs:** `nginx-error`
8\. Verify the **Server Status Path** under the **Nginx stubstatus metrics** section. If the path has not been modified, retain the **default value**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/0XCaVgK6lmjAfZ2B-image.png)
8\. Once all paths and tags have been entered, click **Next** to continue.
9\. Wait for the **Successful** window to display, this will confirm the successful integration.
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Oracle Audit Logs Integration
##### This integration is for ingesting Audit Trail logs and fetching performance, tablespace and sysmetric metrics from Oracle Databases.
##### The integration expects an \*.aud audit file that is generated from Oracle Databases by default. If this has been disabled, then please see the [Oracle Database Audit Trail Documentation](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/introduction-to-auditing.html#GUID-8D96829C-9151-4FA4-BED9-831D088F12FF).
#### **Requirements**
##### Connectivity to Oracle can be facilitated in two ways either by using official Oracle libraries or by using a JDBC driver. Facilitation of the connectivity using JDBC is not supported currently with Metricbeat. Connectivity can be facilitated using Oracle libraries and the detailed steps to do the same are mentioned below.
#### **Oracle Database Connection Pre-requisites**
##### To get connected with the Oracle Database ORACLE\_SID, ORACLE\_BASE, ORACLE\_HOME environment variables should be set.
##### For example: Let’s consider Oracle Database 21c installation using RPM manually by following the [Oracle Installation instructions](https://docs.oracle.com/en/database/oracle/oracle-database/21/ladbi/running-rpm-packages-to-install-oracle-database.html). Environment variables should be set as follows: `ORACLE_SID=ORCLCDB` `ORACLE_BASE=/opt/oracle/oradata` `ORACLE_HOME=/opt/oracle/product/21c/dbhome_1` Also, add `$ORACLE_HOME/bin` to the `PATH` environment variable.
#### **Oracle Instant Client**
##### Oracle Instant Client enables development and deployment of applications that connect to Oracle Database. The Instant Client libraries provide the necessary network connectivity and advanced data features to make full use of Oracle Database. If you have OCI Oracle server which comes with these libraries pre-installed, you don't need a separate client installation.
##### The OCI library install few Client Shared Libraries that must be referenced on the machine where Metricbeat is installed. Please follow the [Oracle Client Installation link](https://docs.oracle.com/en/database/oracle/oracle-database/21/lacli/install-instant-client-using-zip.html#GUID-D3DCB4FB-D3CA-4C25-BE48-3A1FB5A22E84) link for OCI Instant Client set up. The OCI Instant Client is available with the Oracle Universal Installer, RPM file or ZIP file. Download links can be found at the [Oracle Instant Client Download page](https://www.oracle.com/database/technologies/instant-client/downloads.html).
##### If Elastic Agent is running as a systemd service and not using `ldconfig` is an option, to update the links to the shared libraries, you can use the `LD_LIBRARY_PATH` environment variable instead. Follow these steps to ensure Elastic Agent and its spawned processes respect the `LD_LIBRARY_PATH` environment variable.
> ##### Prerequisites: Ensure that you have administrative privileges to modify the Elastic Agent systemd service configuration.
##### **Steps:**
1. ##### Check the status of the Elastic Agent systemd service by running the following command: `systemctl status elastic-agent.service` Take note of the path to the elastic-agent.service file, which is typically located in the systemd service directory. Example path: `/etc/systemd/system/elastic-agent.service`
2. ##### Open the elastic-agent.service file in your preferred text editor, find the `EnvironmentFile` key (commonly found at `/etc/sysconfig/elastic-agent`), and verify its contents, as these configurations are essential for the elastic-agent's runtime environment initialization. If the EnvironmentFile is absent, create it and set the necessary permissions to ensure the elastic-agent has full access.
3. ##### Add the LD\_LIBRARY\_PATH environment variable to the configured `EnvironmentFile`. You can set it to the directory where libraries (`libclntsh.so`) are located. For example, if your libraries are in the `/opt/oracle/instantclient_21_1 directory`, add the following line to the `EnvironmentFile` (i.e. `/etc/systemd/system/elastic-agent.service`)
##### `LD_LIBRARY_PATH=/opt/oracle/instantclient_21_1`
4. ##### Save the changes made to the configured `EnvironmentFile`.
5. ##### Restart the Elastic Agent systemd service to apply the changes by running the following command:
##### `systemctl restart elastic-agent.service`
##### Ensure that you replace `/opt/oracle/instantclient_21_1` with the actual path to the directory where the required libraries (`libclntsh.so`) are located. This will set the library search path for the Elastic Agent service to include the specified directory, allowing it to locate the required libraries.
##### \* Please take note of the **Path** since we will need it later for the integration part.
#### **Enable Listener**
##### The Oracle listener is a service that runs on the database host and receives requests from Oracle clients. Make sure that [Listener](https://docs.oracle.com/cd/B19306%5F01/network.102/b14213/lsnrctl.htm) is be running. To check if the listener is running or not, run:
##### `lsnrctl STATUS`
##### If the listener is not running, use the command to start:
##### `lsnrctl START`
##### Then, Metricbeat can be launched.
#### **Oracle DSN Configuration**
##### The following two configuration formats are supported:
```
oracle://:@
user="" password="" connectString="" sysdba=
```
##### Example values are:
```
oracle://sys:Oradoc_db1@0.0.0.0:1521/ORCLCDB.localdomain?sysdba=1
user="sys" password="Oradoc_db1" connectString="0.0.0.0:1521/ORCLCDB.localdomain" sysdba=true
```
##### In the first, URL-based format, special characters should be URL encoded.
##### In the seoncd, logfmt-encoded DSN format, if the password contains a backslash character (`\`), it must be escaped with another backslash. For example, if the password is `my\_password`, it must be written as `my\\_password`.
##### To mask the password shown in the DSN, remove the username and password from the DSN string, and configure the DSN to only include the host address and any additional parameters required for the connection. Subsequently, we can use the username and password fields under advanced options in the backend to configure them.
##### \* Please take note of the **Oracle DSN** since we will need it later for the integration part.
#### **Integration on AQUILA**
1. ##### Login to **AQUILA**. Go to **Cyber Monitoring** -> **Cyber Incident Management (CIM)** -> **Settings**.
##### 2. Choose **Log Source**. Type "**Oracle**" on the text field then choose the first shown on **List of Integrations** and click **Add to Agent**.
##### 3. Choose what **Log Collector** you want to integrate the **Log Source**.
##### 4. Click the drop-down arrow on **Oracle Audit Logs**. On the **Oracle DSN** textbox input the details you gathered earlier.
##### 5. Scroll down and click the drop-down arrow on **Oracle Audit Log**. In the **Paths** textbox input the data you gathered earlier. In the **Tags** textbox, click the textbox and it will show 1 value choose that.
##### 6. For **Memory metrics, Oracle performance metrics, Sysmetric related metrics, System Statistics** and **Oracle** **tablespace metrics** just click all the **Tags** textbox on them and choose the only value shown. After that click **next**.
##### 7. Wait for the **Successful** window to display, this will confirm the successful integration.
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - PostgreSQL Integration
##### **Please find below the instructions required to set up this integration:**
To configure PostgreSQL with the specified logging settings, you need to modify the **postgresql.conf file**, which is typically located in the PostgreSQL data directory. Here are the steps to configure these settings:
**Step 1:** Locate the **postgresql.conf file**. This file is usually found in the **data directory of your PostgreSQL installation**. The exact path can vary depending on your operating system and installation method.
**Step 2:** **Edit the postgresql.conf file**. Open the file in a text editor with appropriate permissions (you might need superuser privileges).
Add or modify the following settings:
-
**logging\_collector = 'on'**: Enables the logging collector, which is responsible for capturing log messages sent to stderr and redirecting them into log files.
-
**log\_destination = 'csvlog'**: Sets the log output format to CSV, which is useful for structured logging.
-
**log\_statement = 'none'**: Disables logging of all SQL statements.
-
**log\_checkpoints = 'on'**: Logs each checkpoint.
-
**log\_connections = 'on'**: Logs each successful connection.
-
**log\_disconnections = 'on'**: Logs each disconnection.
-
**log\_lock\_waits = 'on'**: Logs lock waits that exceed the deadlock\_timeout.
-
**log\_min\_duration\_statement = 0**: Logs all statements with their durations. Setting this to 0 logs all statements regardless of their execution time.
**Step 3:**Save the changes. After editing the file, save your changes.
**Step 4:** Restart PostgreSQL: For the changes to take effect, you need to restart the PostgreSQL service. The command to restart PostgreSQL can vary depending on your system. Here are some common commands:
- On Linux systems using systemd:
-
sudo systemctl restart postgresql
-
On systems using init.d:
-
sudo /etc/init.d/postgresql restart
On Windows, you can restart the PostgreSQL service from the Services management console.
After completing these steps, PostgreSQL will be configured to log according to the specified settings.
For more detailed information, you can refer to these documentations:
**Required credentials for PostgreSQL Integration access:**
**Log file paths:**
- **/var/log/postgresql/postgresql-\*-*.log*
**
- **/var/log/postgresql/postgresql-\*-*.csv***
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - Salesforce Integration
#### **Overview**
The Salesforce integration enables you to monitor your Salesforce instance. Salesforce is a customer relationship management (CRM) platform that supports businesses in managing marketing, sales, commerce, service, and IT teams from a unified platform accessible from anywhere.
#### **Data Streams Logs**
- Salesforce Apex Logs
- Salesforce Login Logs
- Salesforce Logout Logs
- Salesforce SetupAudit Logs
#### **Configuration**
To configure the Salesforce integration, you need the following information:
- **Create New User Account for the Integration**
- **Salesforce instance URL**
- **Client key and client secret for authentication**
- **Username**
- **Password**
- **Token URL**
- **API version**
#### **Step 1: Create New User Account**
- Go to **Home** page of **Salesforce** and click **Setup** in the top right menu bar.
- In the left side you will see a **Quick Find** search textbox, type **Users**.
- Click **Users** and it will redirect you to the **Users setup** page.
- Click **New User** button and fill up the form:
- First Name
- Last Name
- Email
- Set **User License** to "**Salesforce**"
- Choose an appropriate **Profile** (see below)
- **Profile and Permission Set Configuration**
- **Create a custom profile** or clone an existing minimal profile:
- Clone the **"Standard User"** profile and name it something like **"Log Extraction Service"** or whatever you prefer.
- Remove unnecessary permissions, keeping only:
- **API Enabled**
- **View Setup and Configuration**
- **Specific object permissions for logs you need to extract**
- **Essential permissions** for log extraction:
- **API Enabled** - Required for programmatic access
- **View All Data** - If you need comprehensive log access
- **Read** access to specific objects containing log data
- Scroll down to the bottom and **check** the box that says **Generate new password and notify user immediately.**
- Click **Save**.
- Open the account and set a new password.
Please take note of the **Email Address,** **Username** and **Password** associated with this account, as they will be required during the API and integration setup process.
#### **Step 2: Salesforce instance URL**
This is the URL of your Salesforce Organization.
- **Salesforce Classic:** Given the example URL https://na9.salesforce.com/home/home.jsp, the Salesforce Instance URL is extracted as https://na9.salesforce.com.
- **Salesforce Lightning:** The instance URL is available under your user name in the **View Profile** tab. Use the correct instance URL in case of Salesforce Lightning because it uses \*.lightning.force.com but the instance URL is \*.salesforce.com.
Ensure the **Instance URL** is noted, as it will be used in both API creation and integration steps.
#### **Step 3: Client Key and Client Secret for Authentication**
To use this integration, you need to create a new Salesforce Application using OAuth. Follow these steps to create a connected application in Salesforce:
- Log in to **Salesforce** with the user credentials you want to collect data with.
- Click **Setup** in the top right menu bar.
- In the **Quick Find textbox**, search for **App Manager** or you can scroll down to **PLATFORM TOOLS** and select **App Manager.**
- In the upper right corner, choose the **New External Client App.**
- Provide a name for the connected application. This name will be displayed in the App Manager and on its App Launcher tile.
- Enter the API name. The default is a version of the name without spaces. Only letters, numbers, and underscores are allowed. If the original app name contains any other characters, edit the default name.
- Enter the **email address** of the **new account** you created earlier.
- Under the **API (Enable OAuth Settings)** section, check the box for **Enable OAuth Settings**.
- In the **Callback URL** field, enter the instance URL as specified in **Salesforce instance URL.** Example URL: https://na9.salesforce.com
- Select the following OAuth scopes to apply to the connected app:
- **Manage user data via APIs (api)**
- **Perform requests at any time (refresh\_token, offline\_access)**
- (Optional) If you encounter any permission issues during data collection, add the **Full access (full)** scope.
- Select **Require Secret for the Web Server Flow** to require the app's client secret in exchange for an access token.
- Select **Require Secret for Refresh Token Flow** to require the app's client secret in the authorization request of a refresh token and hybrid refresh token flow.
- Then scroll up above the **Callback URL** on the **App Settings** you will see the **Consumer Key and Secret** button, click it.
- It will create another tab. Verify the user account by entering the Verification Code.
- Copy the `Consumer Key` and `Consumer Secret` from the Consumer Details section. These values should be used as the **Client ID** and **Client Secret**, respectively, in the integration.
- Close that tab and go back to the **External Client App Manager**. Click **Save**.
#### **Step 4: Username**
Provide the **Username** of the new account that you created earlier.
#### **Step 5: Password**
Please provide the **password** you set upon accessing the new account.
**Note:**
When using a Salesforce instance with a security token, append the token directly to your password without spaces or special characters. For example, if your password is **Password** and your security token is **12345** enter: **Pasword12345**
#### **Step 6: Token URL**
- Use the token URL to obtain authentication tokens for API access.
- For most Salesforce instances, the token URL follows this format: https://login.salesforce.com/services/oauth2/token.
- If you're using a Salesforce sandbox environment, use https://test.salesforce.com/services/oauth2/token instead.
- For custom Salesforce domains, replace **login.salesforce.com** with your custom domain name. For example, if your custom domain is **mycompany.my.salesforce.com**, the token URL becomes **https://mycompany.my.salesforce.com/services/oauth2/token.** This applies to Sandbox environments as well.
- In the Salesforce integration, we internally append **/services/oauth2/token** to the URL. Make sure that the URL you provide in the Salesforce integration is the base URL without the **/services/oauth2/token** part. For example, if your custom domain is **mycompany.my.salesforce.com**, the complete token URL would be **https://mycompany.my.salesforce.com/services/oauth2/token**, but the URL you provide in the Salesforce integration should be **https://mycompany.my.salesforce.com.** In most cases, this is the same as the Salesforce instance URL.
**NOTE:** Salesforce Lightning users must use URL with \*.salesforce.com domain (similar to the Salesforce instance URL) instead of \*.lightning.force.com because the Salesforce API does not work with \*.lightning.force.com.
#### **Step 7: API Version**
To find the API version:
- Go to the search textbox and type **Api Version**. Click the first **Api Version** on the list.
***Reference**: [https://www.integrate.io/blog/salesforce-rest-api-integration/](https://www.integrate.io/blog/salesforce-rest-api-integration/)*
**Please provide these credentials and send it to CyTech Support:**
- **Salesforce instance URL**
- **Client key and client secret for authentication**
- **Username**
- **Password**
- **Token URL**
- **API version**
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - Salesforce Integration via JWT Authentication
#### **Overview**
With the OAuth 2.0 JWT bearer token flow, the client posts a JWT to the Salesforce OAuth token endpoint. Salesforce processes the JWT, which includes a digital signature, and issues an access token based on prior approval of the app.
##### **Check "View Event Log Files" Permission**
1. Check Your Org's Event Monitoring License:
- Go to **Setup** > **Quick Find** > **Installed Packages** or **Company Information** (under **Quick Find** > **Company Settings**).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/U4TmmE3cQ8FkSVMy-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/LIihGVNMxVgle7HR-image.png)
- Look for **Event Log File Browser** or **Event Monitoring** and enable it if it shows an option to do so.
2\. Enable **Event Monitoring** Features:
- **Setup** > **Quick Find** > **Event Monitoring Settings** (or search "**Event Log File Browser**").
- If the page loads: Check Enable **Event Log File Browser** > **Save**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/8BOA33WA4VWtnQti-image.png)
##### **Clone and Modify the Profile**
1. **Log in to Salesforce Setup:**
- Go to **Setup** (gear icon > Setup) as an admin.
2. **Clone the Standard User Profile:**
- Navigate to **Setup** > **Quick Find** > **Profiles**.
- Find **Standard User** > Click **Clone** next to it.
- **Profile Information**:
- **Profile Name**: e.g., "Standard User - Log Integration".
- **Description**: "Cloned for Elastic log integration with API and ELF access."
- **User License:** Salesforce Integration
- **Save.** This creates a new custom profile based on Standard User.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/qiDAHpYFkEPgiEkp-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/4Ef32pDrHX40ujej-image.png)
3\. **Edit System Permissions in the Cloned Profile:**
- In **Profiles**, find your new cloned profile > Click **Edit** > Go to the **System Permissions** section (or use Quick Find for "System Permissions").
- Enable the following checkboxes (these are the key changes from Standard User, which starts with them **disabled** for security):
**Permission**
**Change from Standard User**
**Why Enable It?**
**How to Enable**
**API Enabled**
Disabled → **Enabled**
Allows REST/SOAP API calls for fetching logs (e.g., EventLogFile queries). Essential for Elastic integration.
Check the box under **System Permissions**.
**View Event Log Files**
Disabled → **Enabled**
Grants read access to historical Event Log Files (ELF) like logins and Apex events. Core for log ingestion.
Check the box under **System Permissions**.
**View All Data**
Disabled → **Enabled**
Provides broader object read access if ELF queries fail due to restrictions.
Check the box under **System Permissions.**
- **Do NOT enable** unrelated permissions like "Modify All Data" or "Delete All Data" to maintain least-privilege.
- **Save** the profile.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/GBJfyTQF4sZQAPad-image.png)
[ ](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/ojzUxOjf1O1lPgkG-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/5vtL2PVBfnF5cQzo-image.png)
4\. **Assign the Cloned Profile to Your Integration User:**
- **Setup** > **Quick Find** > **Users** > Select your integration user > **Edit**.
- **Profile**: Select "Standard User - Log Integration".
- **Save**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/qhkItD6XiK1CFQhp-image.png)
5\. **Handle Event Monitoring Permissions (Not in Profile—Use Permission Set)**:
- The "View Real-Time Event Monitoring Data" isn't a direct profile permission; it's tied to Event Manager.
- **Create a Permission Set**:
- Go to **Setup** > **Quick Find** > **Permission Sets** > **New**.
- **Label/Name**: e.g., "Event Monitoring Access".
- **License**: "Salesforce Integration" (matches Standard User).
- **Save** > **System Permissions** tab > **Enable View All Data, API Enabled** and **View Event Log Files**.
- **Event Log File Browser** tab: Enable access to specific events.
- **Assign the Permission Set**:
- **Permission Set Assignments** > **New** > Select your integration user > **Assign**.
- **Enable Events in Event Manager**:
- **Setup** > **Quick Find** > **Event Manager**.
- For desired events (e.g., Login Event), click dropdown > **Enable Storage**. This requires the Event Log File Browser add-on license.
- This starts log retention (up to 1 year for ELF; real-time requires add-on license).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/LXDTLpk0pyGbbY3s-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/D8Y4bOlMcDszmNK7-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/UYgRTF1B9eBBHcJM-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/mZK9M3XpWzK5wY7H-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/46QNcp9BP7XGJpKv-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/mKejjzBlT8OlcNnT-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/Xa5mknGrKzfF3qBh-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/86ImA5HtfQ5IoowY-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/7tlqTYV46fCHPntx-image.png)
##### **Client Key and Certification Signature Configuration**
To use this integration, you need to create a new Salesforce Application using OAuth. Follow these steps to create a connected application in Salesforce:
- Log in to **Salesforce** with the user credentials you want to collect data with.
- Click **Setup** in the top right menu bar.
- In the **Quick Find textbox**, search for **App Manager** or you can scroll down to **PLATFORM TOOLS** and select **App Manager.**
- In the upper right corner, choose the **New External Client App.**
- Provide a name for the connected application. This name will be displayed in the App Manager and on its App Launcher tile.
- Enter the API name. The default is a version of the name without spaces. Only letters, numbers, and underscores are allowed. If the original app name contains any other characters, edit the default name.
- Enter the **email address** of the **new account** you created earlier.
- Under the **API (Enable OAuth Settings)** section, check the box for **Enable OAuth Settings**.
- In the **Callback URL** field, enter the instance URL as specified in **Salesforce instance URL.** Example URL: https://na9.salesforce.com
- Select the following OAuth scopes to apply to the connected app:
- **Manage user data via APIs (api)**
- **Perform requests at any time (refresh\_token, offline\_access)**
- (Optional) If you encounter any permission issues during data collection, add the **Full access (full)** scope.
- Select **Require Secret for the Web Server Flow** to require the app's client secret in exchange for an access token.
- Select **Require Secret for Refresh Token Flow** to require the app's client secret in the authorization request of a refresh token and hybrid refresh token flow.
- Then scroll up above the **Callback URL** on the **App Settings** you will see the **Consumer Key and Secret** button, click it.
- It will create another tab. Verify the user account by entering the Verification Code.
- Copy the `Consumer Key` and `Consumer Secret` from the Consumer Details section. These values should be used as the **Client ID** and **Client Secret**, respectively, in the integration.
- Close that tab and go back to the **External Client App Manager**. Click **Save**.
##### **Required fields for JWT Authentication Integration:**
- ##### JWT Authentication Audience URL
- ##### JWT Authentication Client Key Path
- ##### Username
- ##### Client ID
- ##### Instance URL
- ##### Token URL
##### Provide this required fields to **CyTech Support**.
Reference Link:
[OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration in Salesforce](https://www.youtube.com/watch?v=AEcQIXvV_I8)
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Setup Integration from Auth0
### **Auth0 Integration Guide**
Integrate **Auth0** to ingest identity-related logs such as login attempts, user authentications, MFA usage, and blocked requests to support identity threat detection and correlation.
#### **Credentials & API Access Setup (Auth0)**
Before setting up the integration, create a Machine-to-Machine application in Auth0 to collect logs via API.
##### **Steps**:
1. **Log in to Auth0 Dashboard**
- Go to [https://auth0.com](https://auth0.com)
2. **Create a Machine-to-Machine Application**
- Navigate to **Applications → Applications**
- Click **Create Application**
- Enter a name
- Choose the type: **Machine to Machine**
- Click **Create**
3. **Authorize the Auth0 Management API**
- When prompted, select **Auth0 Management API**
- Grant the required scopes depending on the data you want to collect:
- **Login Activity: `read:logs`, `read:users`**
- **MFA Logs: `read:logs`**
- **Failed Logins: `read:logs`**
- **User Access Logs: `read:logs`, `read:users`**
- Click **Authorize**
4. **Get the Required Credentials**
- Go to **Applications → Applications**
- Select your created app
- Go to the **Settings** tab
- Copy the following values:
- **Client ID**: Used for authentication
- **Client Secret**: Used with Client ID for API access
- **Auth0 Domain**: Your tenant domain (e.g., your-tenant.us.auth0.com)
- **Base URL**: Your Auth0 API base URL (e.g., https://your-tenant.us.auth0.com) — same as Domain but with https:// prefix)
5. **These values will be entered into the integration form required on Aquila**
#### **Permissions Reference (Auth0 M2M App)**
Ensure the app is granted the following scopes from the **Auth0 Management API**:
Data Stream
Scopes Required
Why Needed
**Login Activity**
`read:logs`, `read:users`
View login records and user info
**MFA Logs**
`read:logs`
Pull logs related to MFA events
**Failed Logins**
`read:logs`
Detect login failure events
**User Access Logs**
`read:logs`, `read:users`
Track user sessions & activity
####
#### **Aquila Integration Configuration**
##### **AQUILA – Auth0 Integration**
**1.** Log in to AQUILA click here - **[CyTech - AQUILA](https://cytechint.io/)**. Choose **Cyber Monitoring** and click the **small arrow icon** to redirect you to the Cyber Monitoring Dashboard.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/pvtVUycKNLpiyZFP-image.png)
2\. In the dashboard, choose **Cyber Incident Management (SIEM and XDR)**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/i68EMO7YfIStKeyl-image.png)
3\. Navigate through the top left icon and click the Collapse/Expand button.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/llqjBgJ5b1dlLdh8-image.png)
4\. Navigate the "**Cyber Incident Monitoring"** then hover the **"Cyber Incident Management"** till you see the settings.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/z4rUEJDEBmsHf9kd-image.png)
5\. Click the "**Settings** and Navigate through **Settings>Log Source>Search Bar (Search the Source to Add)>Add to Agent**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/qMBu98h6WaqojM41-image.png)
6\. Choose your **Log Collector**. *(If you not yet installed your **Log Collector** please refer to this link -* [**Log Collector** **Installation.**](https://docs.cytechint.io/books/log-collector-installations))
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/1VIERSAN80moG8fG-image.png)
**7. In the integration settings follow the instructions given below.**
- Click the **drop arrow** to display the contents needed for the integration setup.
- Choose the Integration between **via Webhooks** or **API requests.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/ykuDBJDprHeuotlo-image.png)
- Scroll down and go to the Auth0 Logs section.
- This one is for **Log** **Events via Webhooks**. Enter the required fields **Local Address, Listen Port,** and **Webhook Path**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/mhLQQNTaU7n192Uu-image.png)
- This one is for **Log Events via API Requests**. Input the credentials: **Base** **URL,** **Client ID and the Client Secret Value**.
- Finally, click **Next** to install the log source integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/c4h9UGcTveuXoV6W-image.png)
8\. Wait for the **Successful** window to display, this will confirm the successful integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/CNFzJRIuFuvZIEdI-image.png)
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - SNIFF & Detect
**Outlook Add-in for Microsoft 365**
---
#### **Overview** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/BFSw7RHFx4DdtKYR-image.png)
AQUILA – SNIFF & Detect is a custom integration app within the **AQUILA platform** that enables Microsoft 365 environments to deploy **advanced malicious email detection** capabilities.The app is packaged as a **manifest.xml** file and can be added to an organization’s Microsoft 365 tenant via the **Integration Apps** section in the Microsoft 365 Admin Center.
---
#### **Key Capabilities & Value** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/8GsYtIeM7CiwrbzV-image.png)
- **Seamless Integration** – Install in Microsoft 365 with just a few clicks, no complex infrastructure required.
- **Permission-Driven Security** – Requires admin approval to grant permissions, ensuring a secure deployment process.
- **Centralized Control** – Managed via AQUILA and distributed through the AQUILA Store for consistent updates.
- **AI-Enhanced Detection** – Uses AQUILA’s AI and Cyber Threat Intelligence to scan and detect malicious emails in real time.
- **User-Friendly Accessibility** – Appears in the “More apps” section for assigned users, making it easy to launch.
- **Minimal Footprint** – Only ~6 KiB in size, ensuring fast installation without performance impact.
---
#### **Installation & Deployment Manual – Simple Step-by-Step**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/K7Mmeai5fcmudTHG-image.png)
1. **Download the Integration Package**
- Visit the AQUILA Store and download the Sniff & Detect integration (manifest.xml).[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/b7bKUm3nKsq0c5Bm-image.png)
2. **Access Microsoft 365 Admin Center - [https://admin.microsoft.com](https://admin.microsoft.com/)**
- Log in as a **Global Admin** or **Exchange Admin**.
3. **Upload the Integration**
- Go to **Settings** → **Integration Apps** → **Upload Custom Apps** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/GwkifKIdnmjk0lTD-image.png)
- Follow the steps to Deploy the Sniff and Detect App .
- App Type → Office Add-in
-
Choose how to upload app → Upload Manifest file (.xml) from device→ Choose the manifest.xml file.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/r5PYE4pQkIBgAGDe-image.png)
4. **Deploy and Assign Users**
- Assign the app to the relevant users or groups.
5. **Grant Permissions**
- Accept all required permissions:
- ReadWriteItem
- SendReceiveData
6. **Allow Propagation Time**
- In the Integrated Apps page of the Admin Center, confirm the add-in appears with status '**OK**'.
- Wait up to **72 hours** for the app to be available across all assigned accounts.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/xFBy6BimbAdQektG-image.png)
7. **Access the App**
- Open Outlook and check the apps panel to ensure Sniff & Detect is listed and accessible.
- Users can launch it from **More apps** in Microsoft 365.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/x0FuZ3iJt7A0EjRE-image.png)
---
#### **How to Use Sniff and Detect **[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/s5bSBYRa4bCuZWbE-image.png)
- A phishing email impersonating Netflix. An arrow points to the **SNIFF & Detect** icon, indicating where to scan or flag the email as suspicious.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/fdE09hu7Rl60QyT9-image.png)
- Click the “**Scan This Email**” button and wait for the scan to complete.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/pRLtXFAqIgrMvZMx-image.png)
- SNIFF & Detect has scanned the email, highlighting possible errors such as
1. Arrow **1** points to the **Language issues** section, showing spelling and grammar mistakes found in the phishing email.
2. Arrow **2** points to the **What you should do** section, giving safety advice on how to handle the suspicious email.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/o6vEVWiMGeCI3Gsk-image.png)
- **Arrow 1** – Highlights the **AI Insight Results** tab in SNIFF & Detect, which contains the automated analysis results of the scanned email.
- **Arrow 2** – Points to the **Malicious** classification summary. This section briefly explains the reasons the email is flagged, such as suspicious sender details, urgent tone, spelling and grammar errors, and suspicious links.
- **Arrow 3** – Directs attention to the actual phishing email content pretending to be from Netflix, warning about a payment failure and urging the user to update their payment information.
- **Arrow 4** – Indicates the **Report as Phishing** button, which the user can click to formally report the suspicious email to security for further action.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/xCI6XwmmK0SHb2Jv-image.png)
- Click the "**Run a deep scan**" button, which allows for a more detailed examination of the email to detect hidden threats and malicious indicators.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/51ELQvK9m7iXcuUC-image.png)
- **SNIFF & Detect** doing a deep scan on a suspected phishing email pretending to be from Netflix. The scan may take a couple of minutes to finish.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/W3myFSHB02eaTvS2-image.png)
- The scan results are now finished and ready to check.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/mALzljyROiLcmqPz-image.png)
- This is the result of a deep scan conducted by the Sniff & Detect tool on a suspicious email impersonating Netflix.1. **Arrow 1** highlights the domain **netflix-billing.com,** which is flagged as a spoofed domain used to impersonate Netflix and trick users into entering sensitive information.2. **Arrow 2** lists phishing-related email addresses such as **richmond@cytcehint.com** and [**support@netflix-billing.com**](mailto:support@netflix-billing), which are likely used to send or support the fraudulent email.3. **Arrow 3** shows the IP address **192.168.1.45**, flagged as part of the phishing infrastructure. Although it's a private IP, its presence suggests internal spoofing or malicious setup.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/4JxCoYEvR1qYSOzV-image.png)
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# AQUILA - SonicWall Firewall Integration
This integration collects syslog messages from SonicWall firewalls. It has been tested with **Enhanced Syslog** logs from SonicOS versions 6.5 and 7.0, following the **[SonicWall Log Events reference guide](https://www.sonicwall.com/techdocs/pdf/sonicos-6-5-4-log-events-reference-guide.pdf)**.
---
### **Configuration**To set up the integration, configure a **Syslog Server** on your SonicWall firewall with the following settings:
- **Name or IP Address:**The address where your Elastic Agent (or AQUILA Agent) running this integration is reachable.
- **Port:**The UDP port number for Syslog, matching the port configured in your integration.
- **Server Type:**Select **Syslog Server**.
- **Syslog Format:**Choose **Enhanced Syslog**.
- **Syslog ID:**The default value is `firewall`. Change this if you want to differentiate logs from multiple firewalls. This value is stored in the `observer.name` field.
---
### **Time Configuration Recommendation**To avoid timestamp discrepancies:
- Enable **Display UTC in logs** in your SonicWall device under:`Device > Settings > Time Configuration`
- If you use local time instead, configure the **Timezone Offset** setting in your integration to match your firewall’s timezone.
---
### **Connectivity**Ensure proper network connectivity between your SonicWall firewall and the AQUILA Agent (or Elastic Agent) to receive syslog messages successfully.*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# AQUILA - Varonis (DLP) Integration
### **Purpose**This document outlines the procedure to integrate **Varonis DatAlert** or **DatAdvantage** with a SIEM platform using **Syslog (CEF)**. The integration provides visibility into sensitive data access, permissions changes, and threat alerts.
##### **Prerequisites**
- Admin access to **Varonis DatAlert Console**
- IP address and port of your **SIEM/syslog collector**
- Network/firewall access from Varonis to SIEM (UDP or TCP port open)
- (Optional) CEF parsing support in your SIEM
##### **Step 1: Configure Varonis DatAlert for Syslog forwarding**
1. Log in to your **Varonis UI** using admin credentials.
2. In Data Advantage, Navigate to:**Tools** → **DatAlert** → **Select DatAlert.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-10/T1GpiSEOTyEGyjPL-image.png)
3. Now, select **Configuration.**
4\. In **Syslog Message Forwarding**,
- **Syslog Message IP Address:** AQUILA log collector IP
- **Port: 10514** (if the port has already been used, you can set another one)
- **Transport protocol:** Choose **UDP** or **TCP** (if not already an option; some Varonis versions infer it)
- **Facility name:** Choose a different facility.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/H4qC8oP7koYwCy5S-image.png)
5. Click **Apply.**
##### **Step 2: Create Alert Template in Varonis DatAlert**
1. In **DatAlert**, select **Alert Templates**.
2. Click on the **Green Plus** sign to add a New Alert Template.
- In the Template name, select the **'External system default template (CEF)'**
- In the Apply to alert methods, select the **'Syslog message'**
3. Click **OK.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/aEWJh6P68iLccait-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/AlBqxNaiSiN27ETg-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/HPmTOp9hMqvURY5A-image.png)
##### **Step 3: Configuring alerts for single or multiple rules**To select the Syslog alert method for a single rule:
1. From the DatAlert rules table, select the **rule**, then click **Edit Rule**. The rule editing menu appears.
2. From the left menu, select **Alerts Method**. The “**Alert Method**” window appears.
3. Select **Syslog message**.
4. Click **OK**.To select the Syslog alert method for multiple rules:
1. From the DatAlert rules table, select the **rules**, then click **Edit Rule**. The rule editing menu appears and just "control A" to select all rules.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/PftyRnOYp0u3639o-image.png)
1. From the left menu, select **Alerts Method**. The “**Alert Method**” window appears, and its contents are disabled for selection.
2. Click the **edit** icon for the Syslog message option, then click the checkbox next to **Syslog message**.
3. Click **OK**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/qxgzGKNqhjnofPTA-image.png)
---
**Please provide the following information to CyTech Support:**
- **Port Address**
- **Protocol (TCP or UDP)**
*If you need further assistance, kindly contact our support at **[support@cytechint.com](mailto:info@cytechint.com)** for prompt assistance and guidance.*
# AQUILA CSPM - AWS Integration
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-overview)**Overview**
This page explains how to get started monitoring the security posture of your cloud assets using the Cloud Security Posture Management (CSPM) feature.
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-set-up-cloud-access-section)**Set up cloud account access**
The CSPM integration requires access to AWS’s built-in [`SecurityAudit` IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_security-auditor) in order to discover and evaluate resources in your cloud account. To provide access we need:
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-instance-role)**Create IAM User**Follow AWS’s [IAM roles for Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) documentation to create an IAM role using the IAM console, which automatically generates an instance profile.
1. Create an IAM role:
1. In AWS, go to your IAM dashboard. Click **Roles**, then **Create role**.
2. On the **Select trusted entity** page, under **Trusted entity type**, select **AWS service**.
3. Under **Use case**, select **EC2**. Click **Next**.
4. On the **Add permissions** page, search for and select `SecurityAudit`. Click **Next**.
5. On the **Name, review, and create** page, name your role, then click **Create role**.
2. Attach your new IAM role to an EC2 instance:
1. In AWS, select an EC2 instance.
2. Select **Actions > Security > Modify IAM role**.
3. On the **Modify IAM role** page, search for and select your new IAM role.
4. Click **Update IAM role**.
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-keys-directly)**Create Direct access keys**Access keys are long-term credentials for an IAM user or AWS account root user. To use access keys as credentials, you must provide the `Access key ID` and the `Secret Access Key`. After you provide credentials, [finish manual setup](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual "Finish manual setup").For more details, refer to [Access Keys and Secret Access Keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html).
- `Access key ID`: The first part of the access key.
- `Secret Access Key`: The second part of the access key.
**Please provide the following information to CyTech Support:**
- **Access key ID**
- **Secret Access Key**
#### **How to integrate to AQUILA CSPM Module**
##### **Pre-requisites**
1. **Access to CyTech - AQUILA**
- Only users assigned the **"Owner"** or **"Admin"** role can access the Log Collector installation resources within the platform.
**To navigate to CSPM Module please follow the instructions below:**
**Step 1: Log in to CyTech - AQUILA. Click here --> [AQUILACYBER.ai](https://aquilacyber.ai/overview-v3/dashboard/maindashboard)**
**Step 2: Click on Cyber Monitoring.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/hItzqzN09q61CMZZ-image.png)
**Step 3: Choose Cloud Security Posture Management (CSPM).**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/EbsP1Kz74gmIWnyZ-image.png)
**Step 4: Click the "Let's Go" or "Onboard CSPM" icon to launch installation window.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/h53Z6TJIUeSrsoc5-image.png)
**Step 5: Click "Let's go" to start the integration process.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/7DPNcbHQ3TI5nSmY-image.png)
**Step 6: Choose your log collector. If you haven't installed a log collector yet choose "New Log Collector" click here -->** [Log Collector Installation](https://docs.cytechint.io/books/log-collector-installations). **If you have already have an existing log collector choose "Current Log Collector" and click "Next".**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/YmaKgMpQPUBQOutG-image.png)
**Step 7: Click "Next" if the requirements are met.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/9XREDs3GMrovq966-image.png)
**Step 8: Choose your current log collector. This will collect the logs coming from your log sources.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/6JtsLkQBByfBwsLN-image.png)
**Step 9: Choose Amazon Web Services and click "Next" to proceed.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/tnsMSyjrIYJJrPQC-image.png)
**Step 10: Input all the required credentials from the previous AWS configurations and click "Next" to initiate the integration process. Wait for couple of minutes until a success window shows up.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/W3Utk1FQhuv2qKTK-image.png)
**Please refer to this manual for the full guidelines of our CSPM Module. *click here-->* [CyTech - AQUILA CSPM Manual ](https://docs.cytechint.io/books/log-collector-installations/page/cytech-aquila-cloud-security-posture-management-cspm-module)**
[](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual)
*If you need further assistance, kindly contact our support at **[support@cytechint.com](mailto:info@cytechint.com)** for prompt assistance and guidance.*
# AQUILA CSPM - Azure Integration
This manual explains how to get started monitoring the security posture of your Azure CSP using the Cloud Security Posture Management (CSPM) feature.
#### **Requirements**
- The user who gives the CSPM integration permissions in Azure must be an Azure subscription **admin**.
#### **Setup****Service principal with client secret** Before using this method, you must have set up a **Microsoft Entra application** and **service principal that can access resources**. Please go **[here](https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal#get-tenant-and-app-id-values-for-signing-in)** before following the steps below.
1. The following information is required.
1. Directory **(tenant) ID** and **Application (client) ID**
- To get these values:
- Go to the **Registered apps** section of Microsoft Entra ID.
- Click on **New Registration**, name your app and click **Register**.
- Copy your new app’s **Directory (tenant) ID** and **Application (client) ID**.
2. **Client Secret**
- In Azure portal, select Certificates & secrets, then go to the Client secrets tab. Click New client secret.
- Copy the new secret **"Value"**.
2. Return to Azure. Go to your Azure subscription list and select the subscription or management group you want to monitor with CSPM.
3. Go to **Access control (IAM)** and select **Add Role Assignment**.
4. Select the **Reader** function role, assign access to **User, group, or service principal**, and select your new app.
#### **How to integrate to AQUILA CSPM Module**
##### **Pre-requisites**
1. **Access to CyTech - AQUILA**
- Only users assigned the **"Owner"** or **"Admin"** role can access the Log Collector installation resources within the platform.
**To navigate to CSPM Module please follow the instructions below:**
**Step 1: Log in to CyTech - AQUILA. Click here --> [AQUILACYBER.ai](https://aquilacyber.ai/overview-v3/dashboard/maindashboard)**
**Step 2: Click on Cyber Monitoring.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/hItzqzN09q61CMZZ-image.png)
**Step 3: Choose Cloud Security Posture Management (CSPM).**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/EbsP1Kz74gmIWnyZ-image.png)
**Step 4: Click the "Let's Go" or "Onboard CSPM" icon to launch installation window.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/h53Z6TJIUeSrsoc5-image.png)
**Step 5: Click "Let's go" to start the integration process.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/7DPNcbHQ3TI5nSmY-image.png)
**Step 6: Choose your log collector. If you haven't installed a log collector yet choose "New Log Collector" click here -->** [Log Collector Installation](https://docs.cytechint.io/books/log-collector-installations). **If you have already have an existing log collector choose "Current Log Collector" and click "Next".**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/YmaKgMpQPUBQOutG-image.png)
**Step 7: Click "Next" if the requirements are met.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/9XREDs3GMrovq966-image.png)
**Step 8: Choose your current log collector. This will collect the logs coming from your log sources.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/6JtsLkQBByfBwsLN-image.png)
**Step 9: Choose Azure and click "Next" to proceed.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/emYpLrE9GwYlBYXG-image.png)
**Step 10: Input all the required credentials from the previous Azure configurations and click "Next" to initiate the integration process. Wait for couple of minutes until a success window shows up.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/rSv3hwdVltbKSxrr-image.png)
**Please refer to this manual for the full guidelines of our CSPM Module. *click here-->* [CyTech - AQUILA CSPM Manual ](https://docs.cytechint.io/books/log-collector-installations/page/cytech-aquila-cloud-security-posture-management-cspm-module)**
*If you need further assistance, kindly contact our support at **[support@cytechint.com](mailto:info@cytechint.com)** for prompt assistance and guidance.*
# AQUILA CSPM - GCP Integration
##### **Authentication**To use this CSPM Google Cloud Platform (GCP) integration, you need to set up a ***Service Account*** with a ***Role*** and a ***Service Account Key*** to access data on your GCP project.
##### **1. Service Account**First, you need to [create a Service Account](https://cloud.google.com/iam/docs/creating-managing-service-accounts). A Service Account (SA) is a particular type of Google account intended to represent a non-human user who needs to access the GCP resources.The AQUILA Agent uses the SA to access data on Google Cloud Platform using the Google APIs.
##### **2. Required IAM Service Account Roles:****For CSPM-GCP Integration**
- **Browser**: This role grants read access to the project hierarchy.
- **Cloud Asset Viewer**: Can view asset metadata across GCP services.Click here --> [GCP - How to Add a Role](https://docs.cytechint.io/books/system-integrations/page/gcp-how-to-add-a-role)
##### **3. Enable API Services**
- **Cloud Asset API**: Provides metadata inventory and history of GCP resources and IAM policies for security analysis, audit, and compliance.Click here --> [GCP - How to enable Cloud Asset API](https://docs.cytechint.io/books/system-integrations/page/gcp-how-to-enable-cloud-asset-api)
##### **4. Service Account Key **Next, with the Service Account (SA) with access to Google Cloud Platform (GCP) resources setup, you need some credentials to associate with it: a Service Account Key. From the list of SA (Service Accounts):
1. Go to **IAM & Admin > Service Accounts** in the GCP Console.
2. Click the service account you created.
3. Under the **"Keys"** section, click **"Add Key" > "Create new key"**.
4. Choose **JSON** as the key type.
5. **Download and securely store** the generated private key (it cannot be retrieved again from GCP if lost).
**Please provide the following information to CyTech Support:**
- **Project ****ID** -The Project ID is the Google Cloud project ID where your resources exist.
- **Credentials File** - Save the JSON file with the private key in a secure location of the file system, and make sure that the Log Collector Agent has at least read-only privileges to this file.
#### **How to integrate to AQUILA CSPM Module**
##### **Pre-requisites**
1. **Access to CyTech - AQUILA**
- Only users assigned the **"Owner"** or **"Admin"** role can access the Log Collector installation resources within the platform.
**To navigate to CSPM Module please follow the instructions below:**
**Step 1: Log in to CyTech - AQUILA. Click here --> [AQUILACYBER.ai](https://aquilacyber.ai/overview-v3/dashboard/maindashboard)**
**Step 2: Click on Cyber Monitoring.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/hItzqzN09q61CMZZ-image.png)
**Step 3: Choose Cloud Security Posture Management (CSPM).**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/EbsP1Kz74gmIWnyZ-image.png)
**Step 4: Click the "Let's Go" or "Onboard CSPM" icon to launch installation window.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/h53Z6TJIUeSrsoc5-image.png)
**Step 5: Click "Let's go" to start the integration process.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/7DPNcbHQ3TI5nSmY-image.png)
**Step 6: Choose your log collector. If you haven't installed a log collector yet choose "New Log Collector" click here -->** [Log Collector Installation](https://docs.cytechint.io/books/log-collector-installations). **If you have already have an existing log collector choose "Current Log Collector" and click "Next".**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/YmaKgMpQPUBQOutG-image.png)
**Step 7: Click "Next" if the requirements are met.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/9XREDs3GMrovq966-image.png)
**Step 8: Choose your current log collector. This will collect the logs coming from your log sources.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/6JtsLkQBByfBwsLN-image.png)
**Step 9: Choose Google Cloud Platform and click "Next" to proceed.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/IFKXnmI3U8F8BD8P-image.png)
**Step 10: Input all the required credentials from the previous GCP configurations and click "Next" to initiate the integration process. Wait for couple of minutes until a success window shows up.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/MmlY4HH1QBJ1g991-image.png)
**Please refer to this manual for the full guidelines of our CSPM Module. *click here-->* [CyTech - AQUILA CSPM Manual ](https://docs.cytechint.io/books/log-collector-installations/page/cytech-aquila-cloud-security-posture-management-cspm-module)**
*If you need further assistance, kindly contact our support at **[support@cytechint.com](mailto:info@cytechint.com)** for prompt assistance and guidance.*
# AQUILA GCP Integration
This Google Cloud integration collects and analyzes a wide range of logs and metrics to provide comprehensive visibility into your cloud environment. It ingests **Firewall Logs**, **VPC Flow Logs**, **DNS Logs**, and **Load Balancing Logs** exported from **Cloud Logging** via a **Pub/Sub topic sink**. Additionally, it gathers detailed **metrics and metadata** from **Google Cloud Monitoring** across core services, including **Compute Engine**, **Cloud SQL**, **Cloud Run**, **GKE**, **Firestore**, **Dataproc**, **Pub/Sub**, **Redis**, **Storage**, **Load Balancing**, and **Billing**. This enables in-depth monitoring of infrastructure, application performance, network activity, and cost trends.
##### **Logs**
- **Firewall Logs**: Record allowed and denied network traffic based on firewall rules.
- **VPC Flow Logs**: Capture IP traffic flowing to and from network interfaces in a VPC.
- **DNS Logs**: Track DNS queries and responses handled by Google Cloud DNS.
- **Load Balancing Logs**: Provide request-level logs of traffic handled by load balancers, including latency and backend info.
---
##### **Metrics**
- **GCP Billing Metrics**: Track resource usage and cost across GCP services.
- **GCP Compute Metrics**: Monitor performance of Compute Engine instances (CPU, memory, disk, etc.).
- **GCP Firestore Metrics**: Provide insights into Firestore usage like reads, writes, and storage.
- **GCP Load Balancing Metrics**: Measure load balancer traffic, request counts, latency, and backend health.
- **GCP Storage Metrics**: Report usage, operation counts, and latency for Cloud Storage buckets.
- **GCP GKE Metrics**: Monitor Kubernetes clusters including node health, pod usage, and resource consumption.
- **GCP Dataproc Metrics**: Track job status, cluster usage, and Hadoop/Spark performance in Dataproc.
- **GCP PubSub Metrics**: Show message throughput, subscription rates, and processing latency.
- **GCP Redis Metrics**: Display memory usage, operations per second, and cache hit/miss rates for Memorystore Redis.
- **GCP Cloud Run Metrics**: Measure request counts, container instance metrics, and response times.
- **GCP CloudSQL Metrics**: Provide visibility into database performance, including connections, query latency, and CPU usage.
##### **Authentication**
To use this Google Cloud Platform (GCP) integration, you need to set up a ***Service Account*** with a ***Role*** and a ***Service Account Key*** to access data on your GCP project.
##### **1. Service Account**
First, you need to [create a Service Account](https://cloud.google.com/iam/docs/creating-managing-service-accounts). A Service Account (SA) is a particular type of Google account intended to represent a non-human user who needs to access the GCP resources.
The AQUILA Agent uses the SA to access data on Google Cloud Platform using the Google APIs.
##### **2. Required IAM Service Account Roles:**
- **Cloud Memorystore Redis Viewer**: Can view configuration and metadata of Redis instances.
- **Cloud SQL Viewer**: Can view Cloud SQL instance metadata and settings, but not data.
- **Compute Viewer**: Can view all Compute Engine resources (instances, disks, etc.) but not modify them.
- **Logs Viewer**: Can view logs in Cloud Logging across the project.
- **Monitoring Viewer**: Can view monitoring dashboards, alerts, and metrics in Cloud Monitoring.
- **Private Logs Viewer**: Can view all logs, including those with restricted data (e.g., data access logs).
- **Pub/Sub Subscriber**: Grants permission to receive and acknowledge messages from Pub/Sub subscriptions.
- **Viewer**: Read-only access to all resources in a project.
##### **3. Logs Collection Configuration**With a properly configured Service Account and the integration setting in place, it’s time to start collecting some logs.**Requirements**You need to create a few dedicated Google Cloud resources before starting, in detail:
- **Pub/Sub Topic**: A messaging endpoint where publishers send messages that can then be delivered to one or more subscribers.
- **Subscription**: A configuration attached to a Pub/Sub topic that delivers messages to subscribers, either by push or pull.
- **Log Sink**: A configuration that routes logs from Cloud Logging to a specified destination such as Pub/Sub, Cloud Storage, or BigQuery.
It’srecommendedto have a separate Pub/Sub topics for each of the log types so that they can be parsed and stored in a specific data stream.
Here’s an example of collecting Audit Logs using a Pub/Sub topic, a subscription, and a Log Router. We will create the resources in the Google Cloud Console and then configure the Google Cloud Platform integration.
##### **Example Setup Using Google Cloud Console**
1. Navigate to **"Logging" > "Log Router" > "Create Sink"**.
2. Provide a **Sink name** and description.
3. For **Sink destination**, select **"Cloud Pub/Sub topic"**. Choose an existing topic or create a new one.
4. If a new topic is created, you must also **create a subscription** for it.
5. Under **"Choose logs to include in sink"**, use a filter like: logName:"cloudaudit.googleapis.com"
##### **4. Enable API Services**
- **Cloud SQL Admin API**: Enables programmatic management of Cloud SQL instances, including creation, configuration, and backups.
- **Memorystore for Redis API**: Allows automated management of Redis instances on Memorystore, including provisioning, scaling, and configuration.
##### **5. Service Account Key **Next, with the Service Account (SA) with access to Google Cloud Platform (GCP) resources setup, you need some credentials to associate with it: a Service Account Key. From the list of SA (Service Accounts):
1. Go to **IAM & Admin > Service Accounts** in the GCP Console.
2. Click the service account you created.
3. Under the **"Keys"** section, click **"Add Key" > "Create new key"**.
4. Choose **JSON** as the key type.
5. **Download and securely store** the generated private key (it cannot be retrieved again from GCP if lost).
**Please provide the following information to CyTech:**
- **Project ****ID** -The Project ID is the Google Cloud project ID where your resources exist.
- **Credentials File** - Save the JSON file with the private key in a secure location of the file system, and make sure that the Log Collector Agent has at least read-only privileges to this file.Specify the file path in the Log Collector Agent integration UI in the "Credentials File" field. For example: /home/ubuntu/credentials.json.
- **Pub/Sub Topic**- Name of the topic where the logs are written to.
- **Subscription** - Use the short subscription name here, not the full-blown path with the project ID. You can find it as "Subscription ID" on the Google Cloud Console.
*If you need further assistance, kindly contact our support at **[support@cytechint.com](mailto:info@cytechint.com)** for prompt assistance and guidance.*
# Atlassian Bitbucket Integrations
##### **Introduction**The Bitbucket integration collects audit logs from the audit log files or the [audit API](https://developer.atlassian.com/server/bitbucket/reference/rest-api/).Reference: [https://developer.atlassian.com/server/bitbucket/reference/rest-api/](https://developer.atlassian.com/server/bitbucket/reference/rest-api/)
##### **Assumptions**The procedures described in Section 3assume that a Log Collector has already been set up.
##### **Requirements**For more information on auditing in Bitbucket and how it can be configured, see [View and configure the audit log](https://confluence.atlassian.com/bitbucketserver/view-and-configure-the-audit-log-776640417.html) on Atlassian's website.Reference:[https://confluence.atlassian.com/bitbucketserver/view-and-configure-the-audit-log-776640417.html](https://confluence.atlassian.com/bitbucketserver/view-and-configure-the-audit-log-776640417.html)
##### **Logs**
**Audit**
The Confluence integration collects audit logs from the audit log files or the audit API from self-hosted Confluence Data Center. It has been tested with Confluence 7.14.2 but is expected to work with newer versions. As of version 1.2.0, this integration added experimental support for Atlassian Confluence Cloud. JIRA Cloud only supports Basic Auth using username and a Personal Access Token.
Please provide the following information to CyTech:**Collect Bitbucket audit logs via log files******
1. Path
2. Preserve Original Event? (Enable Yes/No)
- Preserves a raw copy of the original event, added to the field event.original
3. Tags
4. Processors (Optional)
5. Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed.
7. Select data streams to configure indexing options. This is an experimental feature and may have effects on other properties.
**Collect Bitbucket audit logs via API (Enable Yes/No)******
1. API URL - The API URL without the path.
2. Bitbucket Username - JIRA Username. Needs to be used with a Password. Do not fill if you are using a personal access token.
3. Bitbucket Password - JIRA Password. Needs to be used with a Username. Do not fill if you are using a personal access token.
4. Personal Access Token - The Personal Access Token. If set, Username and Password will be ignored.
5. Initial Interval - Initial interval for the first API call. Defaults to 24 hours.
# Atlassian Bitbucket Integrations (New)
##### **Introduction**
The Bitbucket integration collects audit logs from the audit log files or the [audit API](https://developer.atlassian.com/server/bitbucket/reference/rest-api/).Reference: [https://developer.atlassian.com/server/bitbucket/reference/rest-api/](https://developer.atlassian.com/server/bitbucket/reference/rest-api/)
##### **Assumptions**
The procedures described in Section 3assume that a Log Collector has already been set up.
##### **Requirements**
For more information on auditing in Bitbucket and how it can be configured, see [View and configure the audit log](https://confluence.atlassian.com/bitbucketserver/view-and-configure-the-audit-log-776640417.html) on Atlassian's website.Reference:[https://confluence.atlassian.com/bitbucketserver/view-and-configure-the-audit-log-776640417.html](https://confluence.atlassian.com/bitbucketserver/view-and-configure-the-audit-log-776640417.html)
##### **Logs**
**Audit**
The Confluence integration collects audit logs from the audit log files or the audit API from self-hosted Confluence Data Center. It has been tested with Confluence 7.14.2 but is expected to work with newer versions. As of version 1.2.0, this integration added experimental support for Atlassian Confluence Cloud. JIRA Cloud only supports Basic Auth using username and a Personal Access Token.
##### **Atlassian Bitbucket Integration Procedures**
Please provide the following information to CyTech:**Collect Bitbucket audit logs via log files******
1. Path
2. Preserve Original Event? (Enable Yes/No)
- Preserves a raw copy of the original event, added to the field event.original
3. Tags
4. Processors (Optional)
5. Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed.
7. Select data streams to configure indexing options. This is an experimental feature and may have effects on other properties.
**Collect Bitbucket audit logs via API (Enable Yes/No)******
1. API URL - The API URL without the path.
2. Bitbucket Username - JIRA Username. Needs to be used with a Password. Do not fill if you are using a personal access token.
3. Bitbucket Password - JIRA Password. Needs to be used with a Username. Do not fill if you are using a personal access token.
4. Personal Access Token - The Personal Access Token. If set, Username and Password will be ignored.
5. Initial Interval - Initial interval for the first API call. Defaults to 24 hours.
#####
##### **Create Access Token:**
Access Tokens are single-purpose access tokens (or passwords) with access to a single workspace with limited permissions (specified at creation time). Use tokens for tasks such as scripting, CI/CD tools, and testing Bitbucket integrations or Marketplace apps while in development.
To create an Access Token:
1. At [bitbucket.org](http://bitbucket.org/ "http://bitbucket.org/"), navigate to the target workspace for the Access Token. This workspace is the only one that the Workspace Access Token can access.
2. On the sidebar, select **Settings**.
3. On the sidebar, under **Security**, select **Access tokens**.
4. Select **Create Workspace Access Token**.
5. Give the Workspace Access Token a name, usually related to the app or task that will use the token.
6. Select the permissions the Access Token needs. *Note give the Access Token admin permission.*
7. Select the **Create** button. The page will display the **Workspace Access Token created** dialog.
8. Copy the generated token and either record or paste it into the app that requires access. *The token is only displayed once and can't be retrieved later*.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Automatically fetch user accounts ( Google IAM )
**STEP 1: Enable APIs**
You’ll need access to one of the following APIs:
- **Cloud Identity API** (for non-Google Workspace orgs)
- **Admin SDK API** (for Google Workspace)
How to Enable:
1. Go to Google Cloud Console
2. Navigate to: APIs & Services > Library
3. Search for:
- Cloud Identity AP
- Admin SDK API
4. Click **Enable**
---
**STEP 2: Set Up a Service Account**
1. In the Cloud Console, go to : IAM & Admin > Service Accounts
2. Click **Create Service Account**
3. Name it and click **Create and Continue**
4. Assign roles:
- For Cloud Identity: Cloud Identity User Read
- For Admin SDK: Viewer or User Management Admin
---
**STEP 3: Create and Download Credentials**
1. Go back to your service account.
2. Under the **Keys** tab, click **Add Key > JSON**
3. Save the .json file securely — this will be used to authenticate API requests.
---
**STEP 4: Grant Domain-Wide Delegation (if using Admin SDK)**
This allows your service account to impersonate an admin.
1. In the Service Account settings, enable **“Enable G Suite Domain-wide Delegation”**
2. Go to your [Google Admin console](https://admin.google.com/)
3. Add a new client: Security > API Controls > Domain-wide Delegation
- **Client ID:** from your service account JSON
**STEP 5: Fetch User Accounts Pro-grammatically**
Use Python and google-auth + google-api-python-client.
**STEP 6: Automate the Process**
- Schedule the script to run via:
- **Cloud Scheduler** (GCP-native)
- **Cron job** (Linux VM)
- **Cloud Functions / Cloud Run** (for serverless)
---
**STEP 7: Send or Sync Data**
Once you fetch users:
- You can store them in:
- Elasticsearch
# Automatically Fetch User Accounts without Manually Importing for JumpCloud
#### **JumpCloud**
**Intoduction**
JumpCloud allows you to automate user account creation and syncing **without manual CSV uploads** by integrating with external identity sources like **Active Directory, OneLogin, Okta, Azure AD, or APIs**.
**Automatic User Provisioning in JumpCloud**
Automatic provisioning means **creating and updating user accounts in JumpCloud from another source system** (e.g., your Identity Provider or directory service) using SCIM or other integrations — **no spreadsheets, no forms, no manual steps**.
**Source System**
**Integration Type**
**Description**
**Active Directory (AD)**
AD Sync Agent
Syncs users/groups from AD to JumpCloud
**OneLogin / Okta / Azure AD**
SCIM Connector
Push users via SCIM to JumpCloud
**Google Workspace / HR System**
API Script (custom)
Use API to fetch users and sync to JC
#### **Option 1: Active Directory (AD) Sync**
##### Description:
Use JumpCloud’s **AD Sync Agent** to connect your on-prem Active Directory to JumpCloud.
What It Does:
- Automatically fetches users and groups from AD into JumpCloud.
- Keeps user profiles updated.
- Supports password sync and group assignments.
##### Steps:
1. 1. **Install the AD Import Agent**:
- Log in to JumpCloud Admin Portal.
- Navigate to **Directory Integrations → Active Directory**.
- Download the **AD Import Agent**.
- Install it on your Domain Controller or a Windows server joined to the domain.
2. **Install the AD Sync Agent (optional for write-back)**:
- If you want to sync changes from JumpCloud to AD (two-way), install the Sync Agent too.
3. **Register the Agents**:
- During installation, provide the **JumpCloud API key**.
- Approve the agent from the JumpCloud admin dashboard.
4. **Set Up AD Group(s) for Sync**:
- Create an AD security group (e.g., JumpCloudSyncUsers).
- Add AD users to this group. Only members will sync.
5. **Configure OU and Attribute Settings**:
- Specify which Organizational Units (OUs) to include.
- Map attributes like email, phone, title, etc.
6. **Test and Enable Sync**:
- Run a test sync.
- Review previewed user data in JumpCloud.
- Enable production sync.
7. **Monitor Sync**:
- Use the AD Integration logs in JumpCloud to monitor status.
#### **Option 2: SCIM-Based Provisioning from OneLogin, Okta, Azure AD**
##### Description:
If you're using a cloud identity provider, you can **push users into JumpCloud** using SCIM.
What It Does:
- Auto-creates users in JumpCloud.
- Syncs attribute updates (name, email, etc.).
- Suspends users when removed from the source.
##### Steps:
1. **Prepare JumpCloud SCIM Settings**:
- In JumpCloud Admin Portal, go to **SSO Applications → + Add App**.
- Choose **Custom SCIM Connector**.
- JumpCloud provides:
- **SCIM Base URL**
- **Bearer Token** (API key)
2. **Configure SCIM in IdP (e.g., OneLogin/Okta)**:
- Create a new SCIM app integration.
- Enter the SCIM Base URL and Token provided by JumpCloud.
- Set the SCIM version to **2.0**.
3. **Define Provisioning Rules**:
- Choose what triggers user creation (e.g., role membership).
- Assign the app to users or groups.
4. **Enable SCIM Provisioning**:
- Turn on auto-provisioning in your IdP.
- Confirm SCIM connection test passes.
5. **Sync Begins Automatically**:
- Users assigned in IdP are instantly created/updated in JumpCloud.
- No manual intervention required.
#### **Option 3: Custom Script Using JumpCloud API**
##### Description:
If users are stored in another system (like Google Workspace, a database, or an HR app), use **JumpCloud’s API** to fetch and sync users automatically.
What It Does:
- Programmatically creates users in JumpCloud.
- Can run on a schedule (daily, hourly, etc.).
- Completely hands-free after setup.
##### Steps:
1. **Get JumpCloud API Credentials**:
- Go to **Admin Portal → API Settings**.
- Copy your **API Key**.
2. **Write a Script**:
- Use Python, Bash, or PowerShell.
- Example logic:
- Connect to your data source.
- Format users as JSON.
- Call POST /systemusers or PUT /systemusers/{id}.
3. **Schedule the Script**:
- On Linux: Use cron to run the script hourly/daily.
- On Windows: Use **Task Scheduler**.
4. **Optional**: Log output or push alerts to Slack/email.
Method
No Manual Upload
Real-Time Updates
Deletion Sync
AD Sync
**✓**
**✓**
**✓**
SCIM (IdPs)
**✓**
**✓**
**✓**
Custom API
**✓**
**☓** (depends on job)
**✓**
#### JumpCloud API
- https://docs.jumpcloud.com/api/
# Automatically Fetch User Accounts without Manually Importing for OneLogin (via SCIM)
#### **OneLogin (via SCIM)**
**Introduction:**
OneLogin gives users the ability to access the applications and other resources they need to do their job by logging in once to a single interface. Platforms like OneLogin are known as **Identity and Access Management (IAM)** solutions that are primarily used to provide their users with a **Single Sign-on (SSO)** experience. OneLogin allows you to automatically send user account data (name, email, role, etc.) into external apps like **Slack, Zoom, Salesforce, or your custom platform** using SCIM without any CSV uploads or manual entry.
##### **SCIM**
SCIM (System for Cross-domain Identity Management) is a standard protocol that automates how users are created, updated, or removed across applications. With SCIM, OneLogin can sync user details, like name, email, role to apps like Zoom, or custom platforms that support SCIM.
**SCIM helps by:**
- Automatically creating users when they’re added to OneLogin
- Updating user info when their OneLogin profile changes
- Disabling or deleting users from apps when removed in OneLogin
SCIM is ideal for improving security, reducing IT overhead, and ensuring consistent identity data across platforms.
##### **SAML**
SAML (Security Assertion Markup Language) is a standard used for **Single Sign-On (SSO)**. It allows users to log in once to OneLogin and gain access to multiple connected apps (like G Suite, Zoom, or Salesforce) without logging in again.
How it works:
- The user logs in to OneLogin.
- OneLogin sends a **secure login token** (assertion) to the app (service provider).
- The app trusts OneLogin and grants access, no separate password needed.
SAML is useful for improving security and user convenience. It’s often used alongside **SCIM**, where SAML handles authentication and SCIM handles user creation, updates, and removals.
##### **What is Automatic User Provisioning via OneLogin?**
Automatic provisioning means **OneLogin pushes user details to your app** when a user is added, updated, or deleted using the SCIM protocol. This reduces errors, saves IT time, and ensures data stays in sync.
**What You Need to Integrate App with OneLogin (SCIM)**
**Requirement**
**Description**
**SCIM API Endpoint**
A web link where OneLogin can send create/update/delete user requests
**Bearer Token**
A secret token (like a password) so OneLogin can authenticate securely
**SCIM 2.0 Support**
Your app must support SCIM 2.0 (understand user creation/update requests)
**Set Up SCIM Integration from OneLogin to Your App**
**Description:**
Use OneLogin’s SCIM connector to automatically create, update, or deactivate user accounts in your SCIM-compatible application.
**What It Does:**
- Auto-creates users in your app.
- Syncs updates to user info (like title, phone, etc.).
- Deactivates/suspends users when removed in OneLogin.
#### **Setup Steps:**
##### **Prepare Your App for SCIM Integration**
- Create a **SCIM 2.0-compatible API endpoint** in your app.
- Generate a **Bearer Token** your app will recognize.
- Support basic SCIM actions:
- POST /Users (create)
- PATCH /Users/{id} (update)
- DELETE /Users/{id} or deactivate (active: false)
#####
##### **Add Your App in OneLogin**
- Go to **Admin Portal → Apps → Add App**.
- Search and select your app (e.g., Zoom, Slack, or Custom SCIM).
- Save and go to the app configuration.
#####
##### **Enable SCIM Provisioning**
- Navigate to the **Provisioning** tab in the app.
- Enable **"Enable Provisioning"**.
- Enter:
- **SCIM Base URL** (from your app)
- **Bearer Token** (from your app)
- Save your settings.
#####
##### **Configure Provisioning Behavior**
- Choose what OneLogin does when:
- A user is added → Create in your app
- A user is updated → Sync changes
- A user is removed → Suspend/Delete in your app
- Toggle actions to **"Automatically"** if you don’t want manual approval.
#####
##### **Set Up User Mappings**
- Go to **Users → Mappings**.
- Create or edit a mapping rule:
- Assign users to the app based on role, department, etc.
- Define how OneLogin sends attributes like name, email, title.
##### **Assign the App to Users or Roles**
- Go to the **Users** tab:
- Assign the app directly to users
- Or assign it to a Role, then assign users to that role
If provisioning is active, users matching the rules will be auto-synced to your app.
**What Happens Next?**
Once integrated:
- When a user is added to OneLogin → They are automatically created in your app.
- If their profile changes in OneLogin → Your app is updated.
- If they’re removed → OneLogin disables or deletes them in your app.
**Requirement**
**Purpose**
**SCIM API URL**
Endpoint where OneLogin sends user actions
**Bearer Token**
Authenticates OneLogin to your app
**SCIM 2.0 Support**
Lets your app understand and apply user changes
**OneLogin Step**
Description
**Add App**
Add your SCIM-compatible app to OneLogin
**Enable Provisioning**
Enter SCIM URL + Token
**Set Provisioning Rules**
Choose when to create/update/delete users
**Create Mappings**
Map OneLogin attributes to your app fields
**Assign Users/Roles**
Control which users get sent to your app
# Automation on fetching user accounts for Azure
To **automatically fetch user accounts into Azure** (e.g., for Azure Active Directory / Microsoft Entra ID) **without manually importing them**, your approach depends on the **source of the user accounts**. Below are common scenarios and how to automate the sync:
##### **From On-Premises Active Directory**
Use **Azure AD Connect** to automatically sync users from on-premises AD to Azure AD.
**Steps:**
1. **Install Azure AD Connect** on your on-prem AD server.
2. Configure it to:
- Use **password hash synchronization** or **pass-through authentication**.
- Enable **automatic synchronization**.
3. Azure AD Connect will:
- Regularly sync users, groups, and passwords to Azure AD automatically.
- No manual importing needed after setup.
##### **From a Third-Party HR System or App (e.g., Workday, SAP, etc.)**
Use **provisioning connectors** available in **Microsoft Entra (Azure AD)**.
**Steps:**
1. Go to **Entra ID > Enterprise Applications > Your App > Provisioning**.
2. Configure **automatic user provisioning** with the source system.
3. Provide credentials/API endpoints of the source system.
4. Define mappings for user properties.
Works for Workday, SuccessFactors, SAP, Oracle, etc.
##### **From CSV/Flat Files in a Scheduled Way**
Use **PowerShell** or **Azure Automation** to import from CSV regularly.
**Option A: PowerShell Script (with schedule)**
- Write a script using `Import-Csv` + `New-AzureADUser` or `Set-AzureADUser`.
- Schedule it using **Task Scheduler** or **Azure Automation**.
**Option B: Logic Apps or Power Automate**
- Use a **Logic App** to watch for a file in OneDrive, SharePoint, or Blob Storage.
- Parse it and create/update users in Azure AD via **Microsoft Graph API**.
##### **Via Microsoft Graph API**
If user accounts are coming from a custom app or identity source, use **Graph API** to programmatically sync them.
**Key Points:**
- Write a script or backend app that calls `POST https://graph.microsoft.com/v1.0/users`.
- Authenticate using **client credentials flow** (service principal).
- Automate the execution on a schedule.
##### **Notes:**
- You need proper permissions: **User administrator** or **Global administrator** in Azure AD.
- Use **SCIM provisioning** if the third-party app supports it.
# Automation on fetching user accounts for Okta
To **automatically fetch user accounts into Okta** without needing to manually import them, you should set up a **Directory Integration** that allows Okta to **sync users from an external directory**, such as **Active Directory (AD)**, **LDAP**, or through a **SCIM integration**. Here's how to approach each method:
##### **Active Directory (AD) Integration (Most Common)**
This is the best option if you're using Windows Server AD.
**Steps:**
1. **Install the Okta AD Agent** on a domain-joined Windows Server.
2. In the Okta Admin Console:
- Go to **Directory > Directory Integrations**.
- Click **Add Directory** > **Add Active Directory**.
3. Follow the wizard:
- Provide domain credentials.
- Select the OUs you want to sync.
- Schedule automatic imports (default every hour).
4. After setup, Okta will **automatically sync users and groups** from AD to Okta.
Okta will **periodically pull new users, updates, and removals**.
##### **LDAP Directory Integration**
If you're using OpenLDAP or similar:
**Steps:**
1. Install the **Okta LDAP Agent** on a server that can access your LDAP directory.
2. Go to **Directory > Directory Integrations** in Okta and add your LDAP configuration.
3. Schedule sync or enable real-time sync depending on the directory.
##### **SCIM (System for Cross-domain Identity Management)**
If your source system supports SCIM (like HR systems, custom apps, etc.):
**Steps:**
1. Ensure the external system supports **SCIM 2.0**.
2. In Okta, go to **Applications** > add SCIM-based integration (or create a custom SCIM app).
3. Configure:
- SCIM base URL
- Bearer token
4. Okta will **auto-provision and deprovision** users via SCIM.
##### **Okta Workflows or API Automation (Advanced)**
For custom scenarios (e.g. syncing from a CSV, API, or Google Workspace):
- Use **Okta Workflows** or the **Okta API** to periodically fetch and push user data.
- Okta Workflows has connectors to services like Google Sheets, Slack, Salesforce, etc.
- You can build a scheduled flow that fetches data and creates users in Okta.
##### **Manual Import = Only Needed If:**
- You don’t use a supported directory or SCIM.
- You're uploading static CSV files.
##### **Sync Frequency**
- AD/LDAP: Every 1 hour (default), configurable
- SCIM: Real-time (if supported), or scheduled via Okta
- API/Workflows: As you define it (e.g., every 15 minutes)
# AWS Cloudtrails Integrations
##### **Introduction**The AWS CloudTrail integration allows you to monitor [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)Reference: [https://aws.amazon.com/cloudtrail/](https://aws.amazon.com/cloudtrail/) Use the AWS CloudTrail integration to collect and parse logs related to account activity across your AWS infrastructure. Then visualize that data in Kibana, create alerts to notify you if something goes wrong, and reference logs when troubleshooting an issue.For example, you could use the data from this integration to spot unusual activity in your AWS accounts—like excessive failed AWS console sign in attempts.The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Data streams**The AWS CloudTrail integration collects one type of data: logs.Logs help you keep a record of every event that CloudTrail receives. These logs are useful for many scenarios, including security and access audits. See more details in the [Logs reference](https://aquila-elk.kb.us-east-1.aws.found.io:9243/app/integrations/detail/aws-1.28.3/overview?integration=cloudtrail#logs-reference).Reference :[https://aquila-elk.kb.us-east-1.aws.found.io:9243/app/integrations/detail/aws-1.28.3/overview?integration=cloudtrail - logs-reference](https://aquila-elk.kb.us-east-1.aws.found.io:9243/app/integrations/detail/aws-1.28.3/overview?integration=cloudtrail#logs-reference)
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### **Requirements**You need Elasticsearch for storing and searching your data and Kibana for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your own hardware.Before using any AWS integration you will need:
- AWS Credentials to connect with your AWS account.
- AWS Permissions to make sure the user you're using to connect has permission to share the relevant data.
For more details about these requirements, see the AWS integration documentation.
##### **Setup**Use this integration if you only need to collect data from the AWS CloudTrail service.If you want to collect data from two or more AWS services, consider using the AWS integration. When you configure the AWS integration, you can collect data from as many AWS services as you'd like.For step-by-step instructions on how to set up an integration, see the [Getting started](https://www.elastic.co/guide/en/welcome-to-elastic/current/getting-started-observability.html) guide.
##### **Logs reference**The cloudtrail data stream collects AWS CloudTrail logs. CloudTrail monitors events like user activity and API usage in AWS services. If a user creates a trail, it delivers those events as log files to a specific Amazon S3 bucket.
##### **AWS CloudTrail integration Procedures**The following will need to be provided in the Configure integration when adding the AWS Audit CloudTrail integration.Procedures:Please provide the following information to CyTech:Configure Integration
1. Collect CloudTrail logs from S3 (Enable)
- Queue URL is required(URL of the AWS SQS queue that messages will be received from.)
2. Collect CloudTrail logs from CloudWatch(Optional)
- Log Group ARN (ARN of the log group to collect logs from.)
3. Collect CloudTrail logs from third-party REST API (Optional)
- URL of Splunk Enterprise Server (i.e. scheme://host:port, path is automatic)
- Splunk REST API Username
- Splunk REST API Password
- Splunk Authorization Token (Bearer Token or Session Key, e.g. "Bearer eyJFd3e46..." or "Splunk 192fd3e...". Cannot be used with username and password.)
# AWS GuardDuty Integrations
##### **Introduction**The Amazon GuardDuty integration collects and parses data from Amazon GuardDuty Findings REST APIs.The Amazon GuardDuty integration can be used in three different modes to collect data:
- HTTP REST API - Amazon GuardDuty pushes logs directly to an HTTP REST API.
- AWS S3 polling - Amazon GuardDuty writes data to S3 and Elastic Agent polls the S3 bucket by listing its contents and reading new files.
- AWS S3 SQS - Amazon GuardDuty writes data to S3, S3 pushes a new object notification to SQS, Elastic Agent receives the notification from SQS, and then reads the S3 object. Multiple Agents can be used in this mode.
##### **Assumptions**
The procedures described in Section 3assume that a Log Collector has already been setup.
##### **Requirements**You need Elasticsearch for storing and searching your data and Kibana for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your own hardware.Note: It is recommended to use AWS SQS for Amazon GuardDuty.
##### **Aws GuardDuty integration Procedures**To collect data from AWS S3 Bucket, follow the steps below:
- Configure the [Data Forwarder](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html) to ingest data into an AWS S3 bucket. However, the user can set the parameter "Bucket List Prefix" according to the requirement.
To collect data from AWS SQS, follow the steps below:
1. If data forwarding to an AWS S3 bucket hasn't been configured, then first setup an AWS S3 bucket as mentioned in the documentation above.
2. To setup an SQS queue, follow "Step 1: Create an Amazon SQS queue" mentioned in the [Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ways-to-add-notification-config-to-bucket.html).
- While creating an SQS queue, please provide the same bucket ARN that has been generated after creating the AWS S3 bucket.
3. Setup event notification for an S3 bucket. Follow this [guide](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications.html).
- The user has to perform Step 3 for the guardduty data-stream, and the prefix parameter should be set the same as the S3 Bucket List Prefix as created earlier. For example, logs/ for guardduty data stream.
- For all the event notifications that have been created, select the event type as s3:ObjectCreated:\*, select the destination type SQS Queue, and select the queue that has been created in Step 2.
Note:
- Credentials for the above AWS S3 and SQS input types should be configured according to the [input configuration guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-aws-s3.html#aws-credentials-config).
- Data collection via AWS S3 Bucket and AWS SQS are mutually exclusive in this case.
To collect data from Amazon GuardDuty API, users must have an Access Key and a Secret Key. To create an API token follow the steps below:
1. Login to [https://console.aws.amazon.com/](https://console.aws.amazon.com/).
2. Go to [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)to access the IAM console.
3. On the navigation menu, choose Users.
4. Choose your IAM user name.
5. Select Create access key from the Security Credentials tab.
6. To see the new access key, choose Show.
Note
- The Secret Access Key and Access Key ID are required for the current integration package.
# AWS Integrations
##### **Introduction**This document shows information related to AWS Integration. The AWS integration is used to fetch logs and metrics from Amazon Web Services.The usage of the AWS integration is to collect metrics and logs across many AWS services managed by your AWS account.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**Before using the AWS integration you will need:
- AWS Credentials to connect with your AWS account.
- AWS Permissions to make sure the user you're using to connect has permission to share the relevant data.
##### **AWS Credentials****Use access keys directly(Option 1 Recommended)**Access keys are long-term credentials for an IAM user or the AWS account root user. To use access keys as credentials, you need to provide:
- access\_key\_id: The first part of the access key.
- secret\_access\_key: The second part of the access key.
**Use an IAM role Amazon Resource Name (ARN)**
To use an IAM role ARN, you need to provide either a credential profile or access keys along with the role\_arn advanced option. role\_arn is used to specify which AWS IAM role to assume for generating temporary credentials.
**Use a shared credentials file (Option 2)**
Instead of providing the access\_key\_id and secret\_access\_key directly to the integration, you will provide two advanced options to look up the access keys in the shared credentials file:
- credential\_profile\_name: The profile name in shared credentials file.
shared\_credential\_file: The directory of the shared credentials file.Access keys are long-term credentials for an IAM user or the AWS account root user. To use access keys as credentials, you need to provide:
- access\_key\_id: The first part of the access key.
- secret\_access\_key: The second part of the access key.
**AWS Permissions**Specific AWS permissions are required for the IAM user to make specific AWS API calls. To enable the AWS integration to collect metrics and logs from all supported services, make sureto give necessary permissions which CyTechto monitor.Reference permissions:
##### **AWS Integrations Procedures****Access Key ID and Secret Access Key:**These are associated with AWS Identity and Access Management (IAM) users and are used for programmatic access to AWS services. To find them:
- Access the AWS Management Console.
- Go to the "IAM" (Identity and Access Management) service.
- Select the IAM user for which you want to retrieve the access keys.
- Under the "Security credentials" tab, you can find the Access Key ID and you can create a new Secret Access Key if needed.
**S3 Bucket ARN:**You can find the Amazon Resource Name (ARN) for an S3 bucket in the S3 Management Console or by using the AWS CLI. It typically looks like this:
- Access the AWS Management Console.
- Go to S3 Bucket Service
- Navigate properties.
- Find the ARN under Bucket overviewSample: arn:aws:s3:::your-bucket-name
**Log Group ARN:**Log Groups are associated with AWS CloudWatch Logs. You can find the ARN for a log group as follows:
- Access the AWS Management Console.
- Go to the "CloudWatch" service.
- In the CloudWatch Logs section, select the log group you're interested in.
- Select the log group that you want to open.
- In the details of the log group, you will find the ARN.
**SQS Queue URL: (Ignore if you're not using SQS Queue URL)**
To find the URL of an Amazon Simple Queue Service (SQS) queue:
- Access the AWS Management Console.
- Go to the "SQS" service.
- Select the specific queue you're interested in.
- In the queue details, you can find the Queue URL
Please provide the following information to CyTech:
- Access Key ID
- Secret Access Key
1. *S3 Bucket ARN*
2. *Log Group ARN*
3. *SQS Queue URL:(Ignore if you're not using SQS Queue URL)*
# AWS Security Hub Integrations
##### **Introduction**The AWS Security Hub integration collects and parses data from AWS Security Hub REST APIs.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup. **Compatibility******
- This module is tested against AWS Security Hub API version 1.0.
##### **Requirements**To collect data from AWS Security Hub APIs, users must have an Access Key and a Secret Key. To create API token follow below steps:
1. Login to [https://console.aws.amazon.com/](https://console.aws.amazon.com/).
2. Go to [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)to access the IAM console.
3. On the navigation menu, choose Users.
4. Choose your IAM user name.
5. Select Create access key from the Security Credentials tab.
6. To see the new access key, choose Show.
**Note:**
1. For the current integration package, it is recommended to have interval in hours.
2. For the current integration package, it is compulsory to add Secret Access Key and Access Key ID.
**Logs:**
1. Findings - This is the securityhub\_findings data stream.
2. Insights - This is the securityhub\_insights data stream.
##### **AWS Security HubIntegrationProcedures**Please provide the following information to CyTech:
**Collect AWS Security Hub logs via API**
1. AWS Region - AWS Region.
**Collect AWS Security Hub Insights from AWS**
1. AWS Region - AWS Region.
# Azure Application Insights Integration
The **Application Insights Integration** allows users to collect metrics from Azure Application Insights.
### **Key Configuration Options:**
- **Application ID**: The ID of the application from the API Access settings in the Azure portal.
- **API Key**: A generated key for authentication.
### **Data Stream: `app_insights`**
Users can retrieve various metrics with filtering options.
#### **Configuration Options:**
- **Metrics**: List of metrics to collect.
- **ID**: Metric IDs or names. Default includes requests, performance, and availability.
- **Interval**: ISO8601 duration for metric retrieval. Defaults to entire timespan if omitted.
- **Aggregation**: Functions like sum, average, etc. Defaults to metric-specific aggregation.
- **Segment**: Dimension to group metric data by.
- **Top**: Number of segments to return (valid only with `segment`).
- **Order By**: Sorting order for segments (valid only with `segment`).
- **Filter**: OData filter expression for refining results.
An example event for `app_insights` looks as following:
```json
{
"@timestamp": "2021-08-23T14:37:42.268Z",
"agent": {
"ephemeral_id": "4162d5df-ab00-4c1b-b4f3-7db2e3b599d4",
"hostname": "docker-fleet-agent",
"id": "d979a8cf-ddeb-458f-9019-389414e0ab47",
"name": "docker-fleet-agent",
"type": "metricbeat",
"version": "7.15.0"
},
"azure": {
"app_insights": {
"end_date": "2021-08-23T14:37:42.268Z",
"start_date": "2021-08-23T14:32:42.268Z"
},
"application_id": "42cb59a9-d5be-400b-a5c4-69b0a0026ac6",
"dimensions": {
"request_name": "GET Home/Index",
"request_url_host": "demoappobs.azurewebsites.net"
},
"metrics": {
"requests_count": {
"sum": 4
}
}
},
"cloud": {
"provider": "azure"
},
"data_stream": {
"dataset": "azure.app_insights",
"namespace": "default",
"type": "metrics"
},
"ecs": {
"version": "8.11.0"
},
"elastic_agent": {
"id": "d979a8cf-ddeb-458f-9019-389414e0ab47",
"snapshot": true,
"version": "7.15.0"
},
"event": {
"agent_id_status": "verified",
"dataset": "azure.app_insights",
"duration": 503187300,
"ingested": "2021-08-23T14:37:41Z",
"module": "azure"
},
"host": {
"architecture": "x86_64",
"containerized": true,
"hostname": "docker-fleet-agent",
"id": "1642d255f9a32fc6926cddf21bb0d5d3",
"ip": [
"192.168.96.7"
],
"mac": [
"02-42-AC-1F-00-07"
],
"name": "docker-fleet-agent",
"os": {
"codename": "Core",
"family": "redhat",
"kernel": "4.19.128-microsoft-standard",
"name": "CentOS Linux",
"platform": "centos",
"type": "linux",
"version": "7 (Core)"
}
},
"metricset": {
"name": "app_insights",
"period": 300000
},
"service": {
"type": "azure"
}
}
```
# Azure Application Insights Integration
#### **Overview**
The Application Insights Integration allows users to retrieve application insights metrics from specified applications.
### [Integration level configuration options](https://www.elastic.co/docs/reference/integrations/azure_application_insights/app_insights#integration-level-configuration-options)
`Application ID`: ID of the application. This is Application ID from the API Access settings blade in the Azure portal.
`API Key`: The API key which will be generated, more on the steps here [https://dev.applicationinsights.io/documentation/Authorization/API-key-and-App-ID](https://dev.applicationinsights.io/documentation/Authorization/API-key-and-App-ID).
#### [Configuration options](https://www.elastic.co/docs/reference/integrations/azure_application_insights/app_insights#configuration-options)
**`Metrics`**: List of different metrics to collect information
`id`: IDs of the metrics that's being reported. Usually, the id is descriptive enough to help identify what's measured. Default metrics include a curated selection of requests counters, performance, and service availability. The list of options can be found here [https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get#metricid](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get#metricid)
**`interval`**: The time interval to use when retrieving metric values. This is an ISO8601 duration. If interval is omitted, the metric value is aggregated across the entire timespan. If interval is supplied, the result may adjust the interval to a more appropriate size based on the timespan used for the query.
**`aggregation`**: The aggregation to use when computing the metric values. To retrieve more than one aggregation at a time, separate them with a comma. If no aggregation is specified, then the default aggregation for the metric is used.
**`segment`**: The name of the dimension to segment the metric values by. This dimension must be applicable to the metric you are retrieving. In this case, the metric data will be segmented in the order the dimensions are listed in the parameter.
**`top`**: The number of segments to return. This value is only valid when segment is specified.
`order_by`: The aggregation function and direction to sort the segments by. This value is only valid when segment is specified.
`filter`: An expression used to filter the results. This value should be a valid OData filter expression where the keys of each clause should be applicable dimensions for the metric you are retrieving.
Example configuration:
```json
- id: ["requests/count", "requests/failed"]
segment: "request/name"
aggregation: ["sum"]
```
## [Additional notes about metrics and costs](https://www.elastic.co/docs/reference/integrations/azure_application_insights/app_insights#additional-notes-about-metrics-and-costs)
Costs: Metric queries are charged based on the number of standard API calls. More information on pricing here [https://azure.microsoft.com/en-us/pricing/details/monitor/](https://azure.microsoft.com/en-us/pricing/details/monitor/).
Example:
```json
{
"@timestamp": "2021-08-23T14:37:42.268Z",
"agent": {
"ephemeral_id": "4162d5df-ab00-4c1b-b4f3-7db2e3b599d4",
"hostname": "docker-fleet-agent",
"id": "d979a8cf-ddeb-458f-9019-389414e0ab47",
"name": "docker-fleet-agent",
"type": "metricbeat",
"version": "7.15.0"
},
"azure": {
"app_insights": {
"end_date": "2021-08-23T14:37:42.268Z",
"start_date": "2021-08-23T14:32:42.268Z"
},
"application_id": "42cb59a9-d5be-400b-a5c4-69b0a0026ac6",
"dimensions": {
"request_name": "GET Home/Index",
"request_url_host": "demoappobs.azurewebsites.net"
},
"metrics": {
"requests_count": {
"sum": 4
}
}
},
"cloud": {
"provider": "azure"
},
"data_stream": {
"dataset": "azure.app_insights",
"namespace": "default",
"type": "metrics"
},
"ecs": {
"version": "8.11.0"
},
"elastic_agent": {
"id": "d979a8cf-ddeb-458f-9019-389414e0ab47",
"snapshot": true,
"version": "7.15.0"
},
"event": {
"agent_id_status": "verified",
"dataset": "azure.app_insights",
"duration": 503187300,
"ingested": "2021-08-23T14:37:41Z",
"module": "azure"
},
"host": {
"architecture": "x86_64",
"containerized": true,
"hostname": "docker-fleet-agent",
"id": "1642d255f9a32fc6926cddf21bb0d5d3",
"ip": [
"192.168.96.7"
],
"mac": [
"02-42-AC-1F-00-07"
],
"name": "docker-fleet-agent",
"os": {
"codename": "Core",
"family": "redhat",
"kernel": "4.19.128-microsoft-standard",
"name": "CentOS Linux",
"platform": "centos",
"type": "linux",
"version": "7 (Core)"
}
},
"metricset": {
"name": "app_insights",
"period": 300000
},
"service": {
"type": "azure"
}
}
```
##### **Please provide the following information to CyTech Support:**
# Azure Logs Integration
### **Introduction**
This document shows information related to Azure Active Directory Integration.
The Azure Logs integration retrieves different types of log data from Azure.
---
##### **Assumptions**
The procedures described in the **Requirements** section assumes that a Log Collector has already
been setup.
---
##### **Requirements**
**Main Setup**
- One or more **event hub** to store in-flight logs exported by Azure services and make them available to the Log Collector
- Example:
- ```
┌────────────────┐ ┌────────────┐
│ adlogs │ │ Log │
│ <> │─────▶ │ Collector │
└────────────────┘ └────────────┘
```
-
- One or more diagnostic setting to export logs from Azure services to Event Hubs
- Example:
- ```
┌──────────────────┐ ┌──────────────┐ ┌─────────────────┐
│Microsoft Entra ID│ │ Diagnostic │ │ Event Hub │
│ <> │─────▶│ settings │────▶│ <> │
└──────────────────┘ └──────────────┘ └─────────────────┘
```
- One **Storage Account Container** to store information about logs consumed by the Log Collector
- - Example: ```
┌────────────────┐ ┌────────────┐
│ adlogs │ logs │ Log │
│ <> │────────────────────▶│ Collector │
└────────────────┘ └────────────┘
│
consumer group info │
┌────────────────┐ (state, position, or │
│ azurelogs │ offset) │
│ <> │◀───────────────────────────┘
└────────────────┘
```
This is the final diagram of the a setup for collecting Activity logs from the Azure Monitor service.
```
┌───────────────┐ ┌──────────────┐ ┌────────────────┐ ┌────────────┐
│ MS Entra ID │ │ Diagnostic │ │ adlogs │ logs │ Log │
│ <> ├──▶│ Settings │──▶│ <> │────────▶│ Collector │
└───────────────┘ └──────────────┘ └────────────────┘ └────────────┘
│
┌──────────────┐ consumer group info │
│ azurelogs │ (state, position, or │
│<> │◀───────────────offset)──────────────┘
└──────────────┘
```
If the integration is running behind a firewall, please proceed [here](https://docs.cytechint.io/books/system-integrations/page/azure-logs-integration#bkmrk-additional-informati).
Here are several requirements before using the integration since the logs will
be read from azure event hubs.
1. **The logs have to be exported first to the event hub.**
• Create an event hub using Azure portal.
• More information can be found on: [https://learn.microsoft.com/en-us/azure/event-hubs/event-hubscreate](https://learn.microsoft.com/en-us/azure/event-hubs/event-hubscreate).
2. **To export activity logs to event hubs users can follow the steps here.**
• Legacy collection methods
• More information can be found on: [https://learn.microsoft.com/en-us/azure/azuremonitor/essentials/activity-log?tabs=powershell#legacy-collectionmethods](https://learn.microsoft.com/en-us/azure/azuremonitor/essentials/activity-log?tabs=powershell#legacy-collectionmethods)
3. **To export audit and sign-in logs to event hubs users can follow the**
**steps here.**
• Stream Azure Active Directory logs
• More information can be found on: [https://learn.microsoft.com/en-us/azure/active-directory/reportsmonitoring/tutorial-azure-monitor-stream-logs-to-event-hub](https://learn.microsoft.com/en-us/azure/active-directory/reportsmonitoring/tutorial-azure-monitor-stream-logs-to-event-hub)
---
##### **Azure Active Directory Integration Procedures**
**Create a Resource Group**
A resource group is a logical collection of Azure resources. All resources are
deployed and managed in a resource group. To create a resource group:
1. Sign in to the Azure portal.
2. In the left navigation, select R**esource groups**, and then
select **Create a resource**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/rfsoNqMpu79o1Qzu-image.png)
3. For **Subscription**, select the name of the Azure subscription in which
you want to create the resource group. For CyTech (**Azure Active Directory**) [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/ckfCmihQIfFGMIsU-image.png)
4. Type a unique **name for the resource group**. The system
immediately checks to see if the name is available in the currently
selected Azure subscription.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/5i62188380p2Jgmm-image.png)
5. Select a **region** for the resource group.
6. Select **Review + Create**.
7. Takes a few minutes to complete.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/Gra67tTYkLyxnftt-image.png)
---
##### **Create an Event Hubs Namespace**
An Event Hubs namespace provides a unique scoping container, in which you create
one or more event hubs. To create a namespace in your resource group using the
portal, do the following actions:
1. In the Azure portal, and select **Create a resource** at the top left of
the screen.
2. Select **All services** in the left menu, and select **star (\*)** next to **Event**
**Hubs** in the **Analytics** category. Confirm that **Event Hubs** is added
to **FAVORITES** in the left navigational menu.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/XWDbjYk9tyfO3fhx-image.png)
3. Select **Event Hubs** under **FAVORITES** in the left navigational menu, and
select **Create** on the toolbar.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/w7ko4IDcNBLGqh06-image.png)
4. On the **Create namespace** page, take the following steps:
a. Select the **subscription** in which you want to create the
namespace.
b. Select the **resource group** you created in the previous step.
c. Enter a **name** for the namespace. The system immediately checks to see if the name is available.[ ](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/xNSBSUX5yRgFSMz3-image.png)d. Select a **location** for the namespace.
e. Choose **Basic** for the **pricing tier**. To learn about differences
between tiers, see Quotas and limits, Event Hubs Premium, and Event
Hubs Dedicated articles.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/RCJf3TPjfd50URZh-image.png)f. Leave the **throughput units** (for standard tier) or **processing**
**units** (for premium tier) settings as it is. To learn about throughput units
or processing units: Event Hubs scalability.[ ](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/mGR1lyuUO6hUuJqe-image.png) g. Select **Review + Create** at the bottom of the page.
h. On the **Review + Create** page, review the settings, and select **Create**.
Wait for the deployment to complete.
5. On the **Deployment** page, select **Go to resource** to navigate to the page for
your namespace.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/wIRje6SGdDLveJNW-image.png)
---
##### **Create an Event Hub**
1. To create an event hub within the namespace, do the following actions:
2. On the **Overview** page, select + **Event hub** on the command bar.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/9lig6swAM47b2QIl-image.png)
3. Type a name for your event hub, then select **Review + create**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/901pQZqZoPOl7tyb-image.png) The **partition count** setting allows you to parallelize consumption across
many consumers. For more information, see Partitions.
The **message retention** setting specifies how long the Event Hubs service
keeps data. For more information, see Event retention.
4. On the **Review + create** page, select Create.
5. You can check the status of the event hub creation in alerts. After the event
hub is created, you see it in the list of event hubs.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/gT6N5aMWn26OLM6p-image.png)
---
##### **Create a Diagnostic Setting**
The diagnostic settings export the logs from Azure services to a destination and in order to use Azure Logs integration, it must be an event hub.
To create a diagnostic settings to export logs:
1. Locate the diagnostic settings for the service (for example, Microsoft Entra ID).
2. Select diagnostic settings in the **Monitoring** section of the service. Note that different services may place the diagnostic settings in different positions.
3. Select **Add diagnostic settings**.
In the diagnostic settings page you have to select the source **log categories** you want to export and then select their **destination**.
#### Select log categories
Each Azure services exports a well-defined list of log categories. Check the individual integration doc to learn which log categories are supported by the integration.
#### [](https://www.elastic.co/guide/en/integrations/current/azure.html#azure-select-the-destination)Select the destination
Select the **subscription** and the **Event Hubs namespace** you previously created. Select the event hub dedicated to this integration.
Example:
```
┌───────────────┐ ┌──────────────┐ ┌───────────────┐ ┌────────────┐
│ MS Entra ID │ │ Diagnostic │ │ adlogs │ │ Log │
│ <> ├──▶│ Settings │──▶│ <> │─────▶ │ Collector │
└───────────────┘ └──────────────┘ └───────────────┘ └────────────┘
```
---
##### **Create a Storage Account**
To create an Azure storage account with the Azure portal, follow these steps:
1. From the left portal menu, select **Storage accounts** to display a list
of your storage accounts. If the portal menu isn't visible, click the
menu button to toggle it on.
2. On the **Storage accounts** page, select **Create**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/RFzieDne1Aq4juN8-image.png)
3. The following image shows a standard configuration of the basic properties[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/7igl0TMPuSppzHAD-image.png)
4. The following image shows a standard configuration of the advanced
properties for a new storage account. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/BFw71OHnlOV83PSy-image.png)
5. The following image shows a standard configuration of the networking
properties for a new storage account. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/71avFNEaMntF6jRM-image.png)
6. The following image shows a standard configuration of the data protection
properties for a new storage account.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/jwCOUksZo8SvpKmW-image.png)
7. The following image shows a standard configuration of the encryption
properties for a new storage account. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/8FXks1uCGDS2pTMw-image.png)
8. **Review + Create** **Tab**
When you navigate to the **Review + create** tab, Azure runs
validation on the storage account settings that you have chosen. If
validation passes, you can proceed to create the storage account.
If validation fails, then the portal indicates which settings need to be
modified.
The following image shows the **Review** tab data prior to the creation
of a new storage account.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/USS9JDQSW7IcMsco-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/wtihkFWZcmTOlVk0-image.png)
---
##### **Resources needed for the integration of Azure Active Directory:**
1. **Azure Diagnostics Settings**
Create a Diagnostics Configuration and select which log from
Azure will send to the event hub.
Navigate to **Microsoft Entra ID > Monitoring > Diagnostic settings**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/m3S6a24n5DflCDxH-image.png)
2. **Event Hub Credentials**
3. **Go to > EventHub Resources > Select Shared Access Policies**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/RRnRHDMhxYsar6W5-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/DTkVmvGA5zTUYYzT-image.png)
4. **Please provide CyTech the:**
a. Event Hubs Name Not the Name Space:
b. Connection string-primary key:
5. **Account Storage Credentials**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/aVuOpXD3kmp4nzYb-image.png)
6. **Please provide CyTech the:**
a. Storage Account Name:
b. Key 1 Key
---
#### **Running the integration behind a firewall:**
When you run the Elastic Agent behind a firewall, to ensure proper communication with the necessary components, you need to allow traffic on port `5671` and `5672` for the event hub, and port `443` for the Storage Account container.
```
┌────────────────────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ │ │ │ │ │
│ ┌────────────┐ ┌───────────┐ │ │ ┌──────────────┐ │ │ ┌───────────────┐ │
│ │ diagnostic │ │ event hub │ │ │ │azure-eventhub│ │ │ │ activity logs │ │
│ │ setting │──▶│ │◀┼AMQP─│ <> │─┼──┼▶│<>│ │
│ └────────────┘ └───────────┘ │ │ └──────────────┘ │ │ └───────────────┘ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ ┌─────────────┬─────HTTPS─┼──────────┘ │ │ │
│ ┌───────┼─────────────┼──────┐ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ ▼ ▼ │ │ └─Log Collector─────┘ └─Elastic Cloud─────┘
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 0 │ │ 1 │ │ │
│ │ │ <> │ │ <> │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ │ │
│ └─Storage Account Container──┘ │
│ │
│ │
└─Azure──────────────────────────┘
```
#### Event Hub
Port `5671` and `5672` are commonly used for secure communication with the event hub. These ports are used to receive events. By allowing traffic on these ports, the Elastic Agent can establish a secure connection with the event hub.
#### Storage Account Container
Port `443` is used for secure communication with the Storage Account container. This port is commonly used for HTTPS traffic. By allowing traffic on port 443, the Elastic Agent can securely access and interact with the Storage Account container, which is essential for storing and retrieving checkpoint data for each event hub partition.
#### DNS
Optionally, you can restrict the traffic to the following domain names:
\*.servicebus.windows.net
\*.blob.core.windows.net
\*.cloudapp.net
---
#### **Additional Information:**
##### **Azure Active Directory Logs contain**
**Sign-in logs** – Information about sign-ins and how your users use your
resources.
- Retrieves Azure Active Directory sign-in logs. The sign-ins report provides
information about the usage of managed applications and user sign-in
activities.
**Identity Protection logs** - Information about user risk status and the events
that change it.
- Retrieves Azure AD Identity Protection logs. The Azure AD Identity
Protection service analyzes events from AD users' behavior, detects risk
situations, and can respond by reporting only or even blocking users at
risk, according to policy configurations.
**Provisioning logs** - Information about users and group synchronization to
and from external enterprise applications.
- Retrieves Azure Active Directory Provisioning logs. The Azure AD
Provisioning service syncs AD users and groups to and from external
enterprise applications. For example, you can configure the provisioning
service to replicate all existing AD users and groups to an external
Dropbox Business account or vice-versa.
**The Provisioning Logs contain a lot of details about a inbound/outbound**
**sync activity, like:**
- User or group details.
- Source and target systems (e.g., from Azure AD to Dropbox).
- Provisioning status.
- Provisioning steps (with details for each step).
**Audit logs** – Information about changes to your tenant, such as users and
group management, or updates to your tenant's resources.
- Retrieves Azure Active Directory audit logs. The audit logs provide
traceability through logs for all changes done by various features within
Azure AD. Examples of audit logs include changes made to any resources
within Azure AD like adding or removing users, apps, groups, roles and
policies.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# BitDefender Integrations
BitDefender GravityZone supports SIEM integration using "push notifications", which are JSON messages sent via HTTP POST to a HTTP or HTTPS endpoint, which this integration can consume.
**This integration additionally provides:**
1. Collection of push notification configuration via API polling, which includes the "state" of the push notification service on the BitDefender GravityZone server, e.g. indicating if it is currently enabled or disabled. This is useful as the state may change to disabled (value of 0) for unknown reasons and you may wish to alert on this event.
2. Collection of push notification statistics via API polling, which includes the number of events sent, and counters for errors of different types, which you may wish to use to troubleshoot lost push notification events and for alerting purposes.
3. Support for multiple instances of the integration, which may be needed for MSP/MSSP scenarios where multiple BitDefender GravityZone tenants exist.
4. BitDefender company ID to your own company name/description mapping, in order to determine to which tenant the event relates to in a human friendly way. This is very useful for MSP/MSSP environments or for large organizations with multiple sub-organizations.
This allows you to search, observe and visualize the BitDefender GravityZone events through Elastic, trigger alerts and monitor the BitDefender GravityZone Push Notification service for state and errors.
---
#### **Data Stream**
##### **Log Stream Push Notifications**
The BitDefender GravityZone events dataset provides events from BitDefender GravityZone push notifications that have been received.
All BitDefender GravityZone log events are available in the `bitdefender_gravityzone.events` field group.
---
#### **Compatibility**
This integration supports BitDefender GravityZone, which is the business-oriented product set sold by BitDefender.
BitDefender products for home users are not supported.
The package collects BitDefender GravityZone push notification transported events sent in `jsonrpc`, `qradar`, or `splunk` format.
The `jsonrpc` format is recommended default, but the ingest pipeline will attempt to detect if `qradar` or `splunk` format events have been received and process them accordingly.
The integration can also collect the push notification configuration and statistics by polling the BitDefender GravityZone API.
---
#### **Configuration**
##### [](https://www.elastic.co/docs/current/integrations/bitdefender#enabling-the-integration-in-elastic)**Enabling the integration in Elastic**
1. In Kibana go to **Management > Integrations**
2. In "Search for integrations" search bar type **GravityZone**
3. Click on "BitDefender GravityZone" integration from the search results.
4. Click on **Add BitDefender GravityZone** button to add BitDefender GravityZone integration.
##### **Create a BitDefender GravityZone API key that can configure a push notification service**
The API key needed to configure push notifications, and collection push notification configuration state and statistics, is typically configured within the BitDefender GravityZone cloud portal.
Bear in mind the API key will be associated to the account you create it from. A named human account may not be desirable, e.g. you may wish to (probably should) create API keys for functions such as push notifications under a non-human/software service account that will never retire or be made redundant.
Navigate to your account details within the GravityZone portal. If you have sufficient privileges, you will see the "API keys" section near the bottom of the page. Click "Add" here.
Give the API key a description and tick the "Event Push Service API" box at minimum.
**NOTE:** If you intend to use the API key for other API calls you may need to tick other boxes.
Click the Key value that is shown in blue.
Click the clipboard icon to copy the API key to your PC's clipboard.*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
##
# Bitwarden Integrations
#### **Overview**
The Bitwarden integration allows users to monitor collections, events, groups, members and policies. Bitwarden is a free and open-source password management service that stores sensitive information such as website credentials in an encrypted vault. The Bitwarden platform offers a variety of client applications including a web interface, desktop applications, browser extensions, mobile apps and a command-line interface. Bitwarden offers a cloud-hosted service as well as the ability to deploy the solution on-premises.
Use the Bitwarden integration to collect and parse data from the REST APIs. Then visualize that data in Kibana.
---
#### **Data streams**
The Bitwarden integration collects five types of data: Collections, Events, Groups, Members and Policies.
**Collections** returns a list of an organization's collections.
**Events** returns a list of an organization's event logs.
**Groups** returns a list of an organization's groups.
**Members** returns the details of an organization's members.
**Policies** returns a list of an organization's policies.
*Reference for [Rest APIs](https://bitwarden.com/help/api/) of Bitwarden.*
---
#### **Requirements**
Elasticsearch is needed to store and search data and Kibana is needed for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your hardware.
This module has been tested against **Bitwarden Version 2023.2.0**.
---
#### **Setup**
##### **To collect data from Bitwarden REST APIs, follow the below steps:**
1. Go to the Bitwarden console, enter an email address and master password.
2. Click **Organizations**.
3. Go to **Settings → Organization info**.
4. Click **View API Key** from API key Section.
5. Enter master password.
6. Click **View API Key**.
7. Copy **client\_id** and **client\_secret**.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Cato Networks - Configuring Event Log Forwarding with Two Windows Servers
#### How to Configure Windows Event Forwarding for User Awareness
Cato Networks’ User Awareness feature usually imports the audit log events directly from the Domain Controller (DC). These log events are shown in the Event Discovery window in the Cato Management Application. Some organizations prefer to forward these events from the DC (the forwarder) to another windows server (the collector) and configure the User Awareness to import the logs from that server.
The following diagram is a sample of Windows Event Forwarding (WEF) with 2 servers: one server is the DC that acts as the forwarder and the second server is the collector. The collector pulls the security events from the forwarder. The Cato PoP imports these events from the collector and shows them in the Cato Management Application.
This article explains how to configure WEF on Windows server.
## Configuring Event Log Forwarding with Two Windows Servers
**Prerequisites:**
Two windows server (2016 or later) instances:
- Forwarder with active directory
- Collector
**To configure the event log forwarding:**
- Configure the Collector
- Configure the Forwarder
### Configuring the Event Log Collector
This section describes how to configure the windows server instance as the collector. The collector is the server that pulls the event logs from the forwarder server (DC).
#### Enabling the Windows Remote Management (WinRM)
Windows Remote Management (WS-Management) is a Microsoft service that allow forwarding the events to the collector. This service is automatically running by default, if not, set the service configuration with status: running and startup type: automatically.
#### Enabling the PowerShell Remoting
Open the Windows PowerShell console and run the command: **Enable-****PSRemoting**to enable the PowerShell Remote service. You can verify that the PSRemoting is enabled by running the command: **Invoke-Command -****ComputerName**<COLLECTORHOSTNAME> **-****ScriptBlock****{1}**. If you don’t receive an error, then the service is running.
#### Starting the Subscription Collector Service
To start the subscription:
1. Open the Event Viewer and click on **Subscription****.**
2. A popup window appears, Click **Yes** to confirm the service to run automatically.
3. Right Click select **Create Subscription****.**
4. Add a Subscription name.
5. In the Destination log, select **ForwardedEvents****.**
6. Under Subscription type and source computers, select **Collector initiated****.**
7. Click Select Computers and enter the Forwarder hostname and click OK to apply. If you have multiple DCs, add them to the list.
8. Click on **Select Events** and verify that Event level: Information is selected.
9. Select By logs and choose the Security Events Logs.
10. To reduce many events, we recommend that you add the Event IDs that Cato uses for the User Awareness: 4768,4769,4770,4624,5145,5140,4625,4647,4608
The following screenshot shows a sample of a Subscription Properties window:
#### Configuring the Forwarded Events Log File
To configure the forwarded events file to use the security events:
1. Open the Event Viewer and navigate to Windows Logs > **ForwardedEvents**
2. Right click on **ForwardedEvents** and click on Properties
3. Change the Log path to the %..\\Security.evtx file and click **OK**
### Configuring the Forwarder (DC)
This section describes how to configure the DC as the forwarder.
#### Allowing Read Permissions to the Security Event Log
Open the Windows PowerShell console and run the command: **wevtutil****gl****security**. This command provides information about the Security event log. Copy the **channelAccess** string.
#### Configuring the Group Policy Management for the Forwarder
- Go to **Server Manger > Tools > Group Policy Management >****Domains >****Domain Controller****s** and click on **Default Domain Controller****s****Policy**. Right Click and click Edit, when the Default Domain Controllers Policy window opens, navigate to ***Computer Configuration*** **→** ***Policies*** **→** ***Administrative Templates*** **→** ***Windows Components*** **→** ***Event Forwarding*** **→** ***Configure target******S******ubscription******M******anager****and* Set the value for the target subscription manager: ***Server=http://<****FQDN of the collector****>:5985/******wsman******/******SubscriptionManager******/******WEC,Refresh******=60***
The following screenshot shows an example of a Subscription Manager for the “MyCollector” server.
2\. Navigate to **Computer Configuration → Policies → Administrative Templates → Windows Components → Event Log Service → Security → Configure log access** select **Enabled** and paste the **channelAccess** string from the [section](https://support.catonetworks.com/hc/en-us/articles/360013279817-How-to-Configure-Windows-Event-Forwarding-for-User-Awareness#UUID-8f3f3e2d-5f81-dc36-4214-6dc0e2b8f27f_N1692081505677 "Starting the Subscription Collector Service") above in the Log Access pane.
The following screenshot shows an example of log access configuration with the channelAccess value:
#### Adding the Network Service into the Event Log Readers Group
Go to **Server Manger > Tools >****Active Directory Users and Computers****>****<****Domain****name>****Builti****n**, Right click on **Event Log Readers** group and click Properties. when the window opens, go to Members tab and add the Network Service account and click OK.
Open the command line and run the command **gpupdate****/force**to update the GPO. Changes to this group require a restart for WinRM to apply the changes.
### Checking the Event Log Forwarding
When you complete the collector and the forwarder configuration, go to the Collector server and open the Event Viewer and navigate to **Windows Logs > Forwarded Events**. Make sure that you can see the events in this section.
Source: [https://support.catonetworks.com/hc/en-us/articles/360013279817-How-to-Configure-Windows-Event-Forwarding-for-User-Awareness](https://support.catonetworks.com/hc/en-us/articles/360013279817-How-to-Configure-Windows-Event-Forwarding-for-User-Awareness)If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.
# Cato Networks - Using Cato API for ELK Stack Integration
To fully integrate the Cato Networks API with the Elastic Stack (ELK Stack), you can follow this comprehensive process. This guide will cover the necessary steps to collect, transform, and visualize data from Cato Networks using the Elastic Stack.
#### **Step 1: Understand the Cato Networks API**
- API Documentation: Begin by reviewing the Cato Networks API documentation to understand the available endpoints, authentication methods, and data formats. This will help you determine which data you want to ingest into the Elastic Stack.
#### **Step 2: Set Up Logstash for Data Collection**
- Install Logstash: Ensure that Logstash is installed and running in your environment. You can download it from the \[Elastic Downloads\](*https://www.elastic.co/downloads/logstash*) page.
- Configure Logstash: Create a Logstash configuration file to collect data from the Cato API. Use the HTTP Poller input plugin to make requests to the API.
Example Logstash configuration (cato\_logstash.conf):
- Run Logstash: Start Logstash with the configuration file:
bin/logstash -f cato\_logstash.conf
#### **Step 3: Transform Data with Logstash Filters**
- Data Transformation: Use Logstash filters to parse and transform the data as needed. This might include parsing JSON fields, renaming fields, or converting data types.
Example filter configuration:
#### **Step 4: Index Data in Elasticsearch**
- Elasticsearch Setup: Ensure that Elasticsearch is running and accessible. You can download and install it from the \[Elastic Downloads\](*https://www.elastic.co/downloads/elasticsearch*) page.
- Index Configuration: Make sure your Elasticsearch index is configured to handle the data structure from the Cato API. You may need to define index mappings to specify data types.
#### **Step 5: Visualize Data with Kibana**
- Kibana Setup: Ensure that Kibana is installed and running. You can download it from the \[Elastic Downloads\](*https://www.elastic.co/downloads/kibana*) page.
- Create Visualizations: Use Kibana to create visualizations and dashboards based on the data indexed in Elasticsearch. This will allow you to analyze and monitor the data from Cato Networks.
- Access Kibana through your web browser.
- Navigate to the "Discover" tab to explore the ingested data.
- Use the "Visualize" tab to create charts and graphs.
- Build dashboards in the "Dashboard" tab to combine multiple visualizations.
#### **Step 6: Secure the Integration**
- Authentication: Ensure that you securely handle authentication when accessing the Cato API. Use API keys or tokens as required by the API.
- Secure Communication: Use HTTPS to encrypt data in transit between Logstash, Elasticsearch, and Kibana.
Additional Resources
\- \[Logstash HTTP Poller Input Plugin\](*https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http\_poller.html*)
\- \[Elasticsearch Documentation\](*https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html*)
\- \[Kibana Documentation\](*https://www.elastic.co/guide/en/kibana/current/index.html*)
If you encounter any issues or have specific questions during the integration process, feel free to ask for further assistance.
# CATO Networks API Integration
#### **1. Overview**
**Cato Networks** is a cloud-native Secure Access Service Edge (SASE) platform that converges networking and security into a single, unified service. It provides SD-WAN, secure internet access, zero-trust network access, and advanced threat protection over a global private backbone, simplifying operations and enhancing security and performance for organizations.
#### **2. Vendor configuration**
In this configuration, you will set up the Cato Networks API Key and Account ID parameter to access the Cato networks API.
- In the Cato Management Application, only account administrators with the **Editor** privilege can generate keys. (CMA).
- To ingest security events, you must enable the events feeds on your account. To enable the events feed, follow the steps below:
1. In the navigation panel, select **System > API Access Management**.
2. Select **Event Feed Enabled**. After this, your account starts sending events to the Cato API server.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/CCRdEQ05uuymb9fl-image.png)
#### **3. API Key**All access to Cato networks requires an API Key. Follow the below instructions to set up an API Key.
1. In the navigation menu, click **Administration > API Management**.[ ](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/c4u0oIDSbEqZXVpB-image.png) 2. On the **API Keys** tab, click **New**. The **Create API Key** panel opens. 3. Enter a **Key Name**.[ ](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/ireVyydZcNnD5pp3-image.png)4. Select **View** in the **API Permission**.5. Select **Any IP** to allow this API key for any IP address under the **Allow Access from IPs** section.6. (Optional) Select a date when the API key expires. If you select an expiration date, then you need to update the source configuration with a new API key, or else an unauthorized error will be received.7. Click **Apply**. The API key is added, and a pop-up window containing the new API key is displayed.8. Copy the API Key generated by the Cato Management Application and save it in a secure location.
Note: The API key value will not be available after closing this window. Kindly ensure that you copy and securely save the API key before closing the window.
9. Click **OK** to close the pop-up window.Reference link: [https://support.catonetworks.com/hc/en-us/articles/4413280536081-Generating-API-Keys-for-the-Cato-API](https://support.catonetworks.com/hc/en-us/articles/4413280536081-Generating-API-Keys-for-the-Cato-API)
#### **4. Build a Collector to Pull Events**Elastic doesn’t natively support Cato, but you can use: **Logstash**You need to create a **Logstash pipeline**. ***Install Logstash if not already.***
##### **Step 1:** ***Install Logstash On Linux (Ubuntu/Debian example)***
```
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
sudo apt-get install apt-transport-https
echo "deb https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt-get update
sudo apt-get install logstash
```
**Verify installation:**
```
logstash --version
```
##### **Step 2: Create Logstash Pipeline**
**2.1: Location**
Create file: /etc/logstash/conf.d/cato-pipeline.conf
**Pipeline Configuration:**
```
input {
http_poller {
urls => {
cato => {
method => post
url => "https://api.catonetworks.com/v1/graphql"
headers => {
"x-api-key" => "YOUR_CATO_API_KEY"
"Content-Type" => "application/json"
}
body => '{
"query": "query { eventsFeed { eventType eventTime eventDetails } }"
}'
}
}
request_timeout => 60
schedule => { cron => "* * * * *" }
codec => "json"
metadata_target => "http_poller_metadata"
}
}
filter {
if [data] {
mutate {
replace => { "[events]" => "%{[data][eventsFeed]}" }
}
split {
field => "[events]"
}
mutate {
add_field => {
"event_type" => "%{[events][eventType]}"
"event_time" => "%{[events][eventTime]}"
}
}
json {
source => "[events][eventDetails]"
target => "event_details"
}
date {
match => [ "event_time", "ISO8601" ]
target => "@timestamp"
}
mutate {
remove_field => [ "data", "events", "[events][eventDetails]", "http_poller_metadata" ]
}
}
}
output {
elasticsearch {
hosts => [ "http://localhost:9200" ]
index => "cato-events-%{+YYYY.MM.dd}"
user => "elastic"
password => "your_elastic_password"
}
stdout {
codec => rubydebug
}
}
```
**Replace:**
- `YOUR_CATO_API_KEY` with your Cato API key
- Elastic credentials (user, password, host)
##### **Step 3: Test the Pipeline****Run syntax test:**
```
sudo /usr/share/logstash/bin/logstash --path.settings /etc/logstash -t
```
✅ You should see: Configuration OK
##### **Step 4: Start Logstash**
```
sudo systemctl start logstash
sudo systemctl enable logstash
```
**Check logs:**
```
sudo journalctl -u logstash -f
```
##### **Step 5: Verify Data in Kibana**
- **Open Kibana: http://<your-server>:5601**
- **Log in**
- **Go to: Stack Management → Data Views → Create data view**
- **Name****:**
- ```
cato-events-*
```
- **Save**Then go to **Discover**, select the new data view, and explore your Cato event logs!
# Cisco AMP for Endpoints API Integration
To integrate **Cisco AMP for Endpoints (now part of Cisco Secure Endpoint)** with **Elastic, follow these general steps:**
##### **Get Cisco AMP API Credentials**
You need to enable API access from the Cisco Secure Endpoint console.
- Log in to: https://console.amp.cisco.com
- Go to **Accounts > API Credentials**
- Click **Create API Credential**
- Choose **"Read & Write"** or at minimum **"Read-only"**
- Save:
- `Client ID`
- `API Key`
These will be used to pull events from the AMP API.
##### **Integrate on AQUILA**
1. Log in to **[CyTech - AQUILA](https://cytechint.io/)**. Choose **Cyber Monitoring** and click the **small arrow icon** to redirect you to the Cyber Monitoring Dashboard.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/gJqiCpD7Puwe6BCH-image.png)
2\. In the dashboard, choose **Cyber Incident Management (SIEM and XDR)**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/ChCabqtdB7BToc5C-image.png)
3\. Navigate through the leftmost top and click **Cyber Incident Monitoring**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/QUgb4SjtLXECWANE-image.png)
4\. Navigate through **Settings>Log Source>Search Bar>Add to Agent**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/Vfi4seGvDtckCMPv-cisco-secure-endpoint.png)
5\. Choose your **Log Collector**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/fd6dcSQhfh3hAxT3-image.png)
6\. In the integration settings follow the instructions given below.
1. Click the **drop arrow** to display the contents. Make sure the Collect logs from the Cisco Secure Endpoint API is **Enabled.**
2. Click the other **drop arrow** to display the other contents needed for the integration setup. Input the Client ID and the API Key.
3. **Scroll down,** leave the other text fields to its default value and go to **Tags.** Click the **Tags** text field and add **cisco-secure\_endpoint** and **forwarded.**
4. Finally, click **Next** to install the log source integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/8tUOUxwRGHIZzxxC-cisco-secure-endpoint2.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/uC8vMozRsBzHWoP6-cisco-secure-endpoint3.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/bhVAJJmfjb38Sqrl-cisco-secure-endpoint4.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/J5ZhAhpkaH46xRxW-cisco-secure-endpoint5.png)
7\. Wait for the **Successfull** window to display, this will confirm the successfull integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/bPXsUbIJSaGHmL83-image.png)
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# Cisco Meraki - Configuring a Syslog Server
#### **Method 1: Using GUI**
##### **Configure log forwarding**
1. Sign in to the **[Meraki Dashboard](https://account.meraki.com/secure/login/dashboard_login)** with administrator permissions.
2. If your account is a member of multiple organizations, select the organization that you want to configure in the **Organization** list.
3. In the **Network** list, select the network that you want to configure.
4. In the navigation menu, click **Network-wide** > **Configure** > **General**.
5. In the **Reporting** section, click **Add a syslog server**.
6. In the **Syslog servers** table, configure these settings:
- **Server IP** - Enter the IP address of your Syslog Server.
- **Port** - the default UDP port value of 514.
- **Roles -** Select **Security events**, **Flows**, and **URL**.
7. In the **Traffic Analysis** section, select **Detailed: collect destination hostnames**.
8. Click **Save**.
9. In the navigation menu, click **Security & SD-WAN > Firewall**.
10. In the **Layer 3** section, mark the **Syslog** checkbox for every rule.
11. Click **Save**.
#### **Method 2 : Linux System**
##### **Step 1: Install the syslog application:**sysadmin@ubuntu:~$ **sudo apt-get install syslog-ng******Once syslog-ng has been installed it needs to be configured to receive log messages from the MX. These instructions will configure syslog-ng to store each of the role categories in their own log file. There will be an individual log file for URLs, Event Logs, etc. Alternatively, it could be configured to store all logs in one file. Use any appropriate editor to make changes to the syslog-ng configuration file. In this example nano is used to edit the file.sysadmin@ubuntu:~$ **sudo nano /etc/syslog-ng/syslog-ng.conf******The LAN IP of the MX in this example will be 192.168.10.1. The syslog server is listening on 192.168.10.241 UDP port 514. Update as needed to reflect the LAN IP of the MX and the syslog server being configured. The first section of code will configure all syslog messages from the MX to be stored in /var/log/meraki.log. The second section of code will use regular expressions to match each of the role categories and store them in individual log files. Only one of the options needs to be configured.
##### **Step 2: Log all messages to /var/log/meraki.log:**\#define syslog source**source s\_net { udp(ip(192.168.10.241) port(514)); };**\#create filter to match traffic (this filter will catch all syslog messages that come from the MX**filter f\_meraki{ host( "192.168.10.1" ); };**\#define a destination for the syslog messages**destination df\_meraki{ file("/var/log/meraki.log"); };**\#bundle the source, filter, and destination rules together with a logging rule**log { source ( s\_net ); filter( f\_meraki ); destination ( df\_meraki ); };**
##### **Step 3: Restart the syslog-ng process:**
sysadmin@ubuntu:~$ **sudo /etc/init.d/syslog-ng restart******
*Source: [https://documentation.meraki.com/General\_Administration/Monitoring\_and\_Reporting/Syslog\_Server\_Overview\_and\_Configuration#Configuring\_a\_Syslog\_Server](https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration#Configuring_a_Syslog_Server)*
#### **Cisco Meraki - Configuring a Syslog Server Integration Procedures **
##### Please provide the following information to CyTech: Requirements:Collect logs via syslog over UDP or TCP
\*Listen Address-> Syslog Collector IP address where the Elastic-Agent is installed
\*Listen Port-> Port Number (Please identify if TCP or UDP)If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.
# CISCO Meraki Integrations
##### **Introduction**Cisco Meraki offers a centralized cloud management platform for all Meraki devices such as MX Security Appliances, MR Access Points and so on. Its out-of-band cloud architecture creates secure, scalable, and easy-to-deploy networks that can be managed from anywhere. This can be done from almost any device using web-based Meraki Dashboard and Meraki Mobile App. Each Meraki network generates its own events.
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### **Compatibility**A syslog server can be configured to store messages for reporting purposes from MX Security Appliances, MR Access Points, and MS switches. This package collects events from the configured syslog server. The integration supports collection of events from "MX Security Appliances" and "MR Access Points". The "MS Switch" events are not recognized.
##### **Requirements**
**Cisco Meraki Dashboard Configuration**
**SYSLOG**Cisco Meraki dashboard can be used to configure one or more syslog servers and Meraki message types to be sent to the syslog servers. Refer to Syslog Server Overview and Configuration page for more information on how to configure syslog server on Cisco Meraki.**API ENDPOINT (WEBHOOKS)**Cisco Meraki dashboard can be used to configure Meraki webhooks. Refer to the Webhooks Dashboard Setup section.
**Configure the Cisco Meraki integration**
**SYSLOG**Depending on the syslog server setup in your environment check one/more of the following options "Collect syslog from Cisco Meraki via UDP", "Collect syslog from Cisco Meraki via TCP", "Collect syslog from Cisco Meraki via file".Enter the values for syslog host and port OR file path based on the chosen configuration options.**API Endpoint (Webhooks)**Check the option "Collect events from Cisco Meraki via Webhooks" option.
1. Enter values for "Listen Address", "Listen Port" and "Webhook path" to form the endpoint URL. Make note of the Endpoint URL https://{AGENT\_ADDRESS}:514/meraki/events.
2. Enter value for "Secret value". This must match the "Shared Secret" value entered when configuring the webhook from Meraki cloud.
3. Enter values for "TLS". Cisco Meraki requires that the webhook accept requests over HTTPS. So you must either configure the integration with a valid TLS certificate or use a reverse proxy in front of the integration.
##### **Log Events**Enable to collect Cisco Meraki log events for all the applications configured for the chosen log stream.
**Logs**
**Syslog**
The cisco\_meraki.log dataset provides events from the configured syslog server. All Cisco Meraki syslog specific fields are available in the cisco\_meraki.log field group.
**API Endpoint (Webhooks)**
##### **Cisco Meraki Integration Procedures**Please provide the following information to CyTech:
1. Collect syslog from Cisco Meraki via UDP
- Listen Address - The bind address to listen for UDP connections. Set to 0.0.0.0 to bind to all available interfaces.
- Listen Port - The UDP port number to listen on.
2. Collect syslog from Cisco Meraki via TCP
- Listen Address - The bind address to listen for TCP connections. Set to 0.0.0.0 to bind to all available interfaces.
- Listen Port - The UDP port number to listen on.
3. Collect syslog from Cisco Meraki via file
- Paths
4. Collect syslog from Cisco Meraki via Webhooks
- Listen Address - Bind address for the listener. Use 0.0.0.0 to listen on all interfaces.
- Listen Port
- Secret Value
# Cisco Meraki via Syslog
1. **Login to Cisco Meraki Dashboard**:
- Go to the **Meraki Dashboard** and log in with your credentials.
2. **Navigate to Alerts & Administration**:
- Go to **Network-wide** → **Alerts & Administration**.
3. **Set up Syslog Server**:
- Under the **Alert recipients** section, select **Syslog** as the alert recipient.
- Add the IP address and port of the Syslog server where the alerts should be sent.
- Example Syslog Server IP: `10.0.0.1` (Replace this with your server IP)
- Example Port: `514` (Standard Syslog port)
4. **Enable Relevant Alerts**:
- Enable the types of alerts you want Meraki to send, such as security events, device status, and network performance issues.
**Guide Links**:
[Meraki Device Reporting - Syslog, SNMP, and API - Cisco Meraki Documentation](https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Device_Reporting_-_Syslog%2C_SNMP%2C_and_API)
# CISCO Nexus Integrations
#### **Overview**
The Cisco Nexus integration allows users to monitor Errors and System Messages. The Cisco Nexus series switches are modular and fixed port network switches designed for the data center. All switches in the Nexus range run the modular NX-OS firmware/operating system on the fabric. NX-OS has some high-availability features compared to the well-known Cisco IOS. This platform is optimized for high-density 10 Gigabit Ethernet.
Use the Cisco Nexus integration to collect and parse data from Syslog and log files. Then visualize that data through search, correlation and visualization within Elastic Security.
---
#### **Data streams**
The Cisco Nexus integration collects one type of data: log.
**Log** consists of errors and system messages. See more details about errors and system messages
---
#### **Requirements**
Elastic Agent must be installed.
The minimum **kibana.version** required is **8.7.0**.
This module has been tested against the **Cisco Nexus Series 9000, 3172T and 3048 Switches**.
---
#### **Setup**
##### **To collect data from Cisco Nexus, follow the below steps:**
##### **Logging System Messages to a File**
You can configure the device to log system messages to a file. By default, system messages are logged to the file /logflash/log/logfilename .
Configures the nonpersistent log file parameters.
logfile-name : Configures the name of the log file that is used to store system messages. Default filename is "message".
severity-level : Configures the minimum severity level to log. A lower number indicates a higher severity level. Default is 5. Range is from 0 through 7:
- 0 – emergency
- 1 – alert
- 2 – critical
- 3 – error
- 4 – warning
- 5 – notification
- 6 – informational
- 7 – debugging
sizebytes : Optionally specify maximum file size. Range is from 4096 through 4194304 bytes.
Logs interface events.
- link-status —Logs all UP/DOWN and CHANGE messages.
- trunk-status —Logs all TRUNK status messages.
- enable —Specifies to enable logging to override the port level configuration.
- default —Specifies that the default logging configuration is used by interfaces that are not explicitly configured.
---
#### **Configuring Syslog Servers**
**Note:** Cisco recommends that you configure the syslog server to use the management virtual routing and forwarding (VRF) instance. For more information on VRFs, see Cisco Nexus 9000 Series NX-OS Unicast Routing Configuration Guide.
You can configure up to eight syslog servers that reference remote systems where you want to log system messages.
#### Procedure
\[no\] logging serverhost \[severity-level \[use-vrfvrf-name\]\]
#### Example:
```
switch(config)# logging server 192.0.2.253
```
#### Example:
```
switch(config)# logging server 2001::3 5 use-vrf red
```
Configures a syslog server at the specified hostname, IPv4, or IPv6 address. You can specify logging of messages to a particular syslog server in a VRF by using the use-vrf keyword. The use-vrfvrf-name keyword identifies the default or management values for the VRF name. The default VRF is the management VRF, by default. However, the show-running command will not list the default VRF. Severity levels range from 0 to 7:
- 0 – emergency
- 1 – alert
- 2 – critical
- 3 – error
- 4 – warning
- 5 – notification
- 6 – informational
- 7 – debugging
The default outgoing facility is local7.
The no option removes the logging server for the specified host.
The first example forwards all messages on facility local 7. The second example forwards messages with severity level 5 or lower to the specified IPv6 address in VRF red.
Enables a source interface for the remote syslog server. The range for the virtual-interface argument is from 0 to 1023.
**NOTE:**
- Use the Timezone Offset parameter, if the timezone is not present in the log messages.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# CISCO Secure Email Gateway Integrations
The **Cisco Email Security Appliance (ESA)** integration is a comprehensive solution for managing and securing email traffic within an organization's network. It provides various functionalities, such as **spam filtering**, **virus scanning**, **policy enforcement**, and **data loss prevention**. The integration collects and parses data from the **Cisco Secure Email Gateway** (formerly known as **Cisco Email Security Appliance**) to provide valuable insights into the email environment. The data collection occurs through multiple methods, primarily through **TCP/UDP communication** and **log file analysis**.
---
#### **Requirements:**
- Cisco account
- Elastic agent already installed
---
#### **Compatibility**
This module has been tested against **Cisco Secure Email Gateway server version 14.0.0 Virtual Gateway C100V with the below given logs pattern**.
[](https://www.elastic.co/docs/current/integrations/cisco_secure_email_gateway#configurations)
---
#### **Setup**
##### **Configurations**
- Sign-in to Cisco Secure Email Gateway Portal and follow the below steps for configurations:
1. In Cisco Secure Email Gateway Administrator Portal, go to **System Administration** > **Log Subscriptions**.
2. Click **Add Log Subscription**.
3. Enter all the **Required Details**.
4. Set **Log Name** as below for the respective category:
- AMP Engine Logs -> amp
- Anti-Spam Logs -> antispam
- Antivirus Logs -> antivirus
- Authentication Logs -> authentication
- Bounce Logs -> bounces
- Consolidated Event Logs -> consolidated\_event
- Content Scanner Logs -> content\_scanner
- HTTP Logs -> gui\_logs
- IronPort Text Mail Logs -> error\_logs
- Text Mail Logs -> mail\_logs
- Status Logs -> status
- System Logs -> system
5. Select **Log Level** as Information.
6. Select **Retrieval Method**.
7. Click **Submit** and commit the Changes.
##### [](https://www.elastic.co/docs/current/integrations/cisco_secure_email_gateway#note)**Note**
- **Retrieval Method** Supported:
- **FTP Push to Remote Server** for the below categories: AMP Engine Logs, Anti-Spam Logs, Antivirus Logs, Authentication Logs, Bounce Logs, Consolidated Event Logs, Content Scanner Logs, HTTP Logs, IronPort Text Mail Logs, Text Mail Logs, Status Logs and System Logs.
- **Syslog Push** for the below categories: AMP Engine Logs, Anti-Spam Logs, Antivirus Logs, Consolidated Event Logs, Content Scanner Logs, HTTP Logs, IronPort Text Mail Logs, Text Mail Logs, Status Logs and System Logs.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# CISCO Secure Endpoint - Secure Endpoint API
#### **Authentication**
The Secure Endpoint API requires access via an authenticated and authorized account. Only authorized accounts are able to submit requests to API operations. All operations must communicate over a secure HTTPS connection.
To authenticate and access the Secure Endpoint API, perform the following:
**1. Integrate Secure Endpoint with Cisco XDR or Secure Client Cloud Management.**
- Navigate to the Secure Endpoint console.
- Click the Integrate Now button on the Secure Endpoint Dashboard.
- This enables the integration between Secure Endpoint and Cisco XDR or Secure Client Cloud Management.
Integrate xdr :
- Navigate to the Cisco XDR or Secure Client Cloud Management console and verify the integration.
- Enable the Integration (Cisco XDR only)
- Navigate to Administration -> Integrations, then click + Enable
- Enable Secure Endpoint
**2. Register the API Client.**
- From within either Cisco XDR or Secure Client Cloud Management
- Navigate to Administration -> API Clients.
- On the API Clients page, click the Generate API Client button to open the Add New Client form.
- add new client form
- Enter a Client Name and select a Scope.
- Note: The Secure Endpoint API will work with any of the selected Scopes.
- The API Client will have the same permissions within Secure Endpoint as the creator of the API Client.
- Optionally, enter a Description and click Add New Client.
- The Client Id and Client Password are generated and will appear on the Add New Client form. api credential form
- Secure the Client ID and Client Password before closing the window. Copy and paste it properly.
**3. Generate an API Access Token.**
#### **Method 1: Linux**
Use the following OAuth2 token API to generate an API access token:
The Client-Id and Client-Password (Client-Secret per OAuth2) generated in the previous step are required to call the token endpoint.
Get an Access Token via the Token API:
\# Read in the client\_id and client\_secret if they are not already set.
\[ -z "$client\_id" \] && read -p "client\_id: " client\_id
\[ -z "$client\_secret" \] && read -p "client\_secret: " client\_secret
\# Call the token endpoint and store the result in a variable.
result=$(curl -s 'https://visibility.eu.amp.cisco.com/iroh/oauth2/token' \\
--user "${client\_id}:${client\_secret}" \\
--header 'Content-Type: application/x-www-form-urlencoded' \\
--header 'Accept: application/json' \\
-d 'grant\_type=client\_credentials')
\# Extract the access\_token from the result.
export BEARER\_TOKEN=$(echo "$result" | jq -r .access\_token)
\# Print the result.
\[ -x "$(command -v jq)" \] && echo "$result" | jq . || echo "$result"
The API access token generated in previous step is required to call the token endpoint.
Get and Access Token from the Secure Endpoint Token API:
\# Call the Secure Endpoint token endpoint and store the result in a variable.
result=$(curl -s 'https://api.amp.cisco.com/v3/access\_tokens' \\
--header 'Content-Type: application/x-www-form-urlencoded' \\
--header 'Accept: application/json' \\
--header "Authorization: Bearer $BEARER\_TOKEN" \\
-d 'grant\_type=client\_credentials')
\# Extract the access\_token from the result.
export BEARER\_TOKEN=$(echo "$result" | jq -r .access\_token)
\# Print the result.
\[ -x "$(command -v jq)" \] && echo "$result" | jq . || echo "$result"
Response:
{
"access\_token": "eyJhbGciO..."
}
5\. Access Secure Endpoint API.
The token generated in previous step is used to access the Secure Endpoint APIs.
Request:
\# Call the Secure Endpoint API and store the result in a variable.
result=$(curl -s 'https://api.amp.cisco.com/v3/organizations?size=10' \\
\--header "Authorization: Bearer ${BEARER\_TOKEN}")
\# Print the result.
\[ -x "$(command -v jq)" \] && echo "$result" | jq . || echo "$result"
#### **Method 2: Windows**
1\. Set Client ID and Client Secret
The script reads client\_id and client\_secret from the user if not set and uses them to request an OAuth2 token.
@echo off
REM Check if client\_id and client\_secret are set
if "%client\_id%"=="" set /p client\_id="Enter client\_id: "
if "%client\_secret%"=="" set /p client\_secret="Enter client\_secret: "
REM Call the OAuth2 token endpoint
curl -s -u "%client\_id%:%client\_secret%" ^
-H "Content-Type: application/x-www-form-urlencoded" ^
-H "Accept: application/json" ^
-d "grant\_type=client\_credentials" ^
https://visibility.amp.cisco.com/iroh/oauth2/token > token.json
REM Extract the access\_token using jq (ensure jq is installed)
for /f "delims=" %%A in ('jq -r ".access\_token" token.json') do set BEARER\_TOKEN=%%A
REM Output the token
echo OAuth2 Access Token: %BEARER\_TOKEN%
2\. Generate Secure Endpoint API Access Token
Use the token from the previous step to generate an API access token for Secure Endpoint.
@echo off
REM Call the Secure Endpoint token endpoint
curl -s -X POST ^
-H "Content-Type: application/x-www-form-urlencoded" ^
-H "Accept: application/json" ^
-H "Authorization: Bearer %BEARER\_TOKEN%" ^
-d "grant\_type=client\_credentials" ^
https://api.amp.cisco.com/v3/access\_tokens > endpoint\_token.json
REM Extract the access\_token using jq (ensure jq is installed)
for /f "delims=" %%A in ('jq -r ".access\_token" endpoint\_token.json') do set SECURE\_ENDPOINT\_TOKEN=%%A
REM Output the Secure Endpoint API token
echo Secure Endpoint API Access Token: %SECURE\_ENDPOINT\_TOKEN%
3\. Access the Secure Endpoint API
@echo off
REM Call the Secure Endpoint API
curl -s -X GET ^
-H "Authorization: Bearer %SECURE\_ENDPOINT\_TOKEN%" ^
https://api.amp.cisco.com/v3/organizations?size=10 > organizations.json
REM Output the API response
echo Secure Endpoint API Response:
type organizations.json
Key Notes:
Prerequisites:
- Install curl (default on Windows 10/11 or available via Chocolatey).
- Install jq for JSON parsing (available via jq).
- Save and Run:
- Save the script as a .bat file (e.g., get\_token.bat).
- Run the script in Command Prompt or PowerShell.
- Replace Region URLs:
- Use the appropriate region URL in the curl commands (e.g., North America, APJC, or Europe).
Source: https://developer.cisco.com/docs/secure-endpoint/authentication/#3-generate-an-api-access-token
# CISCO Secure Endpoint Integrations
##### **Introduction**Secure Endpoint offers cloud-delivered, advanced endpoint detection and response across multidomain control points to rapidly detect, contain, and remediate advanced threats.
##### **Assumptions**The procedures described in Section 3 assume that a Log Collector has already been setup.
##### **Requirements**
This integration is for Cisco Secure Endpoint logs. It includes the following datasets for receiving logs over syslog or read from a file:
- Log in to your AMP for Endpoints Console.
- Go to Accounts > Organization Settings.
- Click Configure API Credentials under Features to generate the Client ID and secure API Key.
##### **Logs**
**Secure Endpoint**
The event dataset collects Cisco Secure Endpoint logs.What can the Secure Endpoint API be used for?
- Generate a list of organizations a user has access to
- Generate a list of policies for a specified organization
- Generate specific information about a specified policy such as:
- - - - General policy data
- Associated network control lists
- Associated computers
- Associated groups
- Proxy settings
- Policy XML
- Generate all policy types and operating systems available for a specified organization
**Top Use Cases**
- Generating reports on policy settings across an organization
- Inspecting a particular policy's settings
- Querying to find policies matching certain criteria in order to detect which policies should be edited
**Response Format**
- Data
- Meta
- Errors
##### **Cisco Secure Endpoint Integration Procedures**Please provide the following information to CyTech:
**Collect logs from the Cisco Secure Endpoint API.**
1. Client ID - Cisco Secure Endpoint Client ID
2. API Key - Cisco Secure Endpoint API Key
# CISCO Umbrella Integrations
#### **Introduction**Cisco Umbrella is a cloud security platform that provides an additional line of defense against malicious software and threats on the internet by using threat intelligence. That intelligence helps prevent adware, malware, botnets, phishing attacks, and other known bad Websites from being accessed.
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### ***Prerequisites***
- - You must have Full Admin access to Umbrella to create and manage Umbrella API keys or Umbrella KeyAdmin API keys.
##### **Requirements**This integration is for Cisco Umbrella. It includes the following datasets for receiving logs from an AWS S3 bucket using an SQS notification queue and Cisco Managed S3 bucket without SQS:
- log dataset: supports Cisco Umbrella logs.
##### **Logs**
**Umbrella**
When using Cisco Managed S3 buckets that does not use SQS there is no load balancing possibilities for multiple agents, a single agent should be configured to poll the S3 bucket for new and updated files, and the number of workers can be configured to scale vertically.The log dataset collects Cisco Umbrella logs.Advantages of Integrating with the Umbrella APIThe Umbrella API features a number of improvements over the Umbrella v1 APIs and the Umbrella Reporting v2 API.
- Intuitive base URI
- API paths defined by top-level scopes
- Intent-based, granular API key scopes
- API key expiration
- Updated API key administration dashboard views
- Programmatic API key administration
- API authentication and authorization supported by OAuth 2.0 client credentials flow
- Portable, programmable API interface for client integrations
Before you send a request to the Umbrella API, you must create new Umbrella API credentials and generate an API access token. For more information, see Umbrella API Authentication. [https://developer.cisco.com/docs/cloud-security/authentication/#authentication](https://developer.cisco.com/docs/cloud-security/authentication/#authentication)
**Authentication**
The Umbrella API provides a standard REST interface and supports the OAuth 2.0 client credentials flow. To get started, log in to Umbrella and create an Umbrella API key. Then, use your API credentials to generate an API access token.Note: API keys, passwords, secrets, and tokens allow access to your private customer data. You should never share your credentials with another user or organization.
**Log in to Umbrella**
- Log in to Umbrella with the following URL: [https://dashboard.umbrella.com](https://dashboard.umbrella.com/)
- You can find your username after Admin in the navigation tree. Confirm that your organization appears under your username.
#### **Create Umbrella API Key**
Create an Umbrella API key ID and key secret.
**Note:** You have only one opportunity to copy your API secret. Umbrella does not save your API secret and you cannot retrieve the secret after its initial creation.
1. Navigate to **Admin > API Keys** or in a Multi-org, Managed Service Provider (MSP), or Managed Secure Service Provider (MSSP) console navigate to **Console Settings > API Keys**.
2. Click **API Keys** and then click **Add**.
- The number of expired API keys appears next to the red triangle.
- The number of API keys that expire within 30 days appears next to the yellow triangle.
3. Enter a name and description for the key. A name must contain fewer than 256 characters. The description is optional.
4. Check the key scopes and expand a key scope to view the scope categories. Check each scope category in a key scope to enable access to the API endpoints.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/JCBMe52qf9X0Mowd-image.png)
5. Choose **Read-Only** or **Read / Write** for the selected scope and resource.
6. For **Expiry Date**, choose the expiration date for the key, or choose **Never expire**.
7. (Optional) For **Network Restrictions**, enter a comma-separated list of public IP addresses or CIDRs, then click **ADD**.
**Note:** You can add up to ten networks to your API key. You can only use your API key to authenticate requests for clients on the selected networks.
8. Click **Create Key**.
9. Copy and save your **API Key** and **Key Secret**.
10. Click **Accept And Close**.
#### **Refresh Umbrella API Key**
Refresh an Umbrella API key ID and key secret.
**Note:** You have only one opportunity to copy your API secret. Umbrella does not save your API secret and you cannot retrieve the secret after its initial creation.
1. Navigate to **Admin > API Keys** or in a Multi-org, Managed Service Provider (MSP), or Managed Secure Service Provider (MSSP) console, navigate to **Console Settings > API Keys**.
2. Click **API Keys**, and then expand an API key.
3. Click **Refresh Key**.
4. Copy and save your **API Key** and **Key Secret**.
5. Click **Accept and Close**.
#### **Update Umbrella API Key**
Update an Umbrella API key.
1. Navigate to **Admin > API Keys** or in a Multi-org, Managed Service Provider (MSP), or Managed Secure Service Provider (MSSP) console, navigate to **Console Settings > API Keys**.
2. Click **API Keys**, and then expand an API key. You can modify the **API Key Name**, **Description**, selected scopes and permissions in **Key Scope**, and **Expiry Date**.
3. For **Network Restrictions**, update the list of IP addresses and CIDRs. Click on the **X** to remove a network address.
4. Click **Save**.
##### **Cisco Secure Endpoint Integration Procedures**Please provide the following information to CyTech:
**Collect logs from the Cisco Umbrella**
1. Queue URL - URL of the AWS SQS queue that messages will be received from. For Cisco Managed S3 buckets or S3 without SQS, use Bucket ARN.
2. Bucket ARN- Required for Cisco Managed S3. If the S3 bucket does not use SQS, this is the address for the S3 bucket, one example is arn:aws:s3:::cisco-managed-eu-central-1 For a list of Cisco Managed buckets, please see [https://docs.umbrella.com/mssp-deployment/docs/enable-logging-to-a-cisco-managed-s3-bucket](https://docs.umbrella.com/mssp-deployment/docs/enable-logging-to-a-cisco-managed-s3-bucket).
3. Bucket Region - Required for Cisco Managed S3. The region the bucket is located in.
4. Bucket List Prefix - Required for Cisco Managed S3. This sets the root folder of the S3 bucket that should be monitored, found in the S3 Web UI. Example value: 1235\_654vcasd23431e5dd6f7fsad457sdf1fd5.
5. Number of Workers - Required for Cisco Managed S3. Number of workers that will process the S3 objects listed. Minimum is 1.
6. Bucket List Interval - Time interval for polling listing of the S3 bucket. Defaults to 120s.
7. Access Key ID
8. Secret Access Key
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Cloudflare Integration
##### **Introduction**Cloudflare integration uses Cloudflare's API to retrieve audit logs and traffic logs from Cloudflare, for a particular zone, and ingest them into Elasticsearch. This allows you to search, observe and visualize the Cloudflare log events through Elasticsearch.Users of Cloudflare use Cloudflare services to increase the security and performance of their web sites and services.To enable the Cloudflare Logpush, please refer to Section 5. Currently, the procedures described is for the setup of Amazon S3.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**
**Configure Cloudflare audit logs data stream**
Enter values "Auth Email", "Auth Key" and "Account ID".
1. 1. 1. Auth Email is the email address associated with your account.
2. Auth Key is the API key generated on the "My Account" page.
3. Account ID can be found on the Cloudflare dashboard. Follow the navigation documentation from [here](https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/find-account-and-zone-ids/).
##### **Configure Cloudflare logs**These logs contain data related to the connecting client, the request path through the Cloudflare network, and the response from the origin web server. For more information see [here](https://developers.cloudflare.com/logs/logpull/).The integration can retrieve Cloudflare logs using -
1. 1. 1. Auth Email and Auth Key
2. API TokenMore information is available [here](https://developers.cloudflare.com/logs/logpull/requesting-logs/#required-authentication-headers).
**CONFIGURE USING AUTH EMAIL AND AUTH KEY**
Enter values "Auth Email", "Auth Key" and "Zone ID".
1. 1. 1. Auth Email is the email address associated with your account.
2. Auth Key is the API key generated on the "My Account" page.
3. Zone ID can be found [here](https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/find-account-and-zone-ids/).
**CONFIGURE USING API TOKEN**Enter values "API Token" and "Zone ID".For the Cloudflare integration to be able to successfully get logs the following permissions must be granted to the API token -
- Account.Access: Audit Logs: Read
1. 1. 1. API Tokens allow for more granular permission settings.
2. Zone ID can be found [here](https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/find-account-and-zone-ids/).
##### **Logs**
**Audit**
Audit logs summarize the history of changes made within your Cloudflare account. Audit logs include account-level actions like login and logout, as well as setting changes to DNS, Crypto, Firewall, Speed, Caching, Page Rules, Network, and Traffic features, etc.
**Logpull**
These logs contain data related to the connecting client, the request path through the Cloudflare network, and the response from the origin web server.
##### **CloudflareIntegrationProcedures** Please provide the following information to CyTech:See the Screenshot Below
**Audit Logs**
1. Auth Email-
2. Auth Key
3. Account ID
**Cloudflare Logs**
1. AuthToken
2. Zone ID
**Enable Logpush to Amazon S3**
To enable the Cloudflare Logpush service:
1. Log in to the Cloudflare dashboard.
2. Select the Enterprise account or domain you want to use with Logpush.
3. Go to Analytics & Logs > Logs.
4. Select Add Logpush job. A modal window opens where you will need to complete several steps.
5. Select the dataset you want to push to a storage service.
6. Select the data fields to include in your logs. Add or remove fields later by modifying your settings in Logs > Logpush.
7. Select Amazon S3.
8. Enter or select the following destination information:
- - - Bucket path
- Daily subfolders
- Bucket region
- Encryption constraint in bucket policy
- For Grant Cloudflare access to upload files to your bucket, make sure your bucket has a policy (if you did not add it already):
- Copy the JSON policy, then go to your bucket in the Amazon S3 console and paste the policy in Permissions > Bucket Policy and click Save.
9. Click Validate access.
10. Enter the Ownership token (included in a file or log Cloudflare sends to your provider) and click Prove ownership. To find the ownership token, click the Open button in the Overview tab of the ownership challenge file.
11. Click Save and Start Pushing to finish enabling Logpush.
Once connected, Cloudflare lists Amazon S3 as a connected service under Logs > Logpush. Edit or remove connected services from here.
# CrowdStrike Integration - using API
#### **Steps to Get Client ID and Client Secret in CrowdStrike Falcon**
1. **Log in to the Falcon Console**
- Go to: [https://falcon.crowdstrike.com](https://falcon.crowdstrike.com)
- Use your admin credentials to log in.
2. **Navigate to API Clients and Keys**
- Click on the **"Support"** (question mark icon) or your **User avatar** on the top right.
- Select **"API Clients and Keys"** from the dropdown.
Alternatively, go to: `https://falcon.crowdstrike.com/support/api-clients-and-keys`
3. **Create a New API Client**
- Click on **“Add new API client”**.
- **Name** your client and optionally add a **description**.
- Under **API Scopes**, select the required **permissions** based on what you need (e.g., read access to Hosts, Alerts, IOCs, etc.).
**Data Stream**
**Scope**
Intel
read:intel
IOC
read:iocs
read:ioc-management
Alert
read:alert
Host
read:host
- Click **“Save”.**
**Please provide to AQUILA support team.**
1. **Copy the Client ID and Client Secret**
- After saving, the **Client ID** and **Client Secret** will be displayed **once**.
- Copy them immediately and store them securely (e.g., in a password manager or secrets vault).
2. **Token url**
***If you need further assistance, kindly contact our support at support@cytechint.com for prompt assistance and guidance.***
# Crowdstrike Integrations
##### **Introduction**This integration is for CrowdStrike products. It includes the following datasets for receiving logs:falcondataset consists of endpoint data and Falcon platform audit data forwarded from Falcon SIEM Connector.fdrdataset consists of logs forwarded using the Falcon Data Replicator.
##### **Assumptions**The procedures described in Section 3 assume that a Log Collector has already been setup.
**Compatibility**
This integration supports CrowdStrike Falcon SIEM-Connector-v2.0.
##### **Requirements**
**Logs**
**Falcon**
Contains endpoint data and CrowdStrike Falcon platform audit data forwarded from Falcon SIEM Connector.
**FDR**
The CrowdStrike Falcon Data Replicator (FDR) allows CrowdStrike users to replicate FDR data from CrowdStrike managed S3 buckets. CrowdStrike writes notification events to a CrowdStrike managed SQS queue when new data is available in S3.This integration can be used in two ways. It can consume SQS notifications directly from the CrowdStrike managed SQS queue or it can be used in conjunction with the FDR tool that replicates the data to a self-managed S3 bucket and the integration can read from there.In both cases SQS messages are deleted after they are processed. This allows you to operate more than one Elastic Agent with this integration if needed and not have duplicate events, but it means you cannot ingest the data a second time.
##### **CrowdStrike Integration Procedures**Please provide the following information to CyTech:
**Collect CrowdStrike Falcon Data Replicator logs (input: aws-s3) Option 1**
1. AWS: Access Key ID
2. AWS: Secret Access Key
3. AWS: Queue URL - URL of the AWS SQS queue that messages will be received from.
**Collect CrowdStrike logs via API. Option 2 (Recommended)**
1. Client ID:Client ID for the CrowdStrike.
2. Client Secret:Client Secret for the CrowdStrike.
3. URL:Token URL of CrowdStrike.
# CrowdStrike to SIEM alerts and ruling
##### **Introduction**
This guide explains how to send security alerts from CrowdStrike Falcon to your Security Information and Event Management (SIEM) system and how to create rules for alert filtering and correlation (ruling). This helps detect threats faster and reduces alert noise.
##### **What You Need Before Starting**
- CrowdStrike Falcon account with admin access
- API Client credentials from CrowdStrike
- Access to your SIEM (Splunk, QRadar, ArcSight, etc.)
- Ability to install/configure software (Windows/Linux)
- Basic knowledge of logs and syslog is helpful but not required
##### **Step 1: Create an API Client in CrowdStrike Falcon**
1. Log in to the CrowdStrike Falcon Console at [https://falcon.crowdstrike.com/login/](https://falcon.crowdstrike.com/login/ "CrowdStrike")
2. Go to **Support → API Clients and Keys**
3. Click **Add new API client**
4. Give the client a name like “SIEM Integration”
5. Select the following API scopes/permissions:
- **Event streams: Read**
- **Detections: Read**
6. Save the client and note the **Client ID** and **Client Secret** — you’ll need them later
##### **Step 2: Choose Your Integration Method**
There are three main ways to forward CrowdStrike data to your SIEM:
- **Falcon SIEM Connector** — easiest for most users, sends logs via syslog
- **Falcon Streaming API** — for custom coding and direct API calls
- **Falcon Data Replicator (FDR)** — for bulk data export, stored in AWS S3
##### **Step 3: Download and Install Falcon SIEM Connector**
**For Windows**
1. Download the SIEM Connector installer from CrowdStrike Support or Falcon Portal
2. Run the installer .exe file
3. Follow the installation wizard to complete setup
**For Linux**
1. Download the SIEM Connector package(.tar.gz)
2. Extract the package and run install script:
tar -xzf crowdstrike-siem-connector.tar.gz
cd crowdstrike-siem-connector
sudo ./install.sh
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/gVgtzDUz9QdyCS0V-image.png)
##### **Step 4: Configure the SIEM Connector**
1\. Open the connector configuration file in a text editor:
- Windows:
C:\\Program Files\\CrowdStrike\\SIEMConnector\\config.json
- Linux:
/etc/crowdstrike-siem/config.json
2\. Add your CrowdStrike API credentials and your SIEM server info. Example config:
{
"falcon\_api": {
"client\_id": "YOUR\_CLIENT\_ID",
"client\_secret": "YOUR\_CLIENT\_SECRET"
},
"output": {
"format": "json",
"destination": "syslog://your.siem.server:514"
}
}
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/Y06bIdU8Y8Mul9KP-image.png)
3\. Save the file.
##### **Step 5: Start the SIEM Connector Service**
**Windows**:
Open Command Prompt as Administrator and run: "net start CrowdStrikeSIEMConnector"
**Linux**:
Run the following commands: "sudo systemctl start crowdstrike-siem"
"sudo systemctl enable crowdstrike-siem"
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/By053HZDN73zseh6-image.png)
##### **Step 6: Verify Data Flow**
Check the connector logs to make sure it is running without errors:
- Windows: Logs usually at C:\\Program Files\\CrowdStrike\\SIEMConnector\\logs\\
- Linux: View logs with: tail -f /var/log/crowdstrike-siem.log
In your SIEM, search for CrowdStrike events to verify logs are being received.
##### **Step 7: Create Alert Rules and Ruling in SIEM**
Use your SIEM’s alerting and correlation features to build rules that:
- Filter out low-severity or false-positive alerts
- Combine multiple alerts related to the same incident for context
- Alert on high-severity or confirmed threats only
Example in Splunk**:index=crowdstrike severity>=high
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/CsSiA2PPmVHgn4TZ-image.png)
##### **Step 8: Best Practices and Tips**
- Always **rotate your API credentials** regularly for security
- Use **TCP or TLS syslog forwarding** for reliable and encrypted log delivery
- Limit forwarded logs to relevant event types to avoid SIEM overload
- Monitor the health of the SIEM connector continuously
- Document all configurations and rules clearly for team collaboration
**Additional Resources:**
# CSPM-AWS Integration
# Get started with CSPM for AWS
## [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-overview)Overview
This page explains how to get started monitoring the security posture of your cloud assets using the Cloud Security Posture Management (CSPM) feature.
**Requirements**
- Minimum privileges vary depending on whether you need to read, write, or manage CSPM data and integrations. Refer to [CSPM privilege requirements](https://www.elastic.co/guide/en/security/current/cspm-required-permissions.html "CSPM privilege requirements").
- The CSPM integration is available to all Elastic Cloud users. On-premise deployments require an [Enterprise subscription](https://www.elastic.co/pricing).
- CSPM only works in the `Default` Kibana space. Installing the CSPM integration on a different Kibana space will not work.
- CSPM is supported only on AWS, GCP, and Azure commercial cloud platforms, and AWS GovCloud. Other government cloud platforms are not supported. [Click here to request support](https://github.com/elastic/kibana/issues/new/choose).
- The user who gives the CSPM integration AWS permissions must be an AWS account `admin`.
## [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-setup)Set up CSPM for AWS
You can set up CSPM for AWS either by enrolling a single cloud account, or by enrolling an organization containing multiple accounts. Either way, first you will add the CSPM integration, then enable cloud account access. Two deployment technologies are available: agentless, and agent-based. [Agentless deployment](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-aws-agentless "Agentless deployment") allows you to collect cloud posture data without having to manage the deployment of Elastic Agent in your cloud. [Agent-based deployment](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-aws-agent-based "Agent-based deployment") requires you to deploy and manage Elastic Agent in the cloud account you want to monitor.[](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-aws-agentless)
## [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-aws-agent-based)Agent-based deployment
### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-add-and-name-integration)Add the CSPM integration
1. Find **Integrations** in the navigation menu or use the [global search field](https://www.elastic.co/guide/en/kibana/8.17/introduction.html#kibana-navigation-search).
2. Search for `CSPM`, then click on the result.
3. Click **Add Cloud Security Posture Management (CSPM)**.
4. Select **AWS**, then either **AWS Organization** to onboard multiple accounts, or **Single Account** to onboard an individual account.
5. Give your integration a name that matches the purpose or team of the AWS account/organization you want to monitor, for example, `dev-aws-account`.
### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-set-up-cloud-access-section)Set up cloud account access
The CSPM integration requires access to AWS’s built-in [`SecurityAudit` IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_security-auditor) in order to discover and evaluate resources in your cloud account. There are several ways to provide access.
For most use cases, the simplest option is to use AWS CloudFormation to automatically provision the necessary resources and permissions in your AWS account. This method, as well as several manual options, are described below.
### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-set-up-cloudformation)CloudFormation (recommended)
1. In the **Add Cloud Security Posture Management (CSPM) integration** menu, under **Setup Access**, select **CloudFormation**.
2. In a new browser tab or window, log in as an admin to the AWS account or organization you want to onboard.
3. Return to your Kibana tab. Click **Save and continue** at the bottom of the page.
4. Review the information, then click **Launch CloudFormation**.
5. A CloudFormation template appears in a new browser tab.
6. For organization-level deployments only, you must enter the ID of the organizational units where you want to deploy into the CloudFormation template’s `OrganizationalUnitIds` field. You can find organizational unit IDs in the AWS console under **AWS Organizations → AWS Accounts** (under each organization’s name). You can also use this field to specify which accounts in your organization to monitor, and which to skip.
7. (Optional) Switch to the AWS region where you want to deploy using the controls in the upper right corner.
8. Tick the checkbox under **Capabilities** to authorize the creation of necessary resources.
9. At the bottom of the template, select **Create stack**.
When you return to Kibana, click **View assets** to review the data being collected by your new integration.
### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-setup-organization-manual)Manual authentication for organization-level onboarding
If you’re onboarding a single account instead of an organization, skip this section.
When using manual authentication to onboard at the organization level, you need to configure the necessary permissions using the AWS console for the organization where you want to deploy:
- In the organization’s management account (root account), create an IAM role called `cloudbeat-root` (the name is important). The role needs several policies:
- The following inline policy:
Click to expand policy
```
```
- The following trust policy:
Click to expand policy
```
```
- The AWS-managed `SecurityAudit` policy.
You must replace `` in the trust policy with your AWS account ID.
- Next, for each account you want to scan in the organization, create an IAM role named `cloudbeat-securityaudit` with the following policies:
- The AWS-managed `SecurityAudit` policy.
- The following trust policy:
Click to expand policy
```
```
You must replace `` in the trust policy with your AWS account ID.
After creating the necessary roles, authenticate using one of the manual authentication methods.
When deploying to an organization using any of the authentication methods below, you need to make sure that the credentials you provide grant permission to assume `cloudbeat-root` privileges.
### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-set-up-manual)Manual authentication methods
- [Default instance role (recommended)](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-instance-role "Option 1 - Default instance role")
- [Direct access keys](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-keys-directly "Option 2 - Direct access keys")
- [Temporary security credentials](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-temp-credentials "Option 3 - Temporary security credentials")
- [Shared credentials file](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-a-shared-credentials-file "Option 4 - Shared credentials file")
- [IAM role Amazon Resource Name (ARN)](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-iam-arn "Option 5 - IAM role Amazon Resource Name (ARN)")
Whichever method you use to authenticate, make sure AWS’s built-in [`SecurityAudit` IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_security-auditor) is attached.
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-instance-role)Option 1 - Default instance role
If you are deploying to an AWS organization instead of an AWS account, you should already have [created a new role](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-setup-organization-manual "Manual authentication for organization-level onboarding"), `cloudbeat-root`. Skip to step 2 "Attach your new IAM role to an EC2 instance", and attach this role. You can use either an existing or new EC2 instance.
Follow AWS’s [IAM roles for Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) documentation to create an IAM role using the IAM console, which automatically generates an instance profile.
1. Create an IAM role:
1. In AWS, go to your IAM dashboard. Click **Roles**, then **Create role**.
2. On the **Select trusted entity** page, under **Trusted entity type**, select **AWS service**.
3. Under **Use case**, select **EC2**. Click **Next**.
4. On the **Add permissions** page, search for and select `SecurityAudit`. Click **Next**.
5. On the **Name, review, and create** page, name your role, then click **Create role**.
2. Attach your new IAM role to an EC2 instance:
1. In AWS, select an EC2 instance.
2. Select **Actions > Security > Modify IAM role**.
3. On the **Modify IAM role** page, search for and select your new IAM role.
4. Click **Update IAM role**.
5. Return to Kibana and [finish manual setup](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual "Finish manual setup").
Make sure to deploy the CSPM integration to this EC2 instance. When completing setup in Kibana, in the **Setup Access\* section, select \*Assume role**. Leave **Role ARN** empty for agentless deployments. For agent-based deployments, leave it empty unless you want to specify a role the Elastic Agent should assume instead of the default role for your EC2 instance. Click **Save and continue**.
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-keys-directly)Option 2 - Direct access keys
Access keys are long-term credentials for an IAM user or AWS account root user. To use access keys as credentials, you must provide the `Access key ID` and the `Secret Access Key`. After you provide credentials, [finish manual setup](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual "Finish manual setup").
For more details, refer to [Access Keys and Secret Access Keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html).
You must select **Programmatic access** when creating the IAM user.
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-temp-credentials)Option 3 - Temporary security credentials
You can configure temporary security credentials in AWS to last for a specified duration. They consist of an access key ID, a secret access key, and a session token, which is typically found using `GetSessionToken`.
Because temporary security credentials are short term, once they expire, you will need to generate new ones and manually update the integration’s configuration to continue collecting cloud posture data. Update the credentials before they expire to avoid data loss.
IAM users with multi-factor authentication (MFA) enabled need to submit an MFA code when calling `GetSessionToken`. For more details, refer to AWS’s [Temporary Security Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) documentation.
You can use the AWS CLI to generate temporary credentials. For example, you could use the following command if you have MFA enabled:
Copy as curl[Try in Elastic](http://localhost:5601/zzz/app/kibana#/dev_tools/console?load_from=https://www.elastic.co/guide/en/security/current/snippets/9.console "Try in Elastic")
The output from this command includes the following fields, which you should provide when configuring the KSPM integration:
- `Access key ID`: The first part of the access key.
- `Secret Access Key`: The second part of the access key.
- `Session Token`: The required token when using temporary security credentials.
After you provide credentials, [finish manual setup](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual "Finish manual setup").
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-a-shared-credentials-file)Option 4 - Shared credentials file
If you use different AWS credentials for different tools or applications, you can use profiles to define multiple access keys in the same configuration file. For more details, refer to AWS' [Shared Credentials Files](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html) documentation.
Instead of providing the `Access key ID` and `Secret Access Key` to the integration, provide the information required to locate the access keys within the shared credentials file:
- `Credential Profile Name`: The profile name in the shared credentials file.
- `Shared Credential File`: The directory of the shared credentials file.
If you don’t provide values for all configuration fields, the integration will use these defaults:
- If `Access key ID`, `Secret Access Key`, and `ARN Role` are not provided, then the integration will check for `Credential Profile Name`.
- If there is no `Credential Profile Name`, the default profile will be used.
- If `Shared Credential File` is empty, the default directory will be used.
- For Linux or Unix, the shared credentials file is located at `~/.aws/credentials`.
After providing credentials, [finish manual setup](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual "Finish manual setup").
#### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-use-iam-arn)Option 5 - IAM role Amazon Resource Name (ARN)
An IAM role Amazon Resource Name (ARN) is an IAM identity that you can create in your AWS account. You define the role’s permissions. Roles do not have standard long-term credentials such as passwords or access keys. Instead, when you assume a role, it provides temporary security credentials for your session.
To use an IAM role ARN, select **Assume role** under **Preferred manual method**, enter the ARN, and continue to Finish manual setup.
### [](https://www.elastic.co/guide/en/security/current/cspm-get-started.html#cspm-finish-manual)Finish manual setup
Once you’ve provided AWS credentials, under **Where to add this integration**:
If you want to monitor an AWS account or organization where you have not yet deployed Elastic Agent:
- Select **New Hosts**.
- Name the Elastic Agent policy. Use a name that matches the purpose or team of the cloud account or accounts you want to monitor. For example, `dev-aws-account`.
- Click **Save and continue**, then **Add Elastic Agent to your hosts**. The **Add agent** wizard appears and provides Elastic Agent binaries, which you can download and deploy to your AWS account.
If you want to monitor an AWS account or organization where you have already deployed Elastic Agent:
- Select **Existing hosts**.
- Select an agent policy that applies the AWS account you want to monitor.
- Click **Save and continue**.
source: *https://www.elastic.co/guide/en/security/current/cspm-get-started.html*
# Custom Windows Event Logs - Integration
## Custom Windows Event Logs
Collect and parse logs from any Windows event log channel with Elastic Agent.
The custom Windows event log package allows you to ingest events from any [Windows event log](https://docs.microsoft.com/en-us/windows/win32/wes/windows-event-log) channel. You can get a list of available event log channels by running [`Get-WinEvent -ListLog * | Format-List -Property LogName`](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) in PowerShell on Windows Vista or newer. If `Get-WinEvent` is not available, [`Get-EventLog *`](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-eventlog) may be used.
By executing this command in the powershell(administrator), it will list the log names that is being used.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/T4wDzWGP1Iq0xMF3-image.png)
Add a channel name in the Channel Name text field (e.g Application).
# Cyber Incident Monitoring Integration Procedure
Go to > Cyber Incident Monitoring
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-04/image.png)
# CyberArk PAM
##### Configure the Vault to Forward syslog Messages to PTA
The system logger of the Vault must be configured to send logging data to the PTA machine for real-time data analysis.
When PTA is configured with Vaults deployed in a distributed environment, configure the primary and satellite Vaults.
[To Configure syslog on the Vault Machine (until Vault v10.4):](https://docs.cyberark.com/pam-self-hosted/11.3/en/content/pta/configuring-vault-forward-syslog-messages.htm)
1.
From the installation package, copy PTA.xsl to the Syslog subdirectory of the Vault installation folder. By default, the subdirectory is:
C:\\Program Files (x86)\\PrivateArk\\Server\\Syslog.
2.
In the same server installation folder,by default C:\\Program Files (x86)\\PrivateArk\\Server, open dbparm.ini and add the following lines:
\[SYSLOG\]
SyslogTranslatorFile=Syslog\\PTA.xsl
SyslogServerPort=<port number>
SyslogServerIP=<server IP>
SyslogServerProtocol=UDP
SyslogMessageCodeFilter=4,17,22,24,31,38,57,60,88,130,142,145,148,149,170,183,185,295,300,301,302,303,306,307,308,344,346,359,360,361,362,372,373,374,375,376,377,378,379,380,381,411,412,414,416,418,426,434,463
UseLegacySyslogFormat=No
Specify the following information:
Parameter Name
Define or Select
SyslogServerIP
The IP address(es) of the PTA machine where messages will be sent.
SyslogServerPort
The port number through which the syslog will be sent.
Specify 514 to send syslogs to the default PTA port.
SyslogServerProtocol
The protocol used to transfer the syslog records.
Specify: tcp or udp.
PTA does not support the SSL protocol.
SyslogMessageCodeFilter
Defines which message codes will be sent from the Vault Machine to PTA through Syslog protocol.
You can specify message numbers, separated by commas. You can also specify range of numbers using ‘-‘.
Message codes are sent for the following events:
Code
Activity
4
User Authentication
17
Add Safe (Unauthorized)
22
CPM Verify Password
24
CPM Change Password
31
CPM Reconcile Password
38
CPM Verify Password Failure
57
CPM Change Password Failure
60
CPM Reconcile Password Failure
88
Set Password
130
CPM Disable Password
142, 145, 148, 149, 170
Delete Safe Failure
183
Delete Safe
185
Add Safe
295
Retrieve Password
300
PSM Connect
301
PSM Connect Failure
302
PSM Disconnect
303
PSM Disconnect Failure
306, 307, 308
Use Password
344
Privileged Command Initiated
346
Privileged Command Completed
359
PSM SQL Command
360
PSM SQL Command Failure
361
PSM Keystrokes
362
PSM Keystrokes Failure
372
Terminate session
373
Terminate session Failure
374
Start Monitor session
375
Start Monitor session Failure
376
End Monitor session
377
End Monitor session Failure
378
PSM Secure Connect Session Start
379
PSM secure Connect session start Failure
380
PSM Secure Connect Session End
381
PSM secure Connect session End Failure
411
PSM Window Title
412
PSM Windows Title Failure
414
CPM Verify SSH Key
416
CPM Rotate SSH Key
418
CPM Reconcile SSH Key
426
CPM Disable SSH Key
434
CPM has deleted the public SSH key
463
Agent successfully changed the password for account
SyslogTranslatorFile
Specifies the XSL file used to parse Vault records data into Syslog protocol.
UseLegacySyslogFormat
Controls the format of the syslog message, and defines whether it will be sent in a newer syslog format (RFC 5424) or in a legacy format.
Required value: No. This enables the Vault to work with the newer syslog format.
3.
To forward Vault syslogs to multiple machines (for instance to your SIEM solution as well as to PTA), you can specify multiple values for the following parameters and separate each value with a comma.
■
■" style="box-sizing: border-box; font-size: 14px; margin-bottom: 8px; vertical-align: top; word-break: normal; overflow-wrap: normal; line-height: 1.5rem; position: relative;" valign="top">This requires a CyberArk Vault version 7.2.5 or higher.
■
■" style="box-sizing: border-box; font-size: 14px; margin-bottom: 8px; vertical-align: top; word-break: normal; overflow-wrap: normal; line-height: 1.5rem; position: relative;" valign="top">All destinations must use the same port and protocol, which are specified in the SyslogServerPort and SyslogServerProtocol fields.
■
■" style="box-sizing: border-box; font-size: 14px; margin-bottom: 8px; vertical-align: top; word-break: normal; overflow-wrap: normal; line-height: 1.5rem; position: relative;" valign="top">The specified values will apply to all destinations configured in SyslogServerIP, using the translator files specified in SysLogTranslatorFile.
Parameter Name
Comments
SyslogServerIP
SyslogTranslatorFile
UseLegacySyslogFormat
SyslogMessageCodeFilter
Separate multiple values with a comma, and separate sets of multiple values with a pipe-line, as shown in the example below.
The following example shows how to send different syslog messages to multiple syslog servers.
\[SYSLOG\]
SysLogTranslatorFile=Syslog\\Arcsight.sample.xsl,Syslog\\QRadar.xsl,Syslog\\PTA.xsl
SyslogServerPort=<port number>
SysLogServerIP=1.1.1.1,1.1.2.2,1.1.3.3
SyslogServerProtocol=UDP
UseLegacySyslogFormat=Yes,Yes,No
SyslogMessageCodeFilter=295,308,7,24,31,428,361,372,373,359,436,412,411,300,302,294,427,471,4
4.
Save the file and close it.
5.
Restart the Vault.
For more detailed instructions about integrating SIEM applications, see [Security Information and Event Management Applications](https://docs.cyberark.com/pam-self-hosted/11.3/en/content/PASIMP/Integrating-with-SIEM-Applications.htm).
[To Configure syslog on the Vault Machine (from Vault v10.5):](https://docs.cyberark.com/pam-self-hosted/11.3/en/content/pta/configuring-vault-forward-syslog-messages.htm)
1.
The PTA syslog parameters are available in the **dbparm.sample.ini** file. Copy the parameters to the **dbparm.ini** configuration file.
To forward Vault syslogs to multiple machines (for instance to your SIEM solution as well as to PTA), you can specify multiple values for the following parameters and separate each value with a comma.
■
■" style="box-sizing: border-box; font-size: 14px; margin-bottom: 8px; vertical-align: top; word-break: normal; overflow-wrap: normal; line-height: 1.5rem; position: relative;" valign="top">All destinations must use the same port and protocol, which are specified in the SyslogServerPort and SyslogServerProtocol fields.
■
■" style="box-sizing: border-box; font-size: 14px; margin-bottom: 8px; vertical-align: top; word-break: normal; overflow-wrap: normal; line-height: 1.5rem; position: relative;" valign="top">The specified values will apply to all destinations configured in SyslogServerIP, using the translator files specified in SysLogTranslatorFile.
Parameter Name
Comments
SyslogServerIP
SyslogTranslatorFile
UseLegacySyslogFormat
SyslogMessageCodeFilter
Separate multiple values with a comma, and separate sets of multiple values with a pipe-line, as shown in the example below.
The following example shows how to send different syslog messages to multiple syslog servers.
\[SYSLOG\]
SysLogTranslatorFile=Syslog\\Arcsight.sample.xsl,Syslog\\QRadar.xsl,Syslog\\PTA.xsl
SyslogServerPort=<port number>
SysLogServerIP=1.1.1.1,1.1.2.2,1.1.3.3
SyslogServerProtocol=UDP
UseLegacySyslogFormat=Yes,Yes,No
SyslogMessageCodeFilter=7,8,295|295-296|295,308,7,24,31,428,361,372,373,359,436,412,411,300,302,294,427,471
3.
To send secured syslog data to PTA, see [Configure Vault Trusted Connection to PTA](https://docs.cyberark.com/pam-self-hosted/11.3/en/content/pta/Configure_PTA-Vault_Trusted_Connection.htm).
4.
Save the file and close it.
5.
Restart the Vault.
For more detailed instructions about integrating SIEM applications, see [Security Information and Event Management Applications](https://docs.cyberark.com/pam-self-hosted/11.3/en/content/PASIMP/Integrating-with-SIEM-Applications.htm).
Source: *[https://docs.cyberark.com/pam-self-hosted/11.3/en/content/pta/configuring-vault-forward-syslog-messages.htm](https://docs.cyberark.com/pam-self-hosted/11.3/en/content/pta/configuring-vault-forward-syslog-messages.htm)*
#### **CyberArk PAM Integration Procedures **
##### Please provide the following information to CyTech: Requirements:Collect logs via syslog over UDP or TCP
\*Syslog Host-> Syslog Collector IP address where the Elastic-Agent is installed.
\*Syslog Port-> Port Number (Please identify if TCP or UDP)If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.
# Digital Guardian Integration
Requirements
You Must Have
Why You Need It
Elastic Agent installed
So Elastic can pull data from DG
Access to Digital Guardian (ARC and DGMC)
That’s where you get the info Elastic needs
---
STEP 1: Get the Info from Digital Guardian
You will need to collect 5 things. Just follow this one by one:
---
Get the Client ID
Where to find it:
- Go to **Digital Guardian ARC**
- Log in
- Click on **Tenant Settings**
- Look for **Tenant ID**
- Copy this and save it somewhere. This is your **Client ID**
---
Get the **Authentication Token or Client Secret**
Still in **Tenant Settings**
- Look for **Authentication Token**
- Copy it — this is your **secret key**
- This helps Elastic talk to Digital Guardian safely
Get the **ARC Server URL**
Now go to the **Digital Guardian Management Console (DGMC)**
- Log in
- Find the **Access Gateway Base URL**
- Copy it. This is the website Elastic will connect to get the data
---
Get the **Authorization Server URL**
Still in DGMC
- Look for something called **Authorization Server URL**
- Copy that too
---
Get the **Export Profile ID**
Go back to ARC
- Click on **Admin** > **Reports** > **Export Profiles**
- Find your Export Profile
- You’ll see something like this: `export-profile:guid:abc-123-xyz`
- Copy **only the middle part** (example: just `abc-123-xyz`)
---
Notes:
- If you don’t see data right away, give it a few minutes.
- Make sure your API info (Client ID, Secret, URLs) are **correct**
# Dropbox Integrations
##### **Introduction**
**Connecting Dropbox**
Use the Workplace Search Dropbox connector to automatically capture, sync and index the following items from your Dropbox service:
##### **Stored Files**Including ID, File Metadata, File Content, Updated by, and timestamps.
##### **Dropbox Paper**Including ID, Metadata, Content, Updated by, and timestamps.This document helps you configure and connect your Dropbox service to Workplace Search. To do this, you must register your Elastic deployment in the Dropbox Developer platform, by creating an OAuth 2.0 app. This gives your app permission to access Dropbox data. You will need your Workplace Search OAuth redirect URL, so have that handy.If you need a primer on OAuth, read the official OAuth 2.0 authorization flow RFC. The diagrams provide a good mental model of the protocol flow. Dropbox also has its own OAuth guide.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**
**Configuring the Dropbox Connector**
1. To register your Elastic deployment with Dropbox, create a new **OAuth app** in your organization’s[Dropbox developer platform](https://www.dropbox.com/developers/apps). Make sure to use a trusted and stable Dropbox account.
2. Provide basic information about the app and define the **access scopes**, or specific permissions, the app needs to interact with Dropbox. A good rule of thumb is that these should be read-only permissions. Choose only the following permissions:
To fetch document-level permissions, you must create an OAuth App using a team-owned (Dropbox Business) account. Enable [document-level permissions](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-sources-document-permissions.html) by adding the following permissions:
3. Register a **redirect URL** for the app to use. This is where the OAuth 2.0 service will return the user after they authorize the application. This is the [Workplace Search OAuth redirect URL](https://www.elastic.co/guide/en/enterprise-search/8.7/endpoints-ref.html#workplace-search-oauth-redirect-url) for your deployment. This must be a https endpoint for production use cases. Only use http for local development.
4. Find and record the client\_id and client\_secret for the app. Dropbox calls these App Key and App Secret.
5. Switch back to your organization’s Workplace Search administrative dashboard
6. In the **Sources —> Add Source** tab, add a new **Dropbox**source
7. Configure the service with Workplace Search using the App Key and App Secret.
Your Dropbox service is now configured, and you can connect it to Workplace Search.
##### **Dropbox Integration Procedures**
**Connecting Dropbox to Workplace Search**
Once the Dropbox connector is configured, you can connect a Dropbox instance to your organization’s Workplace Search deployment.
1. Follow the Dropbox authentication flow as presented in the Workplace Search administrative dashboard.
2. If the authentication flow succeeds, you will be redirected to Workplace Search.
Your Dropbox content becomes searchable as soon as syncing starts. Once configured and connected, Dropbox synchronizes automatically every 2 hours.
**Limiting the content to be indexed**
If you don’t need to index all available content, you can use the API to apply indexing rules. This reduces indexing load and overall index size. See [Customizing indexing](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-customizing-indexing-rules.html).The path\_template and file\_extension rules are applicable for Dropbox.
**Synchronized fields**
The following table lists the fields synchronized from the connected source to Workplace Search. The attributes in the table apply to the default search application, as follows:
- **Display name** - The label used when displayed in the UI
- **Field name** - The name of the underlying field attribute
- **Faceted filter** - whether the field is a faceted filter by default, or can be enabled (see also: [Customizing filters](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-customizing-filters.html))
- **Automatic query refinement preceding phrases** - The default list of phrases that must precede a value of this field in a search query in order to automatically trigger query refinement. If "None," a value from this field may trigger refinement regardless of where it is found in the query string. If '', a value from this field must be the first token(s) in the query string. If N.A., automatic query refinement is not available for this field by default. All fields that have a faceted filter (default or configurable) can also be configured for automatic query refinement; see also [Update a content source](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-content-sources-api.html#update-content-source-api), [Get a content source’s automatic query refinement details](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-content-sources-api.html#get-automatic-query-refinement-details-api) and [Customizing filters](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-customizing-filters.html).
# Enable or Check Syslog/CEF on SonicWall
1. **Log in to SonicWall UI**
- Open a web browser
- Go to your SonicWall’s IP (e.g., `https://192.168.1.1`)
- Login with your admin credentials
2. **Navigate to Log Settings**
- Go to:
- Log > Syslog
- (On older firmware: `Log > Syslog > Syslog Servers`)
- You’ll see the list of configured **Syslog Servers**
3. **Check Syslog Server Configuration**
- Make sure the following are set:
- ****Syslog Server IP Address**:** should be the IP of the ****Elastic Agent**** host
- **Port**: default is **514** for UDP, or **6514** for TCP/TLS
- **Syslog Format**:
- Can be set to **Default**, **Syslog**, or **CEF** (Common Event Format)
- For Elastic integrations, **Syslog** or **CEF** is typically supported
4. **Enable Log Categories**
- Still under **Log > Syslog**, click **Syslog Settings**
- Ensure that **Important log categories** are **enabled for syslog**, like:
- **Firewall**
- **VPN**
- **System**
- **User Activity**
- **Connection dropped**
- Set **Alert level** or **Priority**: e.g., **Information** or **Notice**
5. **If Using CEF Format (For Elastic Agent CEF Integration)**
- Some SonicWall models support **CEF log format**:
- Go to **Log > Syslog**
- Look for an option like **“Syslog Format”** or **“Use CEF”**
- Enable **CEF output**
- *Note:* Not all SonicWall devices support native CEF.
6. **Advanced Settings (Optional)**
- Under **Log > Syslog Settings**, check:
- Syslog Facility (can be left as default: `Local0` or `Local4`)
- Use **Syslog over TLS** if required, and provide the correct certs
7. **Save and Apply**
- Click **Apply** or **Accept** to confirm changes
- Ensure the firewall can reach the Elastic Agent on the configured port
# Enable Syslog on Port 514 and Allow via Firewall (Ubuntu)
##### **Step 1: Install rsyslog**1. Open terminal.2. Run the following commands:
```javascript
sudo apt update
sudo apt install rsyslog -y
sudo systemctl enable rsyslog
sudo systemctl start rsyslog
```
##### **Step 2: Enable Syslog Reception on Port 514**1.Open the rsyslog configuration file:
```javascript
sudo nano /etc/rsyslog.conf
```
##### 2. Find and uncomment or add these lines:
```javascript
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
```
##### 3.Save and exit (Ctrl+X, then Y, then Enter).
##### **Step 3: Restart rsyslog**
```javascript
sudo systemctl restart rsyslog
```
##### **Step 4: Allow Port 514 in UFW Firewall**1. Run the following:
```javascript
sudo ufw allow 514/udp
sudo ufw allow 514/tcp
sudo ufw reload
```
##### 2. Check status:
```javascript
sudo ufw status
```
##### **Step 5: Confirm Port is Listening**
```javascript
sudo ss -tulnp | grep 514
```
##### Or if netstat is available:
```javascript
sudo netstat -tulnp | grep 514
```
##### **Step 6: Optional - Test from Remote Client**From another machine:
```java
logger -n -P 514 "Test syslog message"
```
##### Then on the Ubuntu server:
```javascript
sudo tail -f /var/log/syslog
```
##### **Step 7: End-to-End Connectivity Test (Ping)**From Azure VM (log collector), test connectivity to Cisco Meraki and Palo Alto devices.
##### **Ping Cisco Meraki:**
```javascript
ping
```
##### **Ping Palo Alto:**
```javascript
ping
```
##### **If ping is successful, you'll see replies with time. If not, verify:**
- ##### NSG and UFW rules in Azure
- ##### On-prem firewall rules
- ##### IP reachability and routing
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# ESET Protect Integration
ESET PROTECT allows you to efficiently manage ESET products across workstations and servers within a networked environment, supporting up to 50,000 devices from a single centralized platform. Through the ESET PROTECT Web Console, you can seamlessly deploy ESET solutions, manage tasks, enforce security policies, monitor system health, and swiftly address any issues or threats on remote devices.
---
#### **Data streams**
The ESET PROTECT integration collects three types of logs: Detection, Device Task and Event.
**Detection** is used to retrieve detections via the ESET Connect - Incident Management.
**Device Task** is used to retrieve device tasks via the ESET Connect - Automation.
**Event** is used to retrieve Detection, Firewall, HIPS, Audit, and ESET Inspect logs using the Syslog Server.
---
##### **Requirements:**
- Elastic Agent must be installed
---
#### **Setup**
##### **To collect data from ESET Connect, follow the below steps:**
1. Create API User Account (*Refer to How to Create an API User Account below*)
2. Retrieve the username and password generated during the creation of an API user account.
3. Retrieve the region from the ESET Web Console URL.
##### **To collect data from ESET PROTECT via Syslog, follow the below steps:**
1. Follow the steps to configure syslog server (*Refer to How to Configure Syslog Server*).
- Set the format of the payload to **JSON**.
- Set the format of the envelope to **Syslog**.
- Set the minimal log level to **Information** to collect all data.
- Select all checkboxes to collect logs for all event types.
- Enter the **IP Address** or **FQDN** of the Elastic Agent that is running the integration in the Destination IP field.
---
#### **How to Create an API User Account:**
##### **For ESET Business Account and ESET MSP Administrator 2**
Follow the steps below to create the dedicated API user account:
1. Log in as Superuser (or Root) to your ESET Business Account or ESET MSP Administrator 2.
2. Navigate to User management and create a new user.
3. Under the Access Rights section, enable the toggle next to Integrations.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/aYONheFotttkYVLL-image.png)
4. Click Create to apply the changes.
5. The new user receives an invitation email and must finish the account activation process.
##### **For ESET PROTECT Hub**
Follow the steps below to create the dedicated API user account:
1. Log in as a Superuser to your ESET PROTECT Hub account.
2. Navigate to Users and add a new user.
3. Under the Permissions section, enable the toggle next to Integrations.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-11/opgDzC1d93odlwX4-image.png)
4. Click Next and then click Create to apply the changes.
5. The new user receives an invitation email and must finish the account activation process.
---
#### **How to Configure Syslog Server**
If you have a Syslog server running in your network, you can Export logs to Syslog to receive certain events (Detection Event, Firewall Aggregated Event, HIPS Aggregated Event, etc.) from client computers running ESET Endpoint Security.
**To enable the Syslog server:**
1. Click More > Settings > Syslog and click the toggle next to Enable Syslog sending.
2. Specify the following mandatory settings:
- Format of payload: **JSON**, **LEEF** or **CEF**
- Format of envelope of the log: **BSD** (specification), **Syslog** (specification)
- Minimal log level: **Information**, **Warning**, **Error** or **Critical**
- Event type of logs: Select the type of logs you want to include **(****Antivirus, HIPS, Firewall, Web protection, Audit Log, Blocked files, ESET Inspect alerts).**
- **Destination IP or FQDN of TLS-compatible syslog server:** IPv4 address or hostname of the destination for Syslog messages
- **Validate CA Root certificates of TLS connections: **Click the toggle to enable the certificate validation for the connection between your Syslog server and ESET PROTECT. After enabling the validation, a new text field will be displayed where you can copy and paste the required certificate chain. The server certificate must meet the following requirements:
- The whole certificate chain in PEM format is uploaded and saved in the Syslog export configuration (this includes root CA, as there are no built-in trusted certificates)
- Your Syslog server's certificate provides a Subject Alternative Name extension (DNS=/IP=), in which at least one record corresponds to the FQDN/IP hostname configuration.
> You need the certification authority version 3 (and later) with the Basic Constraints certificate extension to pass the validation.
>
> The validation of TLS connections applies only to the certificates. Disabling the validation does not affect the TLS settings of ESET PROTECT.
After making the applicable changes, click **Apply settings**. The configuration becomes effective in 10 minutes.
>
The regular application log file is constantly being written to. Syslog only serves as a medium to export certain asynchronous events, such as notifications or various client computer events.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# ESET Threat Intelligence Integrations
ESET Threat Intelligence provides advanced, real-time insights into global cybersecurity threats, empowering you to proactively defend your network and systems. By leveraging a vast database of threat data, it enables you to detect and respond to emerging threats, track attack trends, and enhance your security posture with actionable intelligence. With ESET Threat Intelligence, you can make informed decisions to protect your organization from sophisticated cyber threats.
---
#### **Setup:**
**1) Log Collector must be installed.**
**2) Prepare the information from the ESET Threat Intelligence Account:**
- Ensure that you have access to **ESET Threat Intelligence** feeds (via ESET Threat Intelligence API or downloadable data).
- Please prepare the **Username** and **Password** that you have received from ESET during their onboarding process.
---
### **References Information:**
#### **Data streams**
This integration connects with the ESET Threat Intelligence **TAXII version 2 server**. It includes the following datasets for retrieving logs:
Dataset
TAXII2 Collection name
apt
apt stix 2.1
botnet
botnet stix 2.1
cc
botnet.cc stix 2.1
domains
domain stix 2.1
files
file stix 2.1
ip
ip stix 2.1
url
url stix 2.1
#### **Obtaining an API Key for ESET Threat Intelligence**
**Usage of the ESET Threat Intelligence (ETI) API**
The **ESET Threat Intelligence (ETI) API** can be used directly in a web browser’s address bar as a REST API, meaning that it does not necessarily require implementation in a programming language. This allows for a straightforward integration of threat intelligence data without the need for additional software development.
**Authentication**
Authentication with the ETI API is managed via a **token**. This token can be generated in the profile section of the ESET Threat Intelligence portal. It is important to note that each token is valid for **only one hour**, ensuring secure access to the API.
To generate a token, users can either manually generate it through the portal interface or use a **CURL request**. This approach provides flexibility, allowing automated generation of tokens for integration or scheduled use.
> ##### **Generate via CURL Request**
>
> Step 1: Open a Command-Line Interface (CLI)
>
> - **Windows**: Open Command Prompt (cmd) or PowerShell.
> - **macOS/Linux**: Open Terminal.
>
> Step 2: Enter the CURL Command
>
> In the command-line interface, use the following CURL command to generate an authentication token:
>
> **curl -F name="YOUR-USERNAME" -F pass="YOUR-PASSWORD" ETI\_URL/auth/**
>
> Step 3: Copy and save the authentication token
***Note.***
*After 10 failed login attempts within 5 minutes, the user will be blocked for 15 minutes.*
*After 20 failed attempts from a specific IP address within 5 minutes, all login attempts from that IP will be blocked for 15 minutes.*
*If you need further assistance, kindly contact our support at [support@cytechint.com](mailto:info@cytechint.com) for prompt assistance and guidance.*
# F5 Integrations
##### **Introduction**This document shows information related to F5 Integration. The F5 BIG-IP integration allows users to monitor LTM, AFM, APM, ASM, and AVR activity. F5 BIG-IP covers software and hardware designed around application availability, access control, and security solutions.The F5 BIG-IP integration can be used in three different modes to collect data:HTTP Endpoint mode - F5 BIG-IP pushes logs directly to an HTTP endpoint hosted by users’ Elastic Agent.AWS S3 polling mode - F5 BIG-IP writes data to S3 and Elastic Agent polls the S3 bucket by listing its contents and reading new files.AWS S3 SQS mode - F5 BIG-IP writes data to S3, S3 pushes a new object notification to SQS, Elastic Agent receives the notification from SQS, and then reads the S3 object. Multiple Agents can be used in this mode.For example, users can use the data from this integration to analyze the traffic that passes through their F5 BIG-IP network.
##### **Data streams**The F5 BIG-IP integration collects one type of data stream: log.Log help users to keep a record of events happening on the network using telemetry streaming. The log data stream collected by the F5 BIG-IP integration includes events that are related to network traffic. See more details in the Logs.This integration targets the five types of events as mentioned below:
**LTM** provides the platform for creating virtual servers, performance, service, protocol, authentication, and security profiles to define and shape users’ application traffic. For more information, refer to the link here.
**AFM** is designed to reduce the hardware and extra hops required when ADC's are paired with traditional firewalls and helps to protect traffic destined for the user's data center. For more information, refer to the link here.
**APM** provides federation, SSO, application access policies, and secure web tunneling and allows granular access to users' various applications, virtualized desktop environments, or just go full VPN tunnel. For more information, refer to the link here.
**ASM** is F5's web application firewall (WAF) solution. It allows users to tailor acceptable and expected application behavior on a per-application basis. For more information, refer to the link here.
**AVR** provides detailed charts and graphs to give users more insight into the performance of web applications, with detailed views on HTTP and TCP stats, as well as system performance (CPU, memory, etc.). For more information, refer to the link here.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**Elasticsearch is needed to store and search data, and Kibana is needed for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your hardware.The reference link for requirements of telemetry streaming is here.
This module has been tested against F5 BIG-IP version 16.1.0, Telemetry Streamingversion 1.32.0 and AS3 version 3.40.0.
##### **Setup**
**To collect LTM, AFM, APM, ASM, and AVR data from F5 BIG-IP, the user has to configure modules in F5 BIG-IP as per the requirements.**To set up the F5 BIG-IP environment, users can use the BIG-IP system browser-based Configuration Utility or the command line tools that are provided. For more information related to the configuration of F5 BIG-IP servers, refer to F5 support website[ here](https://support.f5.com/csp/knowledge-center/software).
[https://support.f5.com/csp/knowledge-center/software](https://support.f5.com/csp/knowledge-center/software)
##### **Configuration of Telemetry Streaming in F5**For downloading and installing Telemetry Streaming, refer to the link [here](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/installation.html).https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/installation.html
Telemetry Streaming will send logs in the JSON format to the destination. Telemetry Streaming is compatible with BIG-IP versions 13.0 and later. Users have to prepare F5 servers for it and set up the Telemetry Streaming Consumer.To use telemetry streaming, userhave to send POST request on https://<BIG-IP>/mgmt/shared/telemetry/declare for declaration.F5 BIG-IP modules named LTM, AFM, ASM, and APM are not configured by Telemetry Streaming, they must be configured with AS3 or another method. Reference link for setup AS3 extension in F5 BIG-IP is [here](https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/).To configure logging using AS3, refer to the [link here](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/event-listener.html?highlight=as3#configure-logging-using-as3).
[https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/event-listener.html?highlight=as3#configure-logging-using-as3](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/event-listener.html?highlight=as3#configure-logging-using-as3)
##### **To collect data from AWS S3 Bucket, follow the below steps:**
- Create an Amazon S3 bucket. Refer to the link [here](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html).
- The default value of the "Bucket List Prefix" is listed below. However, the user can set the parameter "Bucket List Prefix" according to the requirement.
##### **To collect data from AWS SQS, follow the below steps:**
- If data forwarding to an AWS S3 Bucket hasn't been configured, then first set up an AWS S3 Bucket as mentioned in the above documentation.
- To set up an SQS queue, follow "Step 1: Create an Amazon SQS queue" mentioned in the [Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ways-to-add-notification-config-to-bucket.html). [https://docs.aws.amazon.com/AmazonS3/latest/userguide/ways-to-add-notification-config-to-bucket.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ways-to-add-notification-config-to-bucket.html)
- - While creating an SQS Queue, please provide the same bucket ARN that has been generated after creating an AWS S3 Bucket.
- Set up event notifications for an S3 bucket. Follow this [link](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications.html). [https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications.html)
- - Users have to set the prefix parameter the same as the S3 Bucket List Prefix as created earlier. (for example, log/ for a log data stream.)
- Select the event type as s3:ObjectCreated:\*, select the destination type SQS Queue, and select the queue that has been created in Step 2.
**Note**:
- Credentials for the above AWS S3 and SQS input types should be configured using the [link](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-aws-s3.html#aws-credentials-config). [https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-aws-s3.html#aws-credentials-config](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-aws-s3.html#aws-credentials-config)
- Data collection via AWS S3 Bucket and AWS SQS are mutually exclusive in this case.
**Enabling the integration in Elastic**
1. In Kibana go to Management > Integrations.
2. In the "Search for integrations" search bar, type F5 BIG-IP.
3. Click on F5 BIG-IP integration from the search results.
4. Click on the Add F5 BIG-IP button to add F5 BIG-IP integration.
5. Enable the Integration to collect logs via AWS S3 or HTTP endpoint input.
##### **F5 BIG-IP integration**The "Integration name" and either the "Description" and the followingwill need to be provided in the Configure integration when adding theF5 BIG-IP integration.**Procedures**:Please provide the following information to CyTech:
**Collect F5 BIG-IP logs via HTTP Endpoint:**
1. Listen Address - The bind address to listen for http endpoint connections. Set to 0.0.0.0 to bind to all available interfaces.
**F5 BIG-IP logs via HTTP Endpoint:**
1. Listen Port - The port number the listener binds to.
# Forescout
#### Method 1: Network logs forwarding
The Network logs forwarding page ("Settings" > "System Settings" > "Network logs forwarding") allows users to enable and configure the forwarding of Network Logs to a third-party solution by means of syslog messages. The pages and configuration steps required to enable forwarding of Network Logs are exactly the same as those described for Alerts. The only difference lies in the semantics adopted when users un-tick the "always active" checkbox in the alert forwarding conditions, but leave the conditions "tree" empty. For Alerts, this results in all alerts being forwarded, whereas for Network Logs, this results in no log begin forwarded. The rationale is that Alerts are important events that are generally desirable to be forwarded to an analyst, whereas Network Logs are useful additional intelligence for context and threat hunting. This choice of default behavior is to prevent user mistakes in the configuration of eyeInspect to impact their monitoring capabilities. Pre-set messages for CEF, LEEF and JSON (Splunk) are available also for Network Logs forwarding.
Source: *[https://docs.forescout.com/bundle/eyeinspect-user-guide-v5-5-0/page/gitdoc-eyeinspect/eyeInspect/eyeInspect\_User\_Guide/network-logs-forwarding.html](https://docs.forescout.com/bundle/eyeinspect-user-guide-v5-5-0/page/gitdoc-eyeinspect/eyeInspect/eyeInspect_User_Guide/network-logs-forwarding.html)*
#### Configure the plugin receiver port
Configure the Syslog plugin port for receiving syslog events for each Forescout Platform device configured as a syslog server (receiver of wireless events and/or switch events) in the management interface. Each device receives syslog events sent from managed, individual network devices.
To configure the port for receiving syslog events:
1. Select Tools > Options.
2. From the Options pane, select Syslog.
3. Select the Receive From tab and specify this information:
Source Type
IP Address
Specify the syslog server IP address.
UDP Port
- Cisco Meraki: Specify the port number that you configured for the syslog server port in the Meraki Dashboard. Cisco Meraki only supports using UDP protocol for sending syslog events.
- Ruckus SmartZone: Specify the port number that you configured the syslog server port and protocol in the Ruckus SmartZone Web GUI
- Arista CloudVision WiFi: Arista CloudVision WiFi only supports using port 514 for sending syslog events.
TCP Port
Prisma Access: Specify port 514.
Use TLS
Optional. Select this checkbox to instruct Forescout Platform to encrypt communication with the syslog sources. For required certificates when using "Receive From" syslog servers, refer to: [Certificate Management](https://docs.forescout.com/csh?context=certificate-management) in the Syslog Plugin Configuration Guide.
4. Select Apply > Yes.
5. Repeat steps 4–8 for each device configured as a syslog server in the management interface.
#### Verify the plugin is running
Verify that the Syslog plugin is running in all of the Forescout Platform devices that are configured in the management interface as syslog servers (In the Console, select Options > Modules and expand the Core Extensions module entry).
If the plugin is not running in all of these Forescout Platform devices, select Syslog > Start.
Source: *https://docs.forescout.com/bundle/network-cntrlr-1-2-8-h/page/c-syslog-plugin-configuration-p-d1e1407.html*#### Method 2: Generate an API key for application integrationTo generate an API key for your custom application to query ingested log telemetry and other sources of data, complete the following procedure:
1. In Forescout Cloud Console, select **Integrations** under the **Administration** menu.
2. Click the **Generate API Key** button next to the category of your application - **IoT/OT** or **SIEM**.The **Generate API Key** configuration screen appears.
3. Select a time for the API key to expire or select "Never Expires".
4. Select users to receive Email notifications about the API key generation and expiry date.
5. Click the **Generate** button and copy the API key that appears. This API key is unique and non-retrievable once the window is closed. Store the key in a secure location now; it will be needed by the application with which you are integrating.
When generating an API key for Risk Sharing applications, the configuration screen will display the API endpoint URL needed to communicate with the API.
# Fortinet-Fortigate Integrations
#### **Introduction**This integration is for Fortinet FortiGate logs sent in the syslog format.
---
#### **Pre-requisite:**
##### **Configure syslog on FortiGate**From the GUI:
1. Log into **FortiGate.**
2. Select **Log & Report **to expand the menu.
3. Select **Log Settings.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/NA3iNK8MP2c3LEAA-image.png)
4. Toggle Send Logs to Syslog to **Enabled.******
5. Enter the Syslog Collector **IP address.** Note: IP Address must be **host's IP Address** where the **Elastic-Agent is installed.** (For example. 192.168.1.19 as shown below)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/ab1wMS7UhXMWF0YG-image.png)
**If it is necessary to customize the port or protocol or setup the Syslog from the CLI below are the commands:**
**config log syslogd setting **
set status enable set server "192.168.1.19" -- change IP Address to same as host's where Elastic Agent is installed set mode udp set port 514end
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/7sr8rOWpIXaLJmLL-image.png)
**To establish the connection to the Syslog Server using a specific Source IP Address, use the below CLI configuration: **
**config log syslogd setting**
set status enable set server "192.168.1.19" -- change ip address to match host's IP set source-ip "172.16.1.1" -- change ip address to match host's source-ip address set mode udp set port 514end
---
#### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
**Compatibility**
This integration has been tested against FortiOS versions 6.x and 7.x up to 7.4.1. Newer versions are expected to work but have not been tested.
**Note**
- When using the TCP input, be careful with the configured TCP framing. According to the [Fortigate reference](https://docs.fortinet.com/document/fortigate/7.4.0/cli-reference/405620/config-log-syslogd-setting), framing should be set to `rfc6587` when the syslog mode is reliable.
---
#### **Fortinet FortiGate Integration Procedures**Please provide the following information to **CyTech:******
**Collect Fortinet FortiGate logs (input: tcp)**
1. Listen Address - The bind address to listen for TCP connections.
2. Listen Port - The TCP port number to listen on.
**Collect Fortinet FortiGate logs (input: udp)**
1. Listen Address - The bind address to listen for UDP connections.
2. Listen Port - The UDP port number to listen on.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Forwarding logs from rsyslog client to a remote rsyslogs server
### Introduction
This guide will walk you through setting up Rsyslog for log forwarding between a client and a remote server using Linux.
#### Setup
**Server:** The machine which will send message
**Client:** The machine which will receive the message
#### Prerequisites
Software Requirements
- - Linux operating system
- Rsyslog (version 5.0 or higher recommended)
- Root or sudo access
#### Network Requirements
- - Network connectivity between client and remote server
- Known IP address of the remote Rsyslog server
- Open network ports (typically 514 for UDP or TCP)
#### Step-by-Step Configuration Guide
##### Preparation
Before beginning, ensure you have:
- - Administrative (root) access
- Stable network connection
- IP address of the remote server
##### Step 1: Rsyslog Installation
1.1 Obtain Root Access
```
sudo -i
```
- Enter your root password when prompted
1.2 Update System Packages
If you are using DNF, use the command below:
```bash
sudo dnf update
```
If you are using YUM, use the command below:
```
sudo yum update
```
1.3 Install Rsyslog
If you are using YUM, use the command below:
```
sudo yum install rsyslog
```
If you using DNF, use the command below:
```
sudo dnf install rsyslog
```
*Verification Tip: Confirm Rsyslog is installed successfully*
1.4 Start and Enable Rsyslog Service
```
sudo systemctl enable rsyslog
sudo systemctl start rsyslog
```
1.5 Check Rsyslog Status
```
sudo systemctl status rsyslog
```
*Expected Result*: Service should be in an active state
##### Step 2: Rsyslog Server and Client Configuration
The following steps outline how to forward system logs to a remote server using either TCP or UDP ports. You can choose to use either TCP or UDP, but if both are enabled, ensure that each protocol uses a different port.
2.1 Edit Rsyslog Configuration. Open using a text editor such as "vi" or "nano".
```
vi /etc/rsyslog.conf
```
2.2 Enable UDP or TCP Modules. This should be done on the Client machine only.
\- For **UDP**, locate and uncomment the following lines by removing the `#` symbol. The default port is 514, but you can change it if necessary.
```
$Modload imudp
$UDPServerRun 514
```
\- For **TCP**, locate and uncomment the following lines by removing the `#` symbol. The default port is 10514, but you can change it if necessary.
```
$Modload imtcp
$inputTCPServerRun 10514
```
2.3 Configure Log Template
Add the following line to define log storage:
```
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& ~
```
2.4 **On Server**
Add content below at the end of the file */etc/rsyslog.conf.*
This will configure the log forwarding to the remote host. Please update the "target", "port" and "tcp" appropriately.
```
*.* action(type="omfwd"
queue.type="LinkedList"
action.resumeRetryCount="-1"
queue.size="10000"
queue.saveonshutdown="on"
target="10.43.138.1" Port="10514" Protocol="tcp")
```
**queue.type** enables a LinkedList in-memory queue, queue\_type can be *direct*, *linkedlist* or *fixedarray* (which are in-memory queues), or disk.
enabled **queue.saveonshutdown** saves in-memory data if rsyslog shuts down,
**action.resumeRetryCount**= “-1” setting prevents rsyslog from dropping messages when retrying to connect if server is not responding,
**queue.size** where size represents the specified size of disk queue part. The defined size limit is not restrictive, rsyslog always writes one complete queue entry, even if it violates the size limit.
**target** is the IP Address of the remote machine
**Port** is the port of the remote machine
**Protocol** is the protocol to be used. Values can be udp or tcp.
2.5 Add port in the firewall rules
**On client side**
Add the provided port to the firewall
```
iptables -A INPUT -p tcp --dport 10514 -j ACCEPT
```
Next open the port using nc
```
nc -l -p 10514 -4
```
2.6 Apply Server Configuration
```
systemctl restart rsyslog
```
2.7 Verify Log Directory
Type : ls -1
Expected Result:
Should see a directory with the client's hostname
Contains files like `rsyslogd.log` and `systemd.log`
**Troubleshooting Tips**
Ensure firewall settings allow log forwarding
Verify network connectivity between client and server
Check Rsyslog service status if logs aren't forwarding
**Security Considerations**
\- Configure firewall rules appropriately
\- Use encrypted log transmission when possible
\- Regularly review and rotate logs
**Common Issues**
1\. Port Blocking: Ensure port 514 is open
2\. Permission Errors Verify root/sudo access
3\. Network Connectivity: Check server IP and network settings
**Conclusion**
By following these steps, you should have successfully configured Rsyslog for log forwarding between a client and a remote server.
\*\*Note:\*\* Always test in a controlled environment first and adapt instructions to your specific system configuration.
# GCP - How to Add a Role
1.
Go to the Google Cloud Console.
2.
Navigate to IAM.
3.
Click on "IAM & Admin" in the left navigation menu.
13. After saving, the service account should display all the newly added roles in the IAM permissions list.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/nS29bd2IiOmAyaMp-embedded-image-l35mcgkx.png)
# GCP - How to enable Cloud Asset API
Please refer to these instructions to enable Cloud Asset API.
To enable the Cloud Asset API for your Google Cloud project, follow these steps:
1.
**Go to the Google Cloud Console**:
-
Navigate to Google Cloud Console.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/vjGmkqtqTLwRb2DY-outlook-4l0dvbcd.png)
2.
**Select Your Project**:
-
From the top project drop-down, select the Google Cloud project "**neriviodata-prod**" where you want to enable the Cloud Asset API.
In the search box, type **"Cloud Asset API"**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/JvNZIHMtE2zuTb9b-embedded-image-hnfyxmsn.png)
-
Click on **Cloud Asset API** in the search results. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/ma0kyP9uxqMw2d84-embedded-image-chr092ti.png)
Once enabled, you can verify that the Cloud Asset API is active by going to **APIs & Services** > **Dashboard** and checking for the Cloud Asset API in the list of enabled APIs.
For **Sink destination**, select **"Cloud Pub/Sub topic"**. Choose an existing topic "cytech-elasticsearch".
4.
Under **"Choose logs to include in sink"**, use a filter like: **logName:"cloudaudit.googleapis.com"**
5.
Create Sink.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/P2tC2aPZvQOAeYCH-embedded-image-zo9vmdpw.png)
# GCP and CSPM-GCP Integration
This Google Cloud integration collects and analyzes a wide range of logs and metrics to provide comprehensive visibility into your cloud environment. It ingests **Firewall Logs**, **VPC Flow Logs**, **DNS Logs**, and **Load Balancing Logs** exported from **Cloud Logging** via a **Pub/Sub topic sink**. Additionally, it gathers detailed **metrics and metadata** from **Google Cloud Monitoring** across core services, including **Compute Engine**, **Cloud SQL**, **Cloud Run**, **GKE**, **Firestore**, **Dataproc**, **Pub/Sub**, **Redis**, **Storage**, **Load Balancing**, and **Billing**. This enables in-depth monitoring of infrastructure, application performance, network activity, and cost trends.
##### **Logs**
- **Firewall Logs**: Record allowed and denied network traffic based on firewall rules.
- **VPC Flow Logs**: Capture IP traffic flowing to and from network interfaces in a VPC.
- **DNS Logs**: Track DNS queries and responses handled by Google Cloud DNS.
- **Load Balancing Logs**: Provide request-level logs of traffic handled by load balancers, including latency and backend info.
---
##### **Metrics**
- **GCP Billing Metrics**: Track resource usage and cost across GCP services.
- **GCP Compute Metrics**: Monitor performance of Compute Engine instances (CPU, memory, disk, etc.).
- **GCP Firestore Metrics**: Provide insights into Firestore usage like reads, writes, and storage.
- **GCP Load Balancing Metrics**: Measure load balancer traffic, request counts, latency, and backend health.
- **GCP Storage Metrics**: Report usage, operation counts, and latency for Cloud Storage buckets.
- **GCP GKE Metrics**: Monitor Kubernetes clusters including node health, pod usage, and resource consumption.
- **GCP Dataproc Metrics**: Track job status, cluster usage, and Hadoop/Spark performance in Dataproc.
- **GCP PubSub Metrics**: Show message throughput, subscription rates, and processing latency.
- **GCP Redis Metrics**: Display memory usage, operations per second, and cache hit/miss rates for Memorystore Redis.
- **GCP Cloud Run Metrics**: Measure request counts, container instance metrics, and response times.
- **GCP CloudSQL Metrics**: Provide visibility into database performance, including connections, query latency, and CPU usage.
##### **Authentication**
To use this Google Cloud Platform (GCP) integration, you need to set up a ***Service Account*** with a ***Role*** and a ***Service Account Key*** to access data on your GCP project.
##### **1. Service Account**
First, you need to [create a Service Account](https://cloud.google.com/iam/docs/creating-managing-service-accounts). A Service Account (SA) is a particular type of Google account intended to represent a non-human user who needs to access the GCP resources.
The AQUILA Agent uses the SA to access data on Google Cloud Platform using the Google APIs.
##### **2. Required IAM Service Account Roles:****For CSPM-GCP Integration**
- **Browser**: This role grants read access to the project hierarchy.
- **Cloud Asset Viewer**: Can view asset metadata across GCP services.
**For GCP Integation**
- **Cloud Memorystore Redis Viewer**: Can view configuration and metadata of Redis instances.
- **Cloud SQL Viewer**: Can view Cloud SQL instance metadata and settings, but not data.
- **Compute Viewer**: Can view all Compute Engine resources (instances, disks, etc.) but not modify them.
- **Logs Viewer**: Can view logs in Cloud Logging across the project.
- **Monitoring Viewer**: Can view monitoring dashboards, alerts, and metrics in Cloud Monitoring.
- **Private Logs Viewer**: Can view all logs, including those with restricted data (e.g., data access logs).
- **Pub/Sub Subscriber**: Grants permission to receive and acknowledge messages from Pub/Sub subscriptions.
- **Viewer**: Read-only access to all resources in a project.
##### **3. Logs Collection Configuration**With a properly configured Service Account and the integration setting in place, it’s time to start collecting some logs.**Requirements**You need to create a few dedicated Google Cloud resources before starting, in detail:
- **Pub/Sub Topic**: A messaging endpoint where publishers send messages that can then be delivered to one or more subscribers.
- **Subscription**: A configuration attached to a Pub/Sub topic that delivers messages to subscribers, either by push or pull.
- **Log Sink**: A configuration that routes logs from Cloud Logging to a specified destination such as Pub/Sub, Cloud Storage, or BigQuery.
It’srecommendedto have a separate Pub/Sub topics for each of the log types so that they can be parsed and stored in a specific data stream.
Here’s an example of collecting Audit Logs using a Pub/Sub topic, a subscription, and a Log Router. We will create the resources in the Google Cloud Console and then configure the Google Cloud Platform integration.
##### **Example Setup Using Google Cloud Console**
1. Navigate to **"Logging" > "Log Router" > "Create Sink"**.
2. Provide a **Sink name** and description.
3. For **Sink destination**, select **"Cloud Pub/Sub topic"**. Choose an existing topic or create a new one.
4. If a new topic is created, you must also **create a subscription** for it.
5. Under **"Choose logs to include in sink"**, use a filter like: logName:"cloudaudit.googleapis.com"
##### **4. Enable API Services**
- **Cloud Asset API**: Provides metadata inventory and history of GCP resources and IAM policies for security analysis, audit, and compliance.
- **Cloud SQL Admin API**: Enables programmatic management of Cloud SQL instances, including creation, configuration, and backups.
- **Memorystore for Redis API**: Allows automated management of Redis instances on Memorystore, including provisioning, scaling, and configuration.
##### **5. Service Account Key **Next, with the Service Account (SA) with access to Google Cloud Platform (GCP) resources setup, you need some credentials to associate with it: a Service Account Key. From the list of SA (Service Accounts):
1. Go to **IAM & Admin > Service Accounts** in the GCP Console.
2. Click the service account you created.
3. Under the **"Keys"** section, click **"Add Key" > "Create new key"**.
4. Choose **JSON** as the key type.
5. **Download and securely store** the generated private key (it cannot be retrieved again from GCP if lost).
**Please provide the following information to CyTech:**
- **Project ****ID** -The Project ID is the Google Cloud project ID where your resources exist.
- **Credentials File** - Save the JSON file with the private key in a secure location of the file system, and make sure that the Log Collector Agent has at least read-only privileges to this file.Specify the file path in the Log Collector Agent integration UI in the "Credentials File" field. For example: /home/ubuntu/credentials.json.
- **Pub/Sub Topic**- Name of the topic where the logs are written to.
- **Subscription** - Use the short subscription name here, not the full-blown path with the project ID. You can find it as "Subscription ID" on the Google Cloud Console.
# GitHub
##### **Introduction**The GitHub integration collects events from the [GitHub API](https://docs.github.com/en/rest?apiVersion=2022-11-28).
Logs
##### **Audit**The GitHub audit log records all events related to the GitHub organization. To use this integration, you must be an organization owner, and you must use an Personal Access Token with the admin:org scope.This integration is not compatible with GitHub Enterprise server.
##### **Code Scanning**The Code Scanning lets you retrieve all security vulnerabilities and coding errors from a repository setup using Github Advanced Security Code Scanning feature. To use this integration, GitHub Apps must have the security\_events read permission. Or use a personal access token with the security\_events scope for private repos or public\_repo scope for public repos.
##### **Secret Scanning**The Github Secret Scanning lets you retrieve secret scanning for advanced security alerts from a repository setup using Github Advanced Security Secret Scanning feature. To use this integration, GitHub Apps must have the secret\_scanning\_alerts read permission. Or you must be an administrator for the repository or for the organization that owns the repository, and you must use a personal access token with the repo scope or security\_events scope. For public repositories, you may instead use the public\_repo scope.
##### **Dependabot**The GithubDependabot lets you retrieve known vulnerabilities in dependencies from a repository setup using Github Advanced Security Dependabot feature. To use this integration, you must be an administrator for the repository or for the organization that owns the repository, and you must use a personal access token with the repo scope or security\_events scope. For public repositories, you may instead use the public\_repo scope.
##### **Issues**The Github Issues datastream lets you retrieve github issues, including pull requests, issue assignees, comments, labels, and milestones. See About Issues for more details. You can retrieve issues for specific repository or for entire organization. Since Github API considers pull requests as issues, users can use github.issues.is\_pr field to filter for only pull requests.All issues including closed are retrieved by default. If users want to retrieve only open requests, you need to change State parameter to open.To use this integration, users must use Github Apps or Personal Access Token with read permission to repositories or organization. Please refer to Github Apps Permissions Required and Personal Access Token Permissions Required for more details.
##### **GitHub Integration Procedures**
This integration is not compatible with GitHub Enterprise server.
Please provide the following information to CyTech:1.Select Settings2.Select Developer Settings3. Select token (classic)4. Select scopeadmin:scope
##### **Collect GitHub logs via** **API******
1. Personal Access Token - the GitHub Personal Access Token. Requires the 'admin:org' scope
2. Organization Name - The GitHub organization name/ID
##### **GHAS Code Scanning******
1. Personal Access Token - the GitHub Personal Access Token. Requires the 'public\_repo' scope for public repositories and 'security\_events' scope for private repositories. \\nSee List code scanning alerts for a repository
2. Repository owner - The owner of GitHub Repository. If repository belongs to an organization, owner is name of the organization
##### **GHAS Dependabot**
1. Personal Access Token - The GitHub Personal Access Token. \\nSee Authenticating with GraphQL
2. Repository owner - The owner of GitHub Repository
##### **Github Issues**1.Personal Access Token - the GitHub Personal Access Token.2.Repository owner - The owner of GitHub Repository. If repository belongs to an organization, owner is name of the organization.
##### **GHAS Secret Scanning******1.Personal Access Token - the GitHub Personal Access Token. Requires admin access to the repository or organization owning the repository along with a personal access token with 'public\_repo' scope for public repositories and repo or security\_events scope for private repositories. \\nSee List secret scanning alerts for a repository2.Repository owner - The owner of GitHub Repository
# GitHub Integration
### GitHub Integration
The GitHub integration collects events from the [GitHub API](https://docs.github.com/en/rest).
#### Logs
##### Audit
The GitHub audit log records all events related to the GitHub organization. See [Audit log actions](https://docs.github.com/en/organizations/keeping-your-organization-secure/reviewing-the-audit-log-for-your-organization#audit-log-actions) for more details.
To use this integration, the following prerequisites must be met:
- You must be an organization owner.
- You must be using Github Enterprise Cloud.
- You must use a Personal Access Token with `read:audit_log` scope.
*This integration is not compatible with GitHub Enterprise server.*
##### Code Scanning
The Code Scanning lets you retrieve all security vulnerabilities and coding errors from a repository setup using Github Advanced Security Code Scanning feature. See [About code scanning](https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning) for more details.
To use this integration, GitHub Apps must have the `security_events` read permission. Or use a personal access token with the `security_events` scope for private repos or `public_repo` scope for public repos. See [List code scanning alerts](https://docs.github.com/en/enterprise-cloud@latest/rest/code-scanning#list-code-scanning-alerts-for-a-repository)
##### Secret Scanning
The Github Secret Scanning lets you retrieve secret scanning for advanced security alerts from a repository setup using Github Advanced Security Secret Scanning feature. See [About Secret scanning](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/about-secret-scanning) for more details.
To use this integration, GitHub Apps must have the `secret_scanning_alerts` read permission. Or you must be an administrator for the repository or for the organization that owns the repository, and you must use a personal access token with the `repo` scope or `security_events` scope. For public repositories, you may instead use the `public_repo` scope. See [List secret scanning alerts](https://docs.github.com/en/enterprise-cloud@latest/rest/secret-scanning#list-secret-scanning-alerts-for-a-repository)
##### Dependabot
The Github Dependabot lets you retrieve known vulnerabilites in dependencies from a repository setup using Github Advanced Security Dependabot feature. See [About Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-alerts) for more details.
To use this integration, you must be an administrator for the repository or for the organization that owns the repository, and you must use a personal access token with the `repo` scope or `security_events` scope. For public repositories, you may instead use the `public_repo` scope. See [Authenticating with GraphQL](https://docs.github.com/en/graphql/guides/forming-calls-with-graphql#authenticating-with-graphql) and [Token Issue](https://github.com/dependabot/feedback/issues/169)
##### Issues
The Github Issues datastream lets you retrieve github issues, including pull requests, issue assignees, comments, labels, and milestones. See [About Issues](https://docs.github.com/en/rest/issues/issues?apiVersion=latest) for more details. You can retrieve issues for specific repository or for entire organization. Since Github API considers pull requests as issues, users can use `github.issues.is_pr` field to filter for only pull requests.
All issues including `closed` are retrieved by default. If users want to retrieve only `open` requests, you need to change `State` parameter to `open`.
To use this integration, users must use Github Apps or Personal Access Token with `read` permission to repositories or organization. Please refer to [Github Apps Permissions Required](https://docs.github.com/en/rest/overview/permissions-required-for-github-apps?apiVersion=latest) and [Personal Access Token Permissions Required](https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=latest) for more details.
# GitHub Integration
# **GitHub Integration**
## **Introduction**
Elastic’s GitHub integration allows you to ingest GitHub logs, alerts, and developer activities into the Elastic Stack for centralized analysis. This supports use cases like vulnerability management, compliance auditing, and DevSecOps monitoring.
Note: This integration is only compatible with **GitHub Enterprise Cloud** and is **not supported on GitHub Enterprise Server**.
---
## **GitHub Data Streams Overview**
Feature
Integration Type
Description
Audit Logs
PAT
Track org-level admin and security events
Code Scanning
GitHub App / PAT
Pull static analysis results from GitHub Advanced Security
Secret Scanning
GitHub App / PAT
Detect exposed secrets (API keys, tokens, etc.) in repositories
Dependabot Alerts
GitHub App / PAT
Retrieve alerts on insecure open-source dependencies
Issues & PRs
GitHub App / PAT
Sync issues, pull requests, comments, labels, and milestones
---
## **Option 1: GitHub Audit Logs**
**Description:**
Audit logs contain records of all administrative and security events within a GitHub organization.
### Requirements
- GitHub Enterprise Cloud
- You must be an organization owner
- Use a Personal Access Token (PAT) with `read:audit_log` scope
### What It Does
- Captures repository creation, permission changes, team updates, and more
- Helps detect suspicious or non-compliant behavior
### Setup Steps
1. **Create a PAT**
- Go to GitHub → Developer Settings → Personal Access Tokens
- Click "Generate new token"
- Select `read:audit_log` scope
- Save the token securely
2. **Configure Integration in Elastic**
- Navigate to Integrations in Kibana
- Search for "GitHub" and click "Add GitHub integration"
- Select the "Audit Logs" data stream
- Enter your organization name and paste your PAT
3. **Test and Deploy**
- Click "Test integration" to verify connectivity
- Choose a data stream name and index settings
- Click "Save and Deploy"
4. **Verify in Kibana**
- Navigate to Discover
- Use the index pattern `logs-github.audit-*`
- Filter using fields such as `actor`, `action`, or `created_at`
---
## **Option 2: Code Scanning Alerts**
**Description:**
Collect static code analysis results from GitHub Advanced Security Code Scanning.
### Requirements
- Code Scanning must be enabled per repository
- Use either:
- GitHub App with `security_events` read permission
- PAT with:
- `security_events` (for private repositories)
- `public_repo` (for public repositories)
### What It Does
- Ingests vulnerabilities and insecure code patterns
- Supports SARIF format scan results
### Setup Steps
1. **Enable Code Scanning in GitHub**
- Go to your repository → Security → Code scanning alerts
- Enable GitHub Advanced Security
- Configure workflows such as CodeQL
2. **Generate PAT or GitHub App**
- If using a PAT, ensure it includes `security_events` or `public_repo` scope
3. **Configure Integration in Elastic**
- Open Integrations in Kibana
- Add GitHub integration and select "Code Scanning"
- Input organization name and credentials
4. **Test and Configure**
- Test the integration
- Set polling frequency (e.g., every 5 minutes)
- Save and deploy
5. **Monitor in Kibana**
- Use Discover with the index pattern `logs-github.code_scanning-*`
- Filter by fields such as `severity`, `rule_id`, or `repository.name`
---
## **Option 3: Secret Scanning Alerts**
**Description:**
Detect and alert on exposed secrets in source code repositories.
### Requirements
- Secret Scanning must be enabled in repository settings
- You must be a repository or organization administrator
- Use either:
- GitHub App with `secret_scanning_alerts` read permission
- PAT with:
- `repo` or `security_events` (for private repos)
- `public_repo` (for public repos)
### What It Does
- Flags exposed API keys, tokens, and credentials
- Helps prevent credential leaks
### Setup Steps
1. **Enable Secret Scanning**
- Go to GitHub repo → Settings → Code Security and Analysis
- Enable "Secret scanning alerts"
2. **Generate Access**
- Create a PAT with appropriate scopes
- Or set up a GitHub App with necessary permissions
3. **Configure in Elastic**
- Go to the GitHub integration in Kibana
- Enable the "Secret Scanning" stream
- Provide token and repository/org details
4. **Test and Save**
- Test the connection
- Select desired polling interval (e.g., 10 minutes)
- Save and deploy
5. **Analyze Alerts**
- Open Discover and use `logs-github.secret_scanning-*`
- Use filters such as `alert_type`, `secret_type`, and `state`
---
## **Option 4: Dependabot Alerts**
**Description:**
Monitor dependency vulnerabilities in GitHub repositories using Dependabot.
### Requirements
- Dependabot must be enabled in repository settings
- You must be a repository or organization administrator
- Use either:
- GitHub App
- PAT with:
- `repo`, `security_events`, or `public_repo` scope
### What It Does
- Identifies and alerts on known insecure packages
- Includes CVE metadata and suggested fixes
### Setup Steps
1. **Enable Dependabot in GitHub**
- Go to Repository → Settings → Code Security and Analysis
- Enable "Dependency Graph" and "Dependabot alerts"
2. **Generate GitHub App or PAT**
- Ensure scopes include `repo`, `security_events`, or `public_repo`
3. **Configure in Elastic**
- Go to GitHub integration
- Enable "Dependabot"
- Enter org/repo and credentials
4. **Test and Deploy**
- Test the integration
- Select polling interval
- Save settings
5. **Monitor in Kibana**
- Use Discover → `logs-github.dependabot-*`
- Filter by `dependency_name`, `ecosystem`, `severity`, etc.
---
## **Option 5: Issues & Pull Requests**
**Description:**
Ingest GitHub issues, pull requests, comments, labels, milestones, and other metadata.
### Requirements
- Use a GitHub App or PAT with:
- `repo` (for private repositories)
- `public_repo` (for public repositories)
- Optional: `read:org` for org-wide access
### What It Does
- Collects all issue and PR activity
- Enables filtering of pull requests with `github.issues.is_pr = true`
### Setup Steps
1. **Create or Use PAT / GitHub App**
- Ensure appropriate access to repositories
2. **Enable GitHub Integration in Elastic**
- Choose "Issues" as the data stream
- Enter credentials and repository/organization name
3. **Customize Settings**
- Set state filter (e.g., `state=open` for open issues only)
- Configure sync interval
4. **Test and Activate**
- Verify GitHub API connectivity
- Deploy integration
5. **View Data in Kibana**
- Go to Discover → `logs-github.issues-*`
- Use filters such as `assignees`, `labels`, `state`, or `is_pr`
---
## **Comparison Table**
Feature
GitHub App
PAT Support
Required Scopes
Public Repos
Private Repos
Audit Logs
No
Yes
`read:audit_log`
No
Yes
Code Scanning
Yes
Yes
`security_events`, `public_repo`
Yes
Yes
Secret Scanning
Yes
Yes
`repo`, `security_events`, `public_repo`
Yes
Yes
Dependabot Alerts
Yes
Yes
`repo`, `security_events`, `public_repo`
Yes
Yes
Issues & PRs
Yes
Yes
`repo`, `public_repo`, `read:org`
Yes
Yes
---
## **Documentation References**
- Elastic GitHub Integration: [Cytech Docs](https://docs.cytechint.io/link/294#bkmrk-to-use-this-integrat-4)
- GitHub Official Docs:
- [Audit Logs](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/auditing-audit-log)
- [Code Scanning](https://docs.github.com/en/code-security/code-scanning)
- [Secret Scanning](https://docs.github.com/en/code-security/secret-scanning)
- [Dependabot](https://docs.github.com/en/code-security/supply-chain-security)
- [Issues API](https://docs.github.com/en/rest/issues/issues)
# GitLab Integrations
##### **Introduction**Introduced in GitLab Starter 8.4. Supportfor Amazon Elasticsearch was introduced in GitLabStarter 9.0.This document describes how to set up Elasticsearch with GitLab. Once enabled,you'll have the benefit of fast search response times and the advantage of twospecial searches:
- Advance Global Search
- Advanced Syntax Search
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**Elasticsearch 6.0+ is not supported currently. We will support 6.0+ in the future.
##### **GitLabIntegrationProcedures****Procedures**:Please provide the following information to CyTech:Elasticsearch is not included in the Omnibus packages. You will have to install it yourself whether you are using the Omnibus package or installedGitLab from source. Providing detailed information on installing Elasticsearchis out of the scope of this document.Once the data is added to the database or repository and Elasticsearch isenabled in the admin area the search index will beupdated automatically. Elasticsearch can be installed on the same machine asGitLab, or on a separate server, or you can use the Amazon Elasticsearchservice.You can follow the steps as described in the official web site oruse the packages that are available for your OS.
# Google Cloud Platform (GCP) Audit Logs Integration - using Pub/Sub
##### **Requirements **
To integrate with Google Cloud Platform (GCP), you need to set up the following:
1. **Service Account with a Role.**
2. **Service Account Key to access data on your GCP project.**
##### **Service Accounts **
A **Service Account (SA)** is a special type of Google account intended for applications or services—not human users—that need access to GCP resources.
The **Log Collector** uses this SA to access GCP data via Google APIs.
##### **Service Account with a Role**
Assign the necessary privileges by creating a **custom role** with minimal required permissions:
#### Required Permissions:
*\*1 Only required if Agent is expected to create a new subscription. If you create the subscriptions yourself, you may omit these privileges. *
*\*\*2 Only required if corresponding collection will be enabled. *
**After you have created the custom role, assign the role to your service account. **
##### **Service Account Key **
Next, with the Service Account (SA) with access to Google Cloud Platform (GCP) resources setup, you need some credentials to associate with it: a Service Account Key. From the list of SA (Service Accounts):
1. Go to **IAM & Admin > Service Accounts** in the GCP Console.
2. Click the service account you created.
3. Under the **"Keys"** section, click **"Add Key" > "Create new key"**.
4. Choose **JSON** as the key type.
5. **Download and securely store** the generated private key (it cannot be retrieved again from GCP if lost).
##### **GCP Integrations Procedures - GCP Audit Logs **
The audit dataset collects audit logs of administrative activities and accesses within your Google Cloud resources. **Procedures**The "Project Id" and the "Credentials File" will need to be provided in the integration UI when adding the Google Cloud Platform integration.
##### **Logs Collection Configuration**With a properly configured Service Account and the integration setting in place, it’s time to start collecting some logs.
**Requirements**
You need to create a few dedicated Google Cloud resources before starting, in detail:
It’srecommendedto have a separate Pub/Sub topics for each of the log types so that they can be parsed and stored in a specific data stream.
Here’s an example of collecting Audit Logs using a Pub/Sub topic, a subscription, and a Log Router. We will create the resources in the Google Cloud Console and then configure the Google Cloud Platform integration.
##### **Example Setup Using Google Cloud Console**
1. Navigate to **"Logging" > "Log Router" > "Create Sink"**.
2. Provide a **Sink name** and description.
3. For **Sink destination**, select **"Cloud Pub/Sub topic"**. Choose an existing topic or create a new one.
4. If a new topic is created, you must also **create a subscription** for it.
5. Under **"Choose logs to include in sink"**, use a filter like: logName:"cloudaudit.googleapis.com"
**Please provide the following information to CyTech:**
- **Project ****ID** -The Project ID is the Google Cloud project ID where your resources exist.
- **Credentials File** - Save the JSON file with the private key in a secure location of the file system, and make sure that the Log Collector Agent has at least read-only privileges to this file.Specify the file path in the Log Collector Agent integration UI in the "Credentials File" field. For example: /home/ubuntu/credentials.json.
- **Pub/Sub Topic**- Name of the topic where the logs are written to.
- **Subscription** - Use the short subscription name here, not the full-blown path with the project ID. You can find it as "Subscription ID" on the Google Cloud Console.
##### **After setting up GCP. Go to> CISO Workplace to integrate your log source. Please follow the instructions below:**
**Step1: Log in CISO Workplace>CISO Workplace Modules>Cyber Monitoring>Cyber Incident Management**
**Step2: Navigate through Settings>Log Source>Search Bar(type GCP)>Choose the type of GCP*(for example- Google Cloud Platform (GCP) Audit Logs - Collect audit logs from Google Cloud Platform (GCP) with Elastic Agent)>Click "Add to Agent".***
**Step6: In the Google Cloud Platform (GCP) Audit logs. Provide the "Topic" and "Subscription Name". Additionally, make sure to enable "Subscription Create" and enter "Tags"*(forwarded and gcp-audit)* by clicking the box. Click "Next" to proceed.**
**Step8: A confirmation that the integration is finish installing.**
Documentation reference: *[https://www.elastic.co/guide/en/integrations/current/gcp.html](https://www.elastic.co/guide/en/integrations/current/gcp.html)**If you need further assistance, kindly contact our support at **support@cytechint.com**for prompt assistance and guidance.*
# Google Workspace Integrations
##### **Introduction**Google Workspace (formerly G Suite) is a suite of cloud computing, productivity and collaboration tools, software and products developed and marketed by Google. It allows users to create, edit, and share documents, spreadsheets, presentations, and more. It also includes email, calendar, chat, and video conferencing tools.Google Workspace is designed for businesses of all sizes, from small businesses to large enterprises. It is a popular choice for businesses because it is affordable, easy to use, and secure.The Google Workspace integration collects and parses data from the different [Google Workspace audit reports APIs](https://developers.google.com/admin-sdk/reports).If you want to know more about how you can fully leverage the Google Workspace integration, there is a multipart blog from our Security Labs that will help you:
1. To understand what Google Workspace is in [Part One - Surveying the Land](https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one)
2. To set it up, step by step, in [Part Two - Setup Threat Detection with Elastic](https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two)
3. And to use the collected information to your advantage in [Part Three - Detecting Common Threats](https://www.elastic.co/security-labs/google-workspace-attack-surface-part-three)
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
**Compatibility**
It is compatible with a subset of applications under the [Google Reports API v1](https://developers.google.com/admin-sdk/reports/v1/get-start/getting-started).
##### **Requirements**The procedures described in Section 3 assumes that a Log Collector has already been setup.
**In order to ingest data from the Google Reports API you must:**
- Have an administrator account.
- Set up a ServiceAccount using the administrator account.
- Set up access to the Admin SDK API for the ServiceAccount.
- Enable Domain-Wide Delegation for your ServiceAccount.
**Create access credentials**
Credentials are used to obtain an access token from Google's authorization servers so your app can call Google Workspace APIs. This guide describes how to choose and set up the credentials your app needs.
**Choose the access credential that is right for you**
The required credentials depends on the type of data, platform, and access methodology of your app. There are three types of credential types available:
- **API key credentials** - An API key is a long string containingupper and lower case letters, numbers, underscores, and hyphens, such as AIzaSyDaGmWKa4JsXZ-HjGw7ISLn\_3namBGewQe. This authentication method is used to anonymously access publicly-available data, such as Google Workspace files shared using the "Anyone on the Internet with this link" sharing setting. For more details, see [Using API keys](https://cloud.google.com/docs/authentication/api-keys).To create an API key:
- - In the Google Cloud console, go to Menu > **APIs & Services > Credentials.**
- Click Create credentials > API key.
- Your new API key is displayed.
- - - Click Copy to copy your API key for use in your app's code. The API key can also be found in the "API keys" section of your project's credentials.
- Click Restrict key to update advanced settings and limit use of your API key. For more details, see [Applying API key restrictions](https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions).
- **OAuth client ID credentials** - To authenticate as an end user and access user data in your app, you need to create one or more OAuth 2.0 Client IDs. A client ID is used to identify a single app to Google's OAuth servers. If your app runs on multiple platforms, you must create a separate client ID for each platform.Choose your[application type](https://support.google.com/cloud/answer/6158849#service-web-app&zippy=%2Cweb-applications%2Cnative-applications) for specific instructions about how to create an OAuth client ID:
- **Service account credentials** - A service account is a special kind of account used by an application, rather than a person. You can use a service account to access data or perform actions by the robot account, or to access data on behalf of Google Workspace or Cloud Identity users. For more information, see [Understanding service accounts](https://cloud.google.com/iam/docs/understanding-service-accounts).Create a service account:
- - - - - In the Google Cloud console, go to Menu > IAM & Admin > Service Accounts.
- Click Create service account.
- Fill in the service account details, then click Create and continue.
- Note: By default, Google creates a unique service account ID. If you would like to change the ID, modify the ID in the service account ID field.
- Optional: Assign roles to your service account to grant access to your Google Cloud project's resources. For more details, refer to [Granting, changing, and revoking access to resources.](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
- Click **Continue**.
- *Optional*: Enter users or groups that can manage and perform actions with this service account. For more details, refer to [Managing service account impersonation](https://cloud.google.com/iam/docs/impersonating-service-accounts).
- Click **Done**. Make a note of the email address for the service account.
**Assign a role to a service account:**
You must assign a prebuilt or custom role to a service account by a super administrator account.
1. In the Google Admin console, go to Menu > **Account > Admin roles.**
2. Point to the role that you want to assign, and then click **Assign admin.**
3. Click **Assign service accounts.**
4. Enter the email address of the service account.
5. Click **Add > Assign role.**
**Create credentials for a service account:**
You need to obtain credentials in the form of a public/private key pair. These credentials are used by your code to authorize service account actions within your app.To obtain credentials for your service account:
1. In the Google Cloud console, go to Menu > **IAM & Admin > Service Accounts.**
2. Select your service account.
3. Click **Keys > Add key > Create new key.**
4. Select **JSON**, then click **Create**.
Your new public/private key pair is generated and downloaded to your machine as a new file. Save the downloaded JSON file as credentials.json in your working directory. This file is the only copy of this key. For information about how to store your key securely, see [Managing service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys).
5. Click **Close**.
**Optional: Set up domain-wide delegation for a service account**
To call APIs on behalf of users in a Google Workspace organization, your service account needs to be granted domain-wide delegation of authority in the Google Workspace Admin console by a super administrator account. For more information, see [Delegating domain-wide authority to a service account](https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority).To set up domain-wide delegation of authority for a service account:
1. In the Google Cloud console, go to **Menu > IAM & Admin > Service Accounts.**
2. Select your service account.
3. Click **Show advanced settings.**
4. Under "Domain-wide delegation," find your service account's "Client ID." Click Copy to copy the client ID value to your clipboard.
5. If you have super administrator access to the relevant Google Workspace account, click **View Google Workspace Admin Console**, then sign in using a super administrator user account and continue following these steps.
If you don't have super administrator access to the relevant Google Workspace account, contact a super administrator for that account and send them your service account's Client ID and list of OAuth Scopes so they can complete the following steps in the Admin console.
- - - - In the Google Admin console, go to Menu > **Security > Access and data control > API controls**.
- - Click **Manage Domain Wide Delegation**.
- - Click **Add new**.
- - In the "Client ID" field, paste the client ID that you previously copied.
- - In the "OAuth Scopes" field, enter a comma-delimited list of the scopes required by your application. This is the same set of scopes you defined when configuring the OAuth consent screen.
- - Click **Authorize**.
**This integration will make use of the following oauth2 scope:**
Once you have downloaded your service account credentials as a JSON file, you are ready to set up your integration.Click the Advanced option of Google Workspace Audit Reports. The default value of "API Host" is https://www.googleapis.com. The API Host will be used for collecting access\_transparency, admin, device, context\_aware\_access, drive, gcp, groups, group\_enterprise, login, rules, saml, token and user accounts logs.NOTE: The Delegated Account value in the configuration, is expected to be the email of the administrator account, and not the email of the ServiceAccount.
##### **Google WorkspaceIntegration Procedures**Please provide the following information to CyTech:
**Collect access\_transparency, admin, alert, context\_aware\_access, device, drive, gcp, groups, group\_enterprise, login, rules, saml, token and user accounts logs (input: httpjson).**
1. **Jwt File** - Specifies the path to the JWT credentials file. NOTE: Please use either JWT File or JWT JSON parameter.
2. **Jwt JSON** - Raw contents of the JWT file. Useful when hosting a file along with the agent is not possible. NOTE: Please use either JWT File or JWT JSON parameter.
3. **Delegated Account**- Delegated Account is required. Email of the admin user used to access the API.
# How to Protect a Website with Cloudflare WAF
#### **Introduction**This guide explains how to protect your website using **Cloudflare Web Application Firewall (WAF)**.Cloudflare sits in front of your website and filters all incoming traffic. By changing your DNS to go through Cloudflare, you get:
- Protection against common web attacks (SQL injection, XSS, etc.)
- Built-in DDoS protection
- Free SSL certificates
- Performance benefits from Cloudflare’s global CDNThe process takes a few steps, but once set up, all visitors to your website are automatically filtered through Cloudflare before reaching your server.
##### **Step 1: Log in to Cloudflare**Go to https://dash.cloudflare.comand log in with your account.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/KnK3WKc9iGC6MIWx-image.png)
##### **Step 2: Add Your Website**
1. In the dashboard, click **+ Add** at the top.
2. Select **Connect a domain**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/0wCyOwMfCVpzJGPk-image.png)
##### **Step 3: Enter Your Domain**Type your domain name (example: `yourdomain.com`) and click **Continue**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/SqfhfS6Vfs5oCNVQ-image.png)
##### **Step 4: Choose a Plan**Cloudflare will ask you to choose a plan.
- If you just want the WAF and basic protection, select **Free** (Plan $0).
- Then click **Continue**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/I0brqMOgRA6GmMb9-image.png)
##### **Step 5: Review Your DNS Records**Cloudflare scans your existing DNS records.
- Make sure your main records (A and CNAME for your domain and www) are there.
- The **orange cloud (Proxied)** should be ON for the records you want protected by Cloudflare WAF.
- NS (Nameserver) records should remain as **DNS only** (gray cloud).[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/6KQX9ura0ZpZcCax-image.png)Once ready, click **Continue** (you don’t need to tick the checkboxes).
##### **Step 6: Change Your Nameservers**Cloudflare will give you **two new nameservers**.
Go to your **Cloudflare dashboard** → **Websites** → select your domain → **DNS** → scroll to **Cloudflare Nameservers** section.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/RkRekm8M5ogdeSw0-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/10DwLk0ct3KDQPue-image.png)
- Go to your domain registrar (the company where you bought your domain, like GoDaddy or Namecheap).
- Replace the old nameservers with the Cloudflare ones.
- Save changes.
##### **Step 7: Wait for Propagation**DNS changes take time. Usually, 15 minutes up to 24 hours.When Cloudflare detects the change, your site will show as **Active** in the dashboard.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/tr27cbYyLnaXWqVu-image.png)
##### **Step 8: Enable WAF Protection**
- In the dashboard, go to **Security > Security Rules > WAF**.
- Enable **Managed Rulesets** (Cloudflare OWASP Core Ruleset, Cloudflare Managed Ruleset).
- Cloudflare will now filter malicious traffic before it reaches your site.
- Optionally create **Custom Rules** (e.g., block countries, rate limit requests, block SQL injection patterns).
- Test in “Simulate” mode before switching to “Block” to avoid false positives.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-09/XYGgF0rP3qvSkob6-image.png)
##### **Step 9: Verify**
- Use a tool like **dig** or **nslookup** to confirm the domain resolves to Cloudflare IPs (not your origin server).
- Try visiting the site; Cloudflare headers like **cf-cache-status** should appear.
- You can also test WAF by visiting **http://yoursite.com/?<script>alert(1)</script>** (Cloudflare should block it if rules are active).*If you need further assistance, kindly contact our technical support at **** for prompt assistance and guidance.*
# How to Use Sniff and Detect
#### **Overview** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/U4ks7IDbEjY7Qwvb-image.png)
AQUILA – SNIFF & Detect is a custom integration app within the **AQUILA platform** that enables Microsoft 365 environments to deploy **advanced malicious email detection** capabilities.The app is packaged as a **manifest.xml** file and can be added to an organization’s Microsoft 365 tenant via the **Integration Apps** section in the Microsoft 365 Admin Center.
---
#### **Key Capabilities & Value** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/jBlpQPC2DfMETIrY-image.png)
- **Seamless Integration** – Install in Microsoft 365 with just a few clicks, no complex infrastructure required.
- **Permission-Driven Security** – Requires admin approval to grant permissions, ensuring a secure deployment process.
- **Centralized Control** – Managed via AQUILA and distributed through the AQUILA Store for consistent updates.
- **AI-Enhanced Detection** – Uses AQUILA’s AI and Cyber Threat Intelligence to scan and detect malicious emails in real time.
- **User-Friendly Accessibility** – Appears in the “More apps” section for assigned users, making it easy to launch.
- **Minimal Footprint** – Only ~6 KiB in size, ensuring fast installation without performance impact.
---
#### **Simple Step-by-Step Instructions **[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/L3FUfskDB2bTOhfG-image.png)
1. **Access the App**
- Open Outlook and check the apps panel to ensure Sniff & Detect is listed and accessible.
- Users can launch it from **More apps** in Microsoft 365.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/x0FuZ3iJt7A0EjRE-image.png)
- A phishing email impersonating Netflix. An arrow points to the **SNIFF & Detect** icon, indicating where to scan or flag the email as suspicious.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/fdE09hu7Rl60QyT9-image.png)
- Click the “**Scan This Email**” button and wait for the scan to complete.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/pRLtXFAqIgrMvZMx-image.png)
- SNIFF & Detect has scanned the email, highlighting possible errors such as1. **Arrow 1** points to the **Language issues** section, showing spelling and grammar mistakes found in the phishing email.2. **Arrow 2** points to the **What you should do** section, giving safety advice on how to handle the suspicious email.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/o6vEVWiMGeCI3Gsk-image.png)
- **Arrow 1** – Highlights the **AI Insight Results** tab in SNIFF & Detect, which contains the automated analysis results of the scanned email.
- **Arrow 2** – Points to the **Malicious** classification summary. This section briefly explains the reasons the email is flagged, such as suspicious sender details, urgent tone, spelling and grammar errors, and suspicious links.
- **Arrow 3** – Directs attention to the actual phishing email content pretending to be from Netflix, warning about a payment failure and urging the user to update their payment information.
- **Arrow 4** – Indicates the **Report as Phishing** button, which the user can click to formally report the suspicious email to security for further action.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/xCI6XwmmK0SHb2Jv-image.png)
- Click the "**Run a deep scan**" button, which allows for a more detailed examination of the email to detect hidden threats and malicious indicators.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/51ELQvK9m7iXcuUC-image.png)
- **SNIFF & Detect** doing a deep scan on a suspected phishing email pretending to be from Netflix. The scan may take a couple of minutes to finish.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/W3myFSHB02eaTvS2-image.png)
- The scan results are now finished and ready to check.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/mALzljyROiLcmqPz-image.png)
- This is the result of a deep scan conducted by the Sniff & Detect tool on a suspicious email impersonating Netflix.1. **Arrow 1** highlights the domain **netflix-billing.com,** which is flagged as a spoofed domain used to impersonate Netflix and trick users into entering sensitive information.2. **Arrow 2** lists phishing-related email addresses such as **richmond@cytcehint.com** and [**support@netflix-billing.com**](mailto:support@netflix-billing), which are likely used to send or support the fraudulent email.3. **Arrow 3** shows the IP address **192.168.1.45**, flagged as part of the phishing infrastructure. Although it's a private IP, its presence suggests internal spoofing or malicious setup.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-08/4JxCoYEvR1qYSOzV-image.png)*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# Jumpcloud Integrations
##### **Introduction**The JumpCloud integration allows you to monitor events related to the JumpCloud Directory as a Service via the Directory Insights API.You can find out more about JumpCloud and JumpCloud Directory Insights here
##### **Data streams**A single data stream named "jumpcloud.events" is used by this integration.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**An Elastic Stack with an Elastic Agent is a fundamental requirement.An established JumpCloud tenancy with active users is the the other requirement. Basic Directory Insights API access is available to all subscription levels.NOTE: The lowest level of subscription currently has retention limits, with access to Directory Insights events for the last 15 days at most. Other subscriptions levels provide 90 days or longer historical event access.A JumpCloud API key is required, the JumpCloud documentation describing how to create one is here
**Procedures**:Please provide the following information to CyTech:Enabling the integration in Elastic
1. In Kibana go to Management > Integrations
2. In "Search for integrations" search bar type JumpCloud
3. Click on "JumpCloud" integration from the search results.
4. Click on AddJumpCloud button to add the JumpCloud integration.
5. Configure the integration as appropriate
6. Assign the integration to a new Elastic Agent host, or an existing Elastic Agent host
# JWT For Kali
To create a JSON Web Token (JWT) for Salesforce on **Kali Linux**, you can follow the steps below. Kali Linux is a Debian-based Linux distribution, so the process is similar to other Linux environments. You will use tools like **OpenSSL** for key generation and a programming language (e.g., Python) to generate the JWT.
---
### Step 1: Install Required Tools
Ensure you have the necessary tools installed on Kali Linux:
1. **OpenSSL**:
- OpenSSL is pre-installed on Kali Linux. Verify by running: ```
✄𐘗```
openssl version
```
```
4. **Upload Public Key to Salesforce**:
- Log in to Salesforce and navigate to **Setup** > **App Manager** > Select your Connected App > **Edit Policies** > Upload the public key under **Certificate and Key Management**.
---
### Step 3: Create the JWT Using Python
Use Python to generate the JWT. Below is the Python script:
#### Python Script (`generate_jwt.py`)
python code block:
```
✄𐘗```
import jwt
import time
# Define the private key
private_key = """
-----BEGIN RSA PRIVATE KEY-----
YOUR_PRIVATE_KEY_HERE
-----END RSA PRIVATE KEY-----
"""
# Define the JWT payload
payload = {
"iss": "YOUR_CONSUMER_KEY", # Consumer Key from Salesforce Connected App
"sub": "YOUR_SALESFORCE_USERNAME", # Salesforce username
"aud": "https://login.salesforce.com", # Use https://test.salesforce.com for sandbox
"exp": int(time.time()) + 300 # Token expiration time (5 minutes from now)
}
# Generate the JWT
token = jwt.encode(payload, private_key, algorithm="RS256")
print("Generated JWT:")
print(token)
```
```
#### Steps to Run the Script
1. Save the script as `generate_jwt.py`.
2. Run the script:
```
✄𐘗```
python3 generate_jwt.py
```
```
3. The script will output the JWT token.
---
### Step 4: Use the JWT to Obtain an Access Token
Send the JWT to Salesforce using `curl` to obtain an access token.
#### Example Command
---
### Troubleshooting
1. **Invalid Grant Error**:
- Ensure the `sub` field matches the Salesforce username.
- Ensure the `aud` field matches the correct Salesforce environment (`login.salesforce.com` or `test.salesforce.com`).
2. **Expired Token**:
- Ensure the `exp` field is set to a future time (e.g., 5 minutes from now).
3. **Invalid Signature**:
- Ensure the private key matches the public key uploaded to Salesforce.
4. **Debugging**:
- Use verbose mode in `curl` to debug:
---
### Additional Resources
- [Salesforce JWT Bearer Token Flow(external, opens in a new tab or window)](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_jwt_flow.htm&type=5)
- [PyJWT Documentation(external, opens in a new tab or window)](https://pyjwt.readthedocs.io/)
- [OpenSSL Documentation(external, opens in a new tab or window)](https://www.openssl.org/docs/)
Let me know if you need further assistance!
# ManageEngine
# Log Forwarder
EventLog Analyzer's Syslog Forwarder transmits logs from various sources to a destination server. Logs from syslog devices are forwarded as raw logs, whereas logs from other sources are converted to specific formats such as JSON, RFC 5424, RFC 5424 With Structured Data, and RFC 3164, or a custom format, and then forwarded to the destination server.
## Steps to start forwarding logs
#### Creating a new profile
1. Navigate to **Settings → Admin Settings → Integrations → Log Forwarding**.
2. To add a new forwarder profile, click on Add New Profile on the top right corner of the page.
3. Enter the **Forwarder Name**.
4. Enter the **Destination Server** to which the logs have to be forwarded to.
5. Select the required **Protocol**, either **UDP** or **TCP** from the drop down.
1. Enter the **Port** number. The default port number is 513.
2. Select the required **Syslog Standard** by clicking on **Customize**. The formats include Rawlog, JSON, RFC 5424, RFC 5424 With Structured Data, RFC 3164 and Custom.
1. Select the required format and click **Save**.
2. To create a custom Syslog Format, select **Custom** from the drop-down.
- Enter the **Syslog Format**.
- Enter the **Syslog Message Structure**.
- Enable **Additional Log Fields**.
- Enter the **Timestamp Format**.
- Click **Save**.
1. Under **Select Devices**, add the source devices from which logs have to be fetched.
2. Select the required **Criteria**.
- **All logs** - It forwards all incoming logs.
- **Exclude** - It excludes specific logs based on the given criteria before forwarding.
- **Forward Only** - It forwards only specific logs based on the given criteria.
1. Click **Save**.
#### Updating an existing profile
1. Navigate to **Settings → Admin Settings → Integrations → Log Forwarding**.
2. Click on the **Update Profile** icon on the profile that has to be updated.
1. The **Forwarder Name** would already exist here.
2. Refer to [steps 4 to 11](https://www.manageengine.com/products/eventlog/help/StandaloneManagedServer-UserGuide/Configurations/log-forwarder.html#step4) under Creating a new profile.
3. Click **Update**.
#### Managing forwarder profiles
EventLog Analyzer allows you to create up to 5 distinct profiles to enable seamless log forwarding. The profile dashboard allows you to enable, disable, update and delete the forwarder profiles.
Source: *[https://www.manageengine.com/products/eventlog/help/StandaloneManagedServer-UserGuide/Configurations/log-forwarder.html](https://www.manageengine.com/products/eventlog/help/StandaloneManagedServer-UserGuide/Configurations/log-forwarder.html)*
***If you need further assistance, kindly contact our support at support@cytechint.comfor prompt assistance and guidance.***
# Microsoft 365
Microsoft Office 365 integrationcurrently supports user, admin, system, and policy actions and events from Office 365 and Azure AD activity logs exposed by the Office 365 Management Activity API.
##### **Procedures**
To perform the setup, please confirm that you have the following access:
1. A Microsoft Office 365 account with Administrative Privileges
2. A Microsoft Azure account with Administrative Privileges
Register a new Office 365 web applicationTo get started collecting Office 365 logs, register an Office 365 web application:
1. Log into the Office 365 portal as an Active Directory tenant administrator.
2. Click Show all to expand the left navigation area, and then click Azure Active Directory.
3. Select App Registrations, and then click + New application registration.
4. Provide the following information in the fields:
1. 1. - Name – for example, o365cytech.
- Select Single tenant for supported account types.
- Leave the Redirect URI blank.
- The Audit Log Searchneeds to be enabled.
- Click Register and note the Application (client) ID.
Setup Active Directory security permissionsThe Active Directory security permissions allow the application you created to read threat intelligence data and activity reports for your organization.To set up Active Directory permissions:
1. On the main panel under the new application, click API Permissions, and then click + Add a permission.
2. Locate and click on Office 365 Management APIs.
3. In Application permissions, expand and select ActivityFeed.Read, ActivityFeed.ReadDlp, ActivityReports.Read, and ServiceHealth.Read
4. Ensure all necessary permissions are selected, and then click Add permissions.
5. Click Grant admin consent, and then click Accept to confirm.
6. On the left navigation area, select Certificates & secrets, and then click + New client secret.
7. Make Sure to Copy the Value (Client Secret (Api Key) will disappear
8. 
9. Type a key Description and set the duration to Never or Maximum Grant time.
10. Click Add.
11. Click Overview to return to the application summary, and then click the link under Managed application in local directory.
12. Click Properties, and then note the Object ID associated with the application.
##### **Steps to Renew the Client Secret (API Key):**
1. **Log into the Azure Portal**:
- Go to the Azure Portal and log in using an account with administrative privileges.
2. **Navigate to Azure Active Directory**:
- In the left navigation pane, select **Azure Active Directory**.
- If it's not visible, click **Show all** to expand the list and find it.
3. **Go to App Registrations**:
- Under **Azure Active Directory**, select **App Registrations**.
- Find your registered application (e.g., "o365cytech") in the list, or use the **search bar** to locate it.
4. **Open Certificates & Secrets**:
- Click on the registered app to open its details page.
- In the left-hand menu, select **Certificates & Secrets**.
5. **Generate a New Client Secret**:
- Under **Client Secrets**, you'll see a list of previously created secrets, along with their expiration dates.
- Click **+ New client secret** to create a new one.
6. **Configure the New Secret**:
- Enter a description for the new key (e.g., "Renewed Key for o365cytech").
- Set the duration for the new client secret:
7. **Save and Copy the New Secret**:
- Click **Add**.
- Once the new secret is generated, **copy the value immediately**. This is your new client secret (API key). The secret value will be hidden after you leave this page, so make sure to store it securely.
8. **Update Any Services Using the Key**:
- If any services or scripts are using the previous client secret, you'll need to update them with the new one.
9. **Remove the Old Secret (Optional)**:
- If the old client secret is no longer needed, you can delete it to avoid confusion. Simply click the **trash icon** next to the old key under **Client Secrets**.
# Microsoft 365 DLP Integration and Monitoring
#### **Summary of Actions Required:**
Register an app in Microsoft Entra ID and configure API permissions for Microsoft Graph and Office 365 Management APIs. Grant admin consent and collect credentials (Application ID, Tenant ID, Client Secret). Ensure Unified Audit Logging is enabled in Microsoft 365.**Pre-requisites:**
- **Global Admin** access
- **Microsoft 365 E5** or Compliance add-on licenses
- **Required roles**: Compliance Administrator, Security Reader, Global Reader, or a custom role with DLP alert access**DLP Alerts:**
- Go to Microsoft Purview Portal > Data Loss Prevention > Alerts
- Ensure DLP policies are set to generate alerts
---
##### **Important Note on Microsoft 365 Alert API Limitations**There is an **inherent limitation in the Microsoft 365 Security Alert APIs** that impacts the level of detail you receive in alert data—this is critical when planning your integration and choosing the appropriate license tier.
- **v1.0 Alerts API** (available under Microsoft 365 E3 and E5):
- Provides only **basic alert information**, such as:
- Alert title, category, severity, and timestamps
- Limited context about the affected user or object
- Designed primarily for **initial alerting and manual investigation**
- **v2.0 Alerts API** *(currently in beta, available with Microsoft 365 E5 or Defender Plan 2)*:
- Delivers **richer alert context**, including:
- Detailed user activities leading up to the alert
- Supporting evidence (emails, files, device info)
- Remediation guidance and recommendations
- Useful for **automated triage**, faster incident response, and deeper analysis
**License Implication**:
- If you’re using **Microsoft 365 E3**, only **v1.0 is supported**, limiting you to high-level alert insights.
- For access to **v2.0’s extended context**, an **E5 license or add-on** is required.
**Our Position**:In Microsoft 365 E3, the information from the **v1.0 API is sufficient** to initiate timely investigations.However, depending on your operational requirements, you may need to assess whether the **basic alert data is adequate** or if the **richer, contextual insights of v2.0** are necessary for your workflows.
**Consider this carefully when designing your alert ingestion pipeline or evaluating Microsoft 365 licensing options.**
---
##### **Step 1: Microsoft Entra ID - App Registration****Register Your Application in Microsoft Entra ID:**
- - Log in to your Azure Account, click here - **[Azure Portal Link](https://portal.azure.com/#home)**.
- Navigate to Azure Active Directory > **App registrations**.
- Click **New Registration**.
- Provide a Name for the application, we can suggest "**CyTechAQUILA-Monitoring**".
- Click **Register**.
##### **Step 2: API Permissions****Microsoft Graph API Permissions:**
- - Navigate to **App registrations** in the Azure Portal.
- Select the App you just created, then go to **API Permissions**.
- Search for **Microsoft Graph.**
- Click **Add a permission**.
- Select **Microsoft Graph** **>** **Application**** permissions**.
- Search for and add
- **AuditLog.Read.All**
- **Files.Read.All**
- **InformationProtectionConfig.Read.All**
- **InformationProtectionPolicy.Read.All**
- **Policy.Read.All**
- **SecurityAlert.Read.All**
- **SecurityEvents.Read.All**
- **SecurityEvents.ReadWrite.All**
- **SecurityIncident.Read.All**
- **SensitivityLabels.Read.All**
- **Sites.Read.All**
- **User.Read.All**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/Z7ppaAKB1MfELxkK-image.png)
**Office 365 Management API Permissions:**
- - Search for **Office 365 Management APIs** and add the required permissions.
- In **Application Permissions**, look for permissions.
- To read DLP policy events under ActivityFeed select:
- **ActivityFeed.Read**
- **ActivityFeed.ReadDlp**
- **ServiceHealth.Read**
- - Go to **App registrations** > **Select your application**.
- Copy the **Application (client) ID** from the overview page.
**Directory (Tenant) ID:**
- - In the Azure Portal, navigate to **Azure Active Directory** > **Overview**.
- Copy the **Directory (tenant) ID**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-07/qrBfOWGafjDMJqVo-image.png)
**Create New Client Secret (Value):**
- - In **App registrations > Select your application**, go to **Certificates & secrets**.
- Click **New client secret**.
- Add a description and expiration period, then click Add.
- Copy the **Value** **(displayed only once)**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/fjoxX4o659L9qigQ-image.png)
##### **Step 4: Verify Unified Audit Logging is Enabled**Unified Audit Logging must be enabled before accessing data via the Office 365 Management Activity API.**Method 1: Using Microsoft 365 Security & Compliance Center**
1. Sign in to Microsoft 365:
- Go to **[https://admin.microsoft.com](https://admin.microsoft.com/)** and sign in with your Global Admin credentials.
2. Access the Security & Compliance Center:
- In the left-hand menu, under Admin centers, click on Security (or go directly to**[https://security.microsoft.com](https://security.microsoft.com/)**).
3. Navigate to Audit Log Search:
- In the Security & Compliance Center, go to Search in the left-hand menu and click on **Audit log search**.
4. Check Audit Log Status:
- If you see an option to **search the audit log**, then audit logging is already enabled(*refer to the image below*).
- If you see a banner that says "**Start recording user and admin activity**" or a prompt to enable auditing, it means that audit logging is not yet enabled.
5. Enable Audit Logging:
- If audit logging is not enabled, you can **click on the prompt to enable it**. This will enable auditing for all activities within your Microsoft 365 environment. The process may take a few hours to be fully operational.
---
**Microsoft Purview DLP Policy Creation – General Instruction Manual**
---
#### **Overview: Key Factors to Consider Before Creating a DLP Policy**Before you create any DLP policy, take time to understand and document the following:
##### 1. **Data Sensitivity and Classification**
- What types of sensitive information need protection?
- e.g., Credit card numbers, health records, national IDs, business secrets
- Are sensitivity labels already being used (e.g., “Highly Confidential”)?
##### 2. **Data Locations**
- Where does your organization store and share data?
- Email (Exchange Online), OneDrive, SharePoint, Teams, Devices, or 3rd party apps
##### 3. **User Scope**
- Who should the policy apply to?
- All users, specific departments (e.g., HR, Finance), or external collaborators?
##### 4. **Policy Actions**
- What should happen when sensitive data is detected?
- Block sharing, restrict access, encrypt, notify, log for audit
##### 5. **Exceptions or Conditions**
- Are there any legitimate business needs that require exceptions?
- e.g., Finance team emailing payroll data to a vendor
##### 6. **Notifications and Overrides**
- Should users be notified?
- Should policy tips be shown?
- Should users be allowed to override and justify? (For high-severity events, this is often disabled.)
##### 7. **Audit and Investigation**
- Should each incident trigger admin alerts?
- What severity level should be set for reporting and analytics?
---
#### **Step-by-Step Guide: Creating a DLP Policy in Microsoft Purview**
##### **Step 1: Access the Microsoft Purview Portal**
1. Go to **[https://purview.microsoft.com/](https://purview.microsoft.com/)**
2. Navigate to: **Solutions > Data loss prevention > Policies**
---
##### **Step 2: Create a New Policy**
1. Click **+ Create policy**
2. Choose a template based on your scenario:
- Predefined compliance regulations (e.g., GDPR, HIPAA)
- **Custom policy** for flexibility
---
##### **Step 3: Name & Describe the Policy**
- Provide a clear **name** and a short **description** of what the policy is intended to do.
- Tip: Include the policy intent (who it applies to, what it blocks, exceptions).
---
##### **Step 4: Define Admin Scope**
- Select **Admin units** or apply the policy to the **entire organization** (default).
- Choose **Next**.
---
##### **Step 5: Select Locations to Monitor**
- Choose the services where the policy will be active:
- **Exchange email**
- **SharePoint Online**
- **OneDrive**
- **Microsoft Teams**
- **Devices** (if endpoint DLP is configured)
---
##### **Step 6: Define Policy Rules**
1. Choose: **Create or customize advanced DLP rules**
2. Click **Create rule**
3. Configure the rule components:
**A. Conditions**
- Define what triggers the rule:
- **Sensitive info types** (e.g., Credit Card Number)
- **Sensitivity labels** (e.g., Highly Confidential)
- **File types, file extensions, sharing context**, etc.
**B. Exceptions (Optional)**
- Add **exception groups** using a **Boolean NOT operator**
- Example: Sender is in “Finance Team” AND recipient is “trustedvendor@domain.com”
**C. Actions**
- Choose what to do when the condition is met:
- **Block**, **Restrict**, or **Encrypt** content
- **Audit only** for simulation/testing
**D. User Notifications**
- Enable **notifications** to senders/editors
- Show **policy tips** in apps (e.g., Outlook, Word)
**E. Override Settings**
- Allow or disallow users to override the block by providing a justification
**F. Incident Reporting**
- Set **severity level** (Low, Medium, High)
- Enable **alerts** to compliance/admin teams
---
##### **Step 7: Finalize and Simulate**
1. Review the settings
2. Choose to run the policy in **simulation mode** (recommended for testing)
3. Click **Submit** to create the policy
---
#### **Post-Creation Tips**
- **Simulation Mode**: Monitor effectiveness before enforcement
- **Policy Testing**: Use test data to trigger the policy and confirm expected behavior
- **Policy Reports**: View violations under **Reports** > DLP alerts
- **Fine-tune**: Adjust thresholds, exceptions, and scope as needed
---
#### **Example Use Cases You Can Build From**
Scenario
Example Policy Configuration
Prevent employees from emailing credit card numbers
Condition: Credit Card InfoAction: Block emailNotify sender and admin
Warn users about sharing internal-only content to external domains
Condition: Sensitivity label = InternalAction: Show policy tipAllow override
Restrict uploading HR documents to personal OneDrive
Condition: HR keyword or file nameLocation: DevicesAction: Block upload to personal apps
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# Microsoft Audit Logs vs Compliance Alerts for SOC Monitoring
---
### 1. OverviewThis report outlines the key differences, advantages, disadvantages, and recommendations for using Microsoft Audit Logs and Microsoft Compliance Alerts in the context of Security Operations Center (SOC) monitoring.
---
### 2. Definition and Purpose**Microsoft Audit Logs**
- Provide detailed records of all user and administrator activities across Microsoft 365 services.
- Useful for tracking actions such as logins, file access, configuration changes, etc.**Microsoft Compliance Alerts**
- Triggered based on specific compliance or security policies configured in Microsoft Purview.
- Designed to notify on suspicious, risky, or policy-violating behavior.
---
### 3. Key Differences
Attribute
Microsoft Audit Logs
Microsoft Compliance Alerts
Data Source
Microsoft 365 Unified Audit Log (UAL)
Microsoft Purview (Compliance Center)
Primary Use
Activity tracking, investigations
Policy violation detection, real-time alerts
Data Format
Raw, event-based logs
Structured, policy-based alerts
Trigger Method
Logs all user/admin activities
Fires only when policies are breached
Integration
Supports SIEM integration
Supports alerting systems and workflows
Licensing
M365 E3/E5 (details improve with E5)
Requires M365 E5 or specific add-on licensing
Retention
Up to 1 year (based on license tier)
Retention defined by alert settings
---
### 4. Pros and Cons**Microsoft Audit Logs**
- **Pros:**
- Detailed, timestamped activity records.
- Broad visibility across services.
- Excellent for historical analysis and forensic investigations.
- Integrates well with SIEMs for event correlation.
- **Cons:**
- Not real-time; requires manual or scheduled processing.
- High volume and can be noisy without filtering.
- Requires parsing and context-building for actionable insights.**Microsoft Compliance Alerts**
- **Pros:**
- Provides real-time detection of compliance or security policy violations.
- Easy to configure and link to automated workflows or notifications.
- Useful for detecting insider threats, DLP violations, or unusual behavior.
- **Cons:**
- Alert coverage limited to configured policies only.
- Less raw detail compared to audit logs.
- May produce false positives if rules are not refined.
---
### 5. Recommendations for SOC Monitoring
Monitoring Need
Recommended Source
Real-Time Threat Detection
Microsoft Compliance Alerts
Threat Hunting / Investigations
Microsoft Audit Logs
Forensics and Root Cause Analysis
Microsoft Audit Logs
Policy Enforcement Monitoring
Microsoft Compliance Alerts
SIEM Event Correlation
Both (Audit for context, Alerts for signal)
---
### 6. ConclusionFor a complete SOC monitoring strategy, both Microsoft Audit Logs and Compliance Alerts should be used in tandem. Audit Logs provide the necessary historical detail for investigations and context, while Compliance Alerts offer timely awareness of potential security or compliance issues. Combining both ensures improved visibility, faster response times, and better alignment with security and regulatory requirements.
# Microsoft SQL Server Integration
The Microsoft SQL Server integration package allows you to search, observe, and visualize the SQL Server audit logs, as well as performance and transaction log metrics.
---
#### **Requirements**
Microsoft SQL Server is installed and has connectivity with the CyTech Log Collector.
*Note. For more information regarding Microsoft SQL Server Installation, click the link ([https://learn.microsoft.com/en-us/sql/database-engine/install-windows/install-sql-server?view=sql-server-ver16)](https://learn.microsoft.com/en-us/sql/database-engine/install-windows/install-sql-server?view=sql-server-ver16)) for more info.*
---
#### **Microsoft SQL Server permissions**
Before you can start sending data to the Log Collector, make sure you have the necessary Microsoft SQL Server permissions.
If you browse Microsoft Developer Network (MSDN) for the following tables, you will find a "Permissions" section that defines the permission needed for each table.
1. `transaction_log`:
- sys.databases
- sys.dm\_db\_log\_space\_usage
- sys.dm\_db\_log\_stats (DB\_ID) (Available on SQL Server (MSSQL) 2016 (13.x) SP 2 and later)
2. `performance`:
- sys.dm\_os\_performance\_counters
Please make sure the user has the permissions to system as well as user-defined databases. For the particular user used in the integration, the following requirements are met:
**User setup options:**
- Grant specific permissions as mentioned in the MSDN pages above.
- Alteratively, use `sysadmin` role (includes all required permissions): This can be configured via SQL Server Management Studio (SSMS) in `Server Roles`. Read more about joining a role in the SQL Server documentation.
**User Mappings (using SQL Server Management Studio (SSMS)):**
- Open SSMS and connect to your server.
- Navigate to "Object Explorer" > "Security" > "Logins".
- Right-click the user and select "Properties".
- In the "User Mapping" tab, select the appropriate database and grant the required permissions.
---
#### **Setup**
Below you'll find more specific details on setting up the Microsoft SQL Server integration.
##### **Named Instance**
Microsoft SQL Server has a feature that allows running multiple databases on the same host (or clustered hosts) with separate settings. Establish a named instance connection by using the instance name along with the hostname (e.g. `host/instance_name` or `host:named_instance_port`) to collect metrics. Details of the host configuration are provided below.
##### **Host Configuration**
As part of the input configuration, you need to provide the user name, password and host details. The host configuration supports both named instances or default (no-name) instances, using the syntax below.
*Note: This integration supports collecting metrics from a single host. For multi-host metrics, each host can be run as a new integration.*
**Connecting to Default Instance (host)**:
- `host` (e.g. `localhost` (Instance name is not needed when connecting to default instance))
Note. IP Address of the SQL Server will be needed for the integration
- `host:port` (e.g. `localhost:1433`)
Note. Default port is *1433*
**Connecting to Named Instance (host)**:
- `host/instance_name` (e.g. `localhost/namedinstance_01`)
- `host:named_instance_port` (e.g. `localhost:60873`)
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Mimecast Integrations
##### **Introduction**The Mimecast integration collects events from the Mimecast API.
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### **Requirements**
**Configuration**
Authorization parameters for the Mimecast API (Application Key, Application ID, Access Key, and Secret Key) should be provided by a Mimecast representative for this integration. Under Advanced options you can set the time interval between two API requests as well as the API URL. A Mimecast representative should also be able to give you this information in case you need to change the defaults.Note: Rate limit quotas may require you to set up different credentials for the different available log types.
**Logs**
**Audit Events**
This is the mimecast.audit\_events dataset. These logs contain Mimecast audit events with the following details: audit type, event category and detailed information about the event. More information about these logs.
**DLP Logs**
This is the mimecast.dlp\_logs dataset. These logs contain information about messages that triggered a DLP or Content Examination policy. More information about these logs.
**SIEM Logs**
This is the mimecast.siem\_logs dataset. These logs contain information about messages that contains MTA (message transfer agent) log – all inbound, outbound, and internal messages.
**Threat Intel Feed Malware: Customer**
This is the mimecast.threat\_intel\_malware\_customer dataset. These logs contain information about messages that return identified malware threats at a customer level. Learn more about these logs.
**Threat Intel Feed Malware: Grid**
This is the mimecast.threat\_intel\_malware\_grid dataset. These logs contain information about messages that return identified malware threats at a regional grid level. More about these logs.
**TTP Attachment Logs**
This is the mimecast.ttp\_ap\_logs dataset. These logs contain Mimecast TTP attachment protection logs with the following details: result of attachment analysis (if it is malicious or not etc.), date when file is released, sender and recipient address, filename and type, action triggered for the attachment, the route of the original email containing the attachment and details. Learn more about these logs.
**TTP Impersonation Logs**
This is the mimecast.ttp\_ip\_logs dataset. These logs contain information about messages containing information flagged by an Impersonation Protection configuration.
**TTP URL Logs**
This is the mimecast.ttp\_url\_logs dataset. These logs contain Mimecast TTP attachment protection logs with the following details: the category of the URL clicked, the email address of the user who clicked the link, the url clicked, the action taken by the user if user awareness was applied, the route of the email that contained the link, the action defined by the administrator for the URL, the date that the URL was clicked, url scan result, the action that was taken for the click, the description of the definition that triggered the URL to be rewritten by Mimecast, the action requested by the user, an array of components of the message where the URL was found. More about these logs.
##### **Mimecast Integration Procedures**Please provide the following information to CyTech:**Mimecast API******
1. Application Key - Specifies application key for user.
2. Application ID - Set the Application Id.
3. Access Key - Set Access Key.
4. Secret Key - Set Secret Key.
# MongoDB Integrations
##### **Introduction**This integration is used to fetch logs and metrics from MongoDB.
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup. **Compatibility******
The log dataset is tested with logs from versions v3.2.11 and v4.4.4 in plaintext and json formats. The collstats, dbstats, metrics, replstatus and status datasets are tested with MongoDB 3.4 and 3.0 and are expected to work with all versions >= 2.8.
##### **Requirements**
**MongoDB Privileges**
In order to use the metrics datasets, the MongoDB user specified in the package configuration needs to have certain privileges.We recommend using the clusterMonitor role to cover all the necessary privileges.You can use the following command in Mongo shell to create the privileged user (make sure you are using the admindb by using db command in Mongo shell).db.createUser( { user: "beats",pwd: "pass", roles: \["clusterMonitor"\] })You can use the following command in Mongo shell to grant the role to an existing user (make sure you are using the admindb by using db command in Mongo shell).db.grantRolesToUser("user", \["clusterMonitor"\])
**Logs**
**log**
The log dataset collects the MongoDB logs.
**Metrics**
**collstats**
The **collstats** dataset uses the top administrative command to return usage statistics for each collection. It provides the amount of time, in microseconds, used and a count of operations for the following types: total, readLock, writeLock, queries, getmore, insert, update, remove, and commands.It requires the following privileges, which is covered by the clusterMonitor role:
- top action on cluster resource
**dbstats**
The **dbstats** dataset collects storage statistics for a given database.It requires the following privileges, which is covered by the clusterMonitor role:
- listDatabases
action on cluster resource
- for each of the databases, also need dbStats
action on the database resource
**metrics**
It requires the following privileges, which is covered by the clusterMonitor role:
- serverStatus
action on cluster resource
**replstatus**
The **replstatus** dataset collects status of the replica set. It requires the following privileges, which is covered by the clusterMonitor role:
- find/listCollections action on the local database resource
- collStats action on the local.oplog.rs collection resource
- replSetGetStatus action on cluster resource
**status**
The status returns a document that provides an overview of the database's state.It requires the following privileges, which is covered by the clusterMonitor role:
- serverStatus
action on cluster resource
##### **MongoDB Integration Procedures**Please provide the following information to CyTech:
**Collect MongoDB application logs**
- Paths
**Collect MongoDB metrics**
- Hosts
Ex: localhost:27017
# Nutanix
#### How to Send Logs to a Remote Syslog Server
##### Summary:
This article briefly describes how to configure a Nutanix cluster to send logs to an rsyslog server.
##### Description:
This article briefly describes configuring a Nutanix cluster to send logs to an rsyslog server.
##### Solution:
1. Connect to a Controller VM (CVM) in the cluster using SSH.
2. Enter the **ncli** command to log into the nCLI prompt. ```
```
nutanix@cvm$ ncli
```
```
Note: "<ncli>" is the nCLI prompt.
3. The remote syslog server is enabled by default. Disable it while you configure the settings. ```
```
rsyslog-config set-status enable=false
```
```
4. Add an rsyslog server using the following command, which adds it to the cluster. ```
```
rsyslog-config add-server name= ip-address= port= network-protocol=udp relp-enabled=false
```
```
5. Choose a module to forward log information from and specify the level of information to collect. ```
```
rsyslog-config add-module server-name= module-name= level=
```
```
Replace <module\_name> with one of the following:
- ACROPOLIS - The acropolis services are responsible for task scheduling, execution, stat collection, publishing, etc. For more information, see [Acropolis Services in the Nutanix Bible](https://nutanixbible.com/#anchor-book-of-aos-acropolis-services).
- AUDIT - Seeds the "consolidated\_audit.log" which is used to track ergon tasks that result in changes to the cluster and UVMs.
- CASSANDRA - Stores and manages all of the cluster metadata
- CEREBRO - Responsible for replication and DR capabilities
- CURATOR - Responsible for managing and distributing tasks throughout the cluster
- GENESIS - Responsible for any services interactions (start/stop/etc.) as well as the initial configuration
- PRISM - Management gateway for components and administrators to configure the cluster, monitor the cluster and track logins (successful and unsuccessful).
- STARGATE - Responsible for all data management and I/O operations
- APLOS - API requests
- SYSLOG\_MODULE - SSH logins and much information about local root account usage (starting processes, for example)
- ZOOKEEPER - Stores all of the cluster configuration
For more information about the modules above, see [Cluster Components in the Prism Web Console Guide](https://portal.nutanix.com/page/documents/details?targetId=Web-Console-Guide-Prism-v6_7:arc-cluster-components-c.html) or [the Nutanix Bible](https://nutanixbible.com/#anchor-book-of-basics-cluster-components).
Enable module logs at the ERROR level unless you require more information. Replace <log\_level> with one of the following:
- EMERGENCY
- ALERT
- CRITICAL
- ERROR
- WARNING
- NOTICE
- INFO
- DEBUG
For example, if you set the level to INFO, it also covers the levels above it (i.e. EMERGENCY, ALERT, CRITICAL, ERROR, WARNING and NOTICE). If you select INFO for a module, you do not have to select any of the levels above it for the same module.
**Note:** CVMs send system audit logs to the syslog server by default, even when no modules are configured for the server. Below is an example of these audit logs:
```
```
2021-09-09T08:56:01.353708-05:00 ntnx-xxx-cvm audispd[5307]: node=ntnx-xxx-cvm type=PROCTITLE msg=audit(1631195761.351:193118):
proctitle=2F7573722F62696E2F707974686F6E322E37002D42002F686F6D652F6E7574616E69782F736572766963656162696C6974792F62696E2F7573696E672D67666C616773002F686F6D652F
6E7574616E69782F736572766963656162696C6974792F62696E2F63726F6E5F736572766963656162696C6974792E7079
2021-09-09T08:56:01.353827-05:00 ntnx-xxx-cvm audispd[5307]: node=ntnx-xxx-cvm type=SYSCALL msg=audit(1631195761.351:193119):
arch=c000003e syscall=90 success=yes exit=0 a0=16fbbe0 a1=1ed a2=1 a3=0 items=1 ppid=5498 pid=5503 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000
egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=13210 comm="python2.7" exe="/usr/bin/python2.7" subj=nutanix_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="audit_time_perm_mod_export_delete"
2021-09-09T08:56:01.353939-05:00 ntnx-xxx-cvm audispd[5307]: node=ntnx-xxx-cvm type=PATH msg=audit(1631195761.351:193119):
item=0 name="/home/nutanix/.python-eggs/psutil-5.7.0-py2.7-linux-x86_64.egg-tmp/psutil/tmpe8m0Gx.$extract" inode=1705569 dev=09:02 mode=0100600 ouid=1000
ogid=1000 rdev=00:00 obj=nutanix_u:object_r:user_home_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
```
```
To prevent flooding of the rsyslog server with these audit logs, they need to be filtered on the server level. One possible solution is to filter logs based on the keyword "audispd".
6. Enable the rsyslog server: ```
```
rsyslog-config set-status enable=true
```
```
Logs should start forwarding to the remote syslog server.
To test functionality of sending messages from the Nutanix Cluster to an external rsyslog server, use the native Linux logger command.
For TCP network protocol: ```
```
logger -T -P -n -s "This is a Test"
```
```
For UDP Network protocol: ```
```
logger -d -P -n -s "This is a Test"
```
```
The above commands should print the test message in */var/log* directory of the rsyslog server.
7. To show the current rsyslog server setting and modules added, run the following commands: ```
rsyslog-config ls
rsyslog-config ls-modules server-name=
```
Source: *[https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e0000009CEECA2](https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e0000009CEECA2)**If you need further assistance, kindly contact our support at **support@cytechint.com**for prompt assistance and guidance.*
# OKTA Integrations
##### **Introduction**The Okta integration collects events from the Okta API, specifically reading from the Okta System Log API.
**Logs**
**System**
The Okta System Log records system events related to your organization in order to provide an audit trail that can be used to understand platform activity and to diagnose problems. This module is implemented using the httpjson input and is configured to paginate through the logs while honoring any rate-limiting headers sent by Okta.
##### **OktaIntegrationProcedures**Please provide the following information to CyTech:
**Collect Okta logs via API**
1. API Key - API Key is required.
2. Okta System Log API Url - Okta System Log API Url is required.
# Palo Alto Cortex XDR Integration
#### **Palo Alto Cortex XDR Integration**
Using the Cortex XDR APIs, you can integrate Cortex XDR with third-party apps or services to ingest alerts and to leverage alert stitching and investigation capabilities. The APIs allows you to manage incidents in a ticketing or automation system of your choice by reviewing and editing the incident's details, status, and assignee. Using the APIs, you can also retrieve information on the endpoints, create installation package, perform response actions directly on the endpoint and more.
##### **Alerts**
The Cortex XDR Alerts API is used to retrieve alerts generated by Cortex XDR based on raw endpoint data. A single alert might include one or more local endpoint events, each event generating its own document on Elasticsearch.
The Palo Alto XDR integration requires both an API key and API key ID, both which can be retrieved from the Cortex XDR UI.
##### **API**
**Before you can begin using Cortex XDR APIs, you must generate the following items from the Cortex XDR app:**
Value
Description
**API Key**
The API Key is your unique identifier used as the `Authorization:{key}` header required for authenticating API calls. Depending on your desired security level, you can generate two types of API keys, Advanced or Standard, from your Cortex XDR app.
**API Key ID**
The API Key ID is your unique token used to authenticate the API Key. The header used when running an API call is `x-xdr-auth-id:{key_id}`.
**FQDN**
The FQDN is a unique host and domain name associated with each tenant. When you generate the API Key and Key ID, you are assigned an individual FQDN.
##### **Create Cortex API Key:**
The following steps describe how to generate the necessary key values:
1. Get your Cortex XDR API Key:
1. In Cortex XDR, navigate to **Settings** > **Configurations** > **Integrations** > **API Keys**.
2. Select **+ New Key**.
3. Choose the type of API Key you want to generate based on your desired security level: **Advanced** or **Standard**. The Advanced API key hashes the key useing a nonce, a random string, and a timestamp to prevent replay attacks. cURL does not support this but is suitable with scripts. Use the provided script to create the advanced API authentication token.
**Note: To integrate with Cortex XSOAR you must generate an Advanced Key.**
4. If you want to define a time limit on the API key authentication, mark **Enable Expiration Date** and select the expiration date and time. Navigate to **Settings** > **Configurations** > **Integrations** > **API Keys** to track the **Expiration Time** field for each API key. In addition, Cortex XDR displays a API Key Expiration notification in the Notification Center one week and one day prior to the defined expiration date.
5. Provide a comment that describes the purpose for the API key, if desired.
6. Select the desired level of access for this key. You can select from the list of existing **Roles**, or you can select **Custom** to set the permissions on a more granular level. Roles are available according what was defined in the hub as described in the Manage Roles section of the Cortex XDR Administrator’s Guide.
7. **Generate** the API Key.
8. Copy the API key, and then click **Done**. This value represents your unique `Authorization:{key}`.
**Note: You will not be able to view the API Key again after you complete this step. Ensure that you copy it before closing the notification.**
##### **Cortex XDR API Key ID**
Get your Cortex XDR API Key ID.
1. 1. In the API Keys table, locate the **ID** field.
2. Note your corresponding **ID** number. This value represents the `x-xdr-auth-id:{key_id}` token.
**Note: This key id will be used for integrations with elastic.**
##### **Cortex XDR API FQDN**
Get your FQDN.
1. Right-click your API key and select **View Examples**.
2. Copy the **CURL Example** URL. The example contains your unique FQDN:
`https://api-{fqdn}/public_api/v1/{name of api}/{name of call}/` You can use the **CURL Example** URL to run the APIs.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Palo Alto Firewall Syslog Filter
##### **Introduction**This guide outlines how to configure **Syslog filters** on Palo Alto Networks firewalls to control which logs are sent to external Syslog servers. Proper filtering reduces noise, focuses on relevant events, and improves SIEM performance.
##### **Syslog Overview**Syslog is a protocol used to send logs from network devices to centralized logging systems. Palo Alto firewalls support syslog forwarding for various log types: **traffic**, **threat**, **system**, and **configuration**.
##### **Components Involved**
Component
Description
Syslog Server Profile
Defines the destination server and syslog transport type
Log Forwarding Profile
Specifies what logs to forward and to whom
Security Policy
Determines when logs are generated and which are forwarded
##### **Configuration Steps**
##### **1. Create Syslog Server Profile**
##### Navigate to: **Device** > **Server Profiles** > **Syslog**
##### **Steps:**
1. Click **Add** to create a new profile.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/UVKt7zpsTvW9bCUI-2025-06-19-11-20.png)
2. Enter a **Name (e.g., AQUILA-Syslog-Filter). [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/KZGuGzwbBSly05zw-syslog-name.png)**
3. Under **Syslog Server**, click **Add** and enter:
- **Name**: e.g., AQUILA-Server
- **Server**: IP or hostname of your syslog server(log collecttor IP)
- **Transport**: UDP or TCP
- **Port**: Default is 514 (UDP)
- **Facility**: e.g., local4
- **Format**: BSD
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/jm5IZn8oPyzwM6iS-2025-06-19-11-33.png)
4. Add a **Filter** to specify:
- **Log Type**: Threat
- **Severity**: High
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/NFrEro1pXoJSroAi-levels.png)
5. Click **OK**
##### **2. Create Log Forwarding Profile**Navigate to: **Objects** > **Log Forwarding**
**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/LUCzkkk4DwCi2xW7-objects.png)**
##### **Steps:**
1. Click **Add** to create a new log forwarding profile.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/RBWMVx9jxKAdvLnd-add.png)
2. Name it (example: syslog)
3. Under **Log Type**, click **Add** and configure:
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/TsTqOna0GsjIzAsU-syslog.png)
- **Log Type**: Select Threat
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/cyWcOslLjexb9bjy-traffic.png)
- **Filter**: severity eq high
- **Forward Method**: Select the Syslog Server Profile you created, click **Add** then select the one you **created**
4. Click **OK
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/NITyrphhyaMsouws-methof.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/o8r1tkpKiqn7aHWT-okay.png)**
##### **3. Apply Log Forwarding to Security Policy****Navigate to: Policies > Security**
**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/w7oQKZI0gBzIvdui-sections.png)**
##### **Steps:**
1. Locate and **edit** the security policy you want to apply logging to.
2. Click the **Actions** tab.
3. In the **Log Forwarding** field, select the log forwarding profile you created.
4. (Optional) Enable logging at session start/end.
5. Click **OK** and then **Commit** your changes.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-06/QCZiWwBgPTTVKz7a-fd.png)
##### **Please provide the following information to CyTech: ******Requirements:Collect logs via syslog over UDP or TCP\***Syslog Host**-> Syslog Collector IP address where the Elastic-Agent is installed.
\***Syslog Port**-> Port Number (Please identify if TCP or UDP)*Reference Links:*
- *[https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring](https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring "Palo alto")*
- *[https://www.youtube.com/watch?v=ftR3DU2MtjY&t=137s](https://www.youtube.com/watch?v=ftR3DU2MtjY&t=137s "syslog system configure")*
*If you need further assistance, kindly contact our support at* ***support@cytechint.com*** *for prompt assistance and guidance.*
# Palo Alto Next Generation Firewall
#### **Configure Syslog Monitoring****STEP 1 - Configure a Syslog server profile.**
- - Select **Objects**-->**LogForwarding**, click **Add**, and enter a **Name** to identify the profile.
- - For each log type and each severity level or WildFire verdict, select the **Syslog server profile** and click **OK**.
2. Assign the log forwarding profile to a security policy to trigger log generation and forwarding.
- - Select **Policies**-->**Security**and select a policy rule.
- - Select the **Actions** tab and select the **Log Forwarding** profile you created.
- - For Traffic logs, select one or both **Log at Session Start** and **Log at Session End** check boxes, and click **OK**.
**STEP 3 - Configure syslog forwarding for System, Config, HIP Match, and Correlation logs.**
1. Select **Device**-->**Log Settings**.
2. For System and Correlation logs, click each Severity level, select the **Syslog server profile**, and click **OK**.
3. For Config, HIP Match, and Correlation logs, edit the section, select the **Syslog server profile**, and click **OK**.
Source: *[https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring](https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring)*
#### **Palo Alto Next Generation Firewall Integration Procedures **
##### Please provide the following information to CyTech: Requirements:Collect logs via syslog over UDP or TCP\*Syslog Host-> Syslog Collector IP address where the Elastic-Agent is installed.
\*Syslog Port-> Port Number (Please identify if TCP or UDP)If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.
# Phishing Campaign - Setting Up Microsoft o365
##### **Why Whitelist in Office 365?**Whitelisting ensures the **CyTech - AQUILA Phishing Simulation(PS) Module** functions without issue and prevents PS emails from being automatically moved to the spam folder or notifying users about potential phishing emails. The Connection Filter Policy and Spam Filtering both required to be whitelisted.
##### **Key Configurations:**
1. **[Microsoft Defender](https://security.microsoft.com/)**
- Whitelist the Connection Filter Policy
- Whitelist Using Advanced Delivery Policies
2. **[Exchange Admin Center](https://admin.exchange.microsoft.com/#/)**
- Whitelist Spam Filtering
- Whitelist Advanced Threat Protection (ATP)
##### **Whitelist Connection Filter Policy**The Office 365 Exchange Connection Filter identifies good or bad source email servers by their IP addresses. The actions below will allow all emails from CyTech IP addresses to be received.
##### **Whitelist the Connection Filter Policy** 1. Login to Microsoft Defender, click here - **[Microsoft Defender.](https://security.microsoft.com/)**2. Navigate through **Email & Collaboration>Policies & Rules>Threat Policies>Anti-spam.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/PDl8uDXvhHXHskUW-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/4Fah0R9XdAWXbZvU-image.png)3. Click on "**Connection filter policy**". Then click on "**Edit connection filter policy**".[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/qNwcvxjpzdNb3STp-image.png)4. Add the **IP's** to the "Always allow messages from the following IP addresses or address range:". Then click the "**Save**" button.**Allow IP's: 35.153.237.243**(Mail Server), **107.22.65.180**(Landing Page)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/MvJvE5Zk2I9lb0Tp-image.png)
##### **Whitelist Using Advanced Delivery Policies in Microsoft Defender for Office 365**Phishing simulations are attacks orchestrated by your security team and used for training and learning. Simulations can help identify vulnerable users and lessen the impact of malicious attacks on your organization.Third-party phishing simulations require at least one Sending domain entry \[source domain or DKIM\] AND at least one Sending IP entry. Simulations URLs to allow entries are optional, and prevent the simulated phishing URLs from being blocked at time of click. 1. Go to **Email & Collaboration > Policies & Rules > Threat policies > Advanced delivery in the Rules section**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/mN1S2kTRaISM8muh-image.png)2. In the Advanced delivery menu, navigate to the Phishing simulation tab and press Edit to either add new or configure existing values (refer to the screenshot below). After editing all the needed Domain, Sending IP and Simulation URLs to allow**.** Click **"Save".**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/8y5eyi7HQva7D6au-image.png)3. On the Edit third-party phishing simulation menu that opens, configure the following settings:**Domain:** Expand this setting and enter at least one sending domain specific for campaign by clicking in the box, entering a value, and then pressing Enter or selecting the domains displayed below. Repeat this step as many times as necessary. You can add up to 20 entries.
- slackj.com
- ttrelli.com
- airbnd.cc
- attlassians.com
- eebbey.com
- lastpasss.net
- my1psswords.com
- zooms.cc[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/iUgoti0IotleAb1x-image.png)**Sending IP:** Expand this setting and enter at least one valid IPv4 address by clicking in the box, entering a value, and then pressing Enter or selecting the value that's displayed below the box. Repeat this step as many times as necessary. You can add up to 10 entries.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/Z463XX4cNcj2NV6U-image.png)**Simulation URLs to allow:** Expand this setting and optionally enter specific URLs that are part of your phishing simulation campaign that should not be blocked or detonated by clicking in the box, entering a value, and then pressing Enter or selecting the value that's displayed below the box.For the URL syntax format, see URL syntax for the Tenant Allow/Block List (opens in a new tab). These URLs are wrapped at the time of the click, but they aren't blocked.When you're finished, you can click Add, and click close afterward if this was a first-time addition, or if you were editing existing values click Save and then click Close.
- [Manage allows and blocks in the Tenant Allow/Block List](https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-about?view=o365-worldwide#url-syntax-for-the-tenant-allowblock-list)Refer to these simulation URLs to allow in your campaign:
- slackj.com/\*
- ttrelli.com/\*
- airbnd.cc/\*
- attlassians.com/\*
- eebbey.com/\*
- lastpasss.net/\*
- my1psswords.com/\*
- zooms.cc/\*[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/2upgxf44qn82hAs8-image.png)
##### **Whitelist Spam Filtering**All mail systems have spam filtering. As the CyTech PS emails are "phishing: by definition, the Microsoft spam filter must be whitelisted. The steps below outline how to disable all spam checks for CyTech PS emails, so you won't experience issues with 100% clicked and 100% opened emails, even if the users don't click on them.**Steps to Whitelist the Spam Filtering** 1. Login to Exchange Admin Center, click here - **[Exchange Admin Center.](https://admin.exchange.microsoft.com/#/)**2. Navigate through **Mail flow>Rules>+Add a rule>"Create a new rule"**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/hAk8OrVkreZ6pU04-image.png)3. Give the rule a name, such as "**CyTech Spam Filtering**". Click on "**Apply this rule if** → "**The sender"** → "**IP address is in any of these ranges or exactly matches".**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/gyMSuVo3bL5JlDBM-image.png)4. Specify the IP addresses in the field IP's: **35.153.237.243**(Mail Server), **107.22.65.180**(Landing Page). Please do not forget to click on "**Save**".[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/r7CiZYkeJCeTjbwE-image.png)5. Click the "**+**" to add another rule condition for the message headers.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/S4ggBIlJx5MjjZNX-image.png)6. Click on "**The message headers...."** → "**includes any of these words".**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/mQmSmJQgc8EVK6Ft-image.png)7. Click → **Enter text.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/E2lddVdrD882aVpr-image.png)8. Specify header name → **X-PHISHTEST** and specify words or phrases **→ CYTECH.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/JIYvK0wFwmjjI0G9-image.png)9. Click the "**+**" to add another rule condition for the The sender.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/S4ggBIlJx5MjjZNX-image.png)10. Click on "**The sender...."** → "**domains is".** Specify the domain in your case**.** Then click **"Save".**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/M9MlpGJUEccQSdOf-image.png)11. Click on "**Do the following** → **Modify the message properties** → **Set a Message Header**"[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/FKdNYeHZgcr2lIs5-image.png)12. Click the "**Enter text**" buttons by the right side of the "**Do the following**" field and enter these values: "**MS-Exchange-Organization-BypassClutter**" and "**true**".[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/n9dPl6FKLcXOswSX-image.png)13. Click on the "**+**" sign, to add another rule condition.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/MRkPKW5VW7yuUTso-image.png)14. Choose "**Modify the message properties** → **Set the spam confidence level (SCL)**" and select "**Bypass Spam Filtering**", this will set the value of SCL to **-1**. Then click "**Save**" button.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/C3I64J9LDmN9k8bT-image.png)15. Make sure you have the same output as shown in the image below before proceeding on clicking the "**Next**" button.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/bhMwvKPYIz8UpsNf-image.png)16. Leave the Set Rule settings as is and proceed to the Review and finish window and save the rule.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/VemlEkaeC8mYkQWO-image.png)17. Please make sure the rule is **Enabled**, and priority is **set to "0"**. Your final Completed Mail Flow Rule screen should look as below:[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/ztnnPiUIWFeTARcW-image.png)*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# Pulse Connect Secure Integrations
##### **Introduction**This integration is for [Pulse Connect Secure](https://www.ivanti.com/products/ivanti-neurons-zero-trust-access?psredirect).
##### **Pulse Connect Secure Integration Procedures**Please provide the following information to CyTech:
**Collect Pulse Connect Secure logs (input: udp)**
# Resource Manager Endpoint Integration
The Azure Resource Manager (ARM) endpoint is the primary entry point for interacting with the Azure platform's resource management services. It allows users to deploy, manage, and organize resources like virtual machines, storage accounts, and networks within a defined Azure subscription. The ARM endpoint serves as a REST API that facilitates the creation, modification, and deletion of resources, ensuring secure and scalable management of Azure resources. It also supports role-based access control (RBAC), policy enforcement, and resource tagging for effective governance. In essence, the ARM endpoint enables seamless communication between Azure services and clients for infrastructure management.
---
#### **Requirements:**
- Microsoft Azure account
---
#### **Setup:**
##### **How to Create an Azure Resource Manager Service Endpoint**
##### **1. Create Service Principal**
To create a Service Principal we must first register an application in the Azure Active Directory, which we will do now. As of this writing this can only be done in the original Azure portal. However, many of us are being forced into the new portal upon login. If you are, simply click on **Browse** and select **Active Directory** and you will be redirected to the original Azure portal.
1. Click on **Applications** of the selected Active directory
2. Click the **Add** button at the button of the page
3. Enter a name for your application and make sure Web Application and/or Web API is selected
4. Enter two URLs based on your application name
They do not have to be real. I used the same value for both.
5. Once the application is created, click on **Configure**
6. Make note of the **Client ID** because we will need it in a moment
7. Select a key duration under the keys section and click **Save** at the bottom of the page
8. Once the key is saved copy the value and place it with your Client ID
This will be your only chance to collect this value.
##### **2. Find Tenant ID**
With the Active Directory select on the Applications page, we can harvest the Tenant ID.
1. Click **View Endpoints** at the bottom of the page
2. Copy any of the URLS and paste into an editor
3. The GUID in the URL is your **Tenant ID**
##### **3. Find Subscription Name and ID**
You will also need the subscription name and ID to complete the service endpoint. We can get them while we are in the old portal.
1. Click **Settings** in the left vertical menu
2. Copy the **Subscription** and **Subscription ID** values
##### **4. Grant access**
Now that we have a service principal we need to give it access to create resources in your subscription. Return to the new Azure Portal.
1. Click **Browse** and select **Subscriptions**
2. Select the subscription you are using
3. Click the **Access** button
4. Click **Add**
5. Select **Contributor** as the roll
6. Search and select the name of the application you just created
7. Click **OK** to grant the service principal access to your subscription
There is a script that can do all of this for you [here ](https://raw.githubusercontent.com/Microsoft/vso-agent-tasks/master/Tasks/DeployAzureResourceGroup/SPNCreation.ps1)on GitHub.
##### **5. Create Service Endpoint**
With the Service Principal created, we can now create the Service Endpoint in VSTS.
1. Log in to VSTS and select a project
2. Click the manage project gear icon in the upper right hand corner of the page
3. Select the **Services** tab
4. Select **Azure Resource Manager** from the **New Service Endpoint** drop down
**Field**
**Value**
Connection Name
{AnyValueYouLike}
Subscription Id
Subscription Id
Subscription Name
Subscription Name
Service Principal Id
Client Id
Service Principal Key
Key
Tenant Id
Tenant Id
5. Click **OK**
##### **How to navigate and locate Resource Manager Endpoint.**
1.Sign in to the Azure portal.
2.Select **Resource groups** from the left panel.
3.Select the resource group that you have already created specifically for Azure Integration.
4.Hover to "Overview".
5.Verify the following resources were created in the resource group: "Endpoint Name" and type "Endpoint".
6.Copy the Endpoint Name for integration requirement. Ex. contosocdn123(myCDNProfile/contosocdn123)
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# SentinelOne Integrations
The SentinelOne integration collects and parses data from SentinelOne REST APIs. This integration also offers the capability to perform response actions on SentinelOne hosts directly through the Elastic Security interface
#### **Compatibility**This module has been tested against **SentinelOne Management Console API version 2.1**.
#### **API token**To collect data from SentinelOne APIs, you must have an API token. To create an API token, follow these steps:
1. Log in to the **SentinelOne Management Console** as an **Admin**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/vfZNCYpWdneD5rTU-image.png)2. Navigate to **Logged User Account** from top right panel in the navigation bar.3. Click **My User**.4. In the API token section, click **Generate**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/T2Q4I5N2LudoGmQO-image.png)
The API token generated by the user is time-limited. To rotate a new token, log in with the dedicated admin account.
**Please provide the credenetials to AQUILA Support.**
1. **SentinelOne console URL** (https://<your-sentinelone-domain>.sentinelone.net, where "Domain" is the domain name of your SentinelOne account.)2. **API token**
#### **Integrate on AQUILA****1.** Log in to **[CyTech - AQUILA](https://cytechint.io/)**. Choose **Cyber Monitoring** and click the **small arrow icon** to redirect you to the Cyber Monitoring Dashboard.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/QUruqc4qZzjj39A2-image.png)
2. In the dashboard, choose **Cyber Incident Management (SIEM and XDR)**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/i68EMO7YfIStKeyl-image.png)
3. Navigate through the leftmost top and click **Cyber Incident Monitoring**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/KgRo0wYa67PKNCws-image.png)
4. Navigate through **Settings>Log Source>Search Bar>Add to Agent**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/oe0JNmFK0Jncf3yD-image.png)
5. Choose your **Log Collector**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/1VIERSAN80moG8fG-image.png)
6. In the integration settings follow the instructions given below.
1. Click the **drop arrow** to display the contents needed for the integration setup.
2. Provide **SentinelOne Console URL**.
3. Provide the **API Token**.
4. Finally, click **Next** to install the log source integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/iUdkuG0aq7DTQiaz-image.png)
7. Wait for the **Successfull** window to display, this will confirm the successfull integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/CNFzJRIuFuvZIEdI-image.png)
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# Set Up Integration from SonarQube
#### **SonarQube**
**Introduction**
SonarQube is a self-hosted or cloud-enabled tool that scans source code to detect bugs, vulnerabilities, code smells, duplications, and coverage issues across 30+ languages. It integrates with build tools (Maven, Gradle, MSBuild) and CI/CD pipelines like Jenkins, GitLab, and GitHub Actions. With IDE plugins for VS Code, IntelliJ, Eclipse, and more, it enforces "Clean as You Code" practices during development. Built for DevSecOps, it can block pull requests or deployments if quality gates are not met.
**Description:**
SonarQube does not natively support direct integration with the Elastic Stack for sending code quality metrics.
However, it can forward **logs**, **metrics**, or even **SonarQube API data** into Elasticsearch using custom setups.
##### What It Does:
- Sends SonarQube logs to Elasticsearch for indexing and analysis in Kibana.
- Optionally pushes code quality metrics (bugs, vulnerabilities, coverage, etc.) to Elasticsearch using custom scripts.
- Enables unified observability of code health and platform behavior inside Elastic Stack.
#### **Option 1: Send Logs to Elastic Using Filebeat**
**Description:**
Use Filebeat to collect and forward SonarQube logs to Elasticsearch for centralized logging and visualization in Kibana.
**What It Does:**
- Automatically ships log files from the SonarQube server to Elasticsearch.
- Allows real-time log monitoring, search, and alerting via Kibana.
- Supports analysis of SonarQube behavior, errors, and performance patterns.
##### Steps
**Prepare SonarQube Logs**
- **Locate logs (default path: /opt/sonarqube/logs/)**
- web.log
- ce.log
- es.log
- sonar.log
**Install Filebeat on the SonarQube Host**
- I**nstall Filebeat from**
- https://www.elastic.co/docs/reference/beats/filebeat/filebeat-installation-configuration
**Configure Filebeat to Read SonarQube Logs**
- **Edit filebeat.yml configuration file:**
> filebeat.inputs:
> \- type: log
> enabled: true
> paths:
> \- /opt/sonarqube/logs/\*.log
>
> output.elasticsearch:
> hosts: \["http://<elasticsearch-host>:9200"\]
> username: "elastic"
> password: "your-password"
- **Start and Enable Filebeat**
> sudo systemctl enable filebeat
> sudo systemctl start filebeat
#### **Option 2: Push Metrics to Elastic via SonarQube API**
**Description:**
Use SonarQube’s built-in Web API to extract code quality metrics and push them into Elasticsearch using a custom script.
**What It Does:**
- Retrieves metrics like bugs, vulnerabilities, code smells, and coverage.
- Pushes data to an Elasticsearch index for dashboarding or analysis.
- Enables tracking of project quality trends over time in Kibana.
##### Steps:
**Enable API Access in SonarQube**
- **SonarQube provides a built-in Web API at:**
- - http://<sonarqube-host>/api/measures/component
- **Use the API to retrieve metrics like:**
> GET /api/measures/component?component=<project\_key>&metricKeys=bugs,vulnerabilities,coverage
**Build a Custom Script (Python Example)**
- **Use Python to fetch and send metrics:**
> import requests, json
>
> sonar\_url = "http://<sonarqube>/api/measures/component"
> params = {"component": "your\_project", "metricKeys": "bugs,vulnerabilities,code\_smells"}
>
> res = requests.get(sonar\_url, params=params)
> data = res.json()
>
> \# Send to Elasticsearch
> es\_url = "http://<elasticsearch>:9200/sonarqube-metrics/\_doc"
> requests.post(es\_url, headers={"Content-Type": "application/json"}, data=json.dumps(data))
What Happens Next?
Action
Result
SonarQube writes logs
Filebeat ships them to Elasticsearch
Kibana receives log data
Visualize system behavior and performance
Script pulls SonarQube metrics
Elasticsearch stores code health data (via API)
Kibana dashboards can be created
Visualize bugs, vulnerabilities, coverage, etc.
Requirements
Requirement
Purpose
Filebeat
Forwards log files to Elasticsearch
Elasticsearch
Stores both logs and custom metrics
SonarQube API
Source of code quality data
Custom Script
Pulls metrics and pushes them to Elastic
Cron (optional)
Automates periodic metric synchronization
Integration Mapping Summary
Component
Function
SonarQube Logs
Shipped to Elasticsearch via Filebeat
Filebeat
Collects and forwards logs
Elasticsearch
Stores logs and metrics
SonarQube API
Retrieves code metrics like bugs, smells, coverage
Custom Script
Pushes metrics to Elasticsearch
Kibana
Visualizes logs and code quality over time
# Setup Integration from Qualys
## Qualys VMDR Integration Guide
Integrate **Qualys Vulnerability Management, Detection and Response (VMDR)** with the Elastic Stack via REST API to ingest vulnerability, asset, and detection data directly into Elasticsearch for centralized security monitoring and analysis.
## Credentials & API Access Setup
Before configuring the integration, you’ll need to prepare your API credentials in Qualys:
**Steps:**
1. Log in to the **Qualys Admin Portal**.
2. Go to **User Management**.
3. Create or select a dedicated **API User** with:
- **API Access permission**
- Access to:
- **VMDR Module**
- **Host Detection**
- **Asset Inventory**
- **Knowledge Base**
- **User Activity Log** (if required)
4. Take note of:
- **Username**
- **Password**
- Your **Qualys Platform API URL**:
- Check via: [Qualys Platform Identification](https://www.qualys.com/platform-identification/)
- Or log in to Qualys → Help → About → see “Security Operations Center (SOC)” for your URL.
## Elastic Integration Configuration
#### In Kibana:
1. Go to **Management → Integrations**.
2. In the search bar, type **Qualys VMDR**.
3. Select **Qualys VMDR** from the search results.
4. Click **Add Qualys VMDR Integration**.
#### Provide the following connection details based on the data you want to collect:
Data Stream
Required Details
**Asset Host Detection**
username, password, API URL, interval, input parameters, batch size
**Knowledge Base**
username, password, API URL, initial interval, interval, input parameters
**User Activity Log**
username, password, API URL, initial interval, interval
5. Save the integration.
#### Permissions Reference (API User)
Data Stream
Role
Permission Scope
**Asset Host Detection**
Managers, Unit Managers, Scanners, Readers
VM scanned hosts (depending on role scope)
**Knowledge Base**
Managers, Unit Managers, Scanners, Readers
Can download vulnerability data
**User Activity Log**
Managers, Unit Managers, Scanners, Readers
Can view user actions (own or others, depending on role)
# Slack Integrations
##### **Introduction**
Slack is used by numerous organizations as their primary chat and collaboration tool.
**Please note the Audit Logs API is only available to Slack workspaces on an Enterprise Grid plan. These API methods will not work for workspaces on a Free, Standard, or Business+ plan.**
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
##### **Requirements**
**Configuration**
**Enabling the integration in Elastic**
1. In Kibana go to **Management > Integrations**
2. In the "Search for integrations" search bar type **Slack.**
3. Click on "Slack" integration from the search results.
4. Click on **Add Slack** button to add Slack integration.
**Configure Slack audit logs data stream**
Enter values "OAuth API Token".
1. [OAuth API Token](https://api.slack.com/authentication/basics) will be generated when a [Slack App](https://api.slack.com/apps) is created.
**CONFIGURE USING API TOKEN**For the Slack integration to be able to successfully get logs the following "User Token Scopes"" must be granted to the Slack App:
- **auditlogs:read**
**Logs**
**Audit**
Audit logs summarize the history of changes made within the Slack Enterprise.
##### **SLACKIntegrationProcedures**Please provide the following information to CyTech:
**Collect Slack logs via API**
1. API URL - The root URL for the API endpoints.
**Slack Audit logs**
1. OAuth API Token - The OAuth API Token used to authenticate with the Slack API
# Sophos Integration
#### **Overview**
The Sophos Central integration allows you to monitor Alerts and Events logs. Sophos Central is a cloud-native application with high availability. It is a cybersecurity management platform hosted on public cloud platforms. Each Sophos Central account is hosted in a named region. Sophos Central uses well-known, widely used, and industry-standard software libraries to mitigate common vulnerabilities.
Use the Sophos Central integration to collect logs across Sophos Central managed by your Sophos account. Visualize that data in Kibana, create alerts to notify you if something goes wrong, and reference data when troubleshooting an issue.
##### **Compatibility**
The Sophos Central Application does not feature version numbers. This integration has been configured and tested against **Sophos Central SIEM Integration API version v1**.
##### **Requirements**
You need Elasticsearch for storing and searching your data, and Kibana for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your own hardware.
#### **Setup**
##### **Elastic Integration for Sophos Central Settings**
The Elastic Integration for Sophos Central requires the following Authentication Settings in order to connect to the Target service:
- Client ID
- Client Secret
- Grant Type
- Scope
- Tenant ID
- Token URL
**NOTE**: Sophos central supports logs only upto last 24 hrs.
**Step 1 - Create a service principal**
We will show you how you can sign in to Sophos Central Admin and create a service principal. You need to have the Super Admin role to do this.
**Step 1a - Sophos Central Admin**
Sign in to Sophos Central Admin. Go to [https://central.sophos.com/manage](https://central.sophos.com/manage).
Click 'Global Settings' and then click the "API Credentials" link.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/J8WTNdfPSYwa4Ney-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/kAQf0UBHEHDMxA7E-image.png)
**Step 1b - Add a new set of credentials**
Supply a name for your credential set and a description, then click 'Add' as shown in the example below.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/V6Nbxw3xaP96XCqA-image.png)
**Step 1c - Grab your client ID and secret**
Click 'Copy' to note down the client ID. Also show the client secret.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/G4GNGTJkg3ctQy24-image.png)
Click 'Copy' to note down the client secret.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/iUXdH1ob40RzKe26-image.png)
⚠️ **WARNING:** It is your responsibility to store your client ID and secret securely. If these are lost or stolen, an attacker will be able to call APIs on your behalf and steal your data or cause damage.
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# Sysmon for Linux
##### **Introduction**The Sysmon for Linux integration allows you to monitor the Sysmon for Linux, which is an open-source system monitor tool developed to collect security events from Linux environments.Use the Sysmon for Linux integration to collect logs from linux machine which has sysmon tool running. Then visualize that data in Kibana, create alerts to notify you if something goes wrong, and reference data when troubleshooting an issue.NOTE: To collect Sysmon events from Windows event log, use Windows sysmon\_operational data stream instead.
- [Sysmon for Linux](https://github.com/Sysinternals/SysmonForLinux) - [https://github.com/Sysinternals/SysmonForLinux](https://github.com/Sysinternals/SysmonForLinux)
- [Windows sysmon\_operational data stream](https://docs.elastic.co/en/integrations/windows#sysmonoperational) - https://docs.elastic.co/en/integrations/windows#sysmonoperational
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### **Requirements**
**Setup**
For step-by-step instructions on how to set up an integration, see the Getting started guide.
**Data streams**
The Sysmon for Linux log data stream provides events from logs produced by Sysmon tool running on Linux machine.
**Sysmon for LinuxIntegration**
Please provide the following information to CyTech:Collect Sysmon for Linux logs(Enable Yes/No)
1. Paths - /var/log/sysmon\*
# System Integrations
##### **Introduction**The System integration allows you to monitor servers, personal computers, and more.Use the System integration to collect metrics and logs from your machines. Then visualize that data in Kibana, create alerts to notify you if something goes wrong, and reference data when troubleshooting an issue.For example, if you wanted to be notified when less than 10% of the disk space is still available, you could install the System integration to send file system metrics to Elastic. Then, you could view real-time updates to disk space used on your system in Kibana's \[Metrics System\] Overview dashboard. You could also set up a new rule in the Elastic Observability Metrics app to alert you when the percent free is less than 10% of the total disk space.Data streamsThe System integration collects two types of data: logs and metrics.Logs help you keep a record of events that happen on your machine. Log data streams collected by the System integration include application, system, and security events on machines running Windows and auth and syslog events on machines running macOS or Linux. See more details in the Logs reference.
Metrics give you insight into the state of the machine. Metric data streams collected by the System integration include CPU usage, load statistics, memory usage, information on network behavior, and more. See more details in the Metrics reference.
You can enable and disable individual data streams. If all data streams are disabled and the System integration is still enabled, Fleet uses the default data streams.
##### **Assumptions**The procedures described in Section 3 assumes that a Log Collector has already been setup.
##### **Requirements**You need Elasticsearch for storing and searching your data and Kibana for visualizing and managing it. You can use our hosted Elasticsearch Service on Elastic Cloud, which is recommended, or self-manage the Elastic Stack on your own hardware.Each data stream collects different kinds of metric data, which may require dedicated permissions to be fetched and which may vary across operating systems. Details on the permissions needed for each data stream are available in the Metrics reference.
TroubleshootingNote that certain data streams may access /proc to gather process information, and the resulting ptrace\_may\_access() call by the kernel to check for permissions can be blocked by AppArmor and other LSM software, even though the System module doesn't use ptrace directly.
In addition, when running inside a container the proc filesystem directory of the host should be set using system.hostfs setting to /hostfs.Logs referenceApplicationThe Windows application data stream provides events from the Windows Application event log.SUPPORTED OPERATING SYSTEMS
- Windows
##### **System Integration Procedures**
Please provide the following information to CyTech:**Collect logs from System instances (Enable Yes/No)**
##### **System auth logs (log) (Enable Yes/No)**
- - - **Collect System auth logs using log input.**
1. Paths
2. Preserve original event(Enable Yes/No)
- - - Preserves a raw copy of the original event, added to the field event.original.
3. Ignore events older than
- - - If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Tags
5. Processors (Optional)
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
6. Synthetic source(Enable Yes/No)
**System syslog logs (log)**
1. Paths
2. Tags
3. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
4. Ignore events older than
- - - If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
5. Synthetic source (Enable Yes/No)
**Collect events from the Windows event log (Enable Yes/No)**
1. Application (Enable Yes/No)
- - - Collect Windows application logs.
1. Preserve original event(Enable Yes/No)
- - - Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- - - A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- - - If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- - - The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
6. Synthetic source (Enable Yes/No)
**Security (Enable Yes/No)**
1. Preserve original event(Enable Yes/No)
- - - Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- - - A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- - - If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- - - The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
6. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
7. Synthetic source (Enable Yes/No)
**System (Enable Yes/No)**
1. Preserve original event (Enable Yes/No)
- - - Preserves a raw copy of the original XML event, added to the field event.original
2. Event ID
- - - A list of included and excluded (blocked) event IDs. The value is a comma-separated list. The accepted values are single event IDs to include (e.g. 4624), a range of event IDs to include (e.g. 4700-4800), and single event IDs to exclude (e.g. -4735). Limit 22 IDs.
3. Ignore events older than
- - - If this option is specified, events that are older than the specified amount of time are ignored. Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
4. Language ID
- - - The language ID the events will be rendered in. The language will be forced regardless of the system language. A complete list of language IDs can be found https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c\[here\]. It defaults to 0, which indicates to use the system language. E.g.: 0x0409 for en-US
5. Tags
6. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
7. Synthetic source (Enable Yes/No)
**Collect metrics from System instances (Enable Yes/No)**
1. Proc Filesystem Directory
- - - The proc filesystem base directory.
2. Period
3. Core Metrics
- - - How to report core metrics. Can be "percentages" or "ticks"
4. Tags
5. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
6. Synthetic source (Enable Yes/No)
**System CPU metrics (Enable Yes/No)**
1. Period
2. Cpu Metrics
- - - How to report CPU metrics. Can be "percentages", "normalized\_percentages", or "ticks"
3. Tags
4. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
5. Synthetic source (Enable Yes/No)
**System diskio metrics (Enable Yes/No)**
1. Period
2. Include Devices
- - - Provide a specific list of devices to monitor. By default, all devices are monitored.
3. Tags
4. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
5. Synthetic source (Enable Yes/No)
**System filesystem metrics**
1. Period
2. List of filesystem types to ignore
- - - The filesystem datastream will ignore any filesystems with a matching type as specified here. By default, this will exclude any filesystems marked as "nodev" in /proc/filesystems on linux.
3. Tags
4. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with external metadata.
5. Indexing settings (experimental)
- - - Select data streams to configure indexing options. This is an experimental feature and may have effects on other properties.
6. Synthetic source (Enable Yes/No)
**System fsstat metrics (Enable Yes/No)**
1. Period
2. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with external metadata.
3. Tags
4. Synthetic source (Enable Yes/No)
**System load metrics (Enable Yes/No)**
1. Period
2. Tags
3. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
4. Synthetic source (Enable Yes/No)
**System memory metrics (Enable Yes/No)**
1. Period
2. Tags
3. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
4. Synthetic source (Enable Yes/No)
**System network metrics (Enable Yes/No)**
1. Period
2. Interfaces
- - - List of interfaces to monitor. Will monitor all by default.
3. Tags
4. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
5. Synthetic source (Enable Yes/No)
**System process metrics**
1. Period
2. Process Include Top N By Cpu
- - - Include the top N processes by CPU usage.
3. Process Include Top N By Memory
- - - Include the top N processes by memory usage.
4. Enable cmdline cache (Enable Yes/No)
- - - If false, cmdline of a process is not cached
5. Enable cgroup reporting(Enable Yes/No)
- - - Enable collection of cgroup metrics from processes on Linux.
6. Env whitelist
- - - A list of regular expressions used to whitelist environment variables reported with the process metricset's events. Defaults to empty.
7. Include CPU Ticks (Enable Yes/No)
- - - Include the cumulative CPU tick values with the process metrics.
8. Processes
- - - A glob to match reported processes. By default all processes are reported.
7. Tags
8. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
4. Synthetic source (Enable Yes/No)
**System uptime metrics (Enable Yes/No)**
1. Period
2. Tags
3. Processors
- - - Processors are used to reduce the number of fields in the exported event or to enhance the event with metadata. This executes in the agent before the logs are parsed. See Processors for details.
4. Synthetic source (Enable Yes/No)
**Collect logs from third-party REST API (experimental) (Enable Yes/No)**
1. URL of Splunk Enterprise Server
- - - i.e. scheme://host:port, path is automatic
2. Splunk REST API Username
3. Splunk REST API Password
4. Splunk Authorization Token
- - - Bearer Token or Session Key, e.g. "Bearer eyJFd3e46..." or "Splunk 192fd3e...". Cannot be used with username and password.
5. Preserve original event (Enable Yes/No)
- - - Preserves a raw copy of the original event, added to the field event.original
6. SSL Configuration
- - - i.e.certificate\_authorities, supported\_protocols, verification\_mode etc.
**Windows Application Events via Splunk Enterprise REST API (Enable Yes/No)**
1. Interval to query Splunk Enterprise REST API
- - - Go Duration syntax (eg. 10s)
2. Splunk search string
3. Tags
4. Synthetic source (Enable Yes/No)
**Windows Security Events via Splunk Enterprise REST API (Enable Yes/No)**
1. Interval to query Splunk Enterprise REST API
- - - Go Duration syntax (eg. 10s)
2. Splunk search string
3. Tags
4. Synthetic source (Enable Yes/No)
**Windows System Events via Splunk Enterprise REST API (Enable Yes/No)**
1. Interval to query Splunk Enterprise REST API
- - - Go Duration syntax (eg. 10s)
2. Splunk search string
3. Tags
4. Synthetic source (Enable Yes/No)
# Team Viewer Integrations
**Remote File Copy via TeamViewer**
Identifies an executable or script file remotely downloaded via a TeamViewer transfer session.
**Rule type: eql**
**Rule indices: **
**Severity**: medium **Risk score**: 47 **Runs every**:5m**Searches indices from**: now-9m (Date Math format, see alsoAdditional look-back time) **Maximum** **alerts per execution**: 100 **References**:
1. Install the Elastic Stack (Elasticsearch, Kibana, and Logstash) on your Ubuntu machine by following the instructions provided on the Elastic website.
2. Once you have installed and configured the Elastic Stack, navigate to the Logstash directory and create a new configuration file for the TeamViewer logs by running the command:
Copy and paste the following Logstash configuration into the file: 
5. Ensure that Logstash is properly reading and processing the TeamViewer logs by checking the Logstash logs in the /var/log/logstash/ directory.
6. Navigate to the Kibana web interface by opening a web browser and entering the URL: http://localhost:5601/.
7. In Kibana, click on the "Discover" tab to view your logs.
8. Click on the "Create index pattern" button and enter the name of the TeamViewer index pattern (e.g.teamviewer-\*).
9. Select the time range for the logs you want to view, and click on the "Create index pattern" button.
10. You should now see a list of logs from your TeamViewer deployment. You can filter the logs based on various criteria like severity, source, or date.
11. You can also create custom dashboards or visualizations to monitor specific aspects of your TeamViewer deployment, such as usage patterns or connection quality.
12. If you encounter any issues with your TeamViewer deployment, you can use the logs to identify the root cause and take corrective action.
**Source: ChatGPT**
1. Elastic official documentation: [https://www.elastic.co/guide/index.html](https://www.elastic.co/guide/index.html)
4. Kibana official documentation: https://www.elastic.co/guide/en/kibana/current/index.html
# VMware vSphere Integration
This integration periodically fetches logs and metrics from vSphere vCenter servers.
**Compatibility******
The integration uses the Govmomi library to collect metrics and logs from any Vmware SDK URL (ESXi/VCenter). This library is built for and tested against ESXi and vCenter 6.5, 6.7 and 7.0.**Installation Guide: **
[VMware vSphere 7.0 Installation](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html#installation-notes-for-this-release-12)[Govmomi Library](https://github.com/vmware/govmomi?tab=readme-ov-file)
**Integration Process**
**Go> Cyber Incident Management (XDR and MDR)**
**Go> Cyber Incident Management (XDR and MDR)>Settings**
**Go> Cyber Incident Management (XDR and MDR)> Settings>Integration**
**Go> Cyber Incident Management (XDR and MDR)> Settings> Integration>In search bar type “Vmware”**
**Click Add Agent**
**Choose your Log Collector**
**Click the vSphere logs and metrics**
**Keep it as is **
**Enter the IP address and port**
**Example**:https://127.0.0.1:8989/sdk**127.0.0.1****:** This is the IP address of the local machine (localhost).**8989****:** This is the port number on which the SDK service is running. (Keep it as is)**/sdk****:** This indicates that the SDK is accessible at this path.(Keep it as is)
**Notes**: To add multiple hosts, enter each IP address following the same format (https://<IP\_or\_hostname>:port/sdk) and press enter.
**Enter the Username and password of vSphere account**
**Notes**: The insecure option bypasses the verification of the server's certificate chain, which can be useful in certain scenarios but comes with significant security risks. It is recommended to use this option only when necessary and in environments where security concerns are minimal.
**Logs collection**
**Collect logs from vSphere via UDP**
**Tags**: Click the given tags **UDP host to listen on**: This is the IP address of the machine where the log collector is running.**UDP port to listen on:** This is the port on which the log collector will listen for incoming log data. (Keep it as is)**Notes**: Enabling "Preserve original event" ensures raw log data is always available, crucial for troubleshooting, compliance, and verifying log accuracy. It adds raw data to event.original, doubling storage needs and potentially slowing processing if storage isn't scaled, impacting efficiency.
**Collect logs from vSphere via TCP**
**Tags**: Click the given tags **TCP** **host to listen on:** This is the IP address of the machine where the log collector is running.**TCP** **port to listen on:** This is the port on which the log collector will listen for incoming log data. (Keep it as is)**Notes**: Enabling "Preserve original event" ensures raw log data is always available, crucial for troubleshooting, compliance, and verifying log accuracy. It adds raw data to event.original, doubling storage needs and potentially slowing processing if storage isn't scaled, impacting efficiency.**Click Next to complete the integration.**
# Windows Event Forwarding to Linux server using Nxlog
## Introduction
Windows Event Forwarding (WEF) allows the collection of event logs from multiple Windows machines and their forwarding to a centralized server. Using Nxlog, you can send these logs to a Linux server for storage and analysis. This documentation provides a step-by-step guide to set up Windows Event Forwarding using Nxlog to send logs to a Linux server.
## Prerequisites
- **Windows Server or Workstation**: The machine that will send logs.
- **Linux Server**: The machine that will receive logs.
- **Nxlog**: Download the latest version of Nxlog for Windows from [Nxlog's official website](https://nxlog.co/downloads).
- **Network Connectivity**: Ensure both machines can communicate over the network.
- **Rsyslog:** Download the latest version of Rsyslog for Linux server or workstation.
## Installing Nxlog on Windows
1. **Download Nxlog**:
- Obtain the Nxlog Community Edition installer from the official website.
2. **Install Nxlog**:
- Run the installer and follow the prompts to complete the installation.
3. **Start Nxlog Service**:
- Start the Nxlog service using the Services management console or command line: **net start nxlog**
## Configuring Nxlog on Windows
1. **Open Configuration File**:
- Edit the Nxlog configuration file located at `C:\Program Files\nxlog\conf\nxlog.conf`.
2. **Configure File**:
- Add the following lines to capture Windows Event Logs and send the logs :
#### Configuring Rsyslog on Linux
1. **Open Configuration File**:
- Edit /etc/rsyslog.conf or create a new config file in /etc/rsyslog.d/.
2. **Configure Rsyslog to Listen for UDP**:**module(load="imudp") # Load UDP listener input(type="imudp" port="514")**
3. **Define Output File**:
- Specify where to store the incoming logs:
**\*.\* /var/log/windows\_events.log**
4. **Save and Exit**:
- Save the configuration file and restart Rsyslog:
**sudo systemctl restart rsyslog**
#### Firewall Configuration
#### Windows Firewall
1. **Open Windows Defender Firewall**:
- Go to **Control Panel** > **System and Security** > **Windows Defender Firewall**.
2. **Allow Port 514**:
- In the left pane, click **Advanced settings**.
- Select **Inbound Rules** and click on **New Rule**.
- Choose **Port**, then click **Next**.
- Select **UDP** and enter **514** in the Specific local ports field.
- Allow the connection and complete the rule setup.
#### Firewalld Configuration on Linux
1. **Open Port 514 for UDP**:
### Verifying Event Forwarding
1. **Check Nxlog Status on Windows**:
**nxlog -v**
2. **Monitor Logs on Linux**:
- Use the following command to view the log file:
**tail -f /var/log/windows\_events.log**
3. **Review Rsyslog Logs**:
- If issues arise, check Rsyslog logs located at **/var/log/syslog** or **/var/log/messages.**
# Windows Event Forwarding to Linux server using Powershell script
#### Overview
This PowerShell script forwards Windows event logs to a Linux server using the syslog protocol. It captures specific event logs, sends them to the specified syslog server, and ensures that duplicate events are not sent.
#### Prerequisites
- PowerShell on Windows
- Syslog server running on Linux (e.g., Rocky Linux) with an accessible IP
- UDP port 514 open for communication
### Powershell Script
Save the file as **.ps1** (e.g sendlogs.ps1).
**Script:**
```bash
# Define the syslog server IP address and port
$syslogServerIP = "192.168.20.24" # Replace with your Rocky server's IP
$syslogPort = 514
# File to store last sent event info.
# Change this directory if necessary
$logFilePath = "C:\Users\Administrator\Desktop\lastEventInfo.txt"
# Initialize last sent events
$lastSentEvents = @{}
# Check if the file exists and read the last sent events
if (Test-Path $logFilePath) {
Write-Host "Loading last sent events from file."
$lastSentEvents = Get-Content $logFilePath | ConvertFrom-Json
}
# Loop for sending logs
while ($true) {
Write-Host "Checking for new logs..."
# Define the logs you want to forward
$logNames = @("Application", "Security", "Setup", "System")
# Loop through each log
foreach ($logName in $logNames) {
Write-Host "Processing log: $logName"
# Get new logs
$logs = Get-WinEvent -LogName $logName | Sort-Object TimeCreated
foreach ($log in $logs) {
# Create a unique key based on Event ID and TimeCreated
$eventKey = "$($log.Id)-$($log.TimeCreated.Ticks)"
# Check if the event has already been sent
if (-not $lastSentEvents.ContainsKey($eventKey)) {
# Create syslog message format
$message = "<134>" + $log.TimeCreated.ToString("yyyy-MM-dd HH:mm:ss") + " " + $log.ProviderName + ": " + $log.Message
# Send the message to the syslog server
$client = New-Object System.Net.Sockets.UdpClient
$client.Connect($syslogServerIP, $syslogPort)
$bytes = [System.Text.Encoding]::ASCII.GetBytes($message)
$client.Send($bytes, $bytes.Length)
$client.Close()
# Mark the event as sent
$lastSentEvents[$eventKey] = $true
Write-Host "Sent log: $message"
} else {
Write-Host "Log already sent: $eventKey"
}
}
}
# Save the last sent events to the file
$lastSentEvents | ConvertTo-Json | Set-Content -Path $logFilePath
Write-Host "Last sent events updated."
# Wait for 1 second before running again
Start-Sleep -Seconds 1
}
```
#### Script Components
1. **Define Variables**:
- `$syslogServerIP`: IP address of the Linux syslog server.
- `$syslogPort`: Port number for syslog (default is 514).
- `$logFilePath`: Path to store the last sent event information.
2. **Initialize Last Sent Events**:
- Loads previously sent events from a file, if it exists.
3. **Main Loop**:
- Continuously checks for new logs from specified log categories: `Application`, `Security`, `Setup`, and `System`.
4. **Processing Logs**:
- Retrieves new logs, sorts them, and creates a unique key based on the event ID and timestamp.
- Sends new logs to the syslog server in a specified message format.
- Updates the log file with the newly sent events.
5. **Error Handling**:
- Logs messages indicating whether an event has been sent or is a duplicate.
#### Usage
1. Update the `$syslogServerIP` and `$logFilePath` variables.
2. Run the script in PowerShell. It will run indefinitely, checking for new logs every second.
#### Task Scheduler
Make sure to enable the "Run with highest privileges"
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/YfETGV3Z7d88N6PN-image.png)
Add a new action
1\. Fill in the Program/Script Text Box with: **powershell.exe**
2\. Fill in the Add arguments Text Box with: **-ExecutionPolicy Bypass -File "C:\\Users\\Administrator\\Desktop\\sendlogs.ps1"**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/5xzRjQlucdP4ZuVC-image.png)
Settings Configuration
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/V1NrUVyBufxD6TST-image.png)
After the creating the task, you can enable the script by activating the task.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2024-10/QqAzkqKuwoZzgf5p-image.png)
# Z Scaler Integrations
##### **Introduction**This integration is for Zscaler Internet Access logs. It can be used to receive logs sent by NSS log server on respective TCP ports.The log message is expected to be in JSON format. The data is mapped to ECS fields where applicable and the remaining fields are written under zscaler\_zia.<data-stream-name>.\*.
##### **Assumptions**The procedures described in Section 3assumes that a Log Collector has already been setup.
**Compatibility**
This package has been tested against Zscaler Internet Access version 6.1
##### **Requirements**
**Steps for setting up NSS Feeds**
1. Enable the integration with the TCP input.
2. Configure the Zscaler NSS Server and NSS Feeds to send logs to the Elastic Agent that is running this integration. See Add NSS Server and Add NSS Feeds. Use the IP address hostname of the Elastic Agent as the 'NSS Feed SIEM IP Address/FQDN', and use the listening port of the Elastic Agent as the 'SIEM TCP Port' on the Add NSS Feed configuration screen. To configure Zscaler NSS Server and NSS Feeds follow the following steps.
- In the ZIA Admin Portal, add an NSS Server.
- Log in to the ZIA Admin Portal using your admin account. If you're unable to log in, contact Support.
- Add an NSS server. Refer to Adding NSS Servers to set up an Add NSS Server for Web and/or Firewall.
- Verify that the state of the NSS Server is healthy.
- In the ZIA Admin Portal, go to Administration > Nanolog Streaming Service > NSS Servers.
- In the State column, confirm that the state of the NSS server is healthy.
- In the ZIA Admin Portal, add an NSS Feed.
- Refer to [Add NSS Feeds](https://help.zscaler.com/zia/adding-nss-feeds) and select the type of feed you want to configure. The following fields require specific inputs:
- **SIEM IP Address**: Enter the IP address of the [Elastic agent](https://www.elastic.co/guide/en/fleet/current/fleet-overview.html)you’ll be assigning the Zscaler integration to.
- **SIEM TCP Port**: Enter the port number, depending on the logs associated with the NSS Feed. You will need to create an NSS Feed for each log type.
- Alerts: 9010
- DNS: 9011
- Firewall: 9012
- Tunnel: 9013
- Web: 9014
- **Feed Output Type****:** Select Custom in Feed output type and paste the appropriate response format in Feed output format as follows:
**Steps for setting up Cloud NSS Feeds**
1. Enable the integration with the HTTP Endpoint input.
2. Configure the Zscaler Cloud NSS Feeds to send logs to the Elastic Agent that is running this integration. Provide API URL to send logs to the Elastic Agent. To configure Zscaler Cloud NSS Feeds follow the following steps.
- In the ZIA Admin Portal, add a Cloud NSS Feed.
- Log in to the ZIA Admin Portal using your admin account.
- Add a Cloud NSS Feed. See to [Add Cloud NSS Feed](https://help.zscaler.com/zia/adding-cloud-nss-feeds).
- In the ZIA Admin Portal, go to Administration > Nanolog Streaming Service > Cloud NSS Feeds.
- Give Feed Name, change status to Enabled.
- Select NSS Type.
- Change SIEM Type to other.
- Add an API URL.
- Default ports:
- DNS: 9556
- Firewall: 9557
- Tunnel: 9558
- Web: 9559
- Select JSON as feed output type.
- Add same custom header along with its value on both the side for additional security.
3. Repeat step 2 for each log type.
**Please make sure to use the given response formats for NSS and Cloud NSS Feeds.**
Note: Please make sure to use latest version of given response formats.
##### **ZscalerIntegrationProcedures**Please provide the following information to CyTech:
**Collect Zscaler Internet Access logs via TCP input**
1. 1. Listen Address - The bind address to listen for TCP connections.
2. Types:
- - - - - - TCP Listen Port for Zscaler Internet Access Alerts
- - TCP Listen Port for Zscaler Internet Access DNS logs
- TCP Listen Port for Zscaler Internet Access Firewall Logs
- TCP Listen Port for Zscaler Internet Access Tunnel Logs
- TCP Listen Port for Zscaler Internet Access Web Logs
**Collect Zscaler Internet Access logs via HTTP Endpoint**
1. 1. Listen Address - The bind address to listen for http endpoint connections.
2. Types:
- - TCP Listen Port for Zscaler Internet Access DNS logs
- TCP Listen Port for Zscaler Internet Access Firewall Logs
- TCP Listen Port for Zscaler Internet Access Tunnel Logs
- TCP Listen Port for Zscaler Internet Access Web Logs
# FortiGate Firewall - Syslog Configuration for Log Integration & Security Configuration Recommendations Introduction
#### Introduction
The FortiGate integration enables to monitor your Fortinet FortiGate firewall for security threats, traffic analysis, and compliance reporting. Currently, we are not receiving logs from your firewall. This guide will help you configure syslog to send logs to our monitoring system.
##### Step 1: Log in to your Fortinet FortiGate Admin Portal and Navigate to CLI Console
Log in to your FortiGate web interface and access the CLI Console. Please refer to the images below.
1. Open your web browser and go to: `https://[your-firewall-ip-address]`
2. Click on your **username** in the top-right corner
3. Select **CLI Console** from the dropdown menu
##### Step 2: Required Information for Integration
To configure FortiGate to send logs to your syslog server, we need the following information from you:
**Provide:**
```
FortiGate Source IP (Management IP): ___________________________
Log Collector IP (Where FortiGate sends logs to): ___________________________
FortiGate Model: ___________________________
Firmware Version: ___________________________
```
**To get the FortiGate information, run these commands in CLI:**
```
get system status
get system interface physical
```
##### Step 3: Execute Configuration Commands
Execute these commands on the CLI Console:
##### For Syslog Setting:
```
config log syslogd setting
set status enable
set server
set facility user
set source-ip
set port 10514
set mode tcp
set format default
end
```
**What each setting does:**
- `set status enable` = Turns on syslog functionality
- `set server` = IP address of your log collector (where FortiGate sends logs to)
- `set facility user` = Categories logs as "user" type
- `set source-ip` = FortiGate's management IP address
- `set port 10514` = Destination port for log transmission
- `set mode tcp` = Uses TCP protocol (reliable delivery, no packet loss)
- `set format default` = Uses standard syslog format (compatible with Elastic integration)
**Example with actual values:**
```
config log syslogd setting
set status enable
set server 192.168.10.50
set facility user
set source-ip 192.168.1.99
set port 10514
set mode tcp
set format default
end
```
**Note:**
- Use own log collector IP for `set server`
- Use FortiGate management IP for `set source-ip`
- We recommend using port **10514** if port **514** is already in use
##### For Syslog Filter:
```
config log syslogd filter
set anomaly enable
set forward-traffic enable
set local-traffic enable
set multicast-traffic disable
set netscan-discovery enable
set netscan-vulnerability enable
set severity warning
set sniffer-traffic enable
set voip disable
set ztna-traffic enable
end
```
This configuration enables logging for:
- **Anomaly events** – Unusual network behavior
- **Forward traffic** – Traffic passing through the firewall
- **Local traffic** – Traffic to/from the firewall itself
- **Network scanning** – Port scans and vulnerability scans
- **Sniffer traffic** – Packet capture events
- **ZTNA traffic** – Zero Trust Network Access events
##### Step 4: Network Firewall Configuration Requirements
**IMPORTANT:** Please ensure the following network connectivity is allowed:
**On your FortiGate device:**
- Allow **OUTBOUND** traffic from FortiGate to your log collector
- **Port:** 10514
- **Protocol:** TCP
**On your Log Collector server:**
- Allow **INBOUND** traffic from FortiGate
- **Port:** 10514
- **Protocol:** TCP
**Network Path:**
- Ensure no firewall or network device between your FortiGate is blocking TCP port 10514
- Verify your FortiGate can reach the log collector IP address
##### Step 5: Verify Configuration
After executing the commands, verify the configuration by running:
**To verify Syslog Setting:**
```
show log syslogd setting
```
**Expected output should show:**
```
status: enable
server:
port: 10514
mode: tcp
format: default
```
**To verify Syslog Filter:**
```
show log syslogd filter
```
##### Step 6: Test Connectivity and Log Transmission
**Test 1: Verify network connectivity to your log collector**
```
execute ping
```
This should return successful ping responses.
**Test 2: Send a test log message**
```
execute log test
```
This command sends a test syslog message to your log collector to verify the configuration is working.
##### Step 7: Enable Logging on Firewall Policies
For us to receive traffic logs, logging must be enabled on your firewall policies.
**GUI Method:**
1. Navigate to: **Policy & Objects** → **Firewall Policy**
2. For each policy, click to edit
3. Scroll to **Logging Options**
4. Set **Log Allowed Traffic** to: **All Sessions**
5. Click **OK**
**CLI Method (to check current status):**
```
show firewall policy | grep logtraffic
```
**CLI Method (to enable logging on a specific policy):**
```
config firewall policy
edit
set logtraffic all
next
end
```
##### Verification and Information Needed
To help us verify the integration is working correctly, we would appreciate if you could provide the following:
**Configuration Verification (Screenshots would be helpful):**
1. ☐ Output of: `show log syslogd setting`
2. ☐ Output of: `show log syslogd filter`
3. ☐ Output of: `get system status`
**Network Connectivity Test:**
Please test connectivity to your log collector by running:
```
execute ping
```
This helps us confirm there are no network issues between your firewall and log collector.
**Information for Our Integration Setup:**
To complete the integration on our end, please provide:
```
FortiGate Source IP: ___________________________
Log Collector IP: ___________________________
FortiGate Model: ___________________________
Firmware Version: ___________________________
Port Number: 10514
Protocol: TCP
```
**Optional (but helpful for troubleshooting):**
- Is there any firewall or network device between your FortiGate and log collector? Yes / No
- Did the ping test succeed? Yes / No
##### What Needs for Integration
After completing the configuration and provide the screenshots above, kindly provide us:
**Network Information:**
- **FortiGate Source IP** (Your FortiGate management IP): `___________________________`
- **Log Collector IP** (Your log collector server IP): `___________________________`
- **Port Number**: 10514
- **Protocol**: TCP
##### Troubleshooting Common Issues
##### Issue 1: Cannot ping log collector
**Possible causes:**
- Network firewall blocking traffic
- Incorrect routing
- Log collector server is down
**Solution:**
```
# Check your default route
get router info routing-table all
# Verify interface is up
get system interface physical
```
##### Issue 2: Test log command shows no output
**Solution:**
```
# Verify syslog is enabled
show log syslogd setting | grep status
# Check if server IP is correct
show log syslogd setting | grep server
```
##### Issue 3: Configuration not saving
**Solution:**
- Ensure you typed `end` after each config block
- Verify no syntax errors in commands
- Check you have admin permissions
##### Reference Documentation Links
**Source Link for Full Documentation Manual:**
https://docs.cytechint.io/books/system-integrations/page/fortinet-fortigate-syslog-setting-and-syslog-filter
**Source Link Documentation for Syslog Setting:**
https://docs.fortinet.com/document/fortigate/6.4.4/cli-reference/444620/config-log-syslogd-setting
**Source Link Documentation for Syslog Filter:**
https://docs.fortinet.com/document/fortigate/7.0.9/cli-reference/456620/config-log-syslogd-filter
https://help.fortinet.com/fgt/handbook/cli52\_html/index.html#page/FortiOS%205.2%20CLI/config\_log.16.17.html
**Source Link to Better Understand Log Priority Level:**
https://help.fortinet.com/fweb/551/log/Content/FortiWeb/fortiweb-log/Priority\_level.htm
---
#### FortiGate Firewall - Security Configuration Recommendations
##### Introduction
This document provides security recommendations for your Fortinet FortiGate firewall to strengthen network security, improve policy management, and optimize firewall configuration based on industry standards.
##### **1. Enable Security Profiles on Firewall Policies**
**Risk:** Without security profiles, viruses, malware, exploits, and malicious websites can pass through your firewall undetected.
**Required Profiles for Internet-Bound Policies (LAN → WAN):**
```
☑ Antivirus (AV) - Blocks viruses, malware, ransomware
☑ Web Filter - Blocks malicious and phishing websites
☑ Application Control - Controls which applications can be used
☑ IPS (Intrusion Prevention) - Blocks hacking attempts and exploits
```
**Configuration Steps:**
1. Navigate to **Policy & Objects** → **Firewall Policy**
2. Click on policy allowing internet access
3. Scroll to **Security Profiles** section
4. Enable profiles:
- Antivirus: `default`
- Web Filter: `default`
- Application Control: `default`
- IPS: `protect_client`
5. Click **OK**
##### **2. Review and Optimize Firewall Policies**
**A) Remove Unused Policies**
1. Navigate to **Policy & Objects** → **Firewall Policy**
2. Check **Hit Count** column (0 hits for 30+ days = unused)
3. Verify with department owners before deleting
4. Delete unused policies
**B) Eliminate "Any-Any" Policies**
**Dangerous policies have:**
- Source: `all`
- Destination: `all`
- Service: `ALL`
**Action:** Replace with specific rules defining exact sources, destinations, and services.
**C) Implement Naming Convention**
**Format:** `[SOURCE]-[DESTINATION]-[SERVICE]-[DESCRIPTION]`
**Examples:**
```
LAN-WAN-HTTPS-Employee_Internet_Access
LAN-DMZ-HTTP-Access_to_WebServer
Branch1-HQ-ALL-Site_to_Site_VPN
```
##### **3. Configure Address Objects**
**A) Create Named Objects for Servers**
**Naming Format:** `[TYPE]_[LOCATION]_[PURPOSE]`
**Examples:**
```
SVR_DMZ_WebServer01
SVR_HQ_DatabaseServer
NET_Branch1_LAN
HOST_Finance_Workstation
```
**Steps:**
1. Navigate to **Policy & Objects** → **Addresses**
2. Click **Create New** → **Address**
3. Configure:
- Name: `SVR_DMZ_WebServer01`
- Type: IP/Netmask
- Subnet/IP: `10.10.10.50/32`
- Comment: "Production web server"
4. Click **OK**
**B) Create Address Groups**
**Example:**
```
Group: GRP_Web_Servers
Members:
- SVR_DMZ_WebServer01
- SVR_DMZ_WebServer02
- SVR_DMZ_WebServer03
```
**Benefit:** One policy can manage multiple servers.
**C) Geographic Blocking (Optional)**
Block traffic from high-risk countries:
1. Navigate to **Policy & Objects** → **Addresses**
2. Create New → Address
3. Type: Geography
4. Select countries to block
5. Create deny policy using this object
##### **4. Optimize Service Objects**
**A) Create Custom Services**
**Naming Format:** `[PROTOCOL]_[PURPOSE]_[PORT]`
**Examples:**
```
TCP_Custom_App_8080
TCP_Database_MySQL_3306
TCP_Web_Application_8443
```
**B) Create Service Groups**
**Example: Web Services**
```
GRP_Web_Services:
- HTTP (80)
- HTTPS (443)
- HTTP-ALT (8080)
```
**Example: Email Services**
```
GRP_Email_Services:
- SMTP (25)
- SMTPS (465)
- IMAPS (993)
- POP3S (995)
```
**C) Phase Out Insecure Protocols**
**Replace:**
- Telnet → SSH
- FTP → SFTP/FTPS
- HTTP → HTTPS
- SNMPv1/v2 → SNMPv3
##### **5. Configure NAT Policies**
##### Source NAT (Outbound Internet)
Verify NAT is enabled on internet access policies:
1. Go to **Policy & Objects** → **Firewall Policy**
2. Click internet access policy (LAN → WAN)
3. NAT section: ```
☑ NAT: Enable☑ Use Outgoing Interface Address
```
##### Destination NAT (Inbound Services)
For published services (web, email servers):
```
Name: VIP_External_WebServerExternal IP: Mapped IP: Port Forwarding: EnableProtocol: TCP
```
1. Navigate to **Policy & Objects** → **Virtual IPs**
2. Create New → Virtual IP
3. Configure:
4. Always enable security profiles (AV, IPS) on VIP policies
##### **6. Secure VPN Configuration**
##### SSL VPN (Remote Access)
**Navigate to:** VPN → SSL-VPN Settings
**Security Settings:**
```
☑ Two-Factor Authentication: Enable
Method: FortiToken, Email, or SMS
Login Attempt Limit: 5
Lockout Duration: 30 minutes
Session Timeout: 12 hours
Idle Timeout: 30 minutes
☐ Split Tunneling: Disable (force all traffic through VPN)
```
##### IPsec VPN (Site-to-Site)
**Navigate to:** VPN → IPsec Tunnels
**Strong Encryption:**
```
Phase 1 (IKE):
- Encryption: AES256-GCM
- Authentication: SHA256
- DH Group: 14 or higher
Phase 2 (IPsec):
- Encryption: AES256-GCM
- Authentication: SHA256
- PFS: Enable (Group 14)
☑ Dead Peer Detection: Enable
Interval: 10 seconds
```
##### **7. Administrator Security**
**A) Enable Two-Factor Authentication**
1. Navigate to **System** → **Administrators**
2. Click administrator account
3. Enable Two-Factor Authentication: ```
☑ Enable Two-Factor AuthenticationMethod: FortiToken (recommended) or Email
```
4. Click **OK**
**B) Restrict Trusted Hosts**
Only allow admin login from specific IPs:
```
Trusted Host 1: 10.10.10.0/24 (IT subnet)
Trusted Host 2: 172.16.5.100/32 (VPN gateway)
```
**C) Disable WAN Management**
Navigate to **System** → **Settings**
```
WAN Interface:
☐ HTTPS: Disable
☐ HTTP: Disable
☐ SSH: Disable
```
##### **8. Configure Regular Backups**
##### Manual Backup
1. Click **username** (top-right)
2. Configuration → Backup
3. Choose Local PC
4. Save as: `FortiGate_[Model]_[Date].conf`
##### Backup Schedule
```
Daily: Automated
Before changes: Always
Weekly: Manual verification
Monthly: Offsite storage
Retention:
- Daily: 7 days
- Weekly: 30 days
- Monthly: 1 year
```
##### Storage Locations
```
Primary: Local computer
Secondary: Network file server
Tertiary: Cloud storage (encrypted)
Emergency: USB drive (offsite)
```
##### **9. Enable FortiGuard Services**
### Check License Status
1. Navigate to **System** → **FortiGuard**
2. Verify active licenses: ```
☑ Antivirus☑ IPS (Intrusion Prevention)☑ Web Filtering☑ Application Control
```
3. Check expiration dates (renew 30 days before)
##### Configure Auto-Updates
```
☑ Automatic Updates: Enable
Update Schedule: Daily
Push Update: Enable
```
##### **10. Configure NTP (Time Synchronization)**
##### Why Critical
Accurate timestamps required for:
- Log correlation
- Certificate validation
- Compliance
##### Configuration
1. Navigate to **System** → **Settings**
2. System Time section: ```
☑ Enable NTPSync with: FortiGuard NTP ServersTime Zone:
```
##### Verify NTP
**CLI command:**
```
diagnose sys ntp status
```
**Expected:** `synchronized: yes`
##### Summary Checklist
```
Security Profiles:
☐ AV, Web Filter, App Control, IPS enabled
Policy Management:
☐ Unused policies removed
☐ "Any-any" policies replaced
☐ Naming convention implemented
Objects:
☐ Address objects for servers
☐ Address groups created
☐ Service objects organized
NAT:
☐ Source NAT configured
☐ Destination NAT secured
VPN:
☐ 2FA enabled
☐ Strong encryption
☐ Session timeouts set
Admin Security:
☐ 2FA for admins
☐ Trusted hosts configured
☐ WAN management disabled
Maintenance:
☐ Backup procedure
☐ FortiGuard licenses valid
☐ NTP working
```
##### Reference Links
**FortiGate Best Practices:**
https://docs.fortinet.com/document/fortigate/7.4.0/best-practices
**Administration Guide:**
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/
**FortiGuard Services:**
https://www.fortiguard.com/
# EDR Remote Execution - Using Respond Console Manual
### **Research on Elastic EDR Response Actions for:**
1. Forensic commands for malware investigation on isolated hosts
2. API integration documentation for external systems
### **Key Findings:**
- Elastic EDR has 11 response actions for remote host management
- Primary tool: `execute` command for running forensic commands
- Full API support available for integration with external systems
- Can automate investigation and remediation workflows
#### **AVAILABLE RESPONSE ACTIONS**
#####
##### **ADDITIONAL REFERENCES**
**Official Documentation:**
- Response Actions Overview: [https://www.elastic.co/guide/en/security/8.18/response-actions.html](https://www.elastic.co/guide/en/security/8.18/response-actions.html "https://www.elastic.co/guide/en/security/8.18/response-actions.html")
- Response Actions API: [https://www.elastic.co/guide/en/security/current/response-actions-api.html](https://www.elastic.co/guide/en/security/current/response-actions-api.html "https://www.elastic.co/guide/en/security/current/response-actions-api.html")
- Execute API: [https://www.elastic.co/guide/en/security/current/execute-api.html](https://www.elastic.co/guide/en/security/current/execute-api.html "https://www.elastic.co/guide/en/security/current/execute-api.html")
- API Key Management: [https://www.elastic.co/guide/en/kibana/current/api-keys.html](https://www.elastic.co/guide/en/kibana/current/api-keys.html "https://www.elastic.co/guide/en/kibana/current/api-keys.html")
**Security APIs:**
- Elastic Security APIs: [https://www.elastic.co/guide/en/security/current/security-apis.html](https://www.elastic.co/guide/en/security/current/security-apis.html "https://www.elastic.co/guide/en/security/current/security-apis.html")
# Windows Server - Deploy Software via Group Policy (GPO)
### **Introduction
**Deploy Software via Group Policy (GPO)** is a method used in **Windows Active Directory (AD)** environments to automatically **install, update, or remove software** on computers or for users centrally and silently, without manual installation on each machine. It’s mainly handled by **Group Policy Objects (GPOs)** through Microsoft Installer (MSI) packages.
#### **Open the Windows Server Device:**
- Open **Server Manager dashboard** click **Tools** on the upper right side and choose the **Active Directory Users and Computers.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/MQQgkMhG5cjA5SEQ-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/phG9efsyRpAoBEsr-image.png)
- On the **Active Directory Users and Computers** right click the **Users** folder select **New** and **Group.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/wEdjfYkKvgoRLxeH-image.png)After you clicked the Computer, New Object - Computer window displayed.
- **Input your desired Computer Name:** TSR-Deployment
- **Group scope: Global**
- **Group type: Security**Click "OK" once done and you will see the **TSR-Deployment** added on the **Active Directory Users and Computers**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/jaJv4HWiS9v3AheT-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/0OlRbArKvhNc6x1O-image.png)
- Next Process double click the **TSR-Deployment** on the **Active Directory Users and Computers, TSR-Deployment Properties** will appear and click the **Members** tab.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/ow5BVIAB80PJK0fs-image.png)
- Click **Add**, then select **Object Types**. Once it opens, check the **Computers**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/YB5G1EOVe2ERMHmx-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/AsF2mxZKR1A8llWC-image.png)
- Type the **computer name** that is connected to the domain. Then, click **Check Names** and select only the **Computer** icon that corresponds to your device.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/aeehraMDeA0YUH7H-image.png)
##### **Creating a UNC Path for Software Folders (Windows Server)**To ensure domain-joined computers can access the AQUILA EDR ZIP file package and folder for centralizing logs, create a shared network folder and configure appropriate permissions.
1. On a **Document** folder, create another folder inside of it with your desired name (e.g., **software**).
- Inside of the **software** folder, place the `aquila agent 7.msi` into this folder.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/S0lg9M1r9EFECEYj-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/rvva6I87H1FJ8j0s-image.png)
2. **Enable Folder Sharing**
- Right-click the **software** folder and select **Properties**.
- Navigate to the **Sharing** tab and click **Advanced Sharing**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/opYjeqE5wFFJ3Z8V-image.png)
- Check the box **Share this folder**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/BTHQBRIZqm8z8flC-image.png)
3. Set Permissions
- Click Permissions
- Grant the **Read** permission to `Domain Computers`.
- Grant the **Full Control** permission to `Domain Admins`[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/myA2I9R7JSAhtqXd-image.png)
- Once the **Permission** clicked, **Permissions for software** will be shown and kindly **Remove** the **Everyone.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/3q3dwKXWXABHMPEG-image.png)
- After clicking the **Remove**, click the **Add**, then **Select Users, Computers, Service Accounts, or Group** will be shown. Type "**auth"** then click **Check Names.** The **Multiple Names Found** will be shown and select the **Authenticated Users** and click **OK.** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/vjt3uArmsu3RYQgF-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/zVDiSopC92yCAQ9n-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/TNrjql3n2fdmHv3W-image.png)
- Once **Authenticated Users** selected allow **Full Control,** click **Apply** and **OK.** Including the **Advanced Sharing** click **Apply** and **OK.** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/BGPSc75jbdelNeBK-image.png)
- On the **software folder properties** click the **Security** tab. Point your mouse at **Administrator** ("username"\\administrator) and click **Edit**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/YSq1qwaWqA2Dc1Yt-image.png)
- On the **Permission for software,** click **Add** and type the **Security Group** name you created "**tsr-deployment**" and click the **Check Names (**It will automatically call the **Security Group**) and click **OK.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/6YRhck0CPRFZkvoq-image.png)
- As you can see the "**TSR-Deployment**" Security Group are added. To proceed click **Apply** and **OK.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/5bZePJdlQQl3caCf-image.png)
#### **Let's go back to the Server Manager dashboard.**
- On the **Server Manager** click **Tools** on the upper right side and choose the **Group Policy Management**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/ScQSGuxv1yulVkCs-image.png)
- Select or double click the **Domain.** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/k077w4t2kb6KBe91-image.png)
- Under your **Domain,** you can see the **domain name** `(e.g., ronwinser.com).`[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/ccYm3gNKfXqVqixX-image.png)
- Right click your **domain name** and click the **Create a GPO in this domain, and Link it here** and give a name `(e.g., tsrapp_deployment)` click **OK** once done.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/hCOWsJlaoUZ06ZSL-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/ZanwQn9leRwGzX2S-image.png)
- On the **GPO** you created, right click and choose the **Edit.** [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/PgogkPRg90f6Mhs5-image.png)
- Once you **Edit**, the **Group Policy Management** Editor will be shown just click the arrow from **Computer Configuration** > **Policies** > **Software Settings** > **Software installation,** inside the **Software installation** right click on the enviroment and choose the **New** > **Package.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/1lvK7APBP8uZ0Juv-image.png)
- Once you clicked the **Package** it will direct you from the **folder** you've **created** with a name of "**software".** Kindly click the **Open** your **software installer (Aquila Agent 7 with MSI format)** will be added inside to your **Group Policy Management Edit** or **GPO**. Do not change the "**Assigned**" option from **Deploy Software**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/Vdlj3jSQUhw1kjou-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/2NX9sjFNb90NK2j5-image.png)
- As you can see, we're able to **map out** also the **Network path** of the "**software"** folder we shared earlier. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/iKaLw34H5NTBa8WA-image.png)
- So now your **Aquila Agent** with **.msi** format installer is now already added in the **GPO**.
#### [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/o46In13znWwBH2Ap-image.png)
#### **Let's navigate again to the "Group Policy Management".**
- On your **Group Policy Managent** remove the default **Authenticated Users** in **Security Filtering**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/KyeBPWWHnlDUVaqY-image.png)
- Then click the **Add** button from **Security Filtering**, type **Security Groups** you've created, but for this case was "**TSR-Deployment**" and click the **Check Names** and press **OK.**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/wuHETHOghgSuBPwY-image.png)
- Your **TSR-Deployment** which is the **Global Security group** you've created was already added on the **Security Filtering.** Kindly close the **Group Policy Management** or leave it open. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/p0rqErF1M8gAKK2i-image.png)
> In this case, the setup of **Active Directory Users and Computers** and **Group Policy Management** for software deployment via **Group Policy (GPO)** has already been completed. The installer packages have also been added to **Group Policy Management** and are ready for deployment on the client end.
#### **Let’s proceed to the client-side desktop that is connected to Windows Server domain.**
- Make sure the **PC/Desktop** is connected to the **Windows Server domain**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/7sPDpslUhZ3gfCUz-image.png)
- To automatically install the **software application** from **GPO** to client-end's desktop, we need to update the group policy through **CMD.**
1. Open the **CMD** as **administrator.**
2. Type **gpupdate /force** and hit **enter**.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/pW7OY5yX466t8MzL-image.png)
3. If the group policy updates successfully, type **“Y”** to restart your PC. This allows your **endpoint** to **synchronize** with the GPO.
4. Once the **PC/Desktop** is open, the Aquila Agent installer will automatically be installed, to ensure everything is running kindly proceed to **task manager** and type **Aquila** on the **search bar** and check the status of its module.[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/V43axki7I75jcwQm-image.png) *If you need further assistance, kindly contact our technical support at **** for prompt assistance and guidance.*
# Deploy Software via Group Policy (GPO) (incomplete)
### **Introduction****Deploy Software via Group Policy (GPO)** is a method used in **Windows Active Directory (AD)** environments to automatically **install, update, or remove software** on computers or for users centrally and silently, without manual installation on each machine. It’s mainly handled by **Group Policy Objects (GPOs)** through Microsoft Installer (MSI) packages.
#### **Open the Windows Server Device:**
- Open **Server Manager** click **Tools** on the upper right side and choose the **Active Directory Users and Computers.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/phG9efsyRpAoBEsr-image.png)
- On the **Active Directory Users and Computers** right click the **Users** folder select **New** and **Computer.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/1vYRefnPn8bKRgkY-image.png)
After you clicked the Computer, New Object - Computer window displayed.
- **Input your desired Computer Name:** TSR-Deployment
Click "OK" once done and you will see the TSR-Deployment added on the Active Directory Users and Computers.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/0ZqXIGysHHYUIEcF-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/0OlRbArKvhNc6x1O-image.png)
- Next Process double click the **TSR-Deployment** on the **Active Directory Uses and Computers, TSR-Deployment Properties** will appear and click the **Members** tab.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/ow5BVIAB80PJK0fs-image.png)
- Click the "**Add**" button, select the "**Object Types**" once it opens check the **Computer**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/AsF2mxZKR1A8llWC-image.png)
- Type your **computer name** that is connected to the domain, after that click the **Check Names** and choose only the "**Computer**" icon which is your computer device.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/aeehraMDeA0YUH7H-image.png)
##### **Creating a UNC Path for Software Folders**
To ensure domain-joined computers can access the **AQUILA EDR ZIP** file package and folder for centralizing logs, create a shared network folder and configure appropriate permissions.
1. **Create a ZIP Folder**
- On a file server, create a folder (e.g., `C:\ZIP`).
- Copy the `edr-agent-8.18.1-windows-x86_64.zip` file into this folder.
2. **Enable Folder Sharing**
- Right-click the `ZIP` folder and select **Properties**.
- Navigate to the **Sharing** tab and click **Advanced Sharing**. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/opYjeqE5wFFJ3Z8V-image.png)
- Check the box **Share this folder**. [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/BTHQBRIZqm8z8flC-image.png)
3. Set Permissions
- Click Permissions
- Grant the **Read** permission to `Domain Computers`.
- Grant the **Full Control** permission to `Domain Admins`
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/myA2I9R7JSAhtqXd-image.png)
- Also, in the **Security** tab, grant the **Read & execute** permission to `Domain Computers` and **Full control** permission to `Domain Admins`.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/FxIoPizZ4sAn35bl-image.png)
- Save the network share path [](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/n7WCkSqxbemm2zL4-image.png)
4. Open the shared folder on the User domain logged in.
- Use **windows + R** or search **run** on the **windows search**[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/92XIwI2hrUXOWf93-image.png)
- Type the Shared Folder path, e.g. **(\\\\ServerPath)**
- Open the specified folder where the software are inputted[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/r3F4zuXooUThjDJQ-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/AUryq6tR2kxH7SI7-image.png)
# AQUILA - Google Workspace Gmail Logs (For revision)
**Google Workspace Gmail Logs**
The integration collects and parses Gmail audit logs data available for reporting in Google Workspace. You must first export Google Workspace logs to Google BigQuery. This involves exporting all activity log events and usage reports to Google BigQuery. Only certain Google Workspace editions support this feature. For more details see [About reporting logs and BigQuery(external, opens in a new tab or window)](https://support.google.com/a/answer/9079364?hl=en "https://support.google.com/a/answer/9079364?hl=en"). The integration uses the [BigQuery API(external, opens in a new tab or window)](https://cloud.google.com/bigquery/docs/reference/rest "https://cloud.google.com/bigquery/docs/reference/rest") to query logs from BigQuery.
**Requirements**
In order to ingest data from the Google BigQuery API, you must:
1. Enable BigQuery API if not already
- In the [Google Cloud console(external, opens in a new tab or window)](https://console.cloud.google.com/ "https://console.cloud.google.com/"), navigate to **APIs & Services > Library**.
- Search for **BigQuery API** and select it.
- Click **Enable**.
2. Create a service account:
- In the [Google Cloud console(external, opens in a new tab or window)](https://console.cloud.google.com/ "https://console.cloud.google.com/"), navigate to **APIs & Services > Credentials**.
- Click Create **Credentials > Service account**.
- In the setup:
- Enter a name for the service account.
- Click **Create and Continue**.
- (Optional) Grant project access.
- Click **Continue**.
- (Optional) Grant user access.
- Click **Done**.
3. Generate a JSON Key:
- From the **Credentials** page, click on the name of your new service account.
- Go to the **Keys** tab.
- Click **Add Key > Create new key**.
- Choose **JSON** format and click **Create**.
- Save the downloaded JSON key securely.
4. Grant IAM Role to service account:
- Go to **IAM & Admin > IAM** in the Cloud Console.
- Click **Grant access**.
- Paste the service account email in the **New principals** field.
- Click **Select a role**, search for and select **BigQuery Job User**.
- Click **Save**.
5. Set up a BigQuery project for reporting logs
- Go to **IAM & Admin page** for your project.
- Add a project editor for your project.
- Click **Grant access**.
- Enter gapps-reports@system.gserviceaccount.com in the **New principals** field.
- In **Select a role**, select **Project**, then **Editor**.
- Click **Save**.
- Add a Google Workspace administrator account as a project editor by following the same steps above.
- For more details see [Set up a BigQuery project for reporting logs(external, opens in a new tab or window)](https://support.google.com/a/answer/9082756?hl=en "https://support.google.com/a/answer/9082756?hl=en")
5. Set up a BigQuery Export configuration:
- Sign in to your [Google Admin console(external, opens in a new tab or window)](https://admin.google.com/ "https://admin.google.com/") with a super administrator account.
- Navigate to **Reporting > Data Integrations** (Requires having the **Reports** administrator privilege).
Education administrators go to Menu **Reporting > BigQuery export**, which opens the **Data integrations** page.
- Point to the **BigQuery Export** card and click Edit.
- To activate BigQuery logs, check the **Enable Google Workspace data export to Google BigQuery** box.
- (Optional) To export sensitive parameters of DLP rules, check the **Allow export of sensitive content from DLP rule logs** box.
- Under **BigQuery project ID**, select the project where you want to store the logs.
Choose a project for which gapps-reports@system.gserviceaccount.com has an editor role.
- Under **New dataset within project**, enter the name of the dataset to use for storing the logs in the project.
A new dataset will be created with this name in your BigQuery project.
- (Optional) Check the **Restrict the dataset to a specific geographic location** box > select the location from the menu.
- Click **Save**.
- For more details see [Set up a BigQuery Export configuration(external, opens in a new tab or window)](https://support.google.com/a/answer/9079365?hl=en "https://support.google.com/a/answer/9079365?hl=en").
6. Grant Dataset Permissions: (**If this step is available to your end kindly follow the instructions but if not just skip**.)
- Go to [Google Cloud console(external, opens in a new tab or window)](https://console.cloud.google.com/ "https://console.cloud.google.com/") and search for **BigQuery**.
- Click your Google Cloud project on the left pane.
- Locate the dataset, click the **three-dot menu > Share > Manage Permissions**.
- Click **Add principal**.
- Paste the service account email in **New principals**.
- Select **BigQuery Data Viewer** as the role.
- Click **Save**.
This integration will make use of the following *oauth2 scope*:
- [https://www.googleapis.com/auth/bigquery](https://www.googleapis.com/auth/bigquery "https://www.googleapis.com/auth/bigquery")
Once you have downloaded your service account credentials as a JSON file, you are ready to set up your integration for collecting Gmail logs.
NOTE: For Gmail data stream, the default value of "BigQuery API Host" is [https://bigquery.googleapis.com](https://bigquery.googleapis.com "https://bigquery.googleapis.com/"). The BigQuery API Host will be used for collecting gmail logs only.
**Please provide the following information to CyTech Support:**
-
**GCP Project ID** (GCP Project ID of project that has enabled export Gmail Logs) - The unique identifier of the Google Cloud project where your BigQuery dataset is hosted and where Google Workspace Gmail logs are exported.
-
**Dataset Name** (BigQuery dataset name) - The name of the BigQuery dataset inside the GCP project that stores the exported Gmail logs in daily tables for querying and analysis.
# AQUILA - Zyxel USG Flex 200 SIEM Integration
#### **AQUILA - Zyxel USG Flex 200 Integration**The Zyxel USG Flex 200 is a unified security gateway that provides comprehensive network security and management capabilities. It generates syslog events that can be collected, analyzed, and monitored for security insights and network performance monitoring. This integration enables centralized log collection from Zyxel USG devices for visualization and analysis.
---
##### **Integration Overview**This integration supports event collection through:
- Syslog messages via UDP from Zyxel USG Flex 200 devices
- File-based log collection from configured syslog serversEvents can be searched, observed, and visualized for security monitoring and network analysis.
---
**Compatibility**
- Supports syslog event collection from Zyxel USG Flex 200 devices via UDP on port 514
- Requires syslog-ng service for log collection and filtering
- Compatible with Linux-based log collection servers
---
##### **Syslog Server Configuration**
**Installing Syslog-ng:**
Install the syslog-ng package on your log collection server:
```
sudo apt-get install syslog-ng
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/KbrzzpjqEqv6VrTW-image.png)
**Configuring Syslog-ng:**
Edit the syslog-ng configuration file:
```
sudo nano /etc/syslog-ng/syslog-ng.conf
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/Uk19BubuNCGmYCTu-image.png)
Add the following configuration blocks:Define the syslog source to listen for UDP traffic on IP address **<IP\_Address\_of\_Log\_Source\_Server>** and port 514:
Replace **<IP\_Address\_of\_Log\_Source\_Server>** to the actual IP Address of Syslog-ng Server:
```
source s_net { udp(ip() port(514)); };
```
Create a filter to match traffic from the Zyxel device (this filter catches all syslog messages from the Zyxel Firewall):
replace **<IP\_Address\_of\_Zyxel\_Firewall>** to the actual IP Address of Zyxel Firewall:
```
filter f_zyxel { host( "" ); };
```
Define a destination file for the syslog messages:
```
destination df_zyxel { file("/var/log/zyxel.log"); };
```
Bundle the source, filter, and destination rules together with a logging rule:
```
log { source ( s_net ); filter( f_zyxel ); destination ( df_zyxel ); };
```
Restart the syslog-ng service to apply changes:
```
sudo /etc/init.d/syslog-ng restart
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/fvhTa7WunZmz7WrE-image.png)
Follow these steps to configure the Zyxel USG Flex 200 to send syslog messages to your log collection server:
**Step 1:** Log in to the Zyxel USG Flex 200 Firewall web interface.**Step 2:** Navigate to **Configuration > Log & Report > Log Settings > Remote Server 4**.**Step 3:** Click **Edit** to configure the remote log server settings.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/0b6Q3RzhRiVltELN-image.png)
**Step 4:** Configure the following log settings for Remote Server:
- **Active**: Check the box to enable remote logging
- **Log Format**: Select **CEF/Syslog** from the dropdown menu
- **Server Address**: Enter the IP address of your syslog-ng server
- **Server Port**: Enter **514**
- **Log Facility**: Select any available facility from the dropdown menu[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/7FbKUe8wd4FO2dXn-image.png)
**Step 5:** Click **Apply** or **Save** to apply the configuration changes.
**Step 6:** Verify that syslog messages are being sent to the remote server by checking the log file on your Syslog server:
To manage log file sizes and prevent disk space issues, configure log rotation for Zyxel logs.
Create a logrotate configuration file:
```
sudo nano /etc/logrotate.d/zyxel
```
Paste the following configuration to the file:
```
/var/log/zyxel.log {
daily # Rotate logs every day
missingok # If the log file is missing, don't complain
rotate 7 # Keep the last 7 days' worth of logs
compress # Compress old log files (e.g., .gz format)
delaycompress # Delay compression of the previous log file until the next rotation
notifempty # Do not rotate the log if it's empty
create 0640 root root # Create a new log file with permissions and ownership
postrotate
# Optional: You can add commands to run after log rotation, like restarting syslog
# For example, to reload syslog:
# /etc/init.d/syslog-ng reload
# Or for rsyslog:
# systemctl reload rsyslog
endscript
}
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-01/bqqeUZjzMay4Ksau-image.png)
**Testing Log Rotation:**
To verify the log rotation configuration is working correctly:
Here are the types of events you might find in the event log of a Zyxel UFG Flex 200, categorized by their typical nature:
- **System Events**:
- **Boot Events**: Records when the device starts up, restarts, or shuts down.
- Example: "Device started successfully" or "Reboot initiated."
- **Configuration Changes**: Logs any changes to the system configuration, such as updates to firmware or network settings.
- Example: "Configuration changed by user admin" or "Firmware updated."
- **Service Events**: Events related to system services starting or stopping, like the DHCP service, VPN service, etc.
- Example: "VPN service started" or "DHCP service stopped unexpectedly."
- **Network Events**:
- **Connection Events**: Logs events related to device connections, such as establishing or dropping a connection with other network devices.
- Example: "WAN interface up" or "LAN interface down."
- **Traffic Logs**: Logs traffic-related information, such as the amount of data sent or received.
- Example: "Incoming traffic exceeded threshold" or "Traffic dropped due to policy."
- **Security Events**:
- **Authentication and Authorization Events**: Logs successful or failed login attempts, user authentications, or permissions changes.
- Example: "User login from IP address 192.168.1.5" or "Failed login attempt from IP 10.0.0.1."
- **Firewall or Intrusion Detection Logs**: Captures security-related incidents like firewall rule violations, intrusion attempts, or malware alerts.
- Example: "Firewall rule blocked access from external IP" or "Intrusion detection alert triggered."
- **VPN Events**: Logs VPN connections, including successful connections, disconnections, or errors.
- Example: "VPN tunnel established" or "VPN authentication failure."
- **Error Events**:
- **Hardware or Software Failures**: Captures any critical failures of the system’s hardware or software components.
- Example: "Memory allocation failure" or "Disk error on storage device."
- **Network Failures**: Logs when the network encounters issues, such as a dropped connection or misconfiguration.
- Example: "Lost connection to ISP" or "Network interface error."
- **Warning Events**:
- **Thresholds and Limits**: Logs warnings when system performance reaches a threshold or limit.
- Example: "CPU usage exceeded 80%" or "Disk space running low."
- **Potential Security Risks**: Alerts about actions that might pose a security risk.
- Example: "Multiple failed login attempts detected" or "Suspicious packet detected."
- **Informational Events**:
- **Status Updates**: Logs general information about the device’s operational status.
- Example: "Device configuration completed" or "Service started successfully."
- **Routine Operations**: Logs that provide context to everyday network activity.
- Example: "DHCP lease granted to 192.168.1.10" or "Client connected via wireless."
---
##### **Logs Dataset**The zyxel.log dataset contains events collected from the configured syslog-ng server. All Zyxel USG Flex 200 specific syslog fields are available under the /var/log/zyxel.log file for detailed analysis and security monitoring.sample data logs:
```
Jan 19 18:45:26 192.168.20.1 CEF:0|ZyXEL|USG FLEX 200|5.39(ABUI.1)|0|Traffic Log|4|devID=d8xxxxx40 src=1xx.1xx.xx.xx dst=4xx.xxx.2xxx.xxx spt=62126 dpt=123 dvchost=usgflex200 msg=Traffic Log cat=Traffic Log sourceTranslatedAddress=1xx.xx.xxxx.xxxx sourceTranslatedPort=6xxxx6 suser=unknown ZYduration=300 out=76 in=76 proto=17 app=others ZYnote=Traffic Log ZYdir=RND:EASTERN-2 deviceInboundInterface=RND deviceOutboundInterface=EASTERN-2 ZYmac=xx:xx:xx:xx:xx:24
```
---
*If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.*
# NGINX Integration
#### **Introduction**
The Nginx integration allows you to monitor Nginx servers. Use the Nginx integration to collect metrics and logs from your server then visualize that data.
For example, if you wanted to be notified if a certain number of client requests failed in a given time period, you could install the Nginx integration to send logs to Elastic. Then, you could view the logs stream into Elastic in real time in the Observability Logs app. You could also set up a new log threshold rule in the Logs app to alert you when there are more than a certain number of events with a failing status in a given time period.
#### **Data Collection Types**
It collects two main types of data:
- **Logs** — Capture and record events occurring within the Nginx server. These include access logs (client requests) and error logs (issues encountered during request handling). Log data helps in auditing activities, identifying issues, and analyzing request patterns.
- **Metrics** — Provide real-time performance insights into Nginx server operations. Metrics include details such as the total number of active client connections, connection states, request counts, and other performance indicators essential for capacity planning and system optimization.
By utilizing this integration, administrators gain visibility into both operational and performance aspects of Nginx, enabling effective monitoring, troubleshooting, and optimization of web infrastructure.
#### **Prerequisites**
Before setting up the **Nginx Integration**, ensure that the following requirements are met:
1. **Nginx Server Installed and Running**
- A functioning **Nginx server** must be installed on your host system.
- Verify that the Nginx service is active and accessible.
2. **Access Permissions**
- Administrative or root privileges are required to configure log file paths and enable the Nginx status module.
- Read permissions must be granted for Nginx log files (e.g., `access.log` and `error.log`).
3. **Nginx Status Module Enabled**
- The **stub\_status** module should be enabled to allow collection of server metrics such as active connections and request rates.
- Add or verify the following configuration in your Nginx configuration file.
```
location /nginx_status {
stub_status;
access_log off;
allow 127.0.0.1; # restrict access as needed
allow ; # e.g. 192.172.10.0/24
deny all;
}
```
- Test and Reload Nginx after making changes:
```
sudo nginx -t # Test first
sudo systemctl reload nginx # Use reload, not restart
```
- Verify it works:
```
curl http://127.0.0.1/nginx_status
```
**Linux:**
**Ubuntu/Debian:**
- Main config: `/etc/nginx/nginx.conf`
- Site configs: `/etc/nginx/sites-available/default`
- Enabled sites: `/etc/nginx/sites-enabled/default` (symlink)
**CentOS/RHEL:**
- Main config: `/etc/nginx/nginx.conf`
- Site configs: `/etc/nginx/conf.d/default.conf`
**Where to add `stub_status`:**
- Add to your site configuration file (e.g., `/etc/nginx/sites-available/default` or `/etc/nginx/conf.d/default.conf`)
- Or add directly to `/etc/nginx/nginx.conf` in the `server` block
**Windows:**
**Configuration file location:**
```
C:\nginx\conf\nginx.conf
```
**Where to add `stub_status`:**
- Edit `C:\nginx\conf\nginx.conf`
- Add inside the `http { server { } }` block
**macOS:**
**Homebrew installation:**
```
/usr/local/etc/nginx/nginx.conf
```
**or**
```
/opt/homebrew/etc/nginx/nginx.conf
```
**MacPorts Installation:**
```
/opt/local/etc/nginx/nginx.conf
```
4. **Network Connectivity**
- Ensure that the system where monitoring is configured can connect to the Nginx host via the appropriate network ports (typically port **80** or **443**).
5. **Log File Availability**
- Confirm that standard Nginx log files are present in their default or custom locations:
- Access logs: `/var/log/nginx/access.log`
- Error logs: `/var/log/nginx/error.log`
On the device where **Nginx Server** is installed, you must also install the **AQUILA Log Collector Agent**. This agent is responsible for collecting the Nginx access and error logs and forwarding them to AQUILA for processing.
Please refer to the official manuals for installing the **AQUILA Log Collector Agent** on different operating systems:
- **Linux:** [Log Collector Installation - Linux Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-linux-manual)
- **Windows:** [Log Collector Installation - Windows Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-windows-manual)
- **Mac:** [Log Collector Installation - Mac Manual](https://docs.cytechint.io/books/log-collector-installations/page/log-collector-installation-mac-manual)
Ensure that after installation, the Log Collector service is running properly.
#### **Required Credentials for Integration**
##### **Collect logs from Nginx instances**
- Access Logs Path: *eg. **/var/log/nginx/access.log\****
- Error Logs Path: *eg. **/var/log/nginx/error.log\****
##### **Collect metrics from Nginx instances**
- Host: *eg. [http://127.0.0.1:80](http://127.0.0.1:80)*
Integrating monitoring for NGINX is straightforward once your setup and agents are in place: simply add the integration to an agent policy, configure log paths (e.g., /var/log/nginx/\*.log) and metrics host/path (e.g., http://127.0.0.1/nginx\_status), and let the managed agents handle collection. This enables real-time monitoring of access/error logs and server metrics like connections and requests, with pre-built dashboards for visualization, alerting, and anomaly detection.
NGINX integration is really helpful for boosting reliability and performance insights with minimal effort—it provides centralized management, scalable observability, and easy customization for custom log formats. If issues arise, check agent status and permissions first. For production, secure endpoints and rotate credentials. Dive into the docs for advanced tweaks!
*If you need further assistance, kindly contact our support at for prompt assistance and guidance.*
# AQUILA - SalesForce Integration in Two Deferent Methods (JWT Bearer Flow and Username-Password Flow)
Salesforce requires secure communication protocols for authorization and data exchange between external applications and Salesforce orgs. This involves creating digital certificates, configuring external client apps, and establishing secure authentication methods. OpenSSL provides the cryptographic tools needed to generate private keys and self-signed certificates for secure communication over networks.
#### **Integration Overview**This integration supports secure communication through:
- JWT (JSON Web Token) authentication using digital certificates
- OAuth authentication with external client apps
- Self-signed certificates and keystore managementOrganizations can authorize Salesforce CLI commands and establish secure API connections using these authentication methods.
#### **Compatibility**
- Supports Salesforce CLI authorization via JWT Bearer Flow
- Compatible with macOS, Linux, and Windows operating systems
- Requires OpenSSL for certificate generation
---
#### **Installing OpenSSL in your Log Collector (JWT Bearer Flow)**
OpenSSL is an open-source software library that provides tools and protocols for secure communication over networks. It helps encrypt data so that information like passwords, credit card numbers, and private messages stay secure when sent over the internet.
##### **Step 1:**
**In Linux:**
Install OpenSSL on your system:
```
sudo apt install openssl
```
**In Windows:**
you can refer this manual for more info: [Openssl Installation in Windows 11](https://usdc-docs.cytechint.io/books/system-integrations/page/openssl-installation-in-windows-11 "openssl")
##### **Step 2:** Verify OpenSSL installation by running:
- macOS/Linux: `which openssl`
- Windows: `where openssl`
---
#### **Creating a Private Key and Self-Signed Digital Certificate**A digital certificate and the private key used to sign the certificate are needed to authorize an organization using the `org login jwt` command. While it is strongly advised to utilize a certificate issued by a certifying authority, you can use OpenSSL to generate a self-signed certificate to get started.This process produces two files:
- **server.key** — The private key used when authorizing an org with the `org login jwt` command
- **server.crt** — The digital certificate uploaded when creating the required external client app
##### **Step 1:** Open a terminal (macOS and Linux) or command prompt (Windows).
##### **Step 2:** Create a directory to hold the generated files and navigate to it:
```
mkdir /Users/jdoe/JWT
cd /Users/jdoe/JWT
```
##### **Step 3:** Create a private key and save it as server.key file:
Remember to change "**<your password>**" to the password of your choice. The password should be the same with the **server.pass.key** and **server.key**.
- server.pass.key command
```
openssl genpkey -aes-256-cbc -algorithm RSA -pass pass: -out server.pass.key -pkeyopt rsa_keygen_bits:2048
```
- server.key command
```
openssl rsa -passin pass: -in server.pass.key -out server.key
```
##### **Step 4:** Use the server.key file to create a certificate signing request and save it as server.csr:
When prompted, provide your organization’s details. Enter only the **Country Name, State or Province, Locality, and Organization Name**—you may leave all other fields blank.
**Do not enter a password when generating the `server.csr`, as it may cause an authentication mismatch.**
```
openssl req -new -key server.key -out server.csr
```
##### **Step 5:** Create a self-signed digital certificate using the server.key and server.csr files:
```
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
```
##### **Step 6:**
Clone the server.key file and save it as server.pem
**Important step to successfully integrate into SIEM**
- For Linux
```
cp server.key server.pem
```
- For Windows
- ```
copy server.key server.pem
```
---
#### **Creating User for JWT Bearer Flow/Username-Password Flow**
- In Setup, enter Users in the Quick Find box, then select **Users**.
- Click **New User**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/lxfFZ4d8GQ8QC6V2-image.png)
- Fill out the form, and assign the System Administrator.
- Role > None Specified
- User License > Salesforce
- Profile > System Administrator
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/mxEgnKd9JE9SqBiP-image.png)
- Click **Save**.
---
#### **Creating an External Client App in Salesforce (JWT Bearer Flow)**Salesforce CLI requires an external client app in the org that you're authorizing. An external client app is a packageable framework that enables a third-party application (Salesforce CLI) to integrate with Salesforce using APIs and security protocols. You must create your own external client app when authorizing the org with the `org login jwt` command.
##### **Step 1:** Log in to your Salesforce Organization.
Note: If the salesforce dashboard interface is in classic mode change it to lighting mode.
- **In the Upper Right Corner click the gear icon.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/Kyqkx6MxXwwySPOm-image.png)
- **Select setup.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/W418IIogPqHkBJyB-image.png)
##### **STEP 2:** To find the base URL and instance URL follow the guide below.
- In quick find box, enter my domain then select my domain under Company Settings.
- Under My Domain Details copy Current My Domain URL that's your base URL and Instance URL. (Give it to Cytech Support)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/m7aiSY2jALXJCs7S-image.png)
#####
##### **Step 3:** From the Quick Find box in Setup, enter **App Manager**, then click **App Manager**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/hXfeVemGvOeNRe6b-image.png)
##### **Step 3:** Click **New External Client App**.
##### **Step 4:** Update the basic information as needed, such as the external client app name and your contact email address.
Note: The email address provided must be valid, as **Salesforce** will use it to communicate with your team regarding any updates or issues related to your application usage.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/t7RF1MsnBgsJUWO0-image.png)
##### **Step 5:** Under **API (Enable OAuth Settings)**, click **Enable OAuth**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/nPBfthwtSaUVQTVu-image.png)
##### **Step 6:** Under **App Settings**, in the **Callback URL** box, enter the URL below:
```
https:///callback
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/OrLg2NdHZ39JyZF9-image.png)
##### **Step 7:** In the **OAuth Scopes** section, select these scopes:
- **Manage user data via APIs** (api) - Gives you access to user data.
- **Perform requests at any time (refresh\_token, offline\_access)** - Permits you to get an OAuth access token.
- **Full access (full) -** grant all access to the permission for integration.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/Th0Fx9Vl56KiS3Zw-image.png)
##### **Step 8:** (Required for JWT) In the **Flow Enablement** section, select **Enable Client Credentials Flow** and **Enable JWT Bearer Flow**.
- **Enable Client Credentials Flow** - Allows your app to exchange its client credentials for an access token. And be able to access the credential Client ID.
- **Enable JWT Bearer Flow** - A secure, server-to-server authentication method used to integrate external applications with Salesforce without requiring manual user login.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/ZGUvtPXQ3OVi3JeW-image.png)
##### **Step 9:** (Required for JWT) Click **Upload Files** and upload your digital certificate file (**server.crt**).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/EcdC04TK8734E0rN-image.png)
##### **Step 10:**
In **Security** section check the following:
- Require secret for Refresh Token Flow
- Enable Refresh Token Rotation
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/ZLhwfSBBy0jmOgSJ-image.png)
##### **Step 11:** Click **Create** and **Edit** to configure additional settings.
##### **Step 12:** (Required for JWT) Click the **Policies** tab and configure the following:
- Open **OAuth(Open Authorization) Policies**
- In the **Plugin Policies** section, set **Permitted Users** to **Admin approved users are pre-authorized**
- **(Optional) In OAuth Start URL** use your organization base URL example: (https://fun-dream-996.my.salesforce.com/)
- Click **OK**
- In the **App Policies** section, select the profiles and permission sets that are pre-authorized to use this external client app
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/NuHfJZuvWFJeXBqW-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/6YuVtsg7UDV6XJQX-image.png)
##### **Step 14:** In the **OAuth Flows and External Client App Enhancements** section Enable Client Credentials Flow** and add username**.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/k3Ct7Vxw8p1x9H1b-image.png)
##### **Step 15:** In the **App Authorization** section, under **OAuth(Open Authorization) Policies**, click **Expire refresh token after a specific time**.
##### **Step 16:** Configure token expiration settings:
- **Refresh Token Validity Period**: Enter 365
- **Refresh Token Validity Unit**: Select **Day(s)**
##### **Step 17:** In the **Session Timeout in Minutes** box, enter **15**.
##### **Step 18:** In IP Relaxation Select **Relax IP restrictions** and the Click **Save**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/YTK4VIhQUhFZMT6R-image.png)
##### **Step 19:****Enable Allow Access to External Client App Consumer Secret via REST API****External Client App Setting > Allow Access to External Client App Consumer Secret via REST API**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/W4Jt6m6fQpESM3SS-image.png)
##### **Step 20:****Enable Event log files****Event Monitoring Settings > Generate event log files**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/u83m9Xo4Q4t80Gbm-image.png)
Your external client app is now ready to use.
---
##### **How to Find Client ID (Consumer Key) in External Client App**
- type **external** in quick find search bar and click **external client app manager**
- under **External Client App Name** locate the app you created earlier and click it.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/erObpFuyEh346HHr-image.png)
- under settings tab click **OAuth Settings** then you can the view your **client key** and **client secret** after the verification process.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/JBmH0nQqrZgONVQx-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/sqLlW3FdmcDRQHYY-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/RH4kDudKRkqCoRJQ-image.png)
---
##### **Create A Connected Apps (Username-Password Flow)**
For security reasons, Salesforce blocks the OAuth 2.0 Username-Password flow by default in recent releases. Prefer the JWT bearer flow. If you must use the Username-Password flow, in `OAuth and OpenID Connect Settings`, select `Allow OAuth Username-Password Flows`. For more information, see the Salesforce release note: [Username-Password OAuth flow blocked by default.](https://help.salesforce.com/s/articleView?id=release-notes.rn_security_username-password_flow_blocked_by_default.htm&language=en_US&release=244&type=5)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/VXD6iKeRCEk6htq7-image.png)
- Log in to Salesforce (Lightning UI).
- From `Setup`, in `Quick Find` enter `External Client Apps` and select `Settings`. Turn on `Allow creation of connected apps`. To create a connected app, select `New Connected App`.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/k1o1tW0E5LEV58Zy-image.png)
- Fill `Basic Information`: `Connected App Name`, `API Name`, `Contact Email`.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/IsDNcjY9IF5H6689-image.png)
- In `API (Enable OAuth Settings)`, check `Enable OAuth Settings`.
- `Callback URL`:
- Web apps: your app callback (for example, `https://yourapp.example.com/callback`).
- Not used by the JWT or Username-Password flows, but Salesforce requires a value; you can enter your instance URL.
- Select OAuth scopes:
- `Manage user data via APIs (api)`
- `Perform requests at any time (refresh_token, offline_access)`
- `Full access (full)`
- Enable Client Credentials Flow
- Enable Refresh Token Rotation
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/xYB3Idafcolwvx4x-image.png)
- Click `Save`. It can take up to 10 minutes for the Connected App to propagate.
- After saving, open `Manage Consumer Details` to obtain `Consumer Key` and `Consumer Secret`.
Manage Consumer Details Appears only once so better to copy consumer key and consumer secret in a safe place.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/Vg0C8iMXaXIy0LRF-image.png)
- Then Click Manage to OAuth Policies
- Permitted Users > All users may self-authorize
- IP Relaxation > Relax IP Restrictions
- Refresh Token Policy > Expire refresh token after "365" days
- Client Credentials Flow > "the user you created earlier"
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/zRwgrFo6TSrG2YvC-image.png)
---
##### **Verify if LoginEvent is enable
in Quick find > Event Manager > enable all**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/c3FO4fC2t5KzJ44w-image.png)
---
##### **Required fields for JWT and Username-Password Flow Integration:****For JWT Bearer Flow:**
- ##### `JWT Authentication Client Key Path (full file folder path of server.pem not in root directory)`
- ex: Users/jdoe/JWT/server.pem
- ##### `Username (can be found in View Profile > Settings > Personal Information)or If you have dedicated user for integration can be found in (Quick Find > Users > Username)`
- example format: ADMIN-3dvj@force.com
- ##### `Client ID (Consumer Key)`
- example format: 3MVxxxxxtCx.CV6cbh7fSpKs\_5iexxxxxxxxxxxxxxxxxxxxxxxxxxxZKBaepcxlJUhO1
- ##### `Instance URL`
- example format: [https://company.my.salesforce.com](https://company.my.salesforce.com)
- ##### `API Version`
- in quick find type Apex Classes[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/VvFkdpQXXJS8CMXh-image.png)
**For Username-Password Flow:**
- **Username**
- **Password**
- **Consumer Key**
- **Consumer Secret**
- **Instance URL**
##### Provide this required fields to [**CyTech Support**](mailto:support@cytechint.com).
---
Reference Link: [Create an External Client App in Your Org | Salesforce DX Developer Guide | Salesforce Developers](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_eca.htm)
---
*If you need further assistance, kindly contact our support at [**support@cytechint.com**](mailto:support@cytechint.com) for prompt assistance and guidance.*
# Whitelist in Google Workspacege
### **Whitelisting Simulated Phishing in Google Workspace (Gmail)**
**For Secure Practice Simulation Emails**
This step-by-step guide is intended for **Google Workspace administrators** to allow simulated phishing emails from **Secure Practice** by properly configuring Gmail to recognize and accept messages from specific IP addresses.
> **Note:** You must have an **admin role** in the Google Workspace Admin Console to perform these actions.
---
### **Step 1: Access the Admin Console**
1. Visit [https://admin.google.com](https://admin.google.com/)
2. Sign in using your **administrator account**
---
### **Step 2: Navigate to Gmail Settings**
1. In the left-hand menu, go to:
**Apps** → **Google Workspace** → **Gmail**
2. Under Gmail settings, click on **Spam, Phish and Malware**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/MAdg7TzWA6SuEXGl-image.png)
---
### **Step 3: Add IPs to the Email Allowlist**
1. Click on **Email allowlist**
- **35.153.237.243(Mail Server)**
- **107.22.65.180(Landing Page)**
2. Enter the following IP addresses:
3. Click **Save**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/EHNr7095OZVrXU5Q-image.png)
---
### **Step 4: Configure Inbound Gateway**
This step ensures that Gmail treats the IP addresses above as **internal senders**, preventing SPF or DMARC validation and suppressing warnings to end-users.
1. Scroll down to the **Inbound Gateway** section
2. If not already enabled, click the **Enable** button
3. In the **Gateway IPs** field, enter the same IP addresses listed earlier
4. Optional:
- Enable **Automatic detect external IP**
- **Do not** enable “Reject all mail not from gateway IPs” unless already required—this may block all mail delivery if not properly configured
- Enable **Require TLS for connections**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/0038sCvbVlH5I0NR-image.png)
---
### **Step 5: Configure Message Tagging**
1. Under the **Message Tagging** section:
- Check **"Message is considered spam if the following header regexp matches"**
- Enter a **unique, random string** : fg2jl0ah45oahtTK56SGD23fhk2k
- Check **"Disable Gmail spam evaluation"**
This ensures Gmail skips its spam analysis for messages from the configured IPs.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/jvwcnmC96C1W0GUd-image.png)
---
### **Step 6: Bypass Spam Filters for Trusted Senders**
1. Still under Gmail settings, go to the **Spam** section
2. Click **Configure** to create a spam filter bypass rule
3. Check: **"Bypass spam filters for messages received from addresses or domains"**
4. Click **Create or edit list** and add the following senders:
- slackj.com
- ttrelli.com
- airbnd.cc
- attlassians.com
- eebbey.com
- lastpasss.net
- my1psswords.com
- zooms.cc
5. For flexibility, uncheck **"Authentication required"** for
6. Save the address list and the new spam bypass policy
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/ESsyInCwDlu1fTMU-image.png)
---
### **Step 7: Adding Message Header in Compliance**
1. Navigate to the **Compliance** section in the Google Workspace Admin console.
2. Go to the **Content Compliance** subsection.
3. Click **Configure** or **Add Another**, depending on whether a rule has already been added. This will open the **Add Setting** pop-up window.
4. In the **Content compliance** field, provide a clear description for the rule, such as **"CyTech Whitelisting"**.
5. Under **Email messages to affect**, check the **Inbound** box.
6. In the **Expressions** section, click **Add** to open a new pop-up window.
7. In the first drop-down menu, select **Metadata match**.
8. From the **Attribute** drop-down menu, choose **Source IP**.
9. In the **Match type** drop-down menu, select **Source IP is**.
10. In the value field, enter one of CyTech’s IP addresses.
- **35.153.237.243(Mail Server)**
- **107.22.65.180(Landing Page)**
11. In the **Headers** section, check the **Add custom headers** option.
12. Click **Add** in the **Custom headers** field.
13. In the **Header key** field, enter: **X-PHISHTEST**
14. In the **Header value** field, enter: **CYTECH**
15. Click **Save**.
16. Review all configured settings, then click **Save** again to apply the rule.
### **Optional: Temporary Adjustment for Quicker Testing**
Google offers a feature called **Enhanced Pre-Delivery Message Scanning**.
While not recommended to disable permanently, you may consider turning it off briefly to speed up testing and configuration validation.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2025-05/jkWIar7Ofj3szJ11-image.png)
---
### **Additional Systems in Use?**
If your organization uses other email or security filtering systems, please refer to the [Whitelisting Phishing Overview](https://docs.cytechint.io/books/culture-and-awareness/chapter/whitelisting) and ensure proper bypass configurations are in place across all layers.
---
Reference Documentation Link: *[https://securepractice.co/guides/whitelisting-google](https://securepractice.co/guides/whitelisting-google)*
If you need further assistance, kindly contact our support at **support@cytechint.com** for prompt assistance and guidance.
# AQUILA - Cato Network Integration(Linux)
Cato Networks provides a cloud-native SASE (Secure Access Service Edge) platform that converges networking and security into a global cloud service. The platform generates security and connectivity events that can be collected, analyzed, and monitored for network insights and threat detection. This integration enables centralized event collection from Cato Networks using the Cato CLI for visualization and analysis.
#### **Integration Overview**
This integration supports event collection through:
- Cato CLI (catocli) using the Events Feed API
- Automated event polling via systemd service
- File-based log collection with structured JSON output
Events can be searched, observed, and visualized for security monitoring, connectivity analysis, and network performance tracking.
##### **Compatibility**
- Supports event collection for Security and Connectivity event types
- Requires Python 3.6 or higher
- Compatible with Linux, macOS, and Windows operating systems
- Requires valid Cato Network API token and Account ID
- Systemd service integration for Linux-based systems
##### **Prerequisites**
Before configuring the Cato Network integration, ensure you have:
- Python 3.6 or higher installed
- Python virtual environment configured
- Cato CLI (catocli) installed
- Valid Cato Network API token
- Valid Cato Network Account ID
#### **Python Installation**
##### **Linux Installation:**
##### **Step 1:** Open the Terminal and refresh package lists:
```
sudo apt update
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/KF6h5bY5QGCPa5Hs-image.png)
##### **Step 2:** Update installed packages:
```
sudo apt upgrade -y
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/dJLuZQGlfYpl9Yup-image.png)
##### **Step 3:** Install Python (replace \[version number\] with your desired version):
```
sudo apt install python[version number]
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/eEB6el60eELJcHL5-image.png)
#### **Creating Python Virtual Environment**
A Python virtual environment isolates project dependencies and prevents conflicts with system-wide Python packages.
#### **Linux/macOS:**
##### **Step 1:** Open a Terminal.
##### **Step 2:** Navigate to your project directory using the cd command:
```
cd /path/to/your/project
```
##### **Step 3:** Create a virtual environment:
```
python3 -m venv venv
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/6m9xJWxlJoM4JZgX-image.png)
##### **Step 4:** Activate the virtual environment:
```
source venv/bin/activate
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/8JwkcTJNarZXDjV8-image.png)
##### **Step 5:** Once activated, the virtual environment name (e.g., (venv)) will appear in your terminal prompt.
##### **Step 6:** To deactivate the virtual environment, type:
```
deactivate
```
#### **Cato CLI Installation**
##### **Step 1:** Ensure your virtual environment is activated.
##### **Step 2:** Install the Cato CLI using pip:
```
pip3 install catocli
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/TDTJvkiIMQeZjJSX-image.png)
##### **Step 3:** Verify the installation by running:
```
catocli --version
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/I7ClZSlQtUACeBRR-image.png)
#### **Validating Cato Network API Token and Account ID**
##### **Step 1:** Configure the Cato CLI with your API token and Account ID:
```
catocli configure set --cato-token "your-api-token" --account-id "12345"
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/4LRoTcRf5CQwm73z-image.png)
Replace `"your-api-token"` with your actual Cato Network API token and `"12345"` with your Account ID.
#### **Configuring the Cato Network Integration (Linux)**
##### **Creating a Dedicated User (Optional but Recommended):**
For security and isolation, create a dedicated system user to run the Cato event collection service.
##### **Step 1:** Optional - Create a system user named (for this example) `testing-cato`:
```
sudo useradd -r -s /bin/false testing-cato
```
##### **Step 2:** Create required directories for data, logs:
```
sudo mkdir -p /var/lib/cato /var/log/cato
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/ZRqQkYqmlKfsJL4j-image.png)
##### **Step 3:** Set ownership of the directories to the dedicated user:
```
sudo chown -R testing-cato:testing-cato /var/lib/cato /var/log/cato
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/1afigOby8PUfoHUA-image.png)
#### **Creating the Bash Wrapper Script:**
The wrapper script manages event collection, logging, and ensures only one instance runs at a time.
##### **Step 1:** Create the wrapper script file:
```
sudo nano /usr/local/bin/cato-eventsfeed.sh
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/b2P0ZvFyPtoVS4sx-image.png)
##### **Step 2:** Add the following content to the file:
Important: Replace "testing-cato" in CATOCLI to the actual user
```bash
Ask Cytech Support For the Source code
```
##### **Step 3****:** Save and exit the file
##### **Step 4****:** Make the script executable:
```
sudo chmod +x /usr/local/bin/cato-eventsfeed.sh
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/ZpbIlyeQDiAgLnwn-image.png)
##### **Step 5:** Set ownership to the dedicated user:
```
sudo chown testing-cato:testing-cato /usr/local/bin/cato-eventsfeed.sh
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/MZYxUVp3xeoPojV4-image.png)
#### **Creating the Systemd Service File:**
The systemd service ensures the event collection runs continuously and restarts automatically on failure.
##### **Step 1:** Create the service file:
```
sudo nano /etc/systemd/system/cato-eventsfeed.service
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/0rREOoDP43ogMFqm-image.png)
##### **Step 2:** Add the following content to the file:
```ini
Ask Cytech Support for the Source Code
```
Note: In Environment path, replace the path of the actual path of your python virtual path "PATH=/home/**testing-cato/venv/**bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin". Change User and Group for non-root user as well.
##### **Step 3:** Save and exit the file (Ctrl+X, then Y, then Enter).
#### **Configuring Log Rotation**To manage log file sizes and prevent disk space issues, configure log rotation for Cato event logs.
##### **Step 1:** Create a logrotate configuration file:
```
sudo nano /etc/logrotate.d/cato-events
```
##### **Step 2:** Add the following configuration to the file:
```
/var/log/cato/events.log {
hourly
rotate 24
missingok
notifempty
copytruncate
compress
compressoptions -1
delaycompress
dateext
dateformat -%Y%m%d-%H%M%S
create 0640 testing-cato testing-cato
}
```
This configuration:
- Rotates logs hourly
- Keeps the last 24 rotated log files
- Compresses old log files to save disk space
- Creates new log files with appropriate permissions
##### **Step 3:** Save and exit the file (Ctrl+X, then Y, then Enter).
#### **Configuring Hourly Log Rotation**
By default, logrotate runs daily. To ensure more frequent log rotation for high-volume Cato event logs, configure the logrotate timer to run hourly.
##### **Creating the Timer Override File:**
##### **Step 1:** Create the systemd override directory:
```
sudo mkdir -p /etc/systemd/system/logrotate.timer.d
```
##### **Step 2:** Create the override configuration file:
```bash
sudo nano /etc/systemd/system/logrotate.timer.d/override.conf
```
##### **Step 3:** Add the following configuration to the file:
```ini
[Timer]
OnCalendar=
OnCalendar=hourly
AccuracySec=1m
Persistent=true
```
This configuration:
- Clears the default daily schedule with the empty 'OnCalendar'=
- Sets the timer to run hourly
- Ensures the timer runs within 1 minute of the scheduled time
- Catches up on missed runs if the system was offline
##### **Step 4:** Save and exit the file (Ctrl+X, then Y, then Enter).
#### **Reloading and Restarting the Timer**
##### **Step 1:** Reload the systemd daemon to recognize configuration changes:
```bash
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
```
##### **Step 2:** Restart the logrotate timer to apply the new schedule:
```
sudo systemctl restart logrotate.timer
```
##### **Step 3:** Verify the timer is active and scheduled correctly:
```
sudo systemctl status logrotate.timer
```
##### **Step 4:** Check the next scheduled run time:
```
systemctl list-timers logrotate.timer
```
The output should show the timer scheduled to run hourly.
#### **Enabling and Starting the Service**
##### **Step 1:** Reload systemd to recognize the new service file:
```
sudo systemctl daemon-reload
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/Tu7V23sh2jsdjsNA-image.png)
##### **Step 2:** Enable the service to start automatically on boot:
```
sudo systemctl enable cato-eventsfeed
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/79JRLWTK8bNIR1yJ-image.png)
##### **Step 3:** Start the service:
```
sudo systemctl start cato-eventsfeed
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/Dudlo9JFOl1nIPH7-image.png)
##### **Step 4:** Verify the service is running:
```
sudo systemctl status cato-eventsfeed
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/zeBYSJRErF63eghq-image.png)
The status should show *active (running)* in green text.
##### **Monitoring Live Logs:**
To view real-time logs from the Cato event feed service:
```
journalctl -u cato-eventsfeed -f
```
Press **Ctrl+C** to stop viewing the live logs.
##### **Event Collection** **Settings**
The integration collects the following event types from Cato Networks:
- **Security Events**: Threat detection, malware blocks, IPS alerts, and security policy violations
- **Connectivity Events**: Site connectivity changes, tunnel status, WAN link failures, and network performance issues
##### **Configuration Parameters:**
- **Marker File**: `/var/lib/cato/events-marker.txt` - Tracks the last processed event to prevent duplicates
- **Lock File**: `/var/lock/cato-eventsfeed.lock` - Ensures only one instance of the script runs at a time
- **Log File**: `/var/log/cato/events.log` - Stores collected events in JSON format
- **Runtime Limit**: 10 minutes per execution cycle
- **Event Types**: Security and Connectivity events
##### **Log Events**
Enable this option to collect Cato Network log events across all configured event types from your Cato SASE platform.
##### **Logs Dataset**
The `cato.events` dataset contains events collected from the Cato Networks Events Feed API. All Cato-specific event fields are available in the `/var/log/cato/events.log` file for detailed analysis, including:
- Event timestamps and identifiers
- Source and destination information
- Security threat classifications
- Network connectivity status
- Policy enforcement actions
- Geographic and site information
---
##### **For the Back-end Side**
Add this in the processor:
```yaml
processors:
- decode_json_fields:
fields: ["message"]
target: ""
overwrite_keys: true
add_error_key: true
- add_fields:
target: event
fields:
module: cato-network
- add_fields:
target: component
fields:
id: cato-SASE
```
# AQUILA - Cato Network Integration(Windows)
Cato Networks provides a cloud-native SASE (Secure Access Service Edge) platform that converges networking and security into a global cloud service. The platform generates security and connectivity events that can be collected, analyzed, and monitored for network insights and threat detection. This integration enables centralized event collection from Cato Networks using the Cato CLI for visualization and analysis.
#### **Integration Overview**
This integration supports event collection through:
- Cato CLI (catocli) using the Events Feed API
- Automated event polling via Windows Service (NSSM)
- Python-based event collection script running as a background service
Events can be searched, observed, and visualized for security monitoring, connectivity analysis, and network performance tracking.
##### **Compatibility**
- Supports event collection for Security and Connectivity event types
- Requires Python 3.6 or higher
- Compatible with Windows Server operating systems
- Requires valid Cato Network API token and Account ID
- Requires NSSM (Non-Sucking Service Manager) for Windows Service integration
##### **Prerequisites**
Before configuring the Cato Network integration, ensure you have:
- Python 3.6 or higher installed
- Python virtual environment configured at `C:\cato\venv`
- Cato CLI (catocli) installed
- Valid Cato Network API token
- Valid Cato Network Account ID
- NSSM (Non-Sucking Service Manager) downloaded
#### **Python Installation**
##### **Windows Installation:**
##### **Step 1:** Open your web browser and navigate to the [official Python downloads](https://www.python.org/downloads/ "https://www.python.org/downloads/") page:
##### **Step 2:** Locate the latest stable version of Python 3 (3.12 or newer is recommended) and choose the correct installer for your system type (64-bit or 32-bit).
##### **Step 3:** Click the installer link to download the .exe file.
##### **Step 4:** After downloading, locate the installer file (e.g., python-3.x.x-amd64.exe) and double-click it to start the installation.
##### **Step 5:** On the installer screen, configure the following options:
- Check **Install launcher for all users**
- Check **Add python.exe to PATH** to enable running Python from the Command Prompt
##### **Step 6:** Click **Install Now** to begin the installation process.
##### **Step 7:** Wait for the installation to complete, then click **Close** when the success message appears.
##### **Step 8:** Verify the installation:
- Open the Start menu, type **cmd**, and open Command Prompt
- Type `python --version` and press Enter to confirm the installed Python version
#### **Creating Python Virtual Environment**
A Python virtual environment isolates project dependencies and prevents conflicts with system-wide Python packages.
##### **Step 1:** Open Command Prompt or PowerShell.
##### **Step 2:** Create and Navigate to your project directory using the mkdir and cd command:
```
mkdir "C:\cato"
cd C:\cato
```
##### **Step 3:** Create a virtual environment:
```
python -m venv venv
```
##### **Step 4:** Activate the virtual environment:
- **Command Prompt:**```
venv\Scripts\activate.bat
```
- **PowerShell:**```
.\venv\Scripts\activate.ps1
```
##### **Step 5:** Once activated, the virtual environment name (e.g., (venv)) will appear in your terminal prompt.
##### **Step 6:** To deactivate the virtual environment, type:
```
deactivate
```
#### **Cato CLI Installation**
##### **Step 1:** Ensure your virtual environment is activated.
##### **Step 2:** Install the Cato CLI using pip:
```
pip3 install catocli
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/T8innKXGPj0E8aBZ-image.png)
##### **Step 3:** Verify the installation by running:
```
catocli --version
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/dbZLovD5Ic5UsJPu-image.png)
#### **Configuring Cato CLI for Local System Execution**
To enable the Cato CLI to run as a Windows Service under the Local System account, modify the profile manager configuration.
##### **Step 1:** Navigate to the Cato CLI profile manager file:
```
C:\cato\venv\Lib\site-packages\catocli\Utils\profile_manager.py
```
##### **Step 2:** Open the file in a text editor (e.g., Notepad or Visual Studio Code).
##### **Step 3:** Locate the `__init__` constructor in the file:
```python
def __init__(self):
self.cato_dir = Path.home() / '.cato'
self.credentials_file = self.cato_dir / 'credentials'
self.config_file = self.cato_dir / 'config'
self.default_endpoint = "https://api.catonetworks.com/api/v1/graphql2"
```
##### **Step 4:** Replace `Path.home()` with `Path("C:/cato")`:
```python
def __init__(self):
self.cato_dir = Path("C:/cato") / '.cato'
self.credentials_file = self.cato_dir / 'credentials'
self.config_file = self.cato_dir / 'config'
self.default_endpoint = "https://api.catonetworks.com/api/v1/graphql2"
```
This change ensures the Cato CLI uses a fixed directory path instead of the user's home directory, which is essential for running as a system service.
##### **Step 5:** Save and close the file.
#### **Validating Cato Network API Token and Account ID**
##### **Step 1:** Configure the Cato CLI with your API token and Account ID:
```
catocli configure set --cato-token "your-api-token" --account-id "12345"
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/anuhQHhpEoQO1jgY-image.png)
Replace `"your-api-token"` with your actual Cato Network API token and `"12345"` with your Account ID.
#### **Downloading and Installing NSSM**
NSSM (Non-Sucking Service Manager)is a service helper tool that allows you to run any application as a Windows Service.
##### **Step 1:** Download [NSSM](https://nssm.cc/download "https://nssm.cc/download") from the official website:
##### **Step 2:** Extract the downloaded ZIP file.
##### **Step 3:** Copy the appropriate `nssm.exe` file (32-bit or 64-bit based on your system) to the Cato integration directory:
```
C:\cato\nssm.exe
```
#### **Creating the Python Event Collection Script**
##### **Step 1:** Create a Python script file at:
```
C:\cato\my_script.py
```
##### **Step 2:** Paste this configuration script to my\_script.py that you created earlier:
```python
Ask Cytech Support for the Soure Code
```
##### **Step 3:** Save the script file.
#### **Installing the Cato Events Feed as a Windows Service**
Use NSSM to install the Python script as a Windows Service that runs automatically in the background.
##### **Step 1:** Open PowerShell as Administrator and Navigate to the Cato directory:
```
cd C:\cato
```
##### **Step 2:** Run the NSSM installation command:
```
C:\cato\nssm.exe install CatoEventsFeed
```
This opens the NSSM service installer GUI.
##### **Step 1: Configuring the Service - Application Tab:**
##### **Path:** C:\\cato\\venv\\Scripts\\python.exe
**Startup directory:** C:\\cato
**Arguments:** C:\\cato\\my\_script.py
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/lmjFeXyxwLMPJ7Ce-image.png)
##### **Step 2: Configuring the Service - Details Tab:**
**Display name:** CatoEventsFeed
**Description:** The platform generates security and connectivity events that can be collected, analyzed, and monitored for network insights and threat detection. This service enables centralized event collection from Cato Networks using the Cato CLI for visualization and analysis.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/RykIOTi9dKSTbr1G-image.png)
##### **Step 4: Configuring the Service - Log on tab**
select Local System account
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/Eh2Mzf7VDp8mQIfw-image.png)
This allows the service to run with system-level privileges without requiring a specific user login.
##### **Step 5: Configuring the Service - Exit action tab**
**delay restart if application runs for less than:** 5000
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-03/28zTZgYlIpLbeBec-image.png)
This setting ensures the service waits 5 seconds before attempting a restart if the application crashes immediately after starting.
##### **Step 6: Click Install service to complete the installation.**
#### **Starting the Cato Events Feed Service**
##### **Step 1: **Open PowerShell as Administrator and navigate to the Cato directory:
```
cd C:\cato
```
##### **Step 2:** Start the service using NSSM:
```
.\nssm.exe start CatoEventsFeed
```
##### **Step 3: **Verify the service is running:
```
sc.exe query CatoEventsFeed
```
The output should show "STATE: RUNNING".
#### **Managing the Cato Events Feed Service****To start the service:**
```
C:\cato\nssm.exe start CatoEventsFeed
```
**To restart the service:**
```
C:\cato\nssm.exe restart CatoEventsFeed
```
**To check service status:**
```
C:\cato\nssm.exe status CatoEventsFeed
```
#### **Event Collection Settings**
The integration collects the following event types from Cato Networks:
- **Security Events**: Threat detection, malware blocks, IPS alerts, and security policy violations
- **Connectivity Events**: Site connectivity changes, tunnel status, WAN link failures, and network performance issues
#### **Configuration Parameters:**
- **Marker File**: `C:\cato\events-marker.txt` - Tracks the last processed event to prevent duplicates
- **Runtime Limit**: 10 minutes per execution cycle
- **Event Types**: Security and Connectivity events
- **Collection Interval**: 10 minutes (configurable in my\_script.py)
#### **Log Events**
Enable this option to collect Cato Network log events across all configured event types from your Cato SASE platform.
#### **Logs Dataset**
The `cato.events` dataset contains events collected from the Cato Networks Events Feed API. All Cato-specific event fields are available in the configured log files for detailed analysis, including:
- Event timestamps and identifiers
- Source and destination information
- Security threat classifications
- Network connectivity status
- Policy enforcement actions
- Geographic and site information
# AQUILA - Atlassian Jira Integration through Oauth 2.0(3LO) and API Key
#### **What are API Token Scopes?**
Scopes define what actions an API token is allowed to perform in Atlassian apps such as Jira and Confluence. They enhance security by limiting permissions to only what's needed (e.g., read-only access to audit logs). Always use scoped tokens for AQUILA integrations—unscoped tokens are deprecated for most apps and may not support fine-grained access. For audit logs (events like user actions, config changes, or security incidents), use the specific scopes listed below. Broader scopes may be needed for other integrations (e.g., content indexing) but stick to these for basic monitoring to minimize risk.
##### **Prerequisites**
1. Atlassian Admin Email Account
2. Atlest have a read rights linux privilege
3. Broswer (firefox,chrome)
---
#### **Creating an API Token with Scopes**
1. Log in to [https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens).
2. Select "Create API token with scopes".
3. Enter a descriptive name for the token (e.g., "AQUILA- Audit Logs Monitoring").
Choose an expiration date for the token (between 1 and 365 days; consider shorter for security).
1. Select the application Jira.
2. Select the scopes or permissions the token should have:
- For Jira (audit logs): **Classic**: `manage:jira-configuration or Granular: read:audit-log:jira,read:user:jira` to access /rest/api/3/auditing/record.
3. Click "Create".
4. Copy the token and save it securely. You cannot view it again after this step. If lost, generate a new one. Share only with trusted integrations like AQUILA—revoke if compromised.
---
#### **OAuth 2.0(3LO)apps***OAuth 2.0 (3LO)* (also known as "three-legged OAuth" or "authorization code grants") apps. OAuth 2.0 (3LO) allows external applications and services to access Atlassian product APIs on a user's behalf. OAuth 2.0 (3LO) apps are created and managed in the [developer console](https://developer.atlassian.com/console/myapps/).
---
##### **Enabling OAuth 2.0(3LO)**1. Select your profile icon in the top-right corner, and from the dropdown, select Developer console.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/lVVBIvX9SFkYAF3G-image.png)
2. Select your app from the list (or create one if you don't already have one).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/AKDu1oWN0QYGsdAR-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/4mXowETiREvBPsmB-image.png)
3. Select Permissions in the left menu.4. Next to the API you want to add, select Configure or Add.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/KdSLfu058Xr8DEZd-image.png)
**Select Classic or Granular scope Classic:manage:jira-configuration was selected in this example.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/3qR0Dexu0wp9FzWJ-image.png)
5. Select Authorization in the left menu.6. Next to OAuth 2.0 (3LO), select Configure or Add.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/gtrKQRAoCYfo2kMp-image.png)
7. Enter the Callback URL. Set this to any URL that is accessible by the app. When you implement OAuth 2.0 (3LO) in your app (see next section),
**The redirect\_uri must match this URL.**
```
https://.atlassian.net/callback
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/kZ2esEByR97f2Mfm-image.png)
8. Click Save changes.9. In **Authorization URL generator** Copy and Paste in the browser.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/jufbJ3pRsu1tdHiz-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/iSLb89AftQMgWr9y-image.png)
10. Copy the URL and paste in text editor (notepad).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/J4qUrEsy6hF7BCPI-image.png)
**Example of a copied URL (the boxed section contains the authorization code).**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/UkbRlih2M4xs1pM7-image.png)
---
##### **Exchange authorization code for access token**
**Paste this Curl command into terminal.**
```c
curl --request POST \
--url 'https://auth.atlassian.com/oauth/token' \
--header 'Content-Type: application/json' \
--data '{"grant_type": "authorization_code","client_id": "YOUR_CLIENT_ID","client_secret": "YOUR_CLIENT_SECRET","code": "YOUR_AUTHORIZATION_CODE","redirect_uri": "https://YOUR_APP_CALLBACK_URL"}'
```
Change all fields:
- `client_id`: (*required*) Set this to the **Client ID** for your app. Find this in **Settings** for your app in the [developer console](https://developer.atlassian.com/console/myapps/ "https://developer.atlassian.com/console/myapps/").
- `client_secret`: (*required*) Set this to the **Secret** for your app. Find this in **Settings** for your app in the [developer console](https://developer.atlassian.com/console/myapps/ "https://developer.atlassian.com/console/myapps/").
- `code`: (*required*) Set this to the authorization code received from the initial authorize call (described above).
- `redirect_uri`: (*required*) Set this to the callback URL configured for your app in the [developer console](https://developer.atlassian.com/console/myapps/ "https://developer.atlassian.com/console/myapps/").
**If successful, this call returns an access token similar to this:**
```json
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": ,
"expires_in": ,
"scope":
}
```
---
##### **Make calls to the API using the access token Get the `cloudid` for your site**
Your app now has an access token that it can use to authorize requests to the APIs for the Atlassian site. To make requests, do the following:
1. **Get the `cloudid` for your site.**
2. Construct the request URL using the `cloudid`.
3. Call the API, using the access token and request URL.
---
##### **Get the `cloud_id` for your site**
Make a GET request to [https://api.atlassian.com/oauth/token/accessible-resources](https://api.atlassian.com/oauth/token/accessible-resources) passing the access token as a bearer token in the header of the request. For example:
**Replace "ACCESS\_TOKEN" with your newly generated token.**
```c
curl --request GET \
--url https://api.atlassian.com/oauth/token/accessible-resources \
--header 'Authorization: Bearer ACCESS_TOKEN' \
--header 'Accept: application/json'
```
This will retrieve the sites that have scopes granted by the token (see [Check site access for the app](https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/#siteaccess) below for details). Find your site in the response and copy the `id`. This is the `cloud_id` for your site.
**The wrapper script manages event collection, logging, and ensures only one instance runs at a time.**
1. **Create required directories for data, logs:**
**Create a directory named `jira` (for this example):**
```
mkdir jira
```
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/8hPJBMDmhrLARrmY-image.png)
**2. Create the wrapper script file:**
```
sudo nano /usr/local/bin/jira_audit.sh
```
**3. Add the following content to the file:**
**Replace the file path `FLAT_FILE` , `CHECKPOINT_FILE `as well as `CLOUD_ID`, `USER_EMAIL`, and `API_KEY`, with their actual values.**
```bash
Ask Cytech Support for the Source Code
```
4. **Make the script executable:**
```
sudo chmod +x /usr/local/bin/jira_audit.sh
```
5. **Set ownership to the dedicated user**:
**Replace the "user:group" in this example both `testing-jira:testing-jira`.**
```
sudo chown testing-jira:testing-jira /usr/local/bin/jira_audit.sh
```
---
#### **Creating the Systemd Service File:**
**The systemd service ensures the event collection runs continuously and restarts automatically on failure.**
**1. Create the service file:**
```
sudo nano /etc/systemd/system/jira-audit.service
```
**2. Add the following content to the file:**
**Replace WorkingDirectory file path.**
```ini
Ask Cytech Support for The Source Code
```
---
#### **Create a Systemd Timer to handle looping and run automatically in the background:**
A systemd timer is a feature of systemd used to schedule tasks to run automatically at specific times or intervals.
**1. Create the timer file:**
```
sudo nano /etc/systemd/system/jira-audit.timer
```
**2. Add the following content to the file:**
```ini
[Unit]
Description=Run Atlassian Jira Audit every 10 minutes
[Timer]
OnBootSec=60
OnUnitActiveSec=600
Persistent=true
Unit=jira-audit.service
[Install]
WantedBy=timers.target
```
---
---
#### **Configuring Log Rotation**To manage log file sizes and prevent disk space issues, configure log rotation for Jira Audit Logs.
##### **Step 1:** Create a logrotate configuration file:
```
sudo nano /etc/logrotate.d/jira_audit
```
##### **Step 2:** Add the following configuration to the file:
**Replace `/home/your_user/` with your actual path, and update `user_owner` and `user_group` to match the correct user and group.**
```
/home/your_user/jira/flattened.json {
daily
rotate 7
missingok
notifempty
copytruncate
compress
compressoptions -1
delaycompress
dateext
dateformat -%Y%m%d-%H%M%S
create 0640 user_owner user_group
}
```
---
#### **Enabling and Starting the Service**
**Step 1:** **Reload systemd to recognize the new service file:**
```
sudo systemctl daemon-reload
```
**Step 2: Enable the service to start automatically on boot:**
```
sudo systemctl enable --now jira-audit.timer
```
**Step 3: Verify the service is running:**
```
sudo systemctl list-timers
```
**You should see something like this.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/Ny6BCgorzIHNd8Tw-image.png)
---
##### **Monitoring Live Logs:**
To view real-time logs from the jira-audit service:
```
journalctl -u jira-audit -f
```
**Please provide the following information to CyTech.**
- **Flattened.json file path example "/home/testing-jira/jira/flattened.json"**
# AQUILA - Atlassian Confluence Integration through Oauth 2.0(3LO) and API Key(File Path)
#### **What are API Token Scopes?**
Scopes define what actions an API token is allowed to perform in Atlassian apps such as Jira and Confluence. They enhance security by limiting permissions to only what's needed (e.g., read-only access to audit logs). Always use scoped tokens for AQUILA integrations—unscoped tokens are deprecated for most apps and may not support fine-grained access. For audit logs (events like user actions, config changes, or security incidents), use the specific scopes listed below. Broader scopes may be needed for other integrations (e.g., content indexing) but stick to these for basic monitoring to minimize risk.
##### **Prerequisites**
1. Atlassian Admin Email Account
2. Atlest have a read rights linux privilege
3. Broswer (firefox,chrome)
---
#### **Creating an API Token with Scopes**
1. Log in to [https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens).
2. Select "Create API token with scopes".
3. Enter a descriptive name for the token (e.g., "AQUILA- Audit Logs Monitoring").
Choose an expiration date for the token (between 1 and 365 days; consider shorter for security).
1. Select the application Atlassian Confluence.
2. Select "Create API token with scopes".
3. Select the scopes or permissions the token should have:
- For Atlassian Confluence (audit logs): **`read:audit-log:confluence`** to access /wiki/rest/api/audit.
4. Click "Create".
5. Copy the token and save it securely. You cannot view it again after this step. If lost, generate a new one. Share only with trusted integrations like AQUILA—revoke if compromised.
---
#### **OAuth 2.0(3LO)apps***OAuth 2.0 (3LO)* (also known as "three-legged OAuth" or "authorization code grants") apps. OAuth 2.0 (3LO) allows external applicationsand services to access Atlassian product APIs on a user's behalf. OAuth 2.0 (3LO) apps are created and managed in the [developer console](https://developer.atlassian.com/console/myapps/).
---
##### **Enabling OAuth 2.0(3LO)**
1. Select your profile icon in the top-right corner, and from the dropdown, select Developer console.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/jxdunNFi29RQx2Wh-image.png)
2. Select your app from the list (or create one if you don't already have one).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/GLr4z8AGP77xDqny-image.png)[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/5VIzqFLCjZMQjnzU-image.png)
3. Select Permissions in the left menu.
4. Next to the API you want to add, select Configure or Add.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/tz9LZYlW50k0GsvZ-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/SK89J1rKP3PCjoxl-image.png)
5. Select Authorization in the left menu.
6. Next to OAuth 2.0 (3LO), select Configure or Add.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/dlIErAPJlf0DYWFz-image.png)
7. Enter the Callback URL. Set this to any URL that is accessible by the app. When you implement OAuth 2.0 (3LO) in your app (see next section). in this example "base URL /callback"
**The redirect\_uri must match this URL.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/vmzdQskGSufwcHHW-image.png)
8. Click Save changes.
9. In **Authorization URL generator** Copy and Paste in the browser.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/B6IYfcH2luAqwRAs-image.png)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/19XHXQfd2zApQpIO-image.png)
10. Copy the URL and paste in text editor (notepad).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/nXh8vWzcku4XLqYA-image.png)
**Example of a copied URL (the boxed section contains the authorization code).**
---
##### **Exchange authorization code for access token**
**Paste this Curl command into terminal.**
```bash
curl --request POST \
--url 'https://auth.atlassian.com/oauth/token' \
--header 'Content-Type: application/json' \
--data '{"grant_type": "authorization_code","client_id": "YOUR_CLIENT_ID","client_secret": "YOUR_CLIENT_SECRET","code": "YOUR_AUTHORIZATION_CODE","redirect_uri": "https://YOUR_APP_CALLBACK_URL"}'
```
Change all fields:
- `client_id`: (*required*) Set this to the **Client ID** for your app. Find this in **Settings** for your app in the [developer console](https://developer.atlassian.com/console/myapps/ "https://developer.atlassian.com/console/myapps/").
- `client_secret`: (*required*) Set this to the **Secret** for your app. Find this in **Settings** for your app in the [developer console](https://developer.atlassian.com/console/myapps/ "https://developer.atlassian.com/console/myapps/").
- `code`: (*required*) Set this to the authorization code received from the initial authorize call (described above).
- `redirect_uri`: (*required*) Set this to the callback URL configured for your app in the [developer console](https://developer.atlassian.com/console/myapps/ "https://developer.atlassian.com/console/myapps/").
**If successful, this call returns an access token similar to this:**
```json
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": ,
"expires_in": ,
"scope":
}
```
---
##### **Make calls to the API using the access token Get the `cloudid` for your site**
Your app now has an access token that it can use to authorize requests to the APIs for the Atlassian site. To make requests, do the following:
1. **Get the `cloudid` for your site.**
2. Construct the request URL using the `cloudid`.
3. Call the API, using the access token and request URL.
---
##### **Get the `cloud_id` for your site**
**Make a GET request to [https://api.atlassian.com/oauth/token/accessible-resources](https://api.atlassian.com/oauth/token/accessible-resources) passing the access token as a bearer token in the header of the request. For example:**
**Replace "ACCESS\_TOKEN" with your newly generated token.**
```bash
curl --request GET \
--url https://api.atlassian.com/oauth/token/accessible-resources \
--header 'Authorization: Bearer ACCESS_TOKEN' \
--header 'Accept: application/json'
```
This will retrieve the sites that have scopes granted by the token (see [Check site access for the app](https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/#siteaccess) below for details). Find your site in the response and copy the `id`. This is the `cloud_id` for your site.
**The wrapper script manages event collection, logging, and ensures only one instance runs at a time.**
1. **Create required directories for data, logs:**
**Create a directory named `confluence` (for this example):**
```
mkdir confluence
```
2. **Create the wrapper script file:** ```
sudo nano /usr/local/bin/confluence_audit.sh
```
3. **Add the following content to the file:
Replace the file path `FLAT_FILE` as well as `CLOUD_ID`, `USER_EMAIL`, and `API_KEY`, with their actual values.**
**Don't change "flattened.json" file name so that the script will work properly.**
```bash
Ask Cytech Support for the Source Code
```
4. **Make the script executable:** ```
sudo chmod +x /usr/local/bin/confluence_audit.sh
```
5. **Set ownership to the dedicated user**:
**Replace the "user:group" in this example both ``.**
```
sudo chown testing-confluence:testing-confluence /usr/local/bin/confluence_audit.sh
```
---
#### **Creating the Systemd Service File:**
**The systemd service ensures the event collection runs continuously and restarts automatically on failure.**
**1. Create the service file:
**
```
sudo nano /etc/systemd/system/confluence-audit.service
```
**2. Add the following content to the file:**
**Replace WorkingDirectory file path.**
```ini
Ask Cytech Support for the Source Code
```
---
#### **Create a Systemd Timer to handle looping and run automatically in the background:**
A systemd timer is a feature of systemd used to schedule tasks to run automatically at specific times or intervals.
**1. Create the timer file:**
```
sudo nano /etc/systemd/system/confluence-audit.timer
```
**2. Add the following content to the file:**
```ini
[Unit]
Description=Run Atlassian Confluence Audit every 10 minutes
[Timer]
OnBootSec=60
OnUnitActiveSec=600
Persistent=true
Unit=confluence-audit.service
[Install]
WantedBy=timers.target
```
---
#### **Configuring Log Rotation**To manage log file sizes and prevent disk space issues, configure log rotation for Atlassian Confluence Audit Logs.
##### **Step 1:** Create a logrotate configuration file:
```
sudo nano /etc/logrotate.d/confluence_audit
```
##### **Step 2:** Add the following configuration to the file:
**Replace `/home/your_user/` with your actual path, and update `user_owner` and `user_group` to match the correct user and group.**
```
/home/your_user/confluence/flattened.json {
daily
rotate 7
missingok
notifempty
copytruncate
compress
compressoptions -1
delaycompress
dateext
dateformat -%Y%m%d-%H%M%S
create 0640 user_owner user_group
}
```
---
#### **Enabling and Starting the Service**
**Step 1:** **Reload systemd to recognize the new service file:**
```
sudo systemctl daemon-reload
```
**Step 2: Enable the service to start automatically on boot:**
```
sudo systemctl enable --now confluence-audit.timer
```
**Step 3: Verify the service is running:**
```
sudo systemctl list-timers
```
**You should see something like this.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-04/EOvKLRBONp828xQT-image.png)
---
##### **Monitoring Live Logs:**
To view real-time logs from the confluence-audit service:
```
journalctl -u confluence-audit -f
```
---
**Please provide the following information to CyTech.**
- **Flattened.json file path example "/home/testing-confluence/confluence/flattened.json"**
---
***If you need further assistance, kindly contact our support at for prompt assistance and guidance.***
# Openssl installation in windows 11
### **What is openssl?**OpenSSL is a widely used open-source software library designed to provide secure communication over computer networks through encryption and cryptographic techniques. It implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, which help protect sensitive information exchanged between clients and servers. In addition to enabling secure connections, OpenSSL offers a variety of cryptographic functions, including data encryption, decryption, digital signatures, and certificate management. Due to its reliability, flexibility, and broad platform support, OpenSSL has become an essential component in many web servers, applications, and operating systems worldwide.
---
#### **Installing OpenSSL in your Log Collector**Download the Installer: 1. Go to the [Shining Light Productions](https://slproweb.com/products/Win32OpenSSL.html "openssl") page and download the "Win64 OpenSSL Light" EXE installer (current version 3.x is recommended).
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/KxP2x19Yn5sgxsWh-image.png)
2. Run the Installer: Execute the downloaded file and follow the on-screen instructions.3. Installation Path: It is generally recommended to install in the default location, typically C:\\Program Files\\OpenSSL-Win64.4. Configure System Environment Variable:Search for "Environment Variables" in the Windows search bar.Click "Edit the system environment variables".Click "Environment Variables".Under "System Variables", find and select Path, then click "Edit".
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/34wik5flOCWndiw8-image.png)
Click "Edit" and add the path to the bin folder, for example: C:\\Program Files\\OpenSSL-Win64\\bin.Click OK on all windows to save.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/b2StLkSFXyH6waz5-image.png)
**Restart the Machine to take effect the configuration.**
---
*If you need further assistance, kindly contact our support at [**support@cytechint.com**](mailto:support@cytechint.com) for prompt assistance and guidance.*
# AQUILA - SalesForce Integration (Username-Password Flow)
In Salesforce, the **Username-Password Flow** is an OAuth 2.0 authentication flow where an application obtains an access token by directly sending a Salesforce username, password, and (usually) security token to Salesforce.\\
##### Important note
The Username-Password Flow is increasingly discouraged for new Salesforce integrations because it requires handling user credentials directly. For most modern integrations, the **JWT Bearer Flow** or **Client Credentials Flow** is usually preferred due to better security and easier compliance with MFA requirements.
##### How it works
The client application sends a request to Salesforce's OAuth token endpoint with:
- `grant_type=password`
- Salesforce username
- Salesforce password
- Security token (often appended to the password)
- Connected App client ID
- Connected App client secret
Salesforce validates the credentials and returns an access token if authentication succeeds.
---
Log in to your Salesforce Organization.
Note: If the salesforce dashboard interface is in classic mode change it to lighting mode.
- **In the Upper Right Corner click the gear icon.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-02/Kyqkx6MxXwwySPOm-image.png)
- **Select setup.**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/W418IIogPqHkBJyB-image.png)
To find the base URL and instance URL follow the guide below.
- In quick find box, enter my domain then select my domain under Company Settings.
- Under My Domain Details copy Current My Domain URL that's your base URL and Instance URL. (Give it to Cytech Support)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/m7aiSY2jALXJCs7S-image.png)
#### **Creating User**
- In Setup, enter Users in the Quick Find box, then select **Users**.
- Click **New User**.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/MILGpKWiOlMAsQSh-image.png)
- Fill out the form, and assign the System Administrator.
- Role > None Specified
- User License > Salesforce
- Profile > System Administrator
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/mkrP09959VmcLFYj-image.png)
- Click **Save**.
---
##### **Enable Allow Access to External Client App Consumer Secret via REST API**
**External Client App Setting > Allow Access to External Client App Consumer Secret via REST API**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/W4Jt6m6fQpESM3SS-image.png)
##### **Enable Event log files**
**Event Monitoring Settings > Generate event log files**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-05/u83m9Xo4Q4t80Gbm-image.png)
---
##### **Create A Connected Apps**
For security reasons, Salesforce blocks the OAuth 2.0 Username-Password flow by default in recent releases. Prefer the JWT bearer flow. If you must use the Username-Password flow, in `OAuth and OpenID Connect Settings`, select `Allow OAuth Username-Password Flows`. For more information, see the Salesforce release note: [Username-Password OAuth flow blocked by default.](https://help.salesforce.com/s/articleView?id=release-notes.rn_security_username-password_flow_blocked_by_default.htm&language=en_US&release=244&type=5)
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/VXD6iKeRCEk6htq7-image.png)
- Log in to Salesforce (Lightning UI).
- From `Setup`, in `Quick Find` enter `External Client Apps` and select `Settings`. Turn on `Allow creation of connected apps`. To create a connected app, select `New Connected App`.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/k1o1tW0E5LEV58Zy-image.png)
- Fill `Basic Information`: `Connected App Name`, `API Name`, `Contact Email`.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/IsDNcjY9IF5H6689-image.png)
- In `API (Enable OAuth Settings)`, check `Enable OAuth Settings`.
- `Callback URL`:
- Web apps: your app callback (for example, `https://yourapp.example.com/callback`).
- Not used by the JWT or Username-Password flows, but Salesforce requires a value; you can enter your instance URL.
- Select OAuth scopes:
- `Manage user data via APIs (api)`
- `Perform requests at any time (refresh_token, offline_access)`
- `Full access (full)`
- Enable Client Credentials Flow
- Enable Refresh Token Rotation
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/xYB3Idafcolwvx4x-image.png)
- Click `Save`. It can take up to 10 minutes for the Connected App to propagate.
- After saving, open `Manage Consumer Details` to obtain `Consumer Key` and `Consumer Secret`.
Manage Consumer Details Appears only once so better to copy consumer key and consumer secret in a safe place.
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/Vg0C8iMXaXIy0LRF-image.png)
- Then Click Manage to OAuth Policies
- Permitted Users > All users may self-authorize
- IP Relaxation > Relax IP Restrictions
- Refresh Token Policy > Expire refresh token after "365" days
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/zRwgrFo6TSrG2YvC-image.png)
---
##### **Verify if LoginEvent is enable
in Quick find > Event Manager > enable all**
[](https://cytechint-docs-bookstack.s3.amazonaws.com/uploads/images/gallery/2026-06/c3FO4fC2t5KzJ44w-image.png)
---
##### Provide this to Cytech Support:
- **Username**
- **Password**
- **Consumer Key**
- **Consumer Secret**
- **Instance URL**
---
***If you need further assistance, kindly contact our support at for prompt assistance and guidance.***
# How to Upload Certificate in Salesforce
#### **Steps to Upload Certificate:**
1. Log in to Salesforce and navigate to **Setup**.
2. In the Quick Find box, type **External Client App Manager** and select it from the results.
