Agent-less Integration

Integrate AQUILA seamlessly across your infrastructure without installing local agents. Using secure network connections and APIs, AQUILA collects data, monitors activity, and delivers real-time insights with minimal system impact. Simplify deployment, reduce maintenance, and gain complete visibility with AQUILA’s efficient agentless integration approach.

NG SIEM - 1Password Integration

1Password Events Reporting Integration Manual

With 1Password Business, you can forward account activity to your SIEM system using the 1Password Events API. 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:


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:

These logs help monitor account access patterns and detect unauthorized access attempts.


If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - Abusech Integration

This integration is designed to collect and process AbuseCH threat intelligence logs. It retrieves indicators from multiple AbuseCH APIs and makes them available for security monitoring and analysis.

Supported Datasets

The integration provides the following datasets:

URL Logs

The AbuseCH URL data stream fetches threat intelligence indicators from the following API endpoint:

https://urlhaus-api.abuse.ch/v1/urls/recent/

This stream provides details on recently observed malicious URLs that can be used for detection, correlation, and blocking in security systems.

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - Atlassian Confluence 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 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.


 

Creating an API Token with Scopes

Follow these steps to create a token. Note: As of March 13, 2025, tokens created before December 15, 2024, will expire between March 14 and May 12, 2026. New tokens default to 1-year expiration (adjustable from 1 to 365 days).

  1. Log in to 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").
  4. Choose an expiration date for the token (between 1 and 365 days; consider shorter for security).
  5. Select the application (Jira or Confluence). Important: Create separate tokens for Jira and Confluence—tokens are app-specific and cannot access both.
  6. Select the scopes or permissions the token should have:
    • For Jira (audit logs): read:audit-log:jira (allows viewing audit events).
    • For Confluence (audit logs): read:audit-log:confluence (allows viewing audit events; add write:audit-log:confluence if needed for custom logging, but not required for AQUILA).
  7. Click "Create".
  8. 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.

 

Required Atlassian-Side Permissions

The user account tied to the email (Jira/Confluence User Identifier) must have admin-level access to fetch audit logs via API:

Without these, the API may authenticate successfully (leading to a "healthy" status in AQUILA) but return no data or errors like 403 Forbidden. If you lack access to the client side, request they verify/add these permissions via admin.atlassian.com > Global Permissions.

Additionally, ensure audit logging is enabled and set to "Full" coverage on the Atlassian side (via their admin settings) to generate events. Low activity instances may produce sparse logs.

Note: If you're on a Free plan without org access, you can't enable advanced features—consider upgrading or using site-level logs in individual apps.

Required Credentials for Integration Access (AQUILA Setup)

Use these in AQUILA > Integrations > Atlassian Jira/Confluence setup (separate integrations for each). For Atlassian Cloud, authentication uses Basic Auth (email + token).

For self-hosted (Data Center/Server) instances, a Personal Access Token may be used instead, but Cloud setups prefer the API token.

Please provide the following information to CyTech

NG SIEM - (Plain Scope) Atlassian Confluence Integration

What is API Token?

A secure string used to authenticate external applications or scripts so they can access Confluence’s REST APIs without needing a user password. Its main use is to allow programmatic access for integrations, automation, or tools to interact with Confluence content.


Creating an API Token

Follow these steps to create a token. Note: As of March 13, 2025, tokens created before December 15, 2024, will expire between March 14 and May 12, 2026. New tokens default to 1-year expiration (adjustable from 1 to 365 days).

  1. Log in to https://id.atlassian.com/manage-profile/security/api-tokens.
  2. Select "Create API token".
  3. Enter a descriptive name for the token (e.g., "AQUILA- Audit Logs Monitoring").
  4. Choose an expiration date for the token (between 1 and 365 days; consider shorter for security).
  5. Click "Create".
  6. 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.

Required Atlassian-Side Permissions

The user account tied to the email (Jira/Confluence User Identifier) must have admin-level access to fetch audit logs via API:

image.png


image.png

image.png

image.png

Without this, the API may authenticate successfully (leading to a "healthy" status in AQUILA) but return no data or errors like 403 Forbidden. If you lack access to the client side, request they verify/add these permissions via admin.atlassian.com > Global Permissions.

Note: If you're on a Free plan without org access, you can't enable advanced features—consider upgrading or using site-level logs in individual apps.

Required Credentials for Integration Access (AQUILA Setup)

Use these in AQUILA > Integrations > Atlassian Jira/Confluence setup (separate integrations for each). For Atlassian Cloud, authentication uses Basic Auth (email + token).

For self-hosted (Data Center/Server) instances, a Personal Access Token may be used instead, but Cloud setups prefer the API token.

Please provide the following information to CyTech

NG SIEM - Atlassian Jira 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 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.


 

Creating an API Token with Scopes

Follow these steps to create a token. Note: As of March 13, 2025, tokens created before December 15, 2024, will expire between March 14 and May 12, 2026. New tokens default to 1-year expiration (adjustable from 1 to 365 days).

  1. Log in to 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").
  4. Choose an expiration date for the token (between 1 and 365 days; consider shorter for security).
  5. Select the application (Jira or Confluence). Important: Create separate tokens for Jira and Confluence—tokens are app-specific and cannot access both.
  6. Select the scopes or permissions the token should have:
    • For Jira (audit logs): read:audit-log:jira (allows viewing audit events).
    • For Confluence (audit logs): read:audit-log:confluence (allows viewing audit events; add write:audit-log:confluence if needed for custom logging, but not required for AQUILA).
  7. Click "Create".
  8. 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.

 

Required Atlassian-Side Permissions

The user account tied to the email (Jira/Confluence User Identifier) must have admin-level access to fetch audit logs via API:

Without these, the API may authenticate successfully (leading to a "healthy" status in AQUILA) but return no data or errors like 403 Forbidden. If you lack access to the client side, request they verify/add these permissions via admin.atlassian.com > Global Permissions.

Additionally, ensure audit logging is enabled and set to "Full" coverage on the Atlassian side (via their admin settings) to generate events. Low activity instances may produce sparse logs. 

Note: If you're on a Free plan without org access, you can't enable advanced features—consider upgrading or using site-level logs in individual apps.

Required Credentials for Integration Access (AQUILA Setup)

Use these in AQUILA > Integrations > Atlassian Jira/Confluence setup (separate integrations for each). For Atlassian Cloud, authentication uses Basic Auth (email + token).

For self-hosted (Data Center/Server) instances, a Personal Access Token may be used instead, but Cloud setups prefer the API token.

Please provide the following information to CyTech

NG SIEM - 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:

{
	"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.

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 support@cytechint.com for prompt assistance and guidance.

NG SIEM - Azure CSPM 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

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 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.
  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.

Please saved and provide this values to AQUILA Support Team.

  1. Directory (tenant) ID
  2. Application (client) ID
  3. Client Secret Value:

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - Azure Logs Integration

The Azure Logs integration enables you to collect logs from specific Azure services such as:

Example Use Cases


Data Streams

The Azure Logs integration collects log data streams from the following sources:

Logs 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.


If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - 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:


Compatibility


Cisco Meraki Dashboard Configuration

Syslog Setup:
Configure one or more syslog servers and specify Meraki message types to send to those servers. For details, refer to the Syslog Server Overview and Configuration guide.

API Endpoint (Webhooks):
Configure Meraki webhooks from the dashboard. See the Webhooks Dashboard Setup for detailed instructions.


Configuring the Cisco Meraki Integration

Syslog Collection:

API Webhooks Collection:


Log Events

Enable this option to collect Cisco Meraki log events across all applications configured for the selected log stream.


Logs Dataset

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - 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:

Assumptions

The procedures described in this guide assume that a Log Collector has already been set up.

Prerequisites

Requirements

This integration supports log ingestion from Cisco Umbrella. Data is collected from:

Supported Dataset

Umbrella Logs

When using Cisco-managed S3 buckets without SQS:

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):

 Before sending requests to the Umbrella API, create Umbrella API credentials and generate an access token.
More details: Cisco Umbrella API Authentication


Authentication

Steps:

  1. Log in to Umbrella at: 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:

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - 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

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

Secure Endpoint API Capabilities

The Secure Endpoint API can be used to retrieve and manage detailed information, including:


Top Use Cases

API Response Format

The Secure Endpoint API provides responses in three key objects:


To enable log collection from the Cisco Secure Endpoint API, provide the following information to CyTech Support:

 

 

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - 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 and Auth Key(Depreciated)

  2. API Token

For detailed information on authentication, refer to the Cloudflare API documentation.


1. Configure Using Auth Email and Auth Key

To set up using this method, you need:

These credentials must be included in the request headers:

For more details, refer to Cloudflare’s authentication headers guide.


2. Configure Using API Token

To set up using an API token, you need:

Minimum Required Permissions for the API Token:

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

image.png

image.png

image.png

curl -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json"

image.png


Audit Logs

Audit logs provide a record of configuration changes within your Cloudflare account, including:

These 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:

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - CrowdStrike Integration

CrowdStrike Integration

The CrowdStrike Falcon integration allows you to easily connect your CrowdStrike Falcon platform to Elastic for seamless onboarding of alerts and telemetry from CrowdStrike Falcon and Falcon Data Replicator. Elastic Security can leverage this data for security analytics including correlation, visualization and incident response

Requirements 

API - Steps to Get Client ID and Client Secret in CrowdStrike Falcon (Recomended)

  1. Log in to the Falcon Console

  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.).

  4. Click Save
  5. 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).

  6. Token URL

Collect CrowdStrike Falcon Data Data Replicator Logs (input: aws-s3)

  1. Go to: https://falcon.crowdstrike.com

  2. Log in with your CrowdStrike account

  3. In the left menu, click Support & Resources → Falcon Data Replicator (or directly FDR Access)

  4. You will immediately see a section called AWS-S3 (Option 1) with the three fields already filled in for your customer account:

    • AWS: Access Key ID → copy this
    • AWS: Secret Access Key → copy this (it’s shown only here; you can’t retrieve it again)
    • AWS: Queue URL → copy this exact SQS URL

Please provide the following information to CyTech: 

Collect CrowdStrike Falcon Data Replicator Logs (input: aws-s3)

API - Steps to Get Client ID and Client Secret in CrowdStrike Falcon

NG SIEM - GCP CSPM Integration

The Google Cloud integration collects and parses Google Cloud Audit Logs, VPC Flow Logs, Firewall Rules Logs, and Cloud DNS Logs that have been exported from Cloud Logging to a Google Pub/Subtopic sink and collects Google Cloud metrics and metadata from Google Cloud Monitoring.

Logs

Metrics


Authentication

To use the Google Cloud Platform (GCP) integration, the client must configure a Service Account (SA) that represents a non-human identity requiring access to GCP resources.

Service Account

First, you need to create a Service Account. 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.

IAM Service Account Roles

For CSPM-GCP Integration

Logs Collection Configuration

The Logs Collection Configuration defines how log data is exported, transmitted, and processed within the system. It enables seamless integration between Cloud Logging and other Google Cloud services to ensure logs are efficiently collected, stored, and made available for analysis or monitoring.

Requirements

It’s recommended to 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. 

 


 

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"

Enable API Service

The client can enable their API through the APIs & Services section. To access it, click the ☰ (navigation menu) icon to open the sidebar, then hover over APIs & Services and select Enabled APIs & Services. Alternatively, the client can locate it using the search bar at the top of the page. Next, click Library, search for the required API services, and enable them.


 

Service Account Key

  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:

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance. 

NG SIEM - GCP Integration

Google Cloud Platform (GCP) is Google’s suite of cloud computing services that lets businesses and developers build, deploy, and scale applications on Google’s infrastructure. It offers a wide range of services, including computing power (like virtual machines and Kubernetes), storage, databases, machine learning, networking, and analytics. GCP is known for its global reliability, security, and integration with Google’s data and AI tools, making it suitable for everything from simple websites to complex enterprise applications.


Authentication

To use the Google Cloud Platform (GCP) integration, the client must configure a Service Account (SA) that represents a non-human identity requiring access to GCP resources.


Service Account

First, you need to create a Service Account. 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.


IAM Service Account Roles

For GCP Integration

 

NG SIEM - 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.


Option 1: GitHub Audit Logs

Description:
Audit logs contain records of all administrative and security events within a GitHub organization.

Requirements

What It Does

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

What It Does

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

What It Does

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

What It Does

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

What It Does

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 Yes Yes repo, security_events, public_repo Yes Yes
Issues & PRs Yes Yes repo, public_repo, read:org Yes Yes

Documentation References

If you need further assistance, kindly contact our support at support@cytechint.com for prompt assistance and guidance.

NG SIEM - GoogleWorkspace Integration

Introduction

The Google Workspace integration collects and parses data from various Google Workspace audit reports APIs using a service account authorized via the Admin SDK API.

Requirements

To ingest data from the Google Reports API, the following must be completed:

Note this is only applicable for Administrator Account in Google Workspace. Thank you and have a nice day.


Enable Admin SDK API

Complete the following steps:

Configure OAuth Consent Screen

Complete the following steps:


Create a Service Account

To create a service account, do the following:


Enable Domain-wide Delegation

Please provide the following information to CyTech Support. Thank you

   Reference link: 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. 

NG SIEM - Microsoft 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.


Requirements

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:


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.
  • 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. 


Step 3: Integration Requirements for Office 366

Application (Client) ID: 

  • 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. 

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). 


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:

  1. Access the Security & Compliance Center:

  1. Navigate to Audit Log Search:

    • In the Security & Compliance Center, go to Search in the left-hand menu and click on Audit log search. 

  1. Check Audit Log Status:

    • If you see an option to search the audit log, then audit logging is already enabled.

    • 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. 
  1. 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. 

Please provide the following information to CyTech: 

NG SIEM - Mimecast Integration

Introduction

The Mimecast integration collects events from the Mimecast API.

Agentless integrations allow you to collect data without having to manage Elastic Agent in your cloud. They make manual agent deployment unnecessary, so you can focus on your data instead of the agent that collects it. For more information, refer to Agentless integrations and the Agentless integrations FAQ. Agentless deployments are only supported in Elastic Serverless and Elastic Cloud environments. This functionality is in beta and is subject to change. Beta features are not subject to the support SLA of official GA features.

Requirements

Creating an API 2.0 Application:

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.

Mimecast recommends a group rather than an individual contact.


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:

Please provide the following information to CyTech Support. Thank you

If you need further assistance, kindly contact our support at support@cytechint.com for prompt assistance and guidance.

NG SIEM - Salesforce Integration via JWT Authentication

Introduction

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.


Recommendation - Username / Password Authentication Integration

Create New User Account

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.

Salesforce instance URL

This is the URL of your Salesforce Organization.

Ensure the Instance URL is noted, as it will be used in both API creation and integration steps.


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:

Username

Password

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


Token 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.



API Version

To find the API version:

Reference: https://www.integrate.io/blog/salesforce-rest-api-integration/

Please provide these credentials and send it to CyTech Support:


Recommendation - JWT Integration

This guide provides a step-by-step process for setting up a secure integration between Salesforce and AQUILA. The focus is on using JWT (JSON Web Token) Bearer authentication, which is recommended for server-to-server communication as it avoids sharing passwords. We'll cover preparing Salesforce (where you generate and upload required credentials) and entering those into AQUILA configuration fields.

Prerequisites



Create a Connected App in Salesforce

This app generates the Client ID and links your certificate for JWT trust.

  1. Log in to Salesforce > Click the gear icon > Setup.
  2. Search for Setup > External Client Apps> Enable and click button New Connected Apps.
  3. Fill in:
    • Connected App Name: e.g., "AQUILA JWT Integration".
    • API Name: Auto-fills (edit if needed).
    • Contact Email: Your integration user's email.
  4. Under API (Enable OAuth Settings):
    • Check Enable OAuth Settings.
    • Callback URL: Enter http://localhost (placeholder; not used in JWT).
    • Selected OAuth Scopes: Add api, refresh_token, offline_access. (Optional: Add full for broader access if needed.)
    • Check Use digital signatures > Upload salesforce_cert.crt.
  5. Do not check any "Require Secret" options (no secret needed for JWT).
  6. Click Save (wait 2-10 minutes for activation).
  7. On the app page, copy the Consumer Key—this is your Client ID.
  8. Click Manage > Edit Policies > Set Permitted Users to "Admin approved users are pre-authorized".
  9. Assign the app to your integration user: Under Profiles or Permission Sets, add your user's profile.

Now Salesforce is ready—note your Instance URL (e.g., from your Salesforce homepage: https://your-instance.my.salesforce.com).

References:
OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration
OAuth Authorization Flows
Salesforce input | Beats
Salesforce Connector - How to authenticate using JWT

Please provide these credentials and send it to CyTech Support:

Summary Table
Field Username–Password JWT
Client ID ✔ required ✔ required
Client Secret ✔ required ❌ not used
Username ✔ required ✔ required
Password ✔ required ❌ not used
Private Key Path ❌ ✔ required
Audience URL ❌ ✔ required
Token URL ✔ required ❌ leave blank
API Version optional optional

If you need further assistance, kindly contact our support at support@cytechint.com for prompt assistance and guidance.

NG SIEM - Sophos Central Integration

Sophos Central Integration

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.

 

Step-by-Step: How to Get Your Sophos Central API Credentials (Client ID, Client Secret, Tenant ID, Request URL)
    1. Log in to Sophos Central Admin Open your browser and go to: https://central.sophos.com Log in with your admin account.

    2. Go to API Credentials Manager On the left sidebar, click Global Settings (gear icon at the bottom). Then click API Credentials Manager.

    3. Create a new credential Click the blue button + Add Credential (top right).

    4. Fill in the details

      • Name: Give it a clear name (e.g., “PowerShell Automation”, “SIEM Integration”, “My Script 2025”)
      • Role: Choose the role that matches what you need (usually “Admin” or “Read-Only” is fine)
      • Click Save (or Add)
    5. Copy the four pieces of information immediately A new window/pop-up will appear showing:



      What you need Value shown in the portal Action
      Client ID Long string (e.g., 12345678-abcd-1234-efgh-1234567890ab) Copy it
      Client Secret Long secret key COPY THIS NOW – it will never be shown again!
      Tenant ID (Customer ID) GUID like a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 Copy it
      Request URL Use the Whoami endpoint first: Always use this URL first:
        https://api.central.sophos.com/whoami/v1  

      → Click Copy buttons or select + Ctrl+C for each field. → Paste everything into a secure password manager or your script immediately.

    6. Close the window Once you’ve copied everything, click Done or close the pop-up.

 

Please provide the following information to CyTech: 

 

NG SIEM- AWS CSPM Integration

Introduction

CSPM discovers and evaluates the services in your cloud environment, like storage, compute, IAM, and more, against hardening guidelines defined by the Center for Internet Security (CIS) to help you identify and remediate configurations risks like:

Recommendation

Set up cloud account access

The CSPM integration requires access to AWS’s built-in SecurityAudit IAM policy in order to discover and evaluate resources in your cloud account. To provide access we need:

Create IAM User

Follow AWS’s IAM roles for Amazon EC2 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.

     

  3. 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.

    For more details, refer to Access Keys and Secret Access Keys.

    • 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: 

NG SIEM – LastPass Integration

Overview

The LastPass Elastic Integration allows the ingestion of data from the LastPass Admin Console for enhanced monitoring and reporting.

This integration collects three main data streams:

These logs help monitor password management activities, access permissions, and user behavior for compliance and auditing purposes.

Prerequisites

Before configuring the integration, ensure that the following components and credentials are available.

LastPass Business Account

A LastPass Business account is required to use this integration.
Free or personal accounts are not supported.

Elastic Stack Requirements
API Credentials

Two key credentials are required for Elastic to access the LastPass API:

  1. Account Number (CID)
    • Found in the Admin Console → Dashboard tab.
    • Displayed at the top of the page, preceded by the label “Account Number”.image.png
  2. Provisioning Hash
    • Go to Admin Console → Advanced → Enterprise API.
    • If no hash exists: click Create provisioning hash → OK.
    • If forgotten: click Reset your provisioning hash → OK to generate a new one.
    • Important: Resetting invalidates the previous hash, requiring reconfiguration in all connected integrations.

      image.png

Keep both the CID and Provisioning Hash secure. These credentials grant access to your organization’s LastPass data.

Integration Configuration

1. Access the Integrations Page
  1. Navigate to:
    Integrations → LastPass → Add LastPass
  2. Provide an identifiable integration name.
2. Input Connection Settings

Under Configure integration, fill in the required fields:

3. Select Data Streams

Enable the data streams you want to collect. It can be enabled or disable specific data streams based on visibility needs:

4. Save and Deploy

Once all required fields are configured:

  1. Click Save and continue
  2. Assign the integration to your Elastic Agent policy
  3. Confirm deployment
Notes

If you need further assistance, kindly contact support@cytechint.com for prompt assistance and guidance.

NG SIEM - Apache Tomcat

NG SIEM - Microsoft Defender ATP Logs

Prerequisite

Before starting, ensure you have the following ready:

Item

Details

OS

Windows 10 / Windows Server 2016 or later

Privileges

Local Administrator access on the machine

Network

Outbound HTTPS (port 443) to our Elastic endpoint

Step 1. Connect local Kibana to a Cloud instance

If you are running this Kibana instance against a hosted Elasticsearch instance, proceed with manual setup.

Save the Elasticsearch endpoint as <es_url> and the cluster Password as <password> for your records

Step 2. Download and install Filebeat

First time using Filebeat? See the Quick Start.

  1. Download the Filebeat Windows zip file from the Download page.
  2. Extract the contents of the zip file into C:\Program Files.
  3. Rename the filebeat-9.2.0-windows directory to Filebeat.
  4. Open a PowerShell prompt as an Administrator (right-click the PowerShell icon and select Run As Administrator). If you are running Windows XP, you might need to download and install PowerShell.
  5. From the PowerShell prompt, run the following commands to install Filebeat as a Windows service.
cd "C:\Program Files\Filebeat"
.\install-service-filebeat.ps1

Modify the settings under output.elasticsearch in the C:\Program Files\Filebeat\filebeat.yml file to point to your Elasticsearch installation.

Step 3. Edit the configuration

Modify C:\Program Files\Filebeat\filebeat.yml to set the connection information:

output.elasticsearch:
  hosts: ["<es_url>"]
  username: "elastic"
  password: "<password>"
  # If using Elasticsearch's default certificate
  ssl.ca_trusted_fingerprint: "<es cert fingerprint>"
setup.kibana:
  host: "<kibana_url>"

Where <password> is the password of the elastic user, <es_url> is the URL of Elasticsearch, and <kibana_url> is the URL of Kibana. To configure SSL with the default certificate generated by Elasticsearch, add its fingerprint in <es cert fingerprint>.

Important: Do not use the built-in elastic user to secure clients in a production environment. Instead set up authorized users or API keys, and do not expose passwords in configuration files. Learn more.

Step 4. Enable and configure the microsoft module

From the C:\Program Files\Filebeat folder, run:

Modify the settings in the modules.d/microsoft.yml file. You must enable at least one fileset.

filebeat.exe modules enable microsoft
Step 5. Start Filebeat

The setup command loads the Kibana dashboards. If the dashboards are already set up, omit this command.

.\filebeat.exe setup
Start-Service filebeat
Step 6. Module status

We will check that data is received from the Filebeat microsoft module

Modules

These are the modules that will be ingested after integrating Microsoft Defender ATP Logs


microsoft.defender_atp : Module for ingesting Microsoft Defender ATP.
microsoft.defender_atp.lastUpdateTime:  The date and time (in UTC) the alert was last updated. (type: date)
microsoft.defender_atp.resolvedTime: The date and time in which the status of the alert was changed to 'Resolved'. (type: date)
microsoft.defender_atp.incidentId: The Incident ID of the Alert. (type: keyword)
microsoft.defender_atp.investigationId: The Investigation ID related to the Alert. (type: keyword)
microsoft.defender_atp.investigationState: The current state of the Investigation. (type: keyword)
microsoft.defender_atp.assignedTo: Owner of the alert. (type: keyword)
microsoft.defender_atp.status: Specifies the current status of the alert. Possible values are: 'Unknown', 'New', 'InProgress' and 'Resolved'. (type: keyword)
microsoft.defender_atp.classification: Specification of the alert. Possible values are: 'Unknown', 'FalsePositive', 'TruePositive'. (type: keyword)
microsoft.defender_atp.determination: Specifies the determination of the alert. Possible values are: 'NotAvailable', 'Apt', 'Malware', 'SecurityPersonnel', 'SecurityTesting', 'UnwantedSoftware', 'Other'. (type: keyword)
microsoft.defender_atp.threatFamilyName: Threat family. (type: keyword)
microsoft.defender_atp.rbacGroupName: User group related to the alert (type: keyword)
microsoft.defender_atp.evidence.domainName: Domain name related to the alert (type: keyword)

That's everything needed on your end. Once the Filebeat service is running, logs will automatically begin forwarding to our Elastic instance in real time — no ongoing maintenance is required on your side. If the service ever stops for any reason (e.g. after a Windows update or restart), it will resume automatically as it is installed as a Windows service. If you run into any issues during setup, just reach out and we'll walk you through it.

NG SIEM - Microsoft Defender for Cloud

Overview

The Microsoft Defender for Cloud(external, opens in a new tab or window) integration allows you to monitor security alert events and assessments. When integrated with Elastic Security, this valuable data can be leveraged within Elastic for analyzing the resources and services that users are protecting through Microsoft Defender.

Use the Microsoft Defender for Cloud integration to collect and parse data from Azure Event Hub, Azure REST API, and then visualize that data in Kibana.

Compatibility

The Microsoft Defender for Cloud integration uses the Azure REST API. It uses the 2021-06-01 API version for retrieving assessments and the 2019-01-01-preview API version for retrieving sub-assessments.

How it works

For the assessment data stream, the /assessments endpoint retrieves all available assessments for the provided scope, which can be a Subscription ID or a Management Group Name. For each assessment, if sub-assessments are available, we will make another call to collect them. We will aggregate the results from both calls and publish them.

What data does this integration collect?

This integration collects log messages of the following types:

Requirements

Collect logs from Azure Event Hub
Collect Microsoft Defender Cloud logs via API

Conclusion

Integrating Microsoft Defender for Cloud with Elastic Security provides a powerful way to centralize and analyze your cloud security posture. By leveraging Azure Event Hub for real-time security event streaming and the Azure REST API for assessment data, you gain comprehensive visibility into the threats and vulnerabilities affecting your Azure resources — all within Kibana.

With the Event data stream capturing live security alerts and the Assessment data stream continuously evaluating your scanned resources at both the assessment and sub-assessment level, your team can detect, investigate, and respond to risks more efficiently.

To get the most out of this integration, ensure your Azure environment is properly configured with dedicated Event Hub instances, isolated consumer groups, and the appropriate API credentials (Client ID, Client Secret, and Tenant ID). Choosing the right scope — whether a Subscription ID or Management Group Name — will also determine the breadth of coverage across your organization's Azure resources.

Once set up, this integration serves as a foundational component of a broader cloud security monitoring strategy, enabling your security operations team to act on meaningful, contextualized data rather than navigating siloed tools.

AQUILA - Microsoft Defender for Endpoint

Overview

This guide walks through the full process of integrating Microsoft Defender for Endpoint (MDE) to centralize security telemetry, enrich alerts, and enable unified threat hunting across your environment.

This integration is for Microsoft Defender for Endpoint logs.

Microsoft Defender for Endpoint integration collects data for Alert, Machine, Machine Action, and Vulnerability logs using REST API.

This integration collects the following logs:

Prerequisites

Before you begin, ensure the following are in place:

Azure App Registration

This integration authenticates to the MDE API using OAuth 2.0 client credentials. You need to register an application in Microsoft Entra ID and grant it the appropriate API permissions.

Step 1: Register a New Application

Step 2: Create a Client Secret

Step 3: 

Permission

Purpose

Alert.Read.All

Read all MDE alerts and incidents

Machine.Read.All

Read device inventory and health state

Vulnerability.Read.All

Read vulnerability and software inventory

AdvancedQuery.Read.All

Execute advanced hunting queries (optional)

Step 4: 

Please saved and provide this values:

  1. Directory (tenant) ID
  2. Application (client) ID
  3. Client Secret Value

If you need further assistance, kindly contact our support at support@cytechint.com for prompt assistance and guidance.

NG SIEM - Microsoft Defender XDR

Overview

This guide covers the full integration of Microsoft Defender XDR with the Elastic Stack. Microsoft Defender XDR is a unified extended detection and response platform that correlates signals across endpoints, identities, email, cloud apps, and cloud workloads. Bringing its data into Elastic enables centralized threat hunting, cross-platform correlation, and unified SIEM workflows alongside your other log sources.

Prerequisites

Microsoft Requirements

Azure App Registration

The Elastic Agent authenticates to the Microsoft Graph Security API using OAuth 2.0 client credentials. If you do not already have an app registration, follow the steps below.

Step 1: Register the Application

Step 2: Create a Client Secret

Important Secret Visibility:  Azure only displays the secret value immediately after creation. If the page is refreshed or the value was not saved, you will need to generate a new secret. If you regenerate, remember to update the secret in all Elastic integrations that reference this app registration to avoid breaking existing data pipelines.

Step 3: Grant API Permissions

Elastic Fleet Configuration

With the Azure application registered, the next step is to configure Elastic Fleet to deploy the MDE integration.

Conclusion

Integrating Microsoft Defender XDR with Elastic unlocks a truly unified security operations experience, bringing together telemetry from endpoints, identities, email, cloud apps, and cloud workloads into a single platform for detection, investigation, and response. By connecting the Microsoft Graph Security API to Elastic's SIEM and search capabilities, security teams gain correlated, cross-workload visibility that goes far beyond what any single Defender product can offer on its own. Whether you're leveraging prebuilt detection rules, building custom threat hunting queries, or streaming real-time events via the XDR Streaming API, this integration gives your SOC the context and speed needed to tackle modern multi-stage attacks — all from one place.

 

NG SIEM Microsoft Entra ID

Overview

This guide walks you through connecting Microsoft Entra ID to Elastic so that your identity logs flow automatically into Elasticsearch. Once set up, you'll be able to search, visualize, and alert on Sign-in logs, Audit logs, and Identity Protection logs directly in Kibana.

The integration uses Azure Event Hub as the bridge — Entra ID pushes logs into Event Hub, and the Elastic Agent reads from it in real time. A Storage Account is used behind the scenes to checkpoint progress, so Elastic always picks up exactly where it left off.

Prerequisite

Before you begin, ensure the following are in place:

Part 1 — Set Up Azure Resources

In this part you will create the Event Hub and Storage Account in Azure. These are the two Azure-side components that Elastic connects to.

Step 1.1 Create an Event Hub Namespace and Hub

The Event Hub is the channel that Entra ID will push logs into.

Step 1.2 Create a Consumer Group

A consumer group is a named reader slot on the Event Hub. Elastic needs its own so it does not conflict with any other tools reading from the same hub.

Step 1.3 Copy the Connection String

The connection string is how Elastic authenticates to your Event Hub Namespace.

Step 1.4 Create a Storage Account

Elastic uses a Storage Account to checkpoint which events it has already read. This prevents duplicate ingestion if the agent restarts.

Keep your Storage Account Key secure. Anyone with this key has full access to the storage account. You can rotate it later from the Access Keys page without breaking the integration — just update the key in Elastic too.

Part 2 — Configure Entra ID Diagnostic Settings

Now you will tell Entra ID which log categories to send and point them at the Event Hub you just created.

SignInLogs

Free

All interactive user sign-ins, MFA results, Conditional Access outcomes

AuditLogs

Free

Directory changes — user creation, group changes, role assignments

NonInteractiveUserSignInLogs

Free

Service and application sign-ins without user interaction

UserRiskEvents

P2 only

Identity Protection risky sign-in detections

RiskyUsers

P2 only

Users flagged as at-risk by Identity Protection

Changes to Diagnostic Settings take effect immediately, but it can take 5–15 minutes before the first events begin appearing in the Event Hub — and then another minute or two before Elastic picks them up. This is normal.

Elastic Fleet Configuration

With Azure fully configured, the final step is to install the Microsoft Entra ID integration in Kibana and enter the four connection details you collected.

To enable log collection from the Microsoft Entra ID, provide the following information to CyTech Support:

Conclusion

With the integration configured, Microsoft Entra ID logs are now streaming continuously into Elasticsearch via Azure Event Hub. Sign-in, Audit, and Identity Protection events will be indexed automatically and available for search, visualization, and alerting in Kibana.

To maintain the integration, ensure the Elastic Agent remains healthy in Fleet and rotate the Storage Account Key and Event Hub connection string in both Azure and the Elastic integration settings as part of your regular credential rotation cycle.

NG SIEM - Microsoft Entra ID Entity Analytics

Overview

This guide provides step-by-step instructions for integrating Microsoft Entra ID (formerly Azure Active Directory) Entity Analytics with the Elastic Security platform. By completing this integration, your security team will be able to ingest identity-based risk signals from Entra ID directly into Elastic, enabling enriched detection, investigation, and response workflows.

Entity Analytics in Elastic Security correlates user and host risk scores derived from your identity provider with security events, helping analysts prioritize high-risk entities and reduce alert fatigue.

Prerequisite

Before beginning the integration, ensure the following requirements are met:

Microsoft Entra ID Requirements

Azure App Registration

Elastic connects to Entra ID via the Microsoft Graph API using an Azure App Registration with appropriate permissions. Follow these steps to configure the application.

Register a New Application

Field

Value

Name

Elastic-EntraID-EntityAnalytics

Supported account types

Accounts in this organizational directory only (Single tenant)

Redirect URI

Leave blank (not required for this integration)

Create a Client Secret

    • In your new App Registration, navigate to Certificates & secrets > Client secrets.

    • Click New client secret.

    • Set a description (e.g., "Elastic Entity Analytics") and choose an expiry period.

    • Click Add, then immediately copy the Value. This is shown only once.

Grant API Permissions

The application requires the following Microsoft Graph API permissions:

User.Read.All

Application

Read all user profiles

IdentityRiskEvent.Read.All

Application

Read identity risk events

IdentityRiskyUser.Read.All

Application

Read risky user data

AuditLog.Read.All

Application

Read audit log data

Directory.Read.All

Application

Read directory data

Elastic Fleet Configuration

With the Azure application registered, the next step is to configure Elastic Fleet to deploy the Microsoft Entra ID Entity Analytics integration.

To enable log collection from the Microsoft Entra ID, provide the following information to CyTech Support:

Tenant ID

Directory (Tenant) ID from App Registration

Client ID

Application (Client) ID from App Registration

Client Secret

Secret value created in Section 3.2

Dataset

azure.entityanalytics (auto-populated)

Sync Interval

Recommended: every 30 minutes (default)

Enable User Sync

Toggle ON

Enable Risk Sync

Toggle ON (requires P2 license)

Conclusion

Integrating Microsoft Entra ID Entity Analytics with Elastic Security gives your team a significant advantage in identifying and responding to identity-based threats. By pulling user risk signals directly from Entra ID into Elastic, you gain a unified view of your security posture without having to switch between platforms.

Once the Elastic Agent is configured with the App Registration credentials, it handles everything automatically — authenticating to Microsoft Graph API, syncing user and risk data on your set interval, and feeding that data into Elastic's Entity Analytics engine. From there, detection rules can alert your team on risky sign-ins, elevated risk levels, and behavioral anomalies in real time.

For Elastic Cloud deployments specifically, the integration works out of the box with no additional network configuration needed. The main things to keep on top of after go-live are tuning your detection rules to fit your environment and rotating the Azure App Registration client secret before it expires to avoid any interruption in data collection.

NG SIEM Microsoft Exchange Online Message Trace

Overview

Microsoft Exchange Online Message Trace is a powerful diagnostic and security feature within Microsoft 365 that tracks the flow of email messages through your Exchange Online organization. Integrating Message Trace data into Elastic provides security operations teams with centralized visibility into email traffic, anomaly detection, and compliance monitoring.

This guide covers the end-to-end process of collecting, ingesting, parsing, and analyzing Exchange Online Message Trace data within the Elastic Stack, including configuration of the Microsoft 365 integration via Elastic Agent, index templates, field mappings, dashboards, and alerting

Prerequisite

Before configuring the integration, ensure the following prerequisites are met:

Microsoft 365 Requirements

Azure App Registration

The Microsoft 365 integration authenticates using OAuth2 client credentials. You must create an App Registration in Azure AD and grant it the correct API permissions.

Creating the App Registration

Configuring API Permissions

Navigate to API permissions > Add a permission > Office 365 Management APIs and add the following application permissions:

API

Permission

Type

Office 365 Management APIs

ActivityFeed.Read

Application

Office 365 Management APIs

ActivityFeed.ReadDlp

Application

Microsoft Graph

Reports.Read.All

Application

After adding permissions, click Grant admin consent for [your tenant] to activate them. The status column should show a green checkmark.

Creating a Client Secret

Elastic Fleet Configuration

With the Azure application registered, the next step is to configure Elastic Fleet to deploy the Microsoft Exchange Online Message Trace integration.

Collect Microsoft Exchange Online Message Trace logs from Graph API

To enable log collection from the Microsoft Entra ID, provide the following information to CyTech Support:

Conclusion

Integrating Microsoft Exchange Online Message Trace into Elastic is straightforward when using the Graph API collection method. The client is only required to complete the Azure AD App Registration, grant the necessary API permissions, and securely share three credentials — Tenant ID, Client ID, and Client Secret — with the Elastic team.

Once those credentials are entered into the Microsoft 365 integration in Kibana, Elastic Cloud handles the rest. Data will begin flowing into the platform within 5 to 30 minutes, and the built-in dashboards provide immediate visibility into email traffic, delivery status, and suspicious activity.

No backend configuration, file paths, or command-line access is required for this setup. The alternative file-based collection method available in the Elastic UI is not applicable here, as logs are pulled directly from Microsoft's Graph API.

The only ongoing maintenance required is coordinating with the client to renew the Client Secret before it expires, typically every 24 months.

NG SIEM - Microsoft Exchange Server

Overview

The Microsoft Exchange Server integration for Elastic enables you to monitor Exchange Server installations by collecting and indexing server log data into Elasticsearch. With Kibana, you can visualize, search, and alert on Exchange activity in real time.

This integration is part of the Elastic integrations library and is deployed via Elastic Agent. It is designed for on-premises Exchange Server environments (versions 2013, 2016, and 2019) and supports the following log streams:

Prerequisite

Before setting up the integration, ensure the following components are in place:

Permissions

The Elastic Agent service account (or the user running Filebeat) must have read access to the Exchange log directories. Default log paths require local administrator or at minimum read access to:

Log Streams and File Paths

The integration collects the following log streams. Below are the default file paths for Exchange Server V15 (2013/2016/2019):

Enabling SMTP Protocol Logging

SMTP Send and Receive logs are not enabled by default on Exchange Server. Follow these steps to enable them using the Exchange Management Shell (EMS).

Enable SMTP Send Logging (Hub Transport)

Set-TransportService -Identity <ServerName> -SendProtocolLogPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend" -SendProtocolLogMaxAge 30.00:00:00 -SendProtocolLogMaxDirectorySize 250MB

 

Verify SMTP Logging is Active

After enabling, you can verify log files are being written to the configured path. Wait a few minutes for mail flow to generate entries, then check the directory for new .LOG files.

Enable SMTP Receive Logging (Frontend Transport)

Verify SMTP Logging is Active

After enabling, you can verify log files are being written to the configured path. Wait a few minutes for mail flow to generate entries, then check the directory for new .LOG files.

Log Stream

Default File Path

Notes

HTTPProxy

...\Logging\HttpProxy\{ECP,OWA,EWS,RPC}\*.LOG

Enabled by default

IMAP4

...\Logging\Imap4\*.LOG

Enabled by default

POP3

...\Logging\Pop3\*.LOG

Enabled by default

Message Tracking

...\TransportRoles\Logs\MessageTracking\*.LOG

Enabled by default

SMTP Send

...\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend\*.LOG

Must be enabled manually

SMTP Receive

...\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive\*.LOG

Must be enabled manually

 

Elastic Fleet Configuration

With the Azure application registered, the next step is to configure Elastic Fleet to deploy the Microsoft Exchange Server integration.

To enable log collection from the Microsoft Entra ID, provide the following information to CyTech Support:

Collect Microsoft Exchange Server Logs from file

Exchange Server IMAP4 POP3 Logs

Exchange Messagetracking Logs

Exchange SMTP logs

Conclusion

The Microsoft Exchange Server integration for Elastic is a practical and well-structured solution for organizations that need visibility into their on-premises email infrastructure. By leveraging Elastic Agent to collect and index Exchange log data — covering HTTPProxy, IMAP4/POP3, Message Tracking, and SMTP streams — teams gain centralized observability without having to build custom pipelines from scratch.

The integration's strength lies in its alignment with the Elastic Common Schema (ECS), which makes Exchange logs immediately searchable and compatible with Kibana's pre-built dashboards and alerting tools. This significantly reduces the time-to-value for security and operations teams who need to monitor mail flow, detect anomalies, or audit user activity.

That said, it does require some upfront effort — particularly around enabling SMTP protocol logging manually on the Exchange side and ensuring Elastic Agent has proper file system access. Organizations running non-standard Exchange installations will also need to adjust default file paths accordingly.

Overall, it's a solid community-supported integration that fits well into broader SIEM or observability strategies built on the Elastic Stack. For teams already invested in Elastic, adding Exchange Server monitoring is a natural and low-friction extension of their existing setup.

NG SIEM Microsoft Graph Activity Logs

Overview

Microsoft Graph Activity Logs capture API-level interactions with Microsoft Graph — including the identity of the caller, the resources accessed, permissions used, and the outcome. Forwarding these logs to Elastic gives security and operations teams a centralized platform for detection, alerting, and long-term retention.

Prerequisite

Azure Requirements

Required Azure AD Permissions

Parameter

Description

AuditLog.Read.All

Read all audit log data from Microsoft Graph

Directory.Read.All

Read directory data associated with activity records

User.Read.All

Resolve user display names and UPNs in enrichment

Policy.Read.All

Read conditional access and authorization policies

Azure App Registration

Register an Azure AD Application

Create an Azure Event Hub

Configure Diagnostic Settings in Entra ID

  1. In the Azure Portal, go to Microsoft Entra ID > Diagnostic settings > Add diagnostic setting.

  2. Name the setting (e.g., elastic-graph-activity-stream).

  3. Under Logs, check MicrosoftGraphActivityLogs.

  4. Under Destination, select Stream to an event hub and choose the namespace and Event Hub created above.

  5. Click Save. Logs will begin flowing within 5–15 minutes.

Note: The MicrosoftGraphActivityLogs category may appear as a preview feature. Ensure the feature is enabled for your tenant under Entra ID > User settings > Manage what information is shown.

Elastic Fleet Configuration

With the Azure application registered, the next step is to configure Elastic Fleet to deploy the Microsoft Graph Activity Logs integration.

To enable log collection from the Microsoft Entra ID, provide the following information to CyTech Support:

Conclusion

Integrating Microsoft Graph Activity Logs into Elastic gives your security and operations teams a powerful, centralized view of every API interaction occurring across your Microsoft 365 and Entra ID environment. What was previously a siloed audit stream within Azure becomes a first-class signal in your Elastic security ecosystem — queryable, correlatable, and actionable alongside all your other data sources.

By following this guide, you have established a reliable log pipeline from Microsoft Entra ID through Azure Event Hub into Elasticsearch, mapped raw Graph API telemetry to ECS fields for out-of-the-box detection compatibility, and laid the groundwork for long-term retention, compliance reporting, and threat hunting in Kibana.

As Microsoft continues to expand the Graph Activity Logs preview with richer metadata, this pipeline will grow in value without requiring significant re-architecture. The Event Hub ingest pattern is inherently scalable, and Elastic's data stream model ensures index management stays efficient as log volume increases.

Security visibility is only as strong as the signals feeding it. Microsoft Graph Activity Logs are one of the highest-fidelity sources of identity and access telemetry available in the modern enterprise — and with Elastic, you now have the tools to make the most of them.

 

NG SIEM - CISCO DUO

Overview

This guide provides step-by-step instructions for integrating Cisco DUO multi-factor authentication (MFA) with Elastic Fleet for centralized log collection and security monitoring.

Cisco DUO is a cloud-based access security platform that provides multi-factor authentication, device health checks, and zero-trust access policies. Elastic Fleet, part of the Elastic Stack (ELK), provides a centralized management interface for deploying and managing Elastic Agents across your infrastructure.

By integrating DUO authentication logs into Elastic Fleet, security teams gain:

Prerequisite

Before beginning the integration, ensure all of the following prerequisites are met. Incomplete prerequisites are the most common cause of integration failures.

Cisco DUO Requirements

To enable log collection from the Cisco DUO, provide the following information to CyTech Support:

Conclusion

The Cisco DUO integration with Elastic Fleet enables centralized visibility into authentication events across your environment. By leveraging DUO's Admin API alongside Elastic's log collection and SIEM capabilities, security teams can monitor, analyze, and respond to authentication activity in real time — all from a single platform.