This is the multi-page printable view of this section. Click here to print.
Product Integration Guides
- 1: Apache HTTP Server
- 2: Aruba Networks ClearPass
- 3: Azure Virtual Networks (NSG Flow)
- 4: Blackberry CylancePROTECT
- 5: Check Point Next-Generation Firewall
- 6: Cisco Identity Services Engine (ISE)
- 7: Cisco IOS Routers and Switches
- 8: Cisco Meraki MX Security Appliances
- 9: Cisco Secure Endpoint
- 10: Cisco Secure Firewall (ASA Appliances)
- 11: Cisco Secure Firewall (Firepower Threat Defense)
- 12: Cisco Umbrella
- 13: Citrix Netscaler (Formely Netscaler ADC)
- 14: Claroty Continuous Threat Detection (CTD)
- 15: Claroty xDome
- 16: Crowdstrike Falcon Insight
- 17: CyberArk Privileged Access Security (PAS)
- 18: ESET PROTECT
- 19: Fortinet FortiAnalyzer
- 20: Fortinet FortiGate Next-Generation Firewall
- 21: Fortinet FortiWeb
- 22: GestioIP IPAM
- 23: Google Workspace
- 24: Infoblox DDI
- 25: Linux Authentication
- 26: Microsoft Azure Activity Logs
- 27: Microsoft Azure Application Gateway
- 28: Microsoft Azure Firewall
- 29: Microsoft Defender Advanced Hunting
- 30: Microsoft DHCP Server
- 31: Microsoft DNS Server
- 32: Microsoft Entra ID
- 33: Microsoft Graph (Security)
- 34: Microsoft IIS
- 35: Microsoft Office 365
- 36: Microsoft Windows Event Log
- 37: Palo Alto Networks Cortex XDR Pro
- 38: Palo Alto Networks: Next-Generation Firewall
- 39: Palo Alto Networks: Panorama
- 40: PowerDNS Recursor
- 41: Proofpoint Targeted Attack Protection (TAP)
- 42: Sophos Central
- 43: Squid Proxy
- 44: Trellix Endpoint Security (ENS)
- 45: Trellix Endpoint Security (HX)
- 46: Trend Micro Vision One
- 47: VMware Carbon Black Cloud Enterprise EDR
- 48: WatchGuard Firebox
- 49: Zscaler Internet Access (ZIA)
1 - Apache HTTP Server
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Apache HTTP Server |
This guide describes the steps required to configure Apache HTTP Server hosted on a Linux host to send access and error logs to a Samurai Local Collector deployed on your network by configuring rsyslog.
Connectivity Requirements
Source | Destination | Ports | Description |
---|---|---|---|
Apache HTTP Server | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Configure Apache HTTP Server
Ensure that Apache HTTP Server is configured to log to syslog
Add or modify the ErrorLog and CustomLog directives in your Apache configuration file, normally located at /etc/apache2/apache2.conf:
ErrorLog "|/usr/bin/logger -p local6.error -t apache_error"CustomLog "|/usr/bin/logger -p local6.info -t apache_access" combined
Restart the Apache service to apply the configuration:
sudo systemctl restart apache2
Configure log forwarding with rsyslog
Follow the below steps to configure rsyslog to forward Error and Access events.
Rsyslog prerequisites
Ensure the following statement is included in the main rsyslog configuration file, normally located at /etc/rsyslog.conf:
$IncludeConfig /etc/rsyslog.d/*.conf
If no IncludeConfig statement exist for the /etc/rsyslog.d/ directory, append it to the end of rsyslog.conf.
Create /etc/rsyslog.d/ntt_apache.conf
Create /etc/rsyslog.d/ntt_apache.conf and insert the below configuration block, enter the Local Collector IP in the Target field.
template(name="apache-log" type="string" string="<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% apache_log %STRUCTURED-DATA% %msg%\n")if $programname == 'apache_error' then { action( queue.type="LinkedList" queue.size="10000" type="omfwd" template="apache-log" Target="<Local Collector IP>" Port="514" Protocol="tcp" )}if $programname == 'apache_access' then {action(queue.type="LinkedList" queue.size="10000" type="omfwd" template="apache-log" Target="<Local Collector IP>" Port="514" Protocol="tcp")}
Validate and restart service
Confirm that rsyslog can parse the configuration without any errors by running:
rsyslogd -N1
Then restart the rsyslog service:
sudo systemctl restart rsyslog
The log messages will now be forwarded to the Samurai Local Collector.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
2 - Aruba Networks ClearPass
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Aruba Networks ClearPass |
This guide describes the steps required to configure Aruba Networks ClearPass to send logs to a Samurai Local Collector deployed in your network.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
Aruba Networks ClearPass | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Syslog Configuration
Follow the below steps in ClearPass Policy Manager to enable syslog output to the local collector.
Add a Syslog Target using the following parameters:
Parameter Value Host Address IP of the Samurai Local Collector Protocol TCP Server Port 514 Create Syslog Export Filters for each event type using the following parameters:
Parameter Value Export Template Audit Records, Insight Logs and Session Logs Export Event Format Type CEF Syslog Servers Syslog target created in the above step
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
3 - Azure Virtual Networks (NSG Flow)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector | Samurai [Cloud Native] Collector |
---|---|---|---|
Azure Virtual Network (NSG Flow) |
This guide describes the steps required to configure a Network Security Group to send flow diagnostic logs to Samurai via a cloud native collector.
Prerequisites
Ensure that a cloud native collector has been deployed via the Samurai portal.
The storage account created via the cloud native collector needs to reside in the same region as the telemetry sources which will be ingested into the Samurai platform. For ingesting telemetry from multiple regions you need to create additional cloud native collector(s) for each region.
Take note of the name of the storage account created and which subscription it resides in. This will be used later when setting up the telemetry sources.
If you are planning to reuse an already deployed cloud native collector, the information about the created storage account and subscription can be found via:
- Navigate to the Samurai Portal.
- On the left navigation pane, click Collectors.
- Click on the name of the desired collector.
- Note down information about the:
- Subscription
- Storage account name
Alternatively***,*** you can utilize the integration setup wizard via the Samurai portal for the desired telemetry source listed on Product Integration Guide page which shall provide you the same information required to setup your telemetry source.
Enabling NSG flow logs
Follow the vendor documentation guide to enable NSG flow logs.
When following the vendor documentation, please perform the following adjustments:
- Ensure when configuring the Storage Account setting that it’s referencing the storage account that was setup during the creation of the cloud native collector.
- Ensure that version 2 for the Flow Logs Version is configured. This should be the default value when configuring via the Azure Portal.
- Ensure the retention period aligns with your storage policies however we recommend at minimum 7 days.
4 - Blackberry CylancePROTECT
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Blackberry CylancePROTECT |
This guide describes the steps required to configure CylancePROTECT to send logs to a Samurai Local Collector deployed on your network. CylancePROTECT requires access to the Local Collector via syslog on port 514/TCP.
To complete this Integration you will need to:
1) From the Cylance Console
Cylance syslog configuration
Samurai Local Collector only supports on-premise deployments of CylancePROTECT
Only CylancePROTECT events are supported
Follow the steps outlined within the Blackberry documentation:
Use the following parameters when completing the steps:
Default settings should be used unless otherwise specified in the listed parameters
Blackberry Documentation Step | Field Name | Parameter |
---|---|---|
3 | Event Types | All types related to CylancePROTECT |
5 | SIEM | Other |
6 | Protocol | TCP (TLS/SSL unchecked) |
8 | IP/Domain | Samurai Local Collector IP address |
9 | Port | 514 |
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
5 - Check Point Next-Generation Firewall
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Check Point Next Generation Firewall (NGFW) |
To complete this Integration you will need to:
1) Ensure Connectivity Requirements are in place
2) From Check Point Management Console:
- Configure Syslog Settings
- Create an NTT Account
- Defining Trusted Clients
- Enable Packet Capture for IPS Protections
- Enable Packet Capture for IPS Core Protections
3) From the Samurai application:
Connectivity Requirements
Source | Destination | Ports | Description |
---|---|---|---|
Check Point Management Center | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Samurai Local Collector | Check Point Management Center | TCP/443 (https) | Application Programming Interface (API) access |
Check point logs will be sent from the management server to the Samurai Local Collector via syslog.
Configure Syslog Settings
The syslog exporter package must be installed. Dependent on your Check Point version you may need to update. To validate requirements review the Check Point documentation found at:
Once you have validated or updated your Check Point version follow the steps outlined in the Check Point documentation section Advanced Deployment:
Use the following parameters when completing the Advanced Deployment :
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest: NTT-LOGEXPORT |
target-server | IP address of your Samurai Local Collector |
target-port | 514 |
protocol | tcp |
format | default |
read-mode | semi-unified |
export-attachment-ids | true |
Table 1: Log Exporter
An example of the command to run based on the table above is:
cp_log_export add name NTT-LOGEXPORT target-server <SAMURAI Local Collector IP> target-port 514 protocol tcp format default read-mode semi-unified export-attachment-ids true
Create an NTT Account
When you Complete the Check Point Next-Generation Firewall Integration in the Samurai application you can choose to use a username/password or API key for authentication. Note the authentication method when following the steps below.
Follow the Check Point documentation to create an NTT Account with password authentication:
Follow the Check Point documentation to create an NTT Account with API key authentication:
The URL provided directs you to R81 Check Point administrators guide, be sure to follow the steps for your specific version.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest: NTTUser |
Authentication method | Select either Check Point Password OR API Key |
Password | If Authentication method is Password - Set the password in accordance with your policy, you will need this to complete the integration in the Samurai application. |
Permission Profile | Read Only All (Check Point Documentation) |
Table 2: NTT User creation
If selecting API authentication then be sure to copy the key to Complete the Check Point Next-Generation Firewall Integration.
Defining Trusted Clients
In order to allow the NTT Account to access the Security Management Server via either username/password or API key it may be needed to configure Trusted Clients in the Check Point Management Console.
Follow the Check Point documentation when defining trusted clients:
General recommendation is to limit access to IPv4 Address and specifying the IP address of the Samurai Local Collector.
IPv4 Address filtering do not always work on all Check Point Management Console versions and one therefore needs to resort to utilize Any instead.
Enable Packet Capture for IPS Protections
Follow the Check Point documentation to enable packet capture for specific profiles:
The URL provided directs you to R81 Check Point Threat Prevention guide, be sure to follow the steps for your specific version.
It is recommended to enable packet capture for all signatures that are active within the used profile.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Logging / Track | Log |
Capture Packets | Enabled (check box) |
Table 3: IPS Protections
Enable Packet Capture for IPS Core Protections
Follow the Check Point documentation to enable packet packet for IPS Core Protections:
The URL provided directs you to R81 Check Point Threat Prevention guide, be sure to follow the steps for your specific version.
It is recommended to enable packet capture for all signatures that are active within the used profile.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Logging / Track | Log |
Capture Packets | Enabled (check box) |
Protection Scope | Apply to all HTTP traffic |
Table 4: IPS Core Protections
Complete the Check Point Next-Generation Firewall Integration
Login to your Samurai application tenant
Click Integrations from the main menu
Click Create
Find and select Check Point Next-Generation Firewall
You will be presented with the Local Collector IP Address on the left of the screen
To configure Extended Telemetry Collection ensure it is enabled via the toggle
Enter the following information:
- Name for the Integration - the name will appear in the Samurai application for you to easily reference
- Description - optional but if completed will appear in the Samurai application for you to easily reference)
- Devicename - an arbitrary name to identify the Check Point device
- IP - IP address of host - this can include multiple separated by a comma (,)
- API-key (optional) - if this is not specified will default to Username/Password
- Domain (optional) - if the user is created in a specific domain, specify the domain
- Username (optional) - enter a username if not using an API-Key
- Password - specify password to use
- Port - if you have changed the default port enter the port number, if not, we default to 443
Click on Finish
For general information on Integrations refer to the Integrations article.
6 - Cisco Identity Services Engine (ISE)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco Identity Services Engine (ISE) |
This guide describes the steps required to configure Cisco Identity Services Engine to send logs to a Samurai Local Collector deployed in your network.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
Cisco ISE | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Configure Syslog
Follow the steps outlined in Remote Logging Target Settings using the following parameters:
Field Name | Parameter |
---|---|
Target Type | TCP Syslog |
IP Address | IP address of your Samurai Local Collector |
Port | 514 |
Maximum Length | 8192 |
Comply to RFC 3164 | Enabled |
With the following logging categories enabled:
Logging Category |
---|
AAA Audit |
Failed attempts |
Passed Authentications |
Administrative and Operational Audit |
Posture and Client Provisioning Audit |
MDM |
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
7 - Cisco IOS Routers and Switches
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco IOS Routers and Switches |
This guide describes the steps required to configure Cisco IOS to send logs to a Samurai Local Collector deployed on your network. Your Cisco IOS device(s) require access to the Local Collector via syslog on port 514/UDP.
To complete this Integration you will need to:
1) From your Cisco IOS device
Configure Log
Use these instructions to configure Cisco IOS.
- Log into the Cisco IOS device and specify the following commands:
1. en
2. conf t
3. no logging on
4. archive
5. log config
6. logging enable
7. logging size 1000
8. notify syslog contenttype plaintext
9. hidekeys
10. exit
11. exit
The preceding exit commands will take you from the config-archive-log-cfg command mode to the config command mode.
12. logging host [Local Collector IP Address] where [Local Collector IP Address] is the IP address of the Samurai Local Collector deployed on your network.
13. logging trap 6
14. login on-failure log every 1
15. login on-success log every 1
16. logging origin-id hostname
17. logging source-interface [Interface Name] where [Interface Name] is the name of the interface that has access to the Samurai Local Collector.
18. no service sequence-numbers
19. no service timestamps
20. service timestamps log datetime localtime show-timezone
21. no logging message-counter syslog
22. no logging console
23. no logging monitor
24. logging buffered 16384 informational
25. logging on
26. end
27. wr mem
Test the logging configuration
- Execute the following commands to generate a %SYS-5-CONFIG_I log.
conf t
end
This will test the configuration and connectivity to the Samurai Local Collector.
Configure ACL log
To configure logging of specific ACLs, add the option log to the end of the ACL to be monitored. For example:
access-list 101 deny tcp any host 192.168.35.0/24 25 log
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
8 - Cisco Meraki MX Security Appliances
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco Meraki MX Security Appliances |
This guide describes the steps required to configure Cisco Meraki Security Appliances to send logs to a Samurai Local Collector deployed on your network. Cisco appliances require access to the Local Collector via syslog on port 514/UDP.
To complete this Integration you will need to:
1) From the Meraki Dashboard:
Meraki syslog configuration
Log in to the Meraki Dashboard and complete the following steps:
- Click Network-wide.
- Click General.
- Click Add a syslog server.
- In the Server IP field, enter the IP address of the Collector appliance deployed on your network.
- Specify the Port as 514.
- Select all the available Roles.
- Click Save.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
9 - Cisco Secure Endpoint
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco Secure Endpoint |
Cisco Secure Endpoint logs and data are collected via REST API.
To complete this Integration you will need to:
1) Within the Cisco Secure Endpoint web interface
2) From Cisco Secure Malware Analytics
3) From the Samurai application:
Determine API Endpoint
The URL for API access Secure Endpoint depends on the region the instance is located, at the time of writing the following are available:
- api.amp.cisco.com
- api.apjc.amp.cisco.com
- api.consumer.amp.cisco.com
- api.eu.amp.cisco.com
The URL for API access to Secure Malware Analytics depends on the region the instance is located, at the time of writing the following are available:
Take note of the appropriate URLs as it will be required when completing the Integration within the Samurai MDR application.
Generate API Credentials
Use the steps below to generate API credentials to allow a Samurai cloud collector to gather telemetry from Secure Endpoint:
You can also refer to Cisco documentation for further information at Generate and Delete API Credentials
Log in to your Cisco Secure Endpoint Instance.
Click Accounts > API Credentials
Click + New API Credential
Add a new API key with the following information:
In the Application name field, enter an appropriate name
From the Scope list, ensure Read & Write is selected
Click Create
The API credentials are displayed
Make a note of the 3rd Party API Client ID and API Key values
The Read & Write scope is required to create the stream for collecting events.
You will need the API Client ID and API Key when completing the integration within the Samurai application.
Generate Secure Malware Analytics API Credentials
Use these steps to generate API credentials to allow Samurai to gather telemetry from Secure Malware Analytics:
Log in to your Cisco Secure Malware Analytics Instance.
In the top-right click on your account name,then My Account
If no API key has been generated previously, click Generate API Key
Make a note of the API Key
You will need the API Key when completing the integration within the Samurai application.
Complete the Cisco Secure Endpoint Integration
You will need:
- Devicename (arbitrary name)
- API Endpoint (from Determine API Endpoint)
- API Client ID (from Generate API Credentials)
- API Key (from Generate API Credentials)
- Secure Malware Analytics API Key (from Generate Secure Malware Analytics API Credentials)
Login to the Samurai MDR web application
Select Integrations
Select Create
Locate and click Cisco Secure Endpoint
Click Next (we leverage a Samurai Cloud Collector)
Enter a Name of Integration
Enter a Description (Optional)
Enter your Devicename
Enter your API Endpoint
Enter your API Client ID
Enter your API Key
Enter your Secure Malware Analytics Endpoint
Enter your Secure Malware Analytics API Key
Click Finish
For general information on Integrations refer to the Integrations article.
10 - Cisco Secure Firewall (ASA Appliances)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco Secure Firewall (ASA Appliances) |
This guide describes the steps required to configure Cisco Secure Firewall (ASA Appliances) to send logs to a Samurai Local Collector deployed on your network. Your Cisco appliances require access to the Local Collector via syslog on port 514/UDP.
To complete this Integration you will need to:
1) From your Cisco Firewall:
Configure syslog
Perform the following steps to configure syslog:
Log in to the Cisco ASA
From the command line specify the following commands to setup logging:
en
conf t
logging enable
logging timestamp
logging device-id
logging standby
logging trap debugging
logging queue 1024
logging host [interface name] [Local Collector IP Address]
where:
[interface name] is the name of the interface closest/routable to the Local Collector, and
[Local Collector IP Address ] is the IP address of the Samurai Local Collector deployed on your
network .
For further information from Cisco on CLI configuration you can refer to Cisco ASA Series General Operations CLI Configuration Guide.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
11 - Cisco Secure Firewall (Firepower Threat Defense)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco Secure Firewall (Firepower Threat Defense) |
This guide describes the steps required to configure Cisco Secure Firewall Threat Defense (FTD) (previously entitled Firepower Threat Defense) to send syslog to a Samurai Local Collector.
Cisco Secure Firewall Management Center (FMC) is required.
1) Ensure Connectivity Requirements are in place
2) From Cisco Secure Firewall Management Center console:
- Send Security Event Syslog Messages from FTD Devices
- Enabling External Access to the Database
- Database User Creation
3) From the Samurai application
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
FTD | Samurai Local Collector | UCP/514 (syslog) | For log transmission |
Samurai Local Collector | FMC | TCP/1500 & TCP/2000 | Database access |
Table 1: Connectivity requirements
Send Security Event Syslog Messages from FTD Devices
Follow the steps outlined within the Cisco documentation:
Default settings should be used unless otherwise specified in the listed parameters
Cisco Documentation Step 1:
Use the following parameters:
You can also refer to Configure a Syslog Server if you have queries based on options available
Cisco Documentation Step | Field Name | Parameter |
---|---|---|
1d | IP Address | Samurai Local Collector IP address (verify or add the address) |
1d | Protocol | UDP |
1d | Port | 514 |
1d | Security Zones or Named Interface | Select the interface/zone on which the Samurai Local Collector is reachable |
1e | Time Stamp Format | RFC 5424 (yy-MM-ddTHH:mm:ssZ) |
1e | Enable Syslog Device ID | Enabled (Host Name) |
1f | Send syslogs in EMBLEM format | Unchecked |
Table 2: Syslog settings
Cisco Documentation Step 2:
Use the following parameters:
Field Name | Field Name | Parameter |
---|---|---|
2f | IPS Settings | Send Syslog Messages for IPS Events (Selected) |
2f | File and Malware Settings | Send Syslog messages for File and Malware events (Selected) |
Table 3: General logging settings
Cisco Documentation Step 3:
Complete the steps outlined.
Cisco Documentation Step 4:
Use the following parameters:
Field Name | Field Name | Parameter |
---|---|---|
4d | Logging | Log at End of Connection (Selected) |
Cisco Documentation Step 5:
Complete the steps outlined.
This step if only applicable if using Snort 2
Enabling External Access to the Database
Follow the steps outlined within the Cisco documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Allow External Database Access | Enabled |
Server Hostname | If this is blank, enter the IP address of the Cisco Firepower Management Center that is being configured. |
Add Hosts > IP Address | IP address of your Samurai Local Collector |
Table 6: Enable external access to database
Database User Creation
Follow the steps outlined within the Cisco documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
User Name | Whatever you want |
Authentication > Use External Authentication Method | Unchecked |
Password | Whatever you want, but need to comply with Password Policy |
Options | Only check Check Password Strength. Other than that, unchecked. |
Default User Roles | Only check External Database User. Other than that, unchecked. |
Table 7: User for Database Access
Complete the Cisco Secure Firewall (Firepower Threat Defense) Integration
- Login to the Samurai MDR application
- Click Integrations from the main menu
- Click Create
- Find and select Cisco Secure Firewall (Firepower Threat Defense)
- Select the relevant Local Collector and click Next
- You will be presented with the Local Collector IP Address
- Click Next
- Complete the fields required including the Database Username and Password you created in Database user creation
- Click on Finish
For general information on Integrations refer to the Integrations article.
12 - Cisco Umbrella
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Cisco Umbrella |
This guide describes all steps required to configure Cisco Umbrella to send logs to an S3 bucket and allows Samurai to access (read-only) and ingest the logs.
Cisco Umbrella integration requires a self managed AWS S3 bucket. For more information on Cisco Umbrella logging refer to the Cisco documentation Manage Your Logs.
If you already have an AWS S3 bucket configured and have enabled Cisco Umbrella logging then jump straight to Configure an existing AWS S3 bucket to allow Samurai access
If you have not enabled Cisco Umbrella logging to an AWS S3 bucket then follow the steps below to complete the integration:
1) Ensure you have been provided the following parameters from NTT
- IntegrationsID
- Passkey
These parameters will be made available to you during onboarding
2) Have an Amazon AWS Account
- If you do not have an AWS Account you can refer directly to Cisco Umbrella documentation Enable Logging to your own S3 bucket. This document makes reference to Amazon’s S3 documentation.
3) Decide on an S3 Data Retention Period
- Defined by you and your retention policy, this refers to automatic deletion of objects in the S3 bucket after X number of days. The default is 7 days, however you can override the value and select a maximum of 365 days.
4) From your browser
5) From your Cisco Umbrella console
Launch the integration stack and complete
Complete the following steps from your browser:
- Browse to:
We have simplified the integration through use of a CloudFormation Template that creates the following resources:
- SNS Topic
- S3 Bucket with SNS Notification of ObjectCreated Events
- Secure Bucket Policy, Allowing Samurai RO access
- SNS HTTPS Webhook Subscription to the Samurai Platform
Click on Launch Stack
Sign in to your AWS Account with administrative permissions
The Create Stack page will be shown:
- Select your AWS region to deploy the stack:
Click on Next
The Specify stack details page will be shown:
Specify a unique Stack name (optional) we default to NTTSamuraiS3Stack
Enter the following parameters previously provided to you by NTT:
- Samurai Cloud IntegrationsId
- Samurai Cloud Integrations Pass Key
Select Yes under Enabled Cisco Umbrella access to Cloud Integrations S3 Bucket via Bucket Policy
Leave The name of an existing Cisco Umbrella Bucket blank
Update the Samurai Cloud Integrations Bucket Data Retention period (as needed)
The default retention period is 7 days (we recommend 7 days but based on your retention policy you can override the value as necessary)
Click Next
The Configure stack options will be shown:
Click Next
You can now Review the steps worked through:
Click Create Stack
You will now be shown the stack Events:
- Select the Resources tab:
Make note of the S3 bucket name as you will need this when configuring Cisco Umbrella. The S3 bucket name is the Physical ID of the S3 Bucket and is also a hyperlink.
To verify the webhook has registered with Samurai, click on the hyperlink of the Physical ID of the SamuraiSNS Topic (Logical ID)
The Topic details page will open, you should see Status as Confirmed (see example below):
From your Cisco Umbrella console
Follow the Enable Logging section (Steps 1-3) in the Cisco Umbrella documentation:
Ensure you have the exact name of the AWS S3 bucket
Your integration is now complete. If you have any problems or questions please raise a ticket or reach out to your NTT point of contact.
Configure an existing AWS S3 bucket to allow Samurai access
If you already have Cisco Umbrella logging to a self managed AWS S3 bucket then follow the steps below:
1) Ensure you have been provided the following parameters from NTT
- IntegrationsID
- Passkey
These parameters will be made available to you during onboarding
2) From your browser
Launch the integration stack and complete
Complete the following steps from your browser:
- Browse to:
We have simplified the integration through use of a CloudFormation Template that creates the following resources:
- SNS Topic
- SNS HTTPS Webhook Subscription to the Samurai Platform
Click on Launch Stack
Sign in to your AWS Account with administrative permissions
The Create Stack page will be shown:
- Select your AWS region to deploy the stack:
Click on Next
The Specify stack details page will be shown:
Specify a unique Stack name (optional) we default to NTTSamuraiS3Stack
Enter the following parameters previously provided to you by NTT:
- Samurai Cloud IntegrationsId
- Samurai Cloud Integrations Pass Key
Select Yes under Enabled Cisco Umbrella access to Cloud Integrations S3 Bucket via Bucket Policy
Under The name of an existing Cisco Umbrella Bucket enter the name of your existing S3 Bucket (an example is depicted in the graphic)
Update the Samurai Cloud Integrations Bucket Data Retention period (as needed)
The default retention period is 7 days (we recommend 7 days but based on your retention policy you can override the value as necessary)
Click Next
The Configure stack options will be shown:
Click Next
You can now Review the steps worked through:
Click Create Stack
You will now be shown the stack Events
You can view Resources created:
- You must now Create Event Notifications. Browse to your existing S3 Bucket Properties
- Click Create Event Notification
- The Create event notification window will be shown:
Scroll down for Destination
- Complete the following fields with the following parameters: (leave all other fields as default)
Field Name | Parameter |
---|---|
Event name | whatever you want |
Object creation | All object create events (enabled) |
Destination | SNS Topic (selected) |
Specify SNS topic | Select your method to specify the SNS topic |
SNS Topic | Enter or choose from your topics the relevant Samurai entry |
Click Save Changes
You now need to add an S3 bucket policy. Browse to your existing S3 Bucket Properties
Select Edit and add the following statements:
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::600502389717:user/samurai-xdr-s3-reader-user" }, "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::samurai-12a98319b803", "arn:aws:s3:::samurai-12a98319b803/*" ]}
Click Save changes
To verify the webhook has registered with Samurai. Go to the Resources tab of the Samurai Stack and click on the hyperlink of the Physical ID of the SamuraiSNS Topic*(Logical ID)***
The Topic details page will open, you should see Status as Confirmed (see example below):
You now need to ensure the S3 Object Ownership of your existing S3 bucket to ensure Samurai is able to download the logs. Sign-in to the AWS Management Console and open the Amazon S3 console (if you have not already done so!) at https://console.aws.amazon.com/s3/
In the Buckets list choose the name of the bucket that you want to apply an S3 Object Ownership setting to
Choose the Permissions tab
Under the Object Ownership, choose Edit
Under Object Ownership ensure Bucket owner preferred is enabled (as depicted in the graphic below)
Click Save changes
If you have ACLs disabled, your integration is now complete***.***
If you have ACLs enabled you will need to edit the ACL
In the Buckets list choose the name of the bucket that you want to set permission for
Choose Permissions
Under Access control list, choose Edit
Under Access for other AWS account, click Add grantee
Enter 5501afb2b26d7609fe4051b3d23916c6c185da004301607ebbb71883d12d4142 as the canonical ID
Click List (under Objects) and Read (under Bucket ACL)
- Click Save Changes
Your integration is now complete. If you have any problems or questions please raise a ticket or reach out to your NTT point of contact.
13 - Citrix Netscaler (Formely Netscaler ADC)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Citrix Netscaler |
This guide describes the steps required to configure Citrix Netscaler to send logs to a Samurai Local Collector deployed on your network. Citrix Netscaler requires access to the Local Collector via syslog on port 514/UDP.
To complete this Integration you will need to:
1) From your Citrix Netscaler Appliance :
Follow the steps outlined within the Citrix documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Auditing Type | SYSLOG |
Name | Whatever you want, however we suggest NTT_syslog_action |
ServerIP | IP address of your Samurai Collector |
serverPort | 514 |
logLevel | EMERGENCY,ALERT,CRITICAL,ERROR,WARNING,NOTICE,INFORMATIONAL |
dateFormat | MMDDYYYY |
transport | UDP |
Table 1: Audit-log Action
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest NTT_syslog_policy |
rule | Use the Audit-log action you created above. |
Table 2: Audit-log Policy
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
14 - Claroty Continuous Threat Detection (CTD)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Claroty CTD |
This guide describes the steps required to configure Claroty CTD to send logs to a Samurai Local Collector deployed on your network. Claroty CTD requires access to the Local Collector via syslog on port 514/TCP.
Prerequisites
This document supports Claroty CTD versions 3.x, and 4.x.
The following integration will configure Rules for Baseline, Event and Alert Logs. A user account is also created for read-only API access to gather additional telemetry.
To complete this Integration you will need to:
1) From the Claroty Web management user interface
2) From the Samurai application
Configure Save CAPs and Detect Known Threats
- Log in to Claroty’s web configuration dashboard.
- Click the Configuration tab.
- In the Networks area:
- Select the checkbox to enable Save Caps
- Select the checkbox to enable Detect Known Threats
Configuration of Rules
If a field is not mentioned, please leave it unchanged
Baseline Rule
Log in to Claroty’s web configuration dashboard.
On the main menu on the left, click Configuration
Select Integrations > SIEM Syslog
Complete the following steps to add a rule to send baseline logs:
In the SIEM Syslog screen click on the “+” button
In the From list, click the relevant site(s)
The Add new Syslog screen will appear
Update the following fields:
- Uncheck the LOCAL checkbox
- From the MESSAGE CONTENTS list, click Baselines
- From the MESSAGE FORMAT list, click CEF
- Protocol - select all from the available list
- Communication Type - select all available options
- Access Type - select all available options
- Server - enter in the IP address of your Samurai Local Collector
- Port - enter 514
- Protocol - TCP
Click Save
Events Rule
Log in to Claroty’s web configuration dashboard.
On the main menu on the left, click Configuration
Select Integrations > SIEM Syslog
Complete the following steps to add a rule to send Events logs:
In the SIEM Syslog screen click on the “+” button
In the From list, click the relevant site(s)
The Add new Syslog screen will appear
Update the following fields:
- Uncheck the LOCAL checkbox
- From the MESSAGE CONTENTS list, click Events
- From the MESSAGE FORMAT list, click CEF
- Below Select Filters for the corresponding alerts configure:
- Category - select all available selections
- Protocol - select all from the available list
- Server - enter in the IP address of your Samurai Local Collector
- Port - enter 514
- Protocol - TCP
Click Save
Alert Rule
Log in to Claroty’s web configuration dashboard.
On the main menu on the left, click Configuration
Select Integrations > SIEM Syslog
Complete the following steps to add a rule to send Alerts logs:
In the SIEM Syslog screen click on the “+” button
In the From list, click the relevant site(s)
The Add new Syslog screen will appear
Update the following fields:
- Uncheck the LOCAL checkbox
- From the MESSAGE CONTENTS list, click Alerts
- From the MESSAGE FORMAT list, click CEF
- Category - select all available selections
- Protocol - select all from the available list
- Server - enter in the IP address of your Samurai Local Collector
- Port - enter 514
- Protocol - TCP
Click Save
Create an account for API access
- Log in to Claroty’s web configuration dashboard.
- On the main menu select Configuration and Users
- In the User Management configuration screen, Click Add new users
- Enter a Username
- Enter a Full Name
- Enter a Password
- Repeat the Password
- Click Add
You will need to provide these credentials to NTT during onboarding
If your Security and Authentication > Password Expires are not set to 0 (0=unlimited) you will need to ensure you update the password before it expires.
Create a Group with permissions for the API access account
If a field is not mentioned, please leave it unchanged
- Log in to Claroty’s web configuration dashboard.
- On the main menu select Configuration and Groups
- In the Group Management configuration screen, Click Add new groups
- Enter a Group Name
- Select the user created in Create an account for API access from the Add User dropdown list
- In the Systems Permissions area, Click Add permission
- Select specific sites to which the permissions applies, or All Sites
- From the All dropdown list, select relevant option
- Set the appropriate permission level to Read
- Click Save
Complete the Claroty Continuous Threat Detection (CTD) Integration
Login to the Samurai MDR web application
Click Integrations from the main menu
Click Create
Find and select Claroty Continuous Threat Detection (CTD)
Select the relevant Local Collector and click Next
You will be presented with the Local Collector IP Address on the left of the screen
To configure Extended Telemetry Collection ensure it is enabled via the toggle
Enter the following information:
- Name for the Integration - the name will appear in the Samurai application for you to easily reference
- Description - optional but if completed will appear in the Samurai application for you to easily reference)
- Devicename - an arbitrary name to identify the Claroty CTD device
- IP Address - the IP address of Claroty CTD
- Username - enter the username you created in Create an account for API access
- Password - enter the password you created in Create an account for API access
- Port (Optional)- if you have changed the default port enter the port number, if not, we default to 5000
Click on Finish
For general information on Integrations refer to the Integrations article.
15 - Claroty xDome
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Claroty xDome |
This guide describes the steps required to configure Claroty xDome to send logs to a Samurai Local Collector deployed in your network.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
Claroty xDome Collection Server | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Configure Claroty Syslog
Follow the steps outlined in About Claroty Syslog (Claroty login is required) using the following parameters:
Field Name | Parameter |
---|---|
Destination IP | IP address of your Samurai Local Collector |
Transport Protocol | TCP |
Destination Port | 514 |
Message Format | JSON |
Syslog Protocol Standard | RFC 5424 |
Installation Server | Select your xDome collection server |
Export Comm. Events | ON. Select All Event Types and All Devices |
Export Alerts | ON. Select All Alert Types |
Export Vulnerabilities | ON. Select All |
Table 2: Claroty Syslog Configuration
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
16 - Crowdstrike Falcon Insight
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Crowdstrike Falcon Insight |
To complete this Integration you will need to:
1) From the Crowdstrike Falcon Console:
- Submit a Support case with Crowdstrike
- Create credentials for basic authentication
- Create a new API client
Crowdstrike credentials are required
2) From the Samurai application:
3) Complete and send authorization form
Submit a support case with Crowdstrike
As our integration leverages the ‘Legacy API Credentials’ for the ‘Threat Graph API’ you must submit a support case directly with Crowdstrike for enablement. Please refer to the following Crowdstrike documentation.
Please note Crowdstrike key-based APIs are deprecated however with the exception of Threat Graph API and Tailored Intel API as per the Crowdstrike documentation
Create credentials for basic authentication
To create credentials for basic authentication, perform the following steps:
Log in to the Crowdstrike Falcon Console
Click the Support and resources icon in the left menu pane.
Under Resources and tools select API Clients and Keys. The API Clients and Keys page is displayed.
Select the Legacy API Credentials tab.
Click Create Credentials
Copy the Username and Password. You will need the credentials to Complete the Crowdstrike Falcon Insight Integration
Figure 1: Credentials for basic authentication
Create a new API client
To create a new API client follow the steps below:
Log in to the Crowdstrike Falcon Console
Click the Support and resources icon in the left menu pane.
Under Resources and tools select API Clients and Keys. The API Clients and Keys page is displayed.
Click Create API client. The Create API client page appears.
Perform the following steps:
5.1 Specify NTT API Client in the CLIENT NAME field.
5.2 Specify API client for NTT in the DESCRIPTION field.
5.3 Under API SCOPES, perform the following steps:
5.4 Select the Read checkbox for:
- Detections
- Host
- Host groups
- Prevention policies
- Event Streams,
- User Management.
5.5 Select the Write checkbox for:
- Hosts.
- Click Add.
Figure 2: Add new API client
- Copy and record the values :
- CLIENT ID
- SECRET
Figure 3: Client ID and Secret
The Secret is displayed only once so ensure to record it for use during Complete the Crowdstrike Falcon Insight Integration
- Take note of your Cloud location which is dervived from the Base URL as per the table below, you will need to specify the cloud location under Complete the Crowdstrike Falcon Insight Integration.
The table below outlines the Cloud location and Base URL:
Cloud Location | Base URL |
---|---|
US-1 | https://api.crowdstrike.com |
US-2 | https://api.us-2.crowdstrike.com |
EU-1 | https://api.eu-1.crowdstrike.com |
US-GOV-1 | https://api.laggar.gcw.crowdstrike.com |
- Click DONE.
Complete the Crowdstrike Falcon Insight Integration
You will need:
- OAuth Client ID: (from Step 7 under Create a new API client)
- OAuth Secret: (from Step 7 under Create a new API client)
- Basic User: (from Step 6 under Create credentials for basic authentication)
- Basic Password: (from Step 6 under Create credentials for basic authentication)
- Cloud location: (from Step 8 under Create a new API client)
Login to the Samurai application
Select Integrations
Select Create
Locate and click Crowdstrike Falcon Insight
Click Next (we leverage a Samurai Cloud Collector)
Enter a Name of Integration
Enter a Description (Optional)
Enter a Devicename
Enter your OAuth Client ID
Enter your OAuth Secret
Enter your Basic User
Enter your Basic Password
Select your Cloud Location (US-1 is default).
Click Finish
Complete and send authorization form
Our SOC requires access to your Crowdstrike GUI in order to:
- Perform deeper investigations
- Access data not present in the APIs
- Perform remote isolation tasks
To ensure the SOC has access please complete this form Authorization Form for Access to Crowdstrike Falcon Host by MSP Personnel. Once you have completed, email the form to mssp@crowdstrike.com.
For general information on Integrations refer to the Integrations article.
17 - CyberArk Privileged Access Security (PAS)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
CyberArk Privileged Access Security (PAS) |
This guide describes the steps required to configure CyberArk PAS to send logs to a Samurai Local Collector deployed on your network. Your CyberArk PAS Vault deployment requires access to the Local Collector via syslog on port 514/UDP.
To complete this Integration you will need to:
1) From CyberArk Vault
Configure Vault to forward syslog messages
Follow the steps below, you may also wish to refer to CyberArk documentation.
Download ntt.xsl.
Log in to the (primary) CyberArk PAS Vault server as the administrator user
Navigate to the <CyberArk install folder>\Server\Syslog directory.
- By default, the subdirectory is: C:\Program Files (x86)\PrivateArk\Server\Syslog
Copy the ntt.xsl file into the directory.
Navigate to the <CyberArk install folder>\Server\ directory.
- By default, the subdirector is: C:\Program Files (x86)\PrivateArk\Server\
Copy the existing DBParm.ini file to DBParm.ini.bak file within the same directory (in case you need to rollback)
Edit the DBParm.ini file and make the following configuration changes:
If you are configuring more than one syslog destination, each parameter must match the number of hosts in SyslogServerIP. Each CSV position in SyslogServerIP will correspond with the same CSV position in other fields.
For example:
SyslogServerIP=1.1.1.1,2.2.2.2
SyslogServerPort=514,6514
In the above example, server 1.1.1.1 would match with port 514, while server 2.2.2.2 would match with port 6514.
- For SyslogServerIP, enter the IP address of the Samurai Local Collector deployed on your network.
- For SyslogServerPort, enter 514
- For SyslogServerProtocol, enter TCP
- For SyslogTranslatorFile, enter Syslog\ntt.xsl
This is the file mentioned in step 1 & 4 - For SyslogMessageCodeFilter, enter 0-999.
- For UseLegacySyslogFormat, enter No.
The changes to DBParm.ini should look like the following example:
[SYSLOG]SyslogServerIP=1.1.1.1SyslogServerPort=514SyslogServerProtocol=TCPSyslogTranslatorFile=Syslog\ntt.xslSyslogMessageCodeFilter=0-999UseLegacySyslogFormat=No
Apart from the SyslogServerIP parameter, ensure that the parameter statements match those shown above. If you are copying and pasting from this document, ensure that each parameter statement is on a separate line and that no unwanted spaces are introduced.
Save the file
Restart the Vault server
Ensure that there are no errors in the log file. A list of possible messages that could appear in the log file are included in CyberArk documentation - Syslog Messages
- If applicable. perform the procedure on all Primary and Satellite Vaults.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
18 - ESET PROTECT
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
ESET PROTECT |
This guide describes the steps required to configure ESET PROTECT On-Prem to send logs to a Samurai Local Collector deployed in your network.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
ESET PROTECT | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Syslog Configuration
Follow the steps described in Export logs to Syslog using the following parameters:
Parameter | Value |
---|---|
Host | IP of the Samurai Local Collector |
Port | 514 |
Format | Syslog |
Transport | TCP |
Exported logs format | JSON |
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
19 - Fortinet FortiAnalyzer
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Fortinet FortiAnalyzer (physical/virtual only) |
To complete this Integration you will need to:
1) Ensure Connectivity Requirements are in place
2) From the FortiAnalyzer
3) From your Fortigate devices (if using Fortigate devices)
4) From your FortiWeb devices (if using Fortiweb devices)
5) From the Samurai application:
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
FortiAnalyzer | Samurai Local Collector | UDP/514 (syslog) | For log transmission |
Samurai Local Collector | FortiAnalyzer | TCP/443 (https) default or your definition | Optional (based on optional configuration in this article) |
Create a reduced restricted profile
Follow the steps outlined in the Fortinet documentation:
Select Administrator Profiles to read more about Fortinet profiles (v7.x)
Use the following parameters when completing the steps:
Profile system settings | Value |
---|---|
Profile Name | Whatever you want, however we suggest ntt_restricted_user |
Options | Set all options to None except Log View / FortiView which should be set to Read-Only |
Configure log forwarding
Follow the steps outlined in the Fortinet documentation:
Use the following required parameters when completing the steps:
Log forward setting | Value |
---|---|
Name | Whatever you want, however we suggest NTT_collector |
Status | On |
Remote Server Type | Syslog |
Server Address | IP address of your collector |
Server Port | 514 |
Compression | Off |
Reliable Connection | Off |
Sending Frequency | Real-time |
Device Filters | Click Select Device, then select the devices whose logs will be forwarded (Note: you may have to come back to this if you are not sending logs from your Fortigate devices yet!) |
Log filters | Off |
Enable exclusions | Off |
Enable Masking | Off |
Create a new administrator
Follow the steps outlined in the Fortinet documentation:
Use the following parameters when completing the steps:
Administrator account | Value |
---|---|
User Name | Whatever you want, however we suggest ntt_user |
Description / Comments | Whatever you want |
Admin Type | LOCAL |
Password | Enter a secure password, you will need this later for the integration |
Admin Profile | Select the profile from the the previous step, we recommended ntt_restricted_user |
Administrative Domain | Select based on your setup or use the default option, All ADOMS |
JSON API Access | Read |
Trusted Hosts (optional) | You can optionally restrict this account to the IP address of your Collector |
Enable FortiGate to send logs and PCAP to FortiAnalyzer
All FortiGate devices in scope must be connected to the FortiAnalyzer to send logs and PCAP.
Follow the steps outlined in the Fortinet documentation:
Use the following required parameters when completing the steps:
Remote Logging and Archiving | Value |
---|---|
Send logs to FortiAnalyzer/FortiManager | Enable |
Server | IP address for your FortiAnalyzer |
Upload option | Real Time |
If this is the first time remote logging is configured and the FortiGate device was not previously added to FortiAnalyzer, the device needs to be authorized under FortiAnalyzer Device Manger to be able to upload its logs. Perform this on the FortiAnalyzer
Disk backed log buffer is recommended on Fortigates with an SSD disk.
Follow the steps outlined in the Fortinet documentation:
Configure FortiAnalyzer policies for FortiWeb
Follow the steps in the section entitled ‘Configuring FortiAnalyzer policies’ outlined in the Fortinet FortiWeb documentation:
Complete the Fortinet FortiAnalyzer Integration
Login to the Samurai MDR web application
Click Integrations from the main menu
Click Create
Find and select Fortinet FortiAnalyzer
Select the relevant Local Collector and click Next
Enter the following information
- Name for the Integration - the name will appear in the Samurai application for you to easily reference
- Description - optional but if completed will appear in the Samurai application for you to easily reference)
- The Username and Password you created in Create a new administrator
- Select Enable PCAP (only applicable to FortiGate devices) which was enabled in Enable FortiGate to send logs and PCAP to FortiAnalyzer
- Hostname/IP - enter FortiAnalyzer hostname or IP address
- ***Port (Optional) -***if you have changed the default port enter the port number, if not, we default to 443
- adom (optional) - if not specified we default to “root”
Click on Finish
For general information on Integrations refer to the Integrations article.
20 - Fortinet FortiGate Next-Generation Firewall
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Fortinet FortiGate Next-Generation Firewall |
1)Ensure Connectivity Requirements are in place
2) From FortiGate Next-Generation Firewall console:
- Configure Syslog Forwarding Settings
- Configure Log Settings for Each Security Features
- Configure IPS Packet Logging
- Configure the Storage Settings
- Configure API Access Permission and Create API Key
3) If you have configured the options above, from the Samurai application:
CLI commands may depend on Forti OS version. Refer to the relevant Fortinet documentation if needed.
This guide assumes that you are not using the VDOM feature.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
FortiGate NGFW | Samurai Local Collector | UDP/514 (syslog) | For log transmission |
Samurai Local Collector | FortiGate NGFW | TCP/443 (https) default or your definition | Optional (based on optional configuration in this article) |
Configure Syslog Forwarding Settings
Execute the CLI commands outlined in the FortiGate Next Generation Firewall documentation.
config log syslogd4 setting
set status enable
set server [IP address of your Samurai Collector]
set mode udp
set port 514
unset source-ip
set format default
end
config log syslogd4 filter
set filter [see table 1]
set filter-type include
end
The following table shows the value indicating the send log for each security function.
Security Features | Value indicating the send log (One line each; no separator) |
---|---|
IPS/IDS Features | “ips-level(information)” |
IPS/IDS and AntiVirus Features | “ips-level(information)virus-level(information)” |
IPS/IDS and AntiVirus Features and Web Filter Features | “ips-level(information)virus-level(information)webfilter-level(information)” |
Table 1: Security Features Logs To Be Sent
Configure Log Settings for Each Security Features
Execute the CLI commands outlined in the FortiGate Next Generation Firewall documentation.
config firewall policy
edit [Policy ID]
...
set logtraffic [utm or all]
set logtraffic-start disable
...
next
end
config antivirus profile edit [Profile Name] ... set extended-log enable ... nextend
config webfilter profile
edit [Profile Name]
...
set log-all-url disable
set web-content-log enable
set web-filter-activex-log enable
set web-filter-command-block-log enable
set web-filter-cookie-log enable
set web-filter-applet-log enable
set web-filter-jscript-log enable
set web-filter-js-log enable
set web-filter-vbs-log enable
set web-filter-unknown-log enable
set web-filter-refere-log enable
set web-filter-cookie-removal-log enable
set web-url-log enable
set web-invalid-domain-log enable
set web-ftgd-err-log enable
set web-ftgd-quota-usage enable
set extended-log enable
set web-extended-all-action-log enable
next
end
config ips sensor
edit [Sensor Name]
...
set extended-log enable
config entries
edit [ID]
set location all
set severity info low
set protocol all
set os all
set application all
set status [enable or default]
(please refer to the table below)
set log enable
set log-packet disable
set log-attack-context disable
set action [pass or block or reset or default]
(please refer to the table below)
...
next
edit [ID]
set location all
set severity medium high critical
set protocol allset os all
set application all
set status [enable or default]
(please refer to the table 2)
set log enable
set log-packet enable
set log-attack-context disable
set action [pass or block or reset or default]
(please refer to the table 2)
...
Tip: Ensure evaluation order of IPS sensor entries so that the above settings apply properly.
Action | Status |
---|---|
pass or block or reset | enable |
default | default |
Table 2: Matching Actions to Status
Configure IPS Packet Logging
Execute the CLI command outlined in the FortiGate Next Generation Firewall documentation.
config ips settings set packet-log-history 5 set packet-log-post-attack 10 set ips-packet-quota 0end
Configure the Storage Settings
After checking [HD logging space] with the following command, determine the size of [log-quota] with the following calculation:
[log-quota] = [Total HD logging space] / 2
[log-quota] should be rounded down to the nearest thousand. In the following example, the [log-quota] is 88000.
diagnose sys logdisk usage
Total HD usage: 236286 MB/333 MB
Total HD logging space: 177214 MB
HD logging space usage for vdom "root": 106 MB/177214 MB
Execute the CLI command outlined in the FortiGate Next Generation Firewall documentation.
config log disk setting
set status enable
set ips-archive enable
set max-policy-packet-capture-size 100
set log-quota [calculated value above,for example here, 88000]
set maximum-log-age 5
set full-first-warning-threshold 75
set full-second-warning-threshold 90
set full-final-warning-threshold 95
set max-log-file-size 20
set roll-schedule daily
set diskfull overwrite
...
Configure API Access Permission and Create API Key
Follow the steps outlined in the FortiGate Next Generation Firewall documentation.
Use the following parameters when completing the deployment:
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest: api_admin |
Data Access | Read |
Table 3: Administrator Profile
Use the following parameters when completing the deployment:
Field Name | Parameter |
---|---|
Username | Whatever you want, however we suggest: api_user |
Administrator Profile | *Add your administrator profile created above (*we suggested api_admin) |
Trusted Hosts | IP Address of your Samurai Local Collector |
Table 4: REST API Admin
Complete the Fortinet FortiGate Next-Generation Firewall Integration
Login to the Samurai MDR web application
Click Integrations from the main menu
Click Create
Find and select Fortinet FortiGate Next-Generation Firewall
Select the relevant Local Collector and click Next
You will be presented with the Local Collector IP Address on the left of the screen
To configure Extended Telemetry Collection ensure it is enabled via the toggle
Enter the following information:
- Name for the Integration - the name will appear in the Samurai application for you to easily reference
- Description - optional but if completed will appear in the Samurai application for you to easily reference)
- Devicename - an arbitrary name to identify the Fortinet device
- API-Key - you generated under Create new Rest API Admin
- Select Enable PCAP
- Hostname/IP - hostname or IP address of Fortinet device to collect alerts from
- Port - if you have changed the default port enter the port number, if not, we default to 443
Click on Finish
For general information on Integrations refer to the Integrations article.
21 - Fortinet FortiWeb
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Fortinet FortiWeb |
This guide describes the steps required to configure Fortinet FortiWeb to send logs to a Samurai Local Collector deployed on your network. FortiWeb requires access to the Local Collector via syslog on port 514/UDP.
If you have deployed a FortiAnalyzer, please refer to the Fortinet FortiAnalyzer integration guide.
1) From FortiWeb console:
We reference version 7.0.4 documentation, be sure to select the version applicable to your FortiWeb
For more information on FortiWeb logging refer to Fortinet documentation ‘Logging’.
Configure syslog policy
Follow the steps outlined in the section entitled ‘Configuring Syslog settings’ located within the Fortinet documentation:
Use the parameters defined in the table below for each field:
Field Name | Parameter |
---|---|
Policy Name | Whatever you like, however we recommend ntt_syslog_policy |
IP Address (remote syslog server) | IP address of your Local Samurai Collector |
Port | 514 |
Format | Default |
Enable TLS | disabled |
Table 1 - Syslog settings
Configure trigger policy
Follow the steps outlined in the section entitled ‘Configuring triggers’ within the Fortinet documentation:
Use the parameters defined in the table below for each field:
Field Name | Parameter |
---|---|
Name | Whatever you like, however we recommend ntt_syslog_trigger |
Syslog Policy | We recommended ntt_syslog_policy |
Table 2 - Trigger policy
Configure log destination
Follow the steps outlined in the section entitled ‘Configure log destinations’ within the Fortinet documentation:
Use the parameter defined in the table below for each field:
Field Name | Parameter |
---|---|
Global Log Setting | Enable Syslog |
Syslog Policy | We recommended ntt_syslog_policy |
Log Level | Information |
Facility | leave as default (reserved for local use 7) |
Table 3 - Log destination
Enable log types
Follow the steps outlined within the Fortinet documentation:
Use the parameter defined in the table below for each field:
Field Name | Parameter |
---|---|
Other Log Settings | Enable the following: Enable Attack Log Enable Traffic Log Enable Event Log (Optional) |
System Alert Thresholds | Keep default values for all (CPU Utilization, Memory Utilization, Log Disk Utilization) |
Trigger Policy | We recommended ntt_syslog_trigger |
Table 4 - Log types
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
22 - GestioIP IPAM
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by submitting a ticket in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
GestioIP IPAM |
This guide describes the steps required to configure GestioIP asset information retrieval from a Samurai Local Collector deployed in your network.
The API access used by this integration requires the commercial edition of GestioIP.
This integration only provides contextual data for use by the MDR SOC. No data from this integration will be visible in the Samurai MDR application.
Connectivity Requirements
Source | Destination | Ports | Description |
---|---|---|---|
Samurai Local Collector | GestioIP IPAM | TCP/443 (HTTPS) | API access |
Create GestioIP User
Follow the steps outlined in section 8.1.1.1 GestioIP Documentation to create a local user or section 8.1.2.2 if using LDAP. If using the authorization feature of GestioIP, ensure that the created user is added to the Read Only default group.
Complete the GestioIP IPAM Integration
- Login to the Samurai MDR application
- Select Integrations
- Select Create
- Locate and click GestioIP IPAM
- Select a Samurai Local Collector
- Enter the URL to your GestioIP instance
- Enter User and Password as created in Creating GestioIP User
- Click Finish
23 - Google Workspace
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Google Workspace |
To complete this Integration you will need to perform steps in both Google Workspace and the Samurai Application.
The Google Workspace integration leverages two APIs which are part of the Admin SDK API
Follow the steps below:
1. From Google Workspace
- Enable the Admin SDK API
- Create a service account
- Create credentials for the service account
- Delegate domain-wide authority to the service account
2. From the Samurai application
Enable the Admin SDK API
Follow the Google API Console Help documentation:
A Google API Console project is required and will be created during the steps.
Ensure you login to the Google Console as a super administrator and use the following parameters when completing the steps:
Documentation Step | Field Name | Parameter |
---|---|---|
2 | Project Name | Anything you want but we recommend “SamuraiAPI” |
2 | Organization | The name of your organization |
2 | Location | Anything you want |
4 | API Library | Select and enable against the project created in Step 2: “Admin SDK API” “Google Workspace Alert Center API” |
Review the API Console Help pages if you require more information on Google APIs.
Create a service account
Follow the steps outlined within the Google documentation:
Ensure you have the Project selected that you created in Enable the Admin SDK API
Ignore the optional steps 4 and 6 when creating the service account.
Use the following parameters when completing the steps:
Documentation Step | Field Name | Parameter |
---|---|---|
3 | Service Account Name | Anything you want but we recommend “SamuraiAPI” |
3 | Service Account ID | Anything you want but we recommend “SamuraiAPI” |
3 | Service Account Description | Anything you want but we recommend “SamuraiAPI” |
Take note of the Service Account email address in Step 3 as it will be needed when you Complete the Google Workspace integration
Create credentials for the service account
Follow the steps outlined within the Google documentation:
Documentation Step | Field Name | Parameter |
---|---|---|
2 | Project | Select the project created in Enable the Admin SDK API |
2 | Service Account | Select the service account you created in Create a service account |
4 | Key Type | Ensure “JSON” is selected. |
Download the json file as it will be required when you Complete the Google Workspace integration
Delegate domain-wide authority to the service account
Follow the steps outlined within the Google documentation:
Ensure you login with a super admin account and take note of the associated email address as you will need in when you Complete the Google Workspace integration
Use the following parameters when completing the steps:
Documentation Step | Field Name | Parameter |
---|---|---|
2 | Service Accounrt | Ensure you select the service account created in Create a service account |
5e | OAuth scopes | https://www.googleapis.com/auth/admin.reports.audit.readonly |
https://www.googleapis.com/auth/admin.reports.usage.readonly | ||
https://www.googleapis.com/auth/apps.alerts |
Complete the Google Workspace integration
You will need:
- JSON file you downloaded in Create credentials for the service account
- The admin account email used in Delegate domain-wide authority to the service account
- Login to the Samurai MDR web application
- Select Integrations
- Select Create
- Locate and click Google Workspace
- Click Next (we leverage a Samurai Cloud Collector)
- Enter a Name of Integration
- Enter a Description (Optional)
- Enter your Service Account JSON (copy and paste from the json file you downloaded)
- Enter your Domain-Wide delegation account (the admin account email used for domain-wide delegation)
- Click Finish
For general information on Integrations refer to the Integrations article.
24 - Infoblox DDI
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Infoblox DDI |
This guide describes the steps required to configure an on-premise Infoblox DDI device to send logs to a Samurai Local Collector deployed in your network.
To complete this Integration you will need to:
Ensure correct network connectivity
You must ensure the following connectivity requirements are fulfilled:
Source | Destination | Ports | Description |
---|---|---|---|
Infoblox DDI | Samurai Local Collector | TCP/514 | For log transmission |
Perform Grid Configuration
Perform the steps outlined in the vendor documentation to add an external syslog server:
Perform the below settings adjustments. In case a setting property is not referenced below, simply use the default value:
- Address: Insert the IP address of the Samurai Local Collector.
- Transport: Select TCP.
- Node ID: Select Host Name.
- Severity: Select Info.
- Logging Category: Select Send selected categories and then enable all logging categories.
This is performed to enable prefixing of the log messages instead of using the Send all option when configuring Send selected categories.
Perform Data Management Configuration
Perform the steps outlined in the vendor documentation to configure DNS logging categories:
Perform the below settings adjustments. In case a setting property is not referenced below, simply use the default value:
- Logging Category: Select all the available categories.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
25 - Linux Authentication
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Linux Authentication |
This guide describes the steps required to configure Linux hosts to send authentication logs to a Samurai Local Collector deployed on your network by configuring rsyslog.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
Linux Host | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Configure log forwarding with rsyslog
Follow the below steps to configure rsyslog to forward authentication events.
Rsyslog prerequisites
Ensure the following statement is included in the main rsyslog configuration file, normally located at /etc/rsyslog.conf:
$IncludeConfig /etc/rsyslog.d/*.conf
If no IncludeConfig statement exist for the /etc/rsyslog.d/ directory, append it to the end of rsyslog.conf.
Create /etc/rsyslog.d/ntt_auth.conf
Create /etc/rsyslog.d/ntt_auth.conf and insert the below configuration block, enter the Local Collector IP in the Target field.
template(
name = "linux-auth"
type = "string"
string = "<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% linux_auth %STRUCTURED-DATA% %msg%"
)
if ($syslogfacility-text == "auth" or $syslogfacility-text == "authpriv") then {
action(
queue.type="LinkedList"
queue.size="10000"
type="omfwd"
template="linux-auth"
Target="<Local Collector IP>"
Port="514" Protocol="tcp")
}
Validate and restart service
Confirm that rsyslog can parse the configuration without any errors by running:
rsyslogd -N1
Then restart the rsyslog service:
sudo systemctl restart rsyslog
The authentication messages will now be forwarded to the Samurai Local Collector.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
26 - Microsoft Azure Activity Logs
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector | Samurai [Cloud Native] Collector |
---|---|---|---|
Microsoft Azure Activity Logs |
This guide describes the steps required to configure Microsoft Azure to send Activity Logs to Samurai via a cloud native collector.
Ensure that a cloud native collector has been deployed via the Samurai portal.
The storage account created via the cloud native collector needs to reside in the same region as the telemetry sources which will be ingested into the Samurai platform. For ingesting telemetry from multiple regions you need to create additional cloud native collector(s) for each region.
Take note of the name of the storage account created and which subscription it resides in. This will be used later when setting up the telemetry sources.
If you are planning to reuse an already deployed cloud native collector, the information about the created storage account and subscription can be found via:
- Navigate to the Samurai Portal.
- On the left navigation pane, click Collectors.
- Click on the name of the desired collector.
- Note down information about the:
- Subscription
- Storage account name
Alternatively, you can utilize the integration setup wizard via the Samurai portal for the desired telemetry source listed on Product Integration Guide page which shall provide you the same information required to setup your telemetry source.
Enabling Azure Activity logs
Follow the vendor documentation guide to enable Microsoft Azure Activity logs.
When following the vendor documentation, please perform the following adjustments:
Select the following log categories
- Administrative
- Policy
Ensure when configuring the Storage Account setting that it’s referencing the storage account that was setup during the creation of the cloud native collector.
Ensure the retention period aligns with your storage policies however we recommend at minimum 7 days.
For general information on Integrations refer to the Integrations article.
27 - Microsoft Azure Application Gateway
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
This guide describes all steps required to configure Microsoft Azure Application Gateway to send logs to a Storage account for ingestion to Samurai MDR.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector | Samurai [Cloud Native] Collector |
---|---|---|---|
Microsoft Azure Application Gateway |
Ensure that a cloud native collector has been deployed via the Samurai portal.
The storage account created via the cloud native collector needs to reside in the same region as the telemetry sources which will be ingested into the Samurai platform. For ingesting telemetry from multiple regions you need to create additional cloud native collector(s) for each region.
Take note of the name of the storage account created and which subscription it resides in. This will be used later when setting up the telemetry sources.
If you are planning to reuse an already deployed cloud native collector, the information about the created storage account and subscription can be found via:
- Navigate to the Samurai Portal.
- On the left navigation pane, click Collectors.
- Click on the name of the desired collector.
- Note down information about the:
- Subscription
- Storage account name
Alternatively, you can utilize the integration setup wizard via the Samurai portal for the desired telemetry source listed on Product Integration Guide page which shall provide you the same information required to setup your telemetry source.
Configure logging for Application Gateway
Follow the vendor documentation guide to enable Azure Application Gateway logs through the Azure Portal:
When following the vendor documentation, please perform the following adjustments:
Select the following log categories
- ApplicationGatewayAccessLogs
- ApplicationGatewayFirewallLogs
Ensure when configuring the Storage Account setting that it’s referencing the storage account that was setup during the creation of the cloud native collector.
Ensure the retention period aligns with your storage policies however we recommend at minimum 7 days.
For general information on Integrations refer to the Integrations article.
28 - Microsoft Azure Firewall
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector | Samurai [Cloud Native] Collector |
---|---|---|---|
Microsoft Azure Firewall |
This guide describes the steps required to configure a Microsoft Azure Firewall to send logs to Samurai via a cloud native collector.
Prerequisites
Ensure that a cloud native collector has been deployed via the Samurai portal.
The storage account created via the cloud native collector needs to reside in the same region as the telemetry sources which will be ingested into the Samurai platform. For ingesting telemetry from multiple regions you need to create additional cloud native collector(s) for each region.
Take note of the name of the storage account created and which subscription it resides in. This will be used later when setting up the telemetry sources.
If you are planning to reuse an already deployed cloud native collector, the information about the created storage account and subscription can be found via:
- Navigate to the Samurai Portal.
- On the left navigation pane, click Collectors.
- Click on the name of the desired collector.
- Note down information about the:
- Subscription
- Storage account name
Alternatively, you can utilize the integration setup wizard via the Samurai portal for the desired telemetry source listed on Product Integration Guide page which shall provide you the same information required to setup your telemetry source.
Enabling Azure Firewall logs
Follow the vendor documentation guide to enable Microsoft Azure Firewall logs.
When following the vendor documentation, please perform the following adjustments:
Select the following log categories
- Network Rule
- Application Rule
- Nat Rule
- Threat Intelligence
- IDPS Signature
- DNS query
Ensure when configuring the Storage Account setting that it’s referencing the storage account that was setup during the creation of the cloud native collector.
Ensure the retention period aligns with your storage policies however we recommend at minimum 7 days.
For general information on Integrations refer to the Integrations article.
29 - Microsoft Defender Advanced Hunting
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector | Samurai [Cloud Native] Collector |
---|---|---|---|
Microsoft Defender Advanced Hunting |
This guide describes the steps required to configure Microsoft Defender to send Advanced Hunting Logs to Samurai via a cloud native collector.
Ensure that a cloud native collector has been deployed via the Samurai portal.
The storage account created via the cloud native collector needs to reside in the same region as the telemetry sources which will be ingested into the Samurai platform. For ingesting telemetry from multiple regions you need to create additional cloud native collector(s) for each region.
Take note of the name of the storage account created and which subscription it resides in. This will be used later when setting up the telemetry sources.
If you are planning to reuse an already deployed cloud native collector, the information about the created storage account and subscription can be found via:
- Navigate to the Samurai Portal.
- On the left navigation pane, click Collectors.
- Click on the name of the desired collector.
- Note down information about the:
- Subscription
- Storage account name
Alternatively, you can utilize the integration setup wizard via the Samurai portal for the desired telemetry source listed on Product Integration Guide page which shall provide you the same information required to setup your telemetry source.
Enabling Defender Advanced Hunting Logs
Follow the vendor documentation guide to enable Advanced Hunting Logs data streaming to blob storage.
Configure Microsoft Defender for Endpoint to stream Advanced Hunting events to your Storage account
Ensure when configuring the Storage Account setting that it’s referencing the storage account that was setup during the creation of the cloud native collector.
Ensure the retention period aligns with your storage policies however we recommend at minimum 7 days.
For general information on Integrations refer to the Integrations article.
30 - Microsoft DHCP Server
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Microsoft DHCP Server |
Use this document to install and configure the Filebeat agent to send Microsoft DHCP Server logs to Samurai using the Samurai Local Collector deployed in your network.
To complete this Integration you will need to:
- Ensure correct network connectivity
- Download & Install Filebeat
- Configure & Enable DHCP Server Audit Logging
- Configure & Start Filebeat
This guide is based on the premise of a single Samurai Local Collector installation with deployment of a single Windows host with the DHCP Server service enabled and configured. Repeat these steps outlined in this guide for each Microsoft DHCP Server and site.
Ensure correct network connectivity
You must ensure the following connectivity requirements are fulfilled:
Source | Destination | Ports | Description |
---|---|---|---|
Microsoft DHCP Server Host | Samurai Local Collector | TCP/5044 | For log transmission |
Download & Install Filebeat
Perform the steps outlined in Step 1: Install Filebeat as per the vendor documentation.
Make sure to click the Windows tab for OS selection.
Configure & Enable DHCP Server Audit Logging
DHCP Server Audit Logging should be enabled by default and these steps are used to validate that logging is enabled and determine the logging path.
Configure via Powershell
To view the DHCP Audit logging config, run the command Get-DhcpServerAuditLog.
PS C:\> Get-DhcpServerAuditLogPath : C:\Windows\system32\dhcpEnable : TrueMaxMBFileSize : 70DiskCheckInterval : 50MinMBDiskSpace : 20
Verify that the flag Enabled is set to True.
In case logging is not enabled, run the commend Set-DhcpServerAuditLog. Example command with arguments is presented below.
PS C:\> Set-DhcpServerAuditLog -Enable $True -Path C:\dhcp
The DHCP server needs to be restarted after logging has been enabled, run the following command to restart the service.
PS C:\> Restart-Service DHCPServer
Note down the file path that has been configured, this will be used later in the section Configure & Start Filebeat.
Configure & Start Filebeat
- Access the Filebeat installation folder and open and edit the file filebeat.yml.
- Modify the below template by replacing the section IP_OF_LOCAL_COLLECTOR with the IP address of the Samurai Local Collector.
- Modify the paths section of the template to use the path that was configured for the DHCP Server Audit log file location from Configure & Enable DHCP Server Audit Logging.
Follow the vendor documentation when configuring the paths section.
# ============================== Filebeat inputs ===============================
filebeat.inputs:
- type: filestream
id: win_dhcp
enabled: true
paths:
- 'C:\Windows\System32\dhcp\Dhcp*'
include_lines: ['^\d+,(\d+\/){2}\d+,.*$']
tags: [win_dhcp_server]
#------------------------------ Logstash Output -------------------------------
output.logstash:
hosts: ["IP_OF_LOCAL_COLLECTOR:5044"]
Replace the default configuration of filebeat.yml with the modified template and save the file.
Perform the steps outlined in Step 5: Start Filebeat as per the vendor documentation to start the service.
Make sure to click the Windows tab for OS selection.
31 - Microsoft DNS Server
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Microsoft DNS Server |
Use this document to install and configure the Filebeat agent to send Microsoft DNS Server logs to Samurai using the Samurai Local Collector deployed in your network.
To complete this Integration you will need to:
- Ensure correct network connectivity
- Download & Install Filebeat
- Configure & Enable Microsoft DNS Server Debug Logging
- Configure & Start Filebeat
This guide is based on the premise of a single Samurai Local Collector installation with deployment of a single Windows host with the DNS Server service enabled and configured. Repeat these steps outlined in this guide for each Microsoft DNS Server and site.
Ensure correct network connectivity
You must ensure the following connectivity requirements are fulfilled:
Source | Destination | Ports | Description |
---|---|---|---|
Microsoft DNS Server Host | Samurai Local Collector | TCP/5044 | For log transmission |
Download & Install Filebeat
Perform the steps outlined in Step 1: Install Filebeat as per the vendor documentation.
Make sure to click the Windows tab for OS selection.
Configure & Enable Microsoft DNS Server Debug Logging
All steps up until Step 4 can be ignored if DNS Server debug logging have already been enabled and configured.
Follow the steps outlined in To select and enable debug logging options on the DNS server as per the vendor documentation.
Configure Packet direction & Packet Contents*.*
- Keep default configuration or follow the minimum requirement below.
- Minimum requirement is to enable logging for Outgoing Response.
Figure 1 – Example of default configuration once “Log packets for debugging” has been enabled.
Configure an appropriate log location and name of the log file as well as a suitable Maximum Size (bytes) according to your system needs.
Note down the file path that has been configured, this will be used later in the section Configure & Start Filebeat.
Configure & Start Filebeat
- Access the Filebeat installation folder and open and edit the file filebeat.yml.
- Modify the below template by replacing the section IP_OF_LOCAL_COLLECTOR with the IP address of the Samurai Local Collector.
- Modify the paths section of the template to use the path that was configured for the DNS Server debug log file location from Configure & Enable Microsoft DNS Server Debug Logging.
Follow the vendor documentation when configuring the paths section.
# ============================== Filebeat inputs ===============================
filebeat.inputs:
- type: filestream
id: win_dns_server
enabled: true
paths:
- 'C:\dns_logs\*'
include_lines: ['^\d{1,4}.\d{1,2}.\d{1,4}\s.*?$']
tags: [win_dns_server]
# ------------------------------ Logstash Output -------------------------------
output.logstash:
hosts: ["IP_OF_LOCAL_COLLECTOR:5044"]
- Replace the default configuration of filebeat.yml with the modified template and save the file.
- Perform the steps outlined in Step 5: Start Filebeat as per the vendor documentation to start the service.
Make sure to click the Windows tab for OS selection.
32 - Microsoft Entra ID
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector | Samurai [Cloud Native] Collector |
---|---|---|---|
Microsoft Entra ID |
This guide describes the steps required to configure a Microsoft Entra ID to send logs to Samurai via a cloud native collector.
Prerequisites
Ensure that a cloud native collector has been deployed via the Samurai portal.
The storage account created via the cloud native collector needs to reside in the same region as the telemetry sources which will be ingested into the Samurai platform. For ingesting telemetry from multiple regions you need to create additional cloud native collector(s) for each region.
Take note of the name of the storage account created and which subscription it resides in. This will be used later when setting up the telemetry sources.
If you are planning to reuse an already deployed cloud native collector, the information about the created storage account and subscription can be found via:
- Navigate to the Samurai Portal.
- On the left navigation pane, click Collectors.
- Click on the name of the desired collector.
- Note down information about the:
- Subscription
- Storage account name
Alternatively, you can utilize the integration setup wizard via the Samurai portal for the desired telemetry source listed on Product Integration Guide page which shall provide you the same information required to setup your telemetry source.
Enabling Entra ID activity logs
Follow the vendor documentation guide to archive Microsoft Entra logs to an Azure storage account:
When following the vendor documentation, please perform the following adjustments:
Select the following log categories
- AuditLogs
- SignInLogs
- NonInteractiveUserSignInLogs
- ServicePrincipalSignInLogs
- ManagedIdentitiySignInLogs
- ProvisioningLogs
- ADFSSignInLogs
Please note NonInteractiveUserSignInLogs may cause high log volume
Ensure when configuring the Storage Account setting that it’s referencing the storage account that was setup during the creation of the cloud native collector.
Ensure the retention period aligns with your storage policies however we recommend at minimum 7 days.
For general information on Integrations refer to the Integrations article.
33 - Microsoft Graph (Security)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Microsoft Graph (Security) |
Supported Microsoft Security products
The Microsoft Graph Security API supports collection of alerts for multiple Microsoft Security products. An updated list can be found in the Microsoft documentation. Support for the following products has been validated by Samurai MDR:
- Microsoft Entra ID Protection
- Microsoft 365 Defender
- Microsoft Defender for Cloud Apps
- Microsoft Defender for Endpoint
- Microsoft Defender for Identity
- Microsoft Defender for Office 365
- Microsoft Defender for Cloud
Prerequisites
The user must have Global administrative access to the Microsoft 365 Defender and Microsoft Azure Portal.
You must have an Microsoft Entra ID P2 plan for the Privileged Identity Management features discussed below.
Recommended Advanced Settings for Defender for Endpoint
If you are a customer with the Incident Response (IR) Retainer, in order to ensure an optimal service delivery and a quick turnaround from activation to remediation by the NTT Incident Response team the below features are recommended to be enabled in Defender for Endpoint:
- Live response
- Live response for servers
- Live response unsigned script execution
Follow the Microsoft documentation - Configure advanced features in Defender for Endpoint to enable the features.
To complete this Integration you will need to perform actions in both the Azure Portal and Samurai Application:
1. Azure Portal
2. From the Samurai application
- Complete the Microsoft Graph (Security) Integration
Application Registration
Follow the steps outlined within section entitled Register an application in the Microsoft Graph API documentation using the following parameters.
Field Name Parameter Supported account type Accounts in this organizational directory only Redirect URL Leave blank After creating the App Registration, record the Application (client) ID and Directory (tenant) ID.
Follow the steps outlined within section entitled Add a client secret in the Microsoft Graph API documentation.
Record the secret value as this is only shown once.
Follow the steps outlined within section entitled Configure permissions for Microsoft Graph in the Microsoft Graph API documentation. Select the following permissions.
SecurityAlert.Read.AllRemember to grant administrator consent after selecting permissions.
Enable MDR SOC access to Microsoft 365 Defender
The steps outlined below is required for NTT SOC to perform remote isolation and further analysis through the Microsoft 365 Defender portal. You may also wish to refer to the Microsoft documentation - Granting managed security service provider (MSSP) access
Prerequisites
Ensure role-based access control (RBAC) is enabled in your Microsoft Defender Security Center.
To enable RBAC in Microsoft Defender Security Center, navigate to Settings > Permissions > Roles and Turn on roles from a user account with Global Administrator or Security Administrator rights.
This feature also requires an Entra ID P2 plan for the Privileged Identity Management feature.
Create an Entra ID Group and assign role
To create an Entra ID group for NTT, perform the following steps:
Log in to Entra ID admin center
Navigate to Groups > All groups > New group
Select Security from the Group type list
Ensure that Microsoft Entra roles can be assigned to the group is set to Yes
You cannot change this setting later, so make sure it is enabled. If you do not see this option, check that you have an Entra ID P2 license and have the preview features enabled.
After creating the group, follow the steps in Assign Microsoft Entra roles to groups to assign the Security Reader role to the newly created group.
Add NTT as Connected Organization
Perform the following steps to add NTT as a connected organization:
- Navigate to Identity Governance
- Click Connected organizations
- Click Add connected organization
- On the Basics tab*,* specify a Name and Description
- On the Directory + domain tab, perform the following steps:
- Click Add directory + domain
- In the Select directories + domains field, search for security.ntt
Create a Resource Catalog
In the Entra ID portal under Identity Governance perform the following steps:
- Navigate to the Catalogs tab
- Click New catalog
- Specify a Name and Descriptions, keep other values default
- Click Create
Create an Access Package
An access package enables you to do a one-time set up of resources and policies that automatically administers access for the life of the access package.
To create a new access package, perform the following steps:
Navigate to Identity Governance
Click Access packages
Click New access package
Specify a Name and Description*,* select the Catalog created in the previous step
In the Resource roles tab, add the group created in previously and set Role to Member
In the Requests tab, ensure the following options are set (leave other settings as default):
Set Users who can request access to For users not in your directory
Under Select connected organizations, select NTT
Set Require approval to Yes
Under First Approver, add at least one fallback approver
Set Enable new requests to Yes
In the Lifecycle tab, set Access Reviews to No
After creating the access package provide the My Access portal link to NTT.
Define your Sponsors
Sponsors are the people responsible for approving requests made by NTT staff. You may define internal and/or external sponsors.
Internal sponsors are select individuals from within your organization who can approve requests from NTT. External sponsors are select individuals from within NTT who can approve these on your behalf.
NTT recommends selecting external sponsors and obtaining a list of names during the MDR Onboarding. These names include managers and team leads who support the service.
Setting up sponsors is a time-consuming process as it requires approving access requests from NTT staff. Therefore, NTT recommends you define external sponsors to enable NTT to manage this process.
Initial NTT users will need to be approved by the selected Fallback approvers, after which they can be added as external sponsors.
To add external sponsors, select the Connected Organization and then Sponsors.
Complete the Microsoft Graph (Security) Integration
- Login to the Samurai MDR portal
- Select Integrations
- Select Create
- Locate and click Microsoft Graph (Security)
- Click Next (we leverage a Samurai Cloud Collector)
- Enter Tenant ID, Application ID and Client Secret as created in Application Registration
- Click Finish
34 - Microsoft IIS
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Microsoft IIS |
Use this document to install and configure the Filebeat agent to send Microsoft IIS logs to Samurai using the Samurai Local Collector deployed in your network.
To complete this Integration you will need to:
- Ensure correct network connectivity
- Download & Install Filebeat
- Configure & Enable Microsoft IIS Logging
- Configure & Start Filebeat
This guide is based on the premise of a single Samurai Local Collector installation with deployment of a single Windows host with Microsoft IIS service(s) enabled and configured.
Ensure correct network connectivity
You must ensure the following connectivity requirements are fulfilled:
Source | Destination | Ports | Description |
---|---|---|---|
Microsoft IIS Host | Samurai Local Collector | TCP/5044 | For log transmission |
Download & Install Filebeat
Perform the steps outlined in Step 1: Install Filebeat as per the vendor documentation.
Make sure to click the Windows tab for OS selection.
Configure & Enable Microsoft IIS Logging
Follow the steps outlined below as per the vendor documentation for either per-site or per-server configuration that is best suited to your setup.
During step 4 in the vendor documentation, select W3C logging format.
Under “Select Fields…”, select all available fields:
Configure a suitable log file path for the logging files according to your system requirements.
During step 6 in the vendor documentation, configure Log File Rolloversettings and **Maximum file size (in bytes)**according to your system needs and requirements.
Note down the file path that has been configured, this will be used later in the section Configure & Start Filebeat.
Configure & Start Filebeat
- Access the Filebeat installation folder and open and edit the file filebeat.yml.
- Modify the below template by replacing the section IP_OF_LOCAL_COLLECTOR with the IP address of the Samurai Local Collector.
- Modify the paths section of the template to use the path that was configured for the ISS Web Server log file location from Configure & Enable Microsoft IIS Logging.
Follow the vendor documentation when configuring the paths section.
# ============================== Filebeat inputs ===============================
filebeat.inputs:
- type: filestream
id: microsoft_iis
enabled: true
paths:
- 'c:\inetpub\logs\LogFiles\*\*.log'
include_lines: ['^[^#].*?$']
tags: [microsoft_iis]
# ------------------------------ Logstash Output -------------------------------
output.logstash:
hosts: ["IP_OF_LOCAL_COLLECTOR:5044"]
Replace the default configuration of filebeat.yml with the modified template and save the file.
Perform the steps outlined in Step 5: Start Filebeat as per the vendor documentation to start the service.
Make sure to click the Windows tab for OS selection.
35 - Microsoft Office 365
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Microsoft Office 365 |
To complete this Integration you will need to:
1) Within Microsoft 365:
- Ensure Microsoft Office 365 auditing is enabled
- Ensure Azure Exchange mailbox auditing is enabled (if monitoring Azure Exchange)
- Register application with Azure Active Directory
- Generate application secret key
- Specify permissions for the app
2) From the Samurai application:
Ensure Microsoft 365 auditing is enabled
Audit logging will be turned on by default for Microsoft 365 and Office 365 enterprise organizations. However, when setting up a new Microsoft 365 or Office 365 organization, you should verify the auditing status for your organization
Follow the steps outlined within the Office365 documentation to ensure audit logging is enabled:
Verify that Azure Exchange Mailbox Auditing is Enabled
This is only necessary if monitoring Azure Exchange.
Azure Exchange Mailbox Auditing is enabled by default however verify this by following the Office365 documentation:
Register application with Azure Active Directory
Follow the steps outlined within the Office365 documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Name of app | Whatever you want, however we suggest NTT_app |
Supported Account Types | Select Accounts in this organizational directory only (single tenant) |
Redirect URI | Not required |
Table 1: App registration
Take note of the Application (client) ID and the Directory (tenant) ID as this information will be needed when you Complete the Office 365 Integration within the Samurai application.
Generate Application Secret Key
Follow the steps within the Office365 documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Description | Whatever you want, however we suggest NTT_app |
Expires | The expiration period will depend on your company’s security policies. It will be your responsibility to create a new key should it expire and update the Integration when you Complete the Office 365 Integration |
Redirect URI | Not required |
Table 2: Secret key
Take note of the Client secret as this information will be needed when you Complete the Office 365 Integration within the Samurai application.
Specify permissions for the app
Follow the steps within the Office365 documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Request API permissions | Application permissions |
Permissions | ActivityFeed.Read ActivityFeed.ReadDlp ServiceHealth.Read |
Table 3: App permissions
Complete the Microsoft Office 365 Integration
You will need:
- Application (client) ID and Directory (tenant) ID created during Register application with Azure Active Directory
- Client Secret created during Generate Application Secret Key
- Login to the Samurai MDR web application
- Select Integrations
- Select Create
- Locate and click Microsoft Office 365
- Click Next (we leverage a Samurai Cloud Collector)
- Enter a Name of Integration
- Enter a Description (Optional)
- Enter your Application (client) ID
- Enter your Directory (tenant) ID
- Enter your Secret Key (client Secret)
- Click Finish
For general information on Integrations refer to the Integrations article.
36 - Microsoft Windows Event Log
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Microsoft Windows Event Log |
Use this document to install and configure the Winlogbeat agent to send Microsoft Windows Event Logs to Samurai using the Samurai Local Collector deployed in your network.
To complete this Integration you will need to:
This guide is based on the premise of a single Samurai Local Collector installation with deployment of a single Windows host. Repeat these steps outlined in this guide for each Windows host and site.
Ensure correct network connectivity
You must ensure the following connectivity requirements are fulfilled:
Source | Destination | Ports | Description |
---|---|---|---|
Windows Host | Samurai Local Collector | TCP/5044 | For log transmission |
Download & Install Winlogbeat
Perform the steps outlined in Step 1: Install Winlogbeat as per the vendor documentation.
Configure & Start Winlogbeat
- Access the Winlogbeat installation folder and open and edit the file winlogbeat.yml.
- Modify the below template by replacing the section IP_OF_LOCAL_COLLECTOR with the IP address of the Samurai Local Collector.
# ======================== Winlogbeat specific options =========================
winlogbeat.event_logs:
- name: Application
- name: System
- name: Security
- name: Microsoft-Windows-Sysmon/Operational
# ------------------------------ Logstash Output -------------------------------
output.logstash:
hosts: ["IP_OF_LOCAL_COLLECTOR:5044"]
Default recommendation is to ingest logs from Application, System, Security and Sysmon (if used and installed). Optionally, if you want to ingest other event logs, follow the vendor guidelines to find the correct event log names to use and modify the template accordingly.
- Replace the default configuration of winlogbeat.yml with the modified template and save the file.
- Perform the steps outlined in Step 5: Start Winlogbeat as per the vendor documentation to start the service.
The section about authorized to publish events can be ignored.
37 - Palo Alto Networks Cortex XDR Pro
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Palo Alto Networks Cortex XDR Prevent and Pro |
To complete this Integration you will need to:
1) From your Cortex XDR Gateway:
2) From the Samurai application:
Configure an API Key to allow us to collect telemetry
Follow Steps 1-3 outlined within the Palo Alto Networks documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Security Level | Standard |
Enable Expiration Date | not required (do not select) |
Roles | Viewer |
Be sure to save a copy of the following information as it required to complete the integration:
- API key (as noted in the documentation you will not be able to view it again!)
- API KeyID
- FQDN (for the Base URL e.g https://api-{fqdn}
Complete the Palo Alto Cortex XDR Pro Integration
- Login to the Samurai MDR web application
- Select Integrations
- Select Create
- Locate and click Palo Alto Networks Cortex XDR Pro
- Click Next (we leverage a Samurai Cloud Collector)
- Enter a Name of Integration
- Enter a Description (Optional)
- Enter your Device Name
- Enter the URL, API KeyID and API Key created in Configure an API Key to allow us to collect telemetry
- Click Finish
For general information on Integrations refer to the Integrations article.
38 - Palo Alto Networks: Next-Generation Firewall
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Palo Alto Networks Next-Generation Firewall |
To complete this Integration you will need to:
1) Ensure Connectivity Requirements are in place
2) From your Palo Alto Networks Next Generation Firewall:
- Configure syslog to your Samurai Local Collector
- Create Log Forwarding Profiles
- Create URL Filtering Profile
- Create Filtering Profile Group
- Create Security Policy Rule
- Enable Packet Capture Profiles
- Enable API Access
4) From the Samurai application:
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
PAN NGFW | Samurai Local Collector | UDP/514 (syslog) | For log transmission |
Samurai Local Collector | PAN NGFW | TCP/443 (https) | Packet captures |
Configure syslog to your Samurai Local Collector
Follow the steps outlined within the Palo Alto Networks documentation to configure your firewall to send logs to your Samurai Local Collector:
If you do not have Panorama deployed:
If you have Panorama deployed please refer to Palo Alto Networks: Panorama (Be aware of steps based on your Panorama deployment mode)
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Server Profile Name | Whatever you want, however we suggest NTT_Syslog_Profile |
Syslog Server | IP address of your Samurai Collector |
Transport | UDP |
Port | 514 (Default) |
Format | BSD (Default) |
Facility | keep as default |
Custom Log Format | keep as default for every log type |
Create Log Forwarding Profiles
Follow the steps outlined within the Palo Alto Networks documentation:
You will need to configure Log forwarding profiles for each log type as per the table below:
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest NTT_Log_Fwd_Profile |
Name for each Log Type | Whatever you want, however we suggest NTT_<log type>_Fwd_Profile. Where <log type> denotes each log type available |
Log Type | All (you need to include all log types eg. traffic, threat, wildfire etc) |
Filter | All logs |
Forward Method | Select the syslog Server Profile you configured in* Configure syslog to Samurai Local Collector* (we suggested NTT_Syslog_Profile) |
Create URL Filtering Profile
Follow the steps outlined within the Palo Alto Networks documentation:
(Alternatively, modify your existing URL filtering profile(s). If reusing existing profile(s), ensure that no URL categories are set to the action allow unless you do not want them logged)
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest NTT_URL_Profile |
Site Access for Each Category | Alert. If your company policy requires Block for certain categories, set it that way. |
User Credential Submission for Each Category | Alert. If your company policy requires Block for certain categories, set it that way. |
Settings | Ensure Log container page only is not selected |
HTTP Header Logging | Enable*: User-Agent, Referer, X-Forwarded-For* |
Create Filtering Profile Group
Follow the steps outlined within the Palo Alto Networks documentation:
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Security Profile Group name | Whatever you want, however we suggest NTT_Security_Profile |
Filtering Profiles | All as applicable eg. Anti-virus, Anti-Spyware, Vulnerability Protection, and URL Filtering created in Create URL Filtering Profile and Enable Packet Capture Profiles |
Create Security Policy Rule
Follow the steps outlined within the Palo Alto Networks documentation:
Use the following parameters in the Actions tab when completing the steps:
Field Name | Parameter |
---|---|
Profile Setting | Select the Group Profile you provided in Create Filtering Profile Group (we suggested NTT_Security_Profile) |
Log at Session Start | Enabled |
Log at Session End | Enabled |
Log Forwarding | Select the Log Forwarding Profile you provided in Create Log Forwarding Profile (we suggested NTT_Log_Fwd_Profile) |
Enable Packet Capture Profiles
Follow the steps outlined within the Palo Alto Networks documentation:
You will need to enable Packet Capture for for each profile as tables below:
Anti Virus Profile
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest NTT_AV_Profile |
Anti-Virus | Enable Packet-Capture |
Anti-Spyware Profile
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest NTT_Spyware_Profile |
Severity Critical Severity High Severity Medium | Select extended-capture |
Vulnerability Protection Profile
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest NTT_IDS_Profile |
Severity Critical Severity High Severity Medium | Select extended-capture |
Enable API Access
Follow the steps outlined within the Palo Alto Networks documentation:
Creating a new Admin Role Profile to be used specifically by the Samurai platform.
Under XML API ensure to disable all permissions except the following:
- Log
- Operation Requests
- Export
Once complete you now need to get the API key to be used in the Samurai application. Follow the Palo Alto documentation:
When following the steps be sure to use the username and password you created in the previous step. Once successful make a note of the <Key> string as you will need this later when you Complete the Palo Alto Networks NG Firewall Integration
Complete the Palo Alto Networks Next-Generation Firewall Integration
Login to the Samurai MDR web application
Click Integrations from the main menu
Click Create
Find and select Palo Alto Networks Next-Generation Firewall
Select the relevant Local Collector and click Next
You will be presented with the Local Collector IP Address on the left of the screen
To configure Extended Telemetry Collection ensure it is enabled via the toggle
Enter the following information
- Name for the Integration - the name will appear in the Samurai application for you to easily reference
- Description - optional but if completed will appear in the Samurai application for you to easily reference)
- Physical device name - this name is used as the source for alerts for this integration
- API-Key you captured in Enable API Access
- Hostname/IP - hostname or IP address of Palo Alto device to collect alerts from
Click on Finish
For general information on Integrations refer to the Integrations article.
39 - Palo Alto Networks: Panorama
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Palo Alto Networks Panorama |
To complete this Integration you will need to:
1) Ensure Connectivity Requirements are in place
2) From your Palo Alto Networks Panorama:
- Configure syslog to your Samurai Local Collector
- Enable API Access
- Obtain your Wildfire API key (if applicable)
4) From the Samurai application:
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
Panorama | Samurai Local Collector | UDP/514 (syslog) | For log transmission |
Samurai Local Collector | Panorama | TCP/443 (https) | For Packet Captures |
Configure syslog to your Samurai Local Collector
Follow the steps outlined within the Palo Alto Networks documentation to configure your Panorama to send logs to your Samurai Local Collector:
Ensure to select your current version, we have linked version 10.2 above.
Use the following parameters when completing the steps:
Documentation Step | Field Name | Parameter |
---|---|---|
4.2 | Server Profile Name | Whatever you want, however we suggest NTT_Syslog_Profile |
4.2 | Syslog Server | IP address of your Samurai Collector |
4.2 | Transport | UDP |
4.2 | Port | 514 (Default) |
4.2 | Format | BSD (Default) |
4.2 | Facility | keep as default |
4.4 | Custom Log Format | keep as default for every log type |
If you will not be using the Panorama Management interface you will need to configure an alternative ethernet interface to forward syslog by following the documentation from Step 5.
You must have your Palo Alto Next Generation Firewalls configured to forward logs to Panorama - if you have not configured this yet then follow the steps outlined in Configure Log Forwarding to Panorama
Enable API Access
Follow the steps outlined within the Palo Alto Networks documentation:
Creating a new Admin Role Profile to be used specifically by Samurai.
Under XML API ensure to disable all permissions except the following:
- Log
- Operation Requests
- Export
Once complete you now need to get the API key to be used in the Samurai application. Follow the Palo Alto documentation:
When following the steps be sure to use the username and password you created in the previous step. Once successful make a note of the <Key> string as you will need this later when you Complete the Palo Alto Networks Panorama Integration
Obtain your Wildfire API key
If you leverage Wildfire, follow the steps outlined in the Palo Alto documentation to obtain your Wildfire API key:
ensure to select your deployment model when obtaining your API key.
Complete the Palo Alto Networks Panorama Integration
Login to the Samurai MDR web application
Click Integrations from the main menu
Click Create
Find and select Palo Alto Networks Next-Generation Firewall Panorama
Select the relevant Local Collector and click Next
You will be presented with the Local Collector IP Address on the left of the screen
To configure Extended Telemetry Collection ensure it is enabled via the toggle
Enter the following information
- Name for the Integration - the name will appear in the application for you to easily reference
- Description - optional but if completed will appear in the application for you to easily reference)
- Manager name- this name is used as the source for alerts for this integration
- API-Key you captured in Enable API Access
- Wildfire API-key - to enable Wildfire telemetry collection include the key you captured in Obtain your Wildfire API key
- Hostname/IP - hostname or IP address of Palo Alto device to collect alerts from
Click on Finish
For general information on Integrations refer to the Integrations article.
40 - PowerDNS Recursor
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
PowerDNS Recursor |
This guide describes the steps required to configure PowerDNS Recursor logs to a Samurai Local Collector deployed on your network by configuring rsyslog.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
PowerDNS Host | Samurai Local Collector | TCP/514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Configure PowerDNS
Ensure that Structured Logging is enabled and Quiet is disabled in the PowerDNS Recursor configuration file, normally located at /etc/powerdns/recursor.conf:
structured-logging=yes
quiet=no
Configure log forwarding with rsyslog
Follow the below steps to configure rsyslog to forward authentication events.
Rsyslog prerequisites
Ensure the following statement is included in the main rsyslog configuration file, normally located at /etc/rsyslog.conf:
$IncludeConfig /etc/rsyslog.d/*.conf
If no IncludeConfig statement exist for the /etc/rsyslog.d/ directory, append it to the end of rsyslog.conf.
Create /etc/rsyslog.d/ntt_powerdns.conf
Create /etc/rsyslog.d/ntt_powerdns.conf and insert the below configuration block, enter the Local Collector IP in the Target field.
template(
name = "powerdns-recursor"
type = "string"
string = "<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% powerdns_recursor %STRUCTURED-DATA% %msg%"
)
if ($programname == "pdns-recursor") then {
action(
queue.type="LinkedList"
queue.size="10000"
type="omfwd"
template="powerdns-recursor"
Target="<Local Collector IP>"
Port="514"
Protocol="tcp"
)
}
Validate and restart service
Confirm that rsyslog can parse the configuration without any errors by running:
rsyslogd -N1
Then restart the rsyslog service:
sudo systemctl restart rsyslog
The log messages will now be forwarded to the Samurai Local Collector.
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
41 - Proofpoint Targeted Attack Protection (TAP)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Proofpoint Targeted Attack Protection (TAP) |
The guide outlined the steps required to configure Proofpoint Targeted Attack Protection (TAP) to facilitate log ingestion into the Samurai platform.
To complete this Integration you will need to:
2) From your TAP dashboard:
3) From the Samurai application:
Generate TAP Service Credentials
- Follows the steps outlined within section entitled Generate TAP Service Credentials in the Proofpoint TAP documentation.
Ensure you copy the Service Principle and Secret as you will need this information to complete the integration.
Complete the Proofpoint Targeted Attack Protection (TAP)
Login to your Samurai tenant
Select Integrations
Select Create
Locate and click Proofpoint Targeted Attack Protection
Click Next (we leverage a Samurai Cloud Collector)
Enter a Name of Integration
Enter a Description (Optional)
8. Enter a Devicename
Enter your Service Principle
Enter your Secret
Click Finish
For general information on Integrations refer to the Integrations article.
42 - Sophos Central
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Sophos Central |
Sophos Central telemetry is collected via REST API.
Supported Products
Sophos Central can integrate with many Sophos and Third-Party products. The following products are supported through the Sophos Central integration:
- Sophos Intercept X
To complete this Integration you will need to:
1) Within Sophos Central Admin
2) From the Samurai application:
Create an API Token
Follow steps outlined within the Sophos documentation:
Be sure to save a copy of the following information as it required to complete the integration:
- Client ID
- Client Secret (as noted in the documentation you will not be able to view it again!)
Complete the Sophos Central Integration
You will need:
- Client ID: (from Create an API Token)
- Client Secret: (from Create an API Token)
- Login to the Samurai MDR web application
- Select TIntegrations
- Select Create
- Locate and click Sophos Central
- Click Next (we leverage a Samurai Cloud Collector)
- Enter a Name of Integration
- Enter a Description (Optional)
- Enter your Devicename
- Enter your Client ID
- Enter your Client Secret
- Enter your Tenant ID (optional) - if not included we will identify from your credentials
- Click Finish
For general information on Integrations refer to the Integrations article.
43 - Squid Proxy
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by submitting a ticket in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Squid Proxy Server |
This guide describes the steps required to configure Squid Proxy Server to send logs to a Samurai Local Collector deployed on your network. Your Squid Proxy device(s) require access to the Local Collector via syslog on port 514/UDP.
To complete this Integration you will need to:
1) From your Squid Proxy Server
Configure Log Format
Complete these steps to configure the Squid log format.
- Log into the Squid Server edit the squid.conf file
The default location for this file is /etc/squid/squid.conf
- Add the following to the end of the file:
logformat squid-ntt timestamp="%{%Y-%m-%dT%H:%M:%SZ}tg" vendor="Squid" src="%>A" url="%ru" src_ip=%>a status=%>Hs http_user_agent="%{User-Agent}>h" http_method=%>rm http_content_type=%mt bytes_in=%<st bytes_out=%>st user=%un http_referer="%{Referer}>h" uri_path="%>rp" url_port=%<rP uri_scheme=%>rs duration=%<tt dest_port=%>rP src_port=%>p dest_host="%<A" dest_ip=%<a proxy_ip=%>la proxy_dest_port=%>lp proxy_src_port=%<lp vendor_squid_status=%Ss
access_log syslog:local4.info logformat=squid-ntt
Save and close the file.
Restart the Squid Proxy service.
Configure Syslog
Edit the syslog.conf file
Add the following to the end of the configuration file, replace [Samurai Local Collector IP address) with the IP address of the Samurai Local Collector deployed on your network:
# Logging for NTT Local Collector
local4.info @@[Samurai Local Collector IP address]
Save and close the file.
Restart the syslogd service
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
44 - Trellix Endpoint Security (ENS)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Trellix Endpoint Security (ENS) |
This guide describes the steps required to configure Trellix Endpoint Security (ENS) to send logs through a Trellix ePolicy Orchestrator (On-prem) to a Samurai Local Collector deployed in your network.
Connectivity Requirements
You must ensure the following connectivity requirements are available:
Source | Destination | Ports | Description |
---|---|---|---|
Trellix ePolicy Orchestrator | Samurai Local Collector | TCP/6514 (syslog) | For log transmission |
Table 1: Connectivity requirements
Syslog Configuration
Follow the Trellix Register syslog servers documentation using the following parameters:
Parameter | Value |
---|---|
Server name | IP of the Samurai Local Collector |
TCP port number | 6514 |
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
45 - Trellix Endpoint Security (HX)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Trellix Endpoint Security (HX) |
To complete this Integration you will need to:
1) Ensure Connectivity Requirements are in place
2) From the FireEye HX Console:
- Create Users
- Acquisition Setting
- Enable Auto Triage
- Data Acquisition Script Setting
- Configuration for Log Collection
- Polling Configuration
3) From the Samurai application:
Connectivity Requirements
Source | Destination | Port | Description |
---|---|---|---|
Samurai Local Collector | Trellix Endpoint Security Server | TCP/443 | API access |
Trellix Endpoint Security Server | Samurai Local Collector | UDP/514 TCP/514 | Log forwarding |
Create Users
Users must be created with minimum roles in order to allow NTT to collect evidence information for analysis enrichment. For further reference please consult Chapter 3: Local Authentication of the Trellix FireEye System Security Guide (we reference v2021.1)
Perform the following steps:
- Login to the Endpoint Security Web UI with admin access
- Navigate to Admin > Appliance Settings
- Click User Accounts and specify the following information to create a new user account for NTT:
Account | Parameter |
---|---|
User Name | you choose however we recommend: api_analyst_ntt |
Role | api_admin |
Password | [Set secure password] |
NTT recommends that you set a password of minimum eight-character length, with random characters including digits and symbols, and that you set a different passwords for each account.
Verify the logins using the above accounts as you will need this information to Complete the Trellix Endpoint Security (HX) Integration
Acquisition Setting
Configure the Acquisition setting to enable triage file retrieval:
- Login to the Endpoint Security Web UI with admin access
- Navigate to Admin > Acquisition Settings
- Turn on File & Data Acquisition.
- Click Save.
For further reference please consult Configuring File Acquisition Settings in the Trellix Endpoint Security Server User Guide (we reference Release 5.3)
Enable Auto Triage
Configure the auto triage setting to make triage files available in the HX instance:
- Login to the Endpoint Security Web UI with admin access
- Navigate to Admin > Triage Settings
- On the Automatic Triages settings page, toggle the Triage Settings switch to ON
- Click Save.
For further reference please consult the Configuring Automatic Triage section in the Trellix Endpoint Security Server User Guide (we reference Release 5.3)
Data Acquisition Script Setting
Configure the Data Acquisition setting to enable event log retrieval:
- Login to the Endpoint Security Web UI with admin access
- Navigate to Admin > Data Acquisition Scripts
- Click Standard Investigative Details.
- On the Script Description page, click ACTIONS and select Edit
- Click Event Logs and then enable Security logs in the Windows event logs section.
- Click Save.
For further reference please consult the Acquisition Data Type Reference section in the Trellix Endpoint Security Server User Guide (we reference Release 5.3)
Configuration for Log Collection
Configure a syslog server (the Samurai Local Collector) using the CLI.
There is no remote syslog configuration by default.
# show logging
Local logging level: notice
Override for class cef: none
Remote syslog default level: notice.
- Go to CLI Configuration mode and enter the following commands to configure syslog:
hostname > enable
hostname # configure terminal
hostname (config) # logging [IP Address of your Local Collector] trap none
hostname (config) # logging [IP Address of your Local Collector] trap overrride class cef
priority info
hostname # logging [IP Address of your Local Collector] protocol tcp
hostname (config) # (config) # write memory
- Configure RFC-3339 Time Format
hostname > enable
hostname # configure terminal
hostname (config) # logging fields timestamp format rfc-3339
hostname (config) # (config) # write memory
For further reference please consult Chapter 13: Log Management of the Endpoint Security Server System Administration Guide (we reference Release 5.3)
Polling Configuration
This configuration is not mandatory but recommended to configure certain parameters in order to fully align with our service.
Perform the following steps:
- Login to the Endpoint Security Web UI with admin access
- Navigate to Admin > Policies
- From the Policies page, click Agent Default policy to edit the policy
- From the Edit Policy page, select Polling and overwrite the parameters highlighted in the table below
Parameters | Time |
---|---|
① Polling agents | 1 minute |
② Fastpoll agents | 30 seconds |
③ Request sysinfo | 10 minutes |
④ Poll for agent config | 15 minutes |
- Click Save to apply the configuration
For further reference please consult Configuring Polling from the Endpoint Security xAgent Administration Guide (we reference Release 35.31.0)
Complete the Trellix Endpoint Security (HX) Integration
Login to your Samurai application tenant
Click Integrations from the main menu
Click Create
Find and select Trellix Endpoint Security (HX)
Select the intended Samurai Local Collector
You will be presented with the Local Collector IP Address on the left of the screen
To configure Extended Telemetry Collection ensure it is enabled via the toggle
Enter the following information:
- Name for the Integration - the name will appear in the Samurai application for you to easily reference
- Description (optional) - if completed will appear in the Samurai application for you to easily reference)
- Devicename - an arbitrary name to identify FireEye HX
- Username - enter a username (created under Create Users)
- Password - specify password to use (created under Create Users)
- Hostname / IP - IP address or hostname of the manager
- Custom Port (optional)- if you have changed the default port enter the port number, if not, we default to 443
Click on Finish
For general information on Integrations refer to the Integrations article.
46 - Trend Micro Vision One
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
This guide describes the steps required to integrate Trend Micro Vision One telemetry data to the Samurai platform.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
TrendMicro Vision One |
To complete this Integration you will need to:
1) From the Trend Micro Vision One console
2) From the Samurai MDR application
Create an API user and token
Follow the steps outlined in the Trend Micro documentation:
When completing the steps be sure to:
- Ensure the user account has User Role: Analyst
- Access Level is API Only
- You generate and copy the Authentication Token for use when you Complete the Trend Micro Vision One Integration
Determine your Trend Vision One region
Review the Trend Micro documentation to determine your region:
Take note of your region for use when you Complete the Trend Micro Vision One Integration
Complete the Trend Micro Vision One Integration
You will need:
- Regional Domain: (this corresponds to the region from Determine your Trend Vision One region)
- Authentication Token: (you obtained from Create an API user and token)
- Login to the Samurai MDR application
- Click Telemetry > Integrations from the main menu
- Click Create
- Click Next (we leverage a Samurai Cloud Collector)
- Find and select Trend Micro Vision One
- Enter the Authentication Token within the Access token field
- Select the Regional Domain
- Click on Finish
For general information on Integrations refer to the Integrations article.
47 - VMware Carbon Black Cloud Enterprise EDR
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
VMware Carbon Black Cloud Enterprise EDR |
VMWare Carbon Black Cloud Enterprise EDR logs and data are collected via REST API and Streaming API.
To complete this Integration you will need to:
1) Within the VMware Carbon Black Cloud web interface
2) From the Samurai application:
Determine Environment
The URL for API access appears in the address bar in a browser as follows:
https://defense-<Cloud Instance ID>.conferdeploy.net
Take note of this URL as it will be required when completing the Integration within the Samurai MDR application.
Determine Org Key for API Access
To determine your Org Key for API Access:
- Login to your Carbon Black Cloud instance
- Select Settings > API Access
- The ORG KEY is shown on the screen.
Take note of this Org Key as it will be required when completing the Integration within the Samurai MDR application.
API Access
Use these steps to configure a custom API access level:
- Log in to your Carbon Black Cloud Instance with an account that has the Super Admin role.
- Click Settings > API Access
- Go to the Access Level-tab
- Click Add Access Level
- In the Name field, enter Samurai-Access
- Enter a description
- Select the following permissions
- org.alerts Read
- org.watchlists Read
- device Read
- org.search.events Create, Read
- Click Save
Use these steps to enable API configuration to allow Samurai to gather telemetry:
Click Settings > API Access
Click +Add API Key
Add a new API key with the following information:
- In the Name field, enter Samurai-MDR
- From the Access Level type list, select Custom
- From Custom Access Level list, select Samurai-Access
- Click Save
The API credentials are displayed
Use the copy button to copy the Samurai-MDR API ID and API Secret Key. Paste the information to a file clearly indicating name, API ID, and API secret key.
If you did not manage to copy the information, click the down arrow on the corresponding Samurai-MDR row and select API Credentials
You will need the API ID and API Secret key when completing the integration within the Samurai MDR application.
Complete the VMware Carbon Black Cloud Enterprise EDR Integration
You will need:
- Environment: (the URL from Determine Environment e.g https://defense-<ENV>.conferdeploy.net)
- Organization Key: (from Determine Org Key for API Access)
- API ID: (from API Access)
- API Secret: (from API Access)
- Login to the Samurai MDR web application
- Select Integrations
- Select Create
- Locate and click Carbon Black Enterprise EDR
- Click Next (we leverage a Samurai Cloud Collector)
- Enter a Name of Integration
- Enter a Description (Optional)
- Enter your Environment
- Enter your Organization Key
- Enter your API ID
- Enter your API Secret
- Click Finish
For general information on Integrations refer to the Integrations article.
48 - WatchGuard Firebox
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
This guide describes the steps required to configure WatchGuard Firebox to send logs to a Samurai Local Collector deployed on your network. The Firebox requires access to the Local Collector via syslog on port 514/UDP.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
WatchGuard Firebox |
1) From your WatchGuard Firebox:
Adding Syslog Servers
Follow the steps outlined in the following section of the WatchGuard documentation.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
IP Address | IP address of your Samurai MDR Local Collector |
Port | 514 |
Log Format | IBM LEEF |
Description | Whatever you want. |
The serial number of the device | Enabled |
The syslog header | Enabled |
Syslog facility | Required log message types: Traffic, Alarm Optional log message types: Event, Diagnostic, Performance |
Table 1: Adding Syslog Servers
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.
49 - Zscaler Internet Access (ZIA)
Our Integration guide was accurate at the time of writing but vendors change things frequently! If you find errors or anything is outdated, let us know by raising a request in the Samurai MDR application and we shall get it updated.
Product | Samurai [Local] Collector | Samurai [Cloud] Collector |
---|---|---|
Zscaler Internet Access (ZIA) |
This guide describes the steps required to configure Zscaler Internet Access Nanolog Streaming Service (NSS) to send logs to a Samurai Local Collector deployed on your network. The NSS requires access to the Local Collector via syslog on port 514/TCP.
1) From Zscaler Internet Access Portal:
- Adding NSS Server
- Adding NSS Feeds for Web Logs
- Adding NSS Feeds for Firewall Logs
- Adding NSS Feeds for DNS Logs
Adding NSS Server
Follow the steps outlined in the ZIA documentation. If you use an existing one, skip this section.
There are two types of NSS servers, NSS for Web (Streams web and mobile traffic logs) and NSS for Firewall (Streams logs from the Zscaler next-generation firewall).
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Name | Whatever you want, however we suggest: NTT Monitoring |
Type | NSS for Web / NSS for Firewall |
Table 1: NSS Server
Adding NSS Feeds for Web Logs
Follow the steps outlined in the ZIA documentation.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Feed Name | Whatever you want, however we suggest: NTT-Web |
NSS Type | Select your NSS Server created in Adding NSS Server or the existing server |
SIEM Destination Type | IP Address |
SIEM IP Address | IP address of your Samurai Local Collector |
Log Type | Web Log |
Feed Output Type | Custom |
Feed Output Format | ```{ “sourcetype” : “zscalernss-web”, “event” : {“datetime”:"%d{yy}-%02d{mth}-%02d{dd} %02d{hh}:%02d{mm}:%02d{ss}", |
“reason”:"%s{reason}",“event_id”:"%d{recordid}",“protocol”:"%s{proto}",“action”:"%s{action}", | |
“transactionsize”:"%d{totalsize}",“responsesize”:"%d{respsize}",“requestsize”:"%d{reqsize}", | |
“urlcategory”:"%s{urlcat}",“serverip”:"%s{sip}",“clienttranstime”:"%d{ctime}",“requestmethod”:"%s{reqmethod}", | |
“refererURL”:"%s{ereferer}",“useragent”:"%s{eua}",“product”:“NSS”,“location”:"%s{elocation}", | |
“ClientIP”:"%s{cip}",“status”:"%s{respcode}",“user”:"%s{elogin}",“url”:"%s{eurl}",“vendor”:“Zscaler”, | |
“hostname”:"%s{ehost}",“clientpublicIP”:"%s{cintip}",“threatcategory”:"%s{malwarecat}", | |
“threatname”:"%s{threatname}",“filetype”:"%s{filetype}",“appname”:"%s{appname}",“pagerisk”:"%d{riskscore}", | |
“department”:"%s{edepartment}",“urlsupercategory”:"%s{urlsupercat}",“appclass”:"%s{appclass}", | |
“dlpengine”:"%s{dlpeng}",“urlclass”:"%s{urlclass}",“threatclass”:"%s{malwareclass}", | |
“dlpdictionaries”:"%s{dlpdict}",“fileclass”:"%s{fileclass}",“bwthrottle”:"%s{bwthrottle}", | |
“servertranstime”:"%d{stime}",“contenttype”:"%s{contenttype}",“unscannabletype”:"%s{unscannabletype}", | |
“deviceowner”:"%s{deviceowner}",“devicehostname”:"%s{devicehostname}", | |
“upload_filetype”:"%s{upload_filetype}",“upload_filename”:"%s{upload_filename}"}}``` | |
Timezone | GMT |
Duplicate Logs | Disabled |
Table 2: NSS Feeds Web
Adding NSS Feeds for Firewall Logs
Follow the steps outlined in the ZIA documentation.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Feed Name | Whatever you want, however we suggest: NTT-FW |
NSS Type | NSS for Firewall |
NSS Server | Select your NSS Server created in Adding NSS Server or the existing server |
SIEM Destination Type | IP Address |
SIEM IP Address | IP address of your Samurai Local Collector |
SIEM TCP Port | 514 |
Log Type | Firewall Logs |
Feed Output Type | JSON |
Timezone | GMT |
Duplicate Logs | Disabled |
Table 3: NSS Feeds Firewall
Adding NSS Feeds for DNS Logs
Follow the steps outlined in the ZIA documentation.
Use the following parameters when completing the steps:
Field Name | Parameter |
---|---|
Feed Name | Whatever you want, however we suggest: NTT-DNS |
NSS Type | NSS for Firewall |
NSS Server | Select your NSS Server created in Adding NSS Server or the existing server |
SIEM Destination Type | IP Address |
SIEM IP Address | IP address of your Samurai Local Collector |
SIEM TCP Port | 514 |
Log Type | DNS Logs |
Feed Output Type | JSON |
Timezone | GMT |
Duplicate Logs | Disabled |
Table 4: NSS Feeds DNS
For integrations that utilize a Local Collector where we ingest syslog only, you do not need to follow specific steps in the Samurai MDR Application as we auto detect the vendor and product. The only reason you need to use the Samurai MDR Application is if you need to determine the Local Collector IP address. Of course you will still need to ensure the integration is functioning! See Integrations for more information on checking status.