SentinelOne Firewall Control Management

SCENARIO

Traditional endpoint protection focuses on file-based malware, but network-based attacks (lateral movement, command-and-control callbacks, port scanning, unauthorized remote access) bypass file analysis. Native OS firewalls (Windows Firewall, macOS pf, Linux iptables) provide network segmentation, but managing firewall rules across thousands of endpoints via Group Policy or manual configuration is complex, error-prone, and lacks location awareness.

Use this guide when you need to:

• Centrally manage firewall rules across Windows, macOS, and Linux endpoints from the SentinelOne console
• Implement location-aware firewalls that automatically adapt rules based on network location (corporate office vs. remote/untrusted networks)
• Block lateral movement attempts by restricting inbound RDP, SMB, SSH, and other administrative protocols
• Prevent command-and-control (C2) callbacks by blocking outbound connections to suspicious IPs/domains
• Enforce zero-trust network segmentation where only authorized applications can communicate over the network
• Comply with security frameworks requiring host-based firewalls (CIS Benchmarks, NIST 800-53)
• Replace third-party firewall management tools with native OS firewall control via SentinelOne

Business Impact:

• Lateral movement prevention: Block attackers from pivoting between compromised endpoints
• Data exfiltration blocking: Prevent unauthorized outbound connections to attacker-controlled servers
• Ransomware containment: Isolate infected endpoints before ransomware spreads across the network
• Compliance requirements: Meet audit requirements for host-based firewall enforcement (PCI-DSS 1.4, HIPAA 164.312(a))
• Simplified management: Replace GPO-based firewall rules with centralized console management
• Zero-touch security: Automatically apply stricter firewall rules when endpoints leave corporate network

SentinelOne Firewall Control leverages native OS firewalls (Windows Defender Firewall, macOS pf, Linux iptables/nftables) with centralized policy management and location awareness for context-based rule enforcement.

REQUIREMENTS & ASSUMPTIONS

Prerequisites:

• SentinelOne Singularity Control or Complete license: Firewall Control is included in Control tier and above
• Minimum agent version:
  • Windows: 2.8 or later
  • macOS: 2.7 or later
  • Linux: 3.0 or later
• Console version: Liberty or later
• Console access: Admin role with Firewall Policy Management permissions
• Supported operating systems:
  • Windows 10/11, Windows Server 2016/2019/2022
  • macOS 10.15 (Catalina) and later
  • Linux (Ubuntu 18.04+, RHEL/CentOS 7+, Debian 9+)

License Verification: Check console for Firewall Control availability:

Console > Settings > License > Modules: "Firewall Control" should be listed

Network Assumptions:

• Corporate office networks are defined (IP ranges or DNS suffixes)
• Network locations can be identified via DNS, Active Directory domain membership, or gateway IP
• Administrators understand which protocols/ports are required for business applications
• Existing firewall rules (GPO-based, manually configured) are documented before migration

Firewall Rule Evaluation Order:

1. SentinelOne Firewall Rules (highest priority)
2. Local OS Firewall Rules (existing GPO or manually configured rules)
3. Default OS Behavior (allow outbound, block inbound)

Important: SentinelOne firewall rules are additive to existing OS firewall rules. To fully control firewall behavior, disable or remove existing GPO-based rules.

PROCESS

Step 1: Enable Firewall Control in the console

1. Navigate to Console → Settings → Firewall

2. Verify Firewall Control module is licensed:

   • If "Firewall" section is visible, the module is licensed
   • If not visible, contact SentinelOne account manager to upgrade license

3. Enable Firewall Control globally or per-site:

   • Toggle Enable Firewall Control to ON
   • Select scope: Global (all sites) or Specific Sites

4. Configure global firewall settings:

   • Enforcement Mode:
     • Monitor Only: Log firewall events but don't block traffic (recommended for initial deployment)
     • Enforce: Actively block traffic based on firewall rules
   • Logging Level:
     • All Traffic: Log all allowed and blocked connections (verbose, may impact performance)
     • Blocked Traffic Only: Log only blocked connections (recommended)
     • Disabled: No firewall logging

5. Save settings

Result: Firewall Control is enabled. Agents will begin enforcing firewall rules based on policy configuration.

Step 2: Define network locations (location awareness)

Location awareness allows firewall rules to adapt based on where the endpoint is connected (corporate office, home, coffee shop).

1. Navigate to Console → Settings → Firewall → Network Locations
2. Click + New Network Location

Example Location 1: Corporate Office Network

Location Name: Corporate_Office
Description: On-premises corporate network (trusted)

Detection Method: DNS Suffix
- DNS Suffix: corp.company.com
- Fallback: Gateway IP Range (10.0.0.0/8, 172.20.0.0/16)

Firewall Policy: Relaxed (allow RDP, SMB, intranet services)

Example Location 2: VPN Connection

Location Name: Corporate_VPN
Description: Remote users connected via VPN (semi-trusted)

Detection Method: Gateway IP Address
- VPN Gateway IPs: 10.100.0.1, 10.100.0.2

Firewall Policy: Moderate (allow VPN protocols, block direct inbound RDP)

Example Location 3: Untrusted Networks (default/catch-all)

Location Name: Untrusted_Network
Description: Public WiFi, home networks, any non-corporate network (untrusted)

Detection Method: Default (if no other location matches)

Firewall Policy: Strict (block all inbound except VPN, restrict outbound to approved destinations)

3. Save network locations

Detection Methods:

Best Practice: Define locations from most specific to most general. Agents test locations in order, applying the first match.

Result: Network locations are defined. Firewall policies will automatically adapt based on endpoint location.

Step 3: Create firewall policy templates

Firewall policies are rule sets that define allowed/blocked network traffic.

1. Navigate to Console → Settings → Firewall → Policy Templates
2. Click + New Policy Template

Template 1: Corporate Office Policy (Relaxed)

Policy Name: Firewall_Policy_Corporate_Office
Description: Firewall rules for endpoints on corporate network (trusted environment)

Location: Corporate_Office
Enforcement Mode: Enforce

Inbound Rules:
- Allow RDP (TCP 3389) from 10.0.0.0/8 (IT admin subnet)
- Allow SMB (TCP 445) from 10.0.0.0/8 (file servers)
- Allow ICMP (Ping) from 10.0.0.0/8 (network monitoring)
- Block all other inbound

Outbound Rules:
- Allow all outbound (default)

Template 2: VPN Policy (Moderate)

Policy Name: Firewall_Policy_VPN
Description: Firewall rules for remote users on VPN (semi-trusted)

Location: Corporate_VPN
Enforcement Mode: Enforce

Inbound Rules:
- Block all inbound (except established connections)

Outbound Rules:
- Allow HTTPS (TCP 443) to any
- Allow DNS (UDP 53) to any
- Allow VPN protocols (UDP 1194, UDP 500, TCP 1723) to VPN gateway
- Block all other outbound

Template 3: Untrusted Network Policy (Strict)

Policy Name: Firewall_Policy_Untrusted
Description: Firewall rules for endpoints on public WiFi / untrusted networks (strict)

Location: Untrusted_Network
Enforcement Mode: Enforce

Inbound Rules:
- Block all inbound (except established connections)

Outbound Rules:
- Allow HTTPS (TCP 443) to any
- Allow DNS (UDP 53) to corporate DNS servers only (10.1.1.10, 10.1.1.11)
- Allow VPN (UDP 1194) to VPN gateway (203.0.113.50)
- Block RDP (TCP 3389) to any (prevent remote admin over untrusted network)
- Block SMB (TCP 445) to any (prevent ransomware spread)
- Allow all other outbound (for web browsing, email)

3. Save policy templates

Result: Firewall policy templates are created. Next step is to create specific firewall rules.

Step 4: Create inbound firewall rules

Inbound rules control connections initiated from external sources to the endpoint (e.g., RDP, SSH, SMB).

1. Navigate to Console → Settings → Firewall → Rules → Inbound
2. Click + New Inbound Rule

Example Rule 1: Allow RDP from IT Admin Subnet (Corporate Office)

Rule Name: Allow_RDP_IT_Admins
Description: Allow IT administrators to RDP into endpoints on corporate network

Policy Template: Firewall_Policy_Corporate_Office
Priority: 1 (highest)

Match Criteria:
- Protocol: TCP
- Destination Port: 3389
- Source IP Range: 10.1.100.0/24 (IT admin subnet)

Action: Allow
Logging: Enabled (log all RDP connections)

Scope: All endpoints

Example Rule 2: Block All Inbound RDP (Untrusted Networks)

Rule Name: Block_RDP_Untrusted_Networks
Description: Block RDP access when endpoints are on untrusted networks

Policy Template: Firewall_Policy_Untrusted
Priority: 1

Match Criteria:
- Protocol: TCP
- Destination Port: 3389
- Source IP Range: Any

Action: Block
Logging: Enabled

Scope: All endpoints

Example Rule 3: Allow ICMP Ping (Corporate Office Only)

Rule Name: Allow_Ping_Corporate_Network
Description: Allow network monitoring tools to ping endpoints on corporate network

Policy Template: Firewall_Policy_Corporate_Office
Priority: 5

Match Criteria:
- Protocol: ICMP
- ICMP Type: Echo Request (Type 8)
- Source IP Range: 10.0.0.0/8

Action: Allow
Logging: Disabled (too verbose)

Scope: All endpoints

Example Rule 4: Block SMB from Internet (All Locations)

Rule Name: Block_SMB_from_Internet
Description: Block SMB/WannaCry ransomware vectors from internet

Policy Template: All Policies
Priority: 1

Match Criteria:
- Protocol: TCP
- Destination Port: 445, 139
- Source IP Range: 0.0.0.0/0 (any) EXCEPT 10.0.0.0/8, 172.20.0.0/16 (corporate)

Action: Block
Logging: Enabled

Scope: All endpoints

3. Save rules

Rule Priority: Lower numbers = higher priority. If multiple rules match a connection, the highest-priority rule is applied.

Result: Inbound firewall rules are configured to block unauthorized access while allowing legitimate administrative connections on trusted networks.

Step 5: Create outbound firewall rules

Outbound rules control connections initiated from the endpoint to external destinations (e.g., web browsing, C2 callbacks, data exfiltration).

1. Navigate to Console → Settings → Firewall → Rules → Outbound
2. Click + New Outbound Rule

Example Rule 1: Allow HTTPS to Approved SaaS Applications

Rule Name: Allow_HTTPS_Approved_SaaS
Description: Allow HTTPS to approved SaaS applications (Microsoft 365, Salesforce, etc.)

Policy Template: All Policies
Priority: 5

Match Criteria:
- Protocol: TCP
- Destination Port: 443
- Destination FQDN:
  - *.office.com
  - *.microsoft.com
  - *.salesforce.com
  - *.google.com

Action: Allow
Logging: Disabled

Scope: All endpoints

Example Rule 2: Block Tor Exit Nodes (Prevent Data Exfiltration)

Rule Name: Block_Tor_Exit_Nodes
Description: Block connections to Tor network (prevent data exfiltration)

Policy Template: All Policies
Priority: 1

Match Criteria:
- Protocol: Any
- Destination IP Range: [Tor Exit Node IP List]
  - Example: 185.220.101.0/24 (Tor exit node subnet)

Action: Block
Logging: Enabled

Scope: All endpoints

Example Rule 3: Block Cryptocurrency Mining Pools

Rule Name: Block_Crypto_Mining_Pools
Description: Block outbound connections to cryptocurrency mining pools

Policy Template: All Policies
Priority: 1

Match Criteria:
- Protocol: TCP
- Destination Port: 3333, 4444, 5555, 7777, 8888, 9999 (common mining ports)
- Destination FQDN:
  - *.stratum.*.com
  - *.pool.*.com
  - *.mining.*.com

Action: Block
Logging: Enabled

Scope: All endpoints

Example Rule 4: Block RDP/SSH to External IPs (Prevent Lateral Movement)

Rule Name: Block_Remote_Admin_External
Description: Block RDP/SSH to external IPs (prevent attackers from pivoting to other networks)

Policy Template: Firewall_Policy_Untrusted
Priority: 1

Match Criteria:
- Protocol: TCP
- Destination Port: 3389 (RDP), 22 (SSH)
- Destination IP Range: Any EXCEPT 10.0.0.0/8, 172.20.0.0/16 (corporate)

Action: Block
Logging: Enabled

Scope: All endpoints

Example Rule 5: Allow DNS to Corporate DNS Servers Only (DNS Filtering)

Rule Name: Force_Corporate_DNS
Description: Force all DNS queries to corporate DNS servers (prevent DNS tunneling)

Policy Template: Firewall_Policy_Corporate_Office
Priority: 1

Match Criteria:
- Protocol: UDP
- Destination Port: 53
- Destination IP: 10.1.1.10, 10.1.1.11 (corporate DNS servers)

Action: Allow

---

Match Criteria (blocking rule):
- Protocol: UDP
- Destination Port: 53
- Destination IP: Any EXCEPT 10.1.1.10, 10.1.1.11

Action: Block
Logging: Enabled

Scope: All endpoints

3. Save rules

Best Practice: Use URL/FQDN filtering for outbound rules instead of IP addresses (IPs change frequently for cloud services).

Result: Outbound firewall rules block C2 callbacks, data exfiltration, and unauthorized remote access while allowing legitimate business traffic.

Step 6: Test firewall rules in Monitor mode

Before enforcing firewall rules, validate they work as expected without blocking legitimate traffic.

1. Set policy templates to Monitor Only mode:

   • Console → Settings → Firewall → Policy Templates → [Template Name]
   • Change Enforcement Mode to Monitor Only

2. Deploy firewall policies to pilot group:

   • Console → Settings → Policies → [Pilot Group Policy]
   • Assign firewall policy template to pilot group
   • Policies update to endpoints within 60 seconds

3. Monitor firewall activity logs:

   • Console → Activity → Firewall Logs
   • Filter: Enforcement Mode = Monitor Only
   • Review connections that would be blocked if enforcement were enabled

4. Identify false positives:

   • Look for blocked connections to legitimate business applications
   • Example false positive:

     Blocked Connection (Monitor Only):
     Source: 10.1.50.22 (Workstation-JDoe)
     Destination: 192.0.2.100:8443 (Unknown)
     Protocol: HTTPS
     Rule: Block_Unknown_HTTPS_Destinations
     
     Investigation: 192.0.2.100 is company's internal app server
     Resolution: Add 192.0.2.100 to allowed destination list
     

5. Test connectivity for critical applications:

   • RDP to endpoints (should be allowed from IT admin subnet, blocked from other sources)
   • Access internal file shares (SMB should be allowed from corporate network)
   • Browse internet (HTTPS should be allowed, Tor should be blocked)
   • Test VPN connectivity (VPN ports should be allowed)

6. Tune firewall rules:

   • Update rules to exclude false positives
   • Adjust IP ranges, FQDNs, ports based on test results

Result: Firewall policies are validated in Monitor mode, reducing business disruption when switching to enforcement.

Step 7: Enforce firewall policies

After testing and tuning in Monitor mode, switch to active enforcement.

1. Review and finalize firewall rules:

   • Verify all critical business applications have allow rules
   • Document approved IP ranges, FQDNs, ports
   • Notify users before enforcement begins

2. Switch policy templates to Enforce mode:

   • Console → Settings → Firewall → Policy Templates → [Template Name]
   • Change Enforcement Mode from Monitor Only to Enforce
   • Click Save Changes

3. Policies take effect within 60 seconds (agents receive policy update from console)

4. Monitor initial enforcement:

   • Console → Activity → Firewall Logs
   • Watch for blocked connection events
   • Prepare helpdesk for connectivity issue reports

5. Expected user experience when connection is blocked:

   • Windows: Connection timeout (no explicit notification unless logging is enabled)
   • macOS: Connection refused error
   • Linux: Connection timeout or reset

6. Helpdesk workflow for connectivity issues:

   • User reports: "Cannot access application X"
   • IT reviews firewall logs:
     • Console → Activity → Firewall Logs
     • Filter: Endpoint = [User's computer]
     • Identify blocked connection
   • If legitimate business need:
     • Create allow rule for the destination IP/FQDN/port
     • Rule takes effect within 60 seconds
     • Notify user to retry connection

Result: Firewall policies are actively enforcing network controls, blocking unauthorized traffic.

Step 8: Monitor and maintain firewall policies

1. Daily: Review blocked connection events:

   • Console → Activity → Firewall Logs
   • Filter: Action = Blocked
   • Identify patterns:
     • Repeated blocks to same destination = user needs allow rule
     • Unusual outbound connections = potential C2 callback, investigate

2. Weekly: Generate firewall activity report:

   • Console → Reports → Firewall Activity
   • Metrics to track:
     • Total connections (last 7 days)
     • Blocked connections count
     • Top blocked destinations (IPs, FQDNs)
     • Top users with blocked connections
     • Most triggered firewall rules

3. Monthly: Audit firewall rules:

   • Review all firewall rules for relevance
   • Remove stale rules (e.g., allow rules for decommissioned servers)
   • Update IP ranges if network infrastructure changed

4. Quarterly: Policy tuning:

   • Analyze false positive rate (legitimate connections blocked)
   • Update FQDN allow-lists for new SaaS applications
   • Adjust location detection criteria if offices moved or VPN changed

Result: Firewall policies remain effective and aligned with business needs.

VERIFICATION

Verify Firewall Control is active:

1. Check policy status:

   Console → Settings → Firewall → Policy Templates → [Template Name]
   - Firewall Control: Enabled
   - Enforcement Mode: Enforce
   

2. Verify agent receives firewall policy:

   • On a managed endpoint, run:

     # Windows
     & "C:\Program Files\SentinelOne\Sentinel Agent *\SentinelCtl.exe" policy show
      
     # Look for "Firewall Control: Enabled"

3. Test inbound blocking:

   • From an unauthorized source IP, attempt RDP to managed endpoint:

     mstsc /v:10.1.50.22

   • Expected result: Connection timeout, event logged in console

4. Test outbound blocking:

   • From managed endpoint, attempt connection to blocked destination (e.g., Tor exit node):

     Test-NetConnection -ComputerName 185.220.101.1 -Port 443

   • Expected result: Connection failed, event logged

5. Test location awareness:

   • Disconnect endpoint from corporate network (simulate untrusted WiFi)
   • Verify firewall policy automatically switches to Untrusted_Network policy
   • Check: Console → Activity → Firewall Logs → Filter: Endpoint = [Computer Name]
   • Expected: Log entry showing "Network location changed: Corporate_Office → Untrusted_Network"

TROUBLESHOOTING

Issue: Firewall rules not applying

Symptoms: Connections are not blocked despite enforce mode enabled

Solutions:

1. Verify agent version:

   & "C:\Program Files\SentinelOne\Sentinel Agent *\SentinelCtl.exe" status
   # Windows agent must be 2.8+, macOS 2.7+, Linux 3.0+

2. Check agent connectivity:

   & "C:\Program Files\SentinelOne\Sentinel Agent *\SentinelCtl.exe" status
   # "Management connectivity: Connected"

3. Force policy refresh:

   Restart-Service -Name "SentinelAgent" -Force

4. Verify native OS firewall is enabled:

   • Windows: Get-NetFirewallProfile → Enabled = True
   • macOS: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate → Firewall is enabled
   • Linux: sudo ufw status or sudo iptables -L

Issue: Legitimate traffic blocked (false positive)

Symptoms: Users cannot access business applications

Solutions:

1. Identify blocked connection:

   • Console → Activity → Firewall Logs
   • Filter: User = [username] OR Endpoint = [computer]
   • Find blocked event, note destination IP/FQDN/port

2. Create allow rule:

   • Console → Settings → Firewall → Rules → Outbound
   • Create new rule allowing destination IP/FQDN/port
   • Set higher priority than blocking rule

3. Verify rule scope:

   • Ensure allow rule applies to correct policy template and endpoints

Issue: Location awareness not working

Symptoms: Endpoint remains on wrong firewall policy despite network change

Solutions:

1. Verify location detection criteria:

   • Console → Settings → Firewall → Network Locations
   • Check DNS suffix, gateway IP, FQDN reachability criteria
   • Verify endpoint matches criteria (e.g., DNS suffix = corp.company.com)

2. Force location re-detection:

   # Windows
   Restart-Service -Name "SentinelAgent" -Force

3. Check detection order:

   • Locations are tested in priority order
   • Higher-priority location may match before intended location
   • Reorder locations: drag-and-drop in console

COMMANDS/SCRIPTS

PowerShell script to audit firewall activity:

<#
.SYNOPSIS
    Audit SentinelOne firewall activity
.DESCRIPTION
    Retrieves firewall logs and generates report of blocked connections
.PARAMETER ApiToken
    SentinelOne API token
.PARAMETER ConsoleUrl
    SentinelOne console URL
.PARAMETER Days
    Number of days to audit (default: 7)
.EXAMPLE
    .\Audit-S1-Firewall.ps1 -ApiToken "abc123" -ConsoleUrl "https://yourtenant.sentinelone.net" -Days 7
#>
 
param(
    [Parameter(Mandatory=$true)]
    [string]$ApiToken,
 
    [Parameter(Mandatory=$true)]
    [string]$ConsoleUrl,
 
    [Parameter(Mandatory=$false)]
    [int]$Days = 7
)
 
$ErrorActionPreference = 'Stop'
 
$headers = @{
    "Authorization" = "ApiToken $ApiToken"
    "Content-Type" = "application/json"
}
 
Write-Host "=== SentinelOne Firewall Activity Audit ===" -ForegroundColor Cyan
 
$startDate = (Get-Date).AddDays(-$Days).ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
 
# Retrieve firewall activity
Write-Host "[1/2] Retrieving firewall activity (last $Days days)..." -ForegroundColor Yellow
 
$activityFilter = @{
    createdAt__gte = $startDate
    activityTypes = @(7001, 7002)  # Firewall allowed, blocked
    action = "blocked"
}
 
$activity = Invoke-RestMethod -Uri "$ConsoleUrl/web/api/v2.1/activities" -Headers $headers -Method Get -Body $activityFilter
 
Write-Host "[SUCCESS] Retrieved $($activity.data.Count) blocked connection events" -ForegroundColor Green
 
# Analyze activity
Write-Host "[2/2] Analyzing blocked connections..." -ForegroundColor Yellow
 
$stats = @{
    TotalBlocked = $activity.data.Count
    TopDestinations = @{}
    TopUsers = @{}
    TopRules = @{}
}
 
foreach ($event in $activity.data) {
    $dest = "$($event.data.destinationIP):$($event.data.destinationPort)"
    if (-not $stats.TopDestinations.ContainsKey($dest)) {
        $stats.TopDestinations[$dest] = 0
    }
    $stats.TopDestinations[$dest]++
 
    $user = $event.data.username
    if (-not $stats.TopUsers.ContainsKey($user)) {
        $stats.TopUsers[$user] = 0
    }
    $stats.TopUsers[$user]++
 
    $rule = $event.data.ruleName
    if (-not $stats.TopRules.ContainsKey($rule)) {
        $stats.TopRules[$rule] = 0
    }
    $stats.TopRules[$rule]++
}
 
# Generate report
$report = @"
================================================================================
SENTINELONE FIREWALL ACTIVITY AUDIT REPORT
================================================================================
 
AUDIT PERIOD: Last $Days days ($(Get-Date $startDate -Format 'yyyy-MM-dd') to $(Get-Date -Format 'yyyy-MM-dd'))
 
SUMMARY
-------
Total Blocked Connections: $($stats.TotalBlocked)
 
TOP BLOCKED DESTINATIONS
------------------------
$($stats.TopDestinations.GetEnumerator() | Sort-Object Value -Descending | Select-Object -First 10 | ForEach-Object { "  $($_.Key): $($_.Value) blocks" } | Out-String)
 
TOP USERS (by blocked connections)
----------------------------------
$($stats.TopUsers.GetEnumerator() | Sort-Object Value -Descending | Select-Object -First 10 | ForEach-Object { "  $($_.Key): $($_.Value) blocks" } | Out-String)
 
TOP FIREWALL RULES TRIGGERED
-----------------------------
$($stats.TopRules.GetEnumerator() | Sort-Object Value -Descending | Select-Object -First 10 | ForEach-Object { "  $($_.Key): $($_.Value) triggers" } | Out-String)
 
RECOMMENDATIONS
---------------
- Investigate top blocked destinations (potential C2 servers or misconfigured apps)
- Review users with excessive blocks (may need allow rules or security awareness training)
- Tune firewall rules with high trigger counts if causing false positives
 
================================================================================
"@
 
$reportPath = "C:\Temp\SentinelOne-Firewall-Audit-$(Get-Date -Format 'yyyyMMdd-HHmmss').txt"
$report | Out-File -FilePath $reportPath -Encoding UTF8
 
Write-Host "[SUCCESS] Audit report generated" -ForegroundColor Green
Write-Host "Report saved to: $reportPath"
Write-Host "`n$report"

REFERENCES

• SentinelOne Firewall Control Feature Spotlight
• Singularity Control Features
• Network Control Essentials Course
• SentinelOne Expands Firewall and NDR Capabilities

Document Version: 1.0 Last Updated: 2025-11-26 Author: CosmicBytez IT Operations Reviewed By: Security Operations Team

Related Reading

• SentinelOne Control vs Complete Feature Comparison
• SentinelOne Deep Visibility Threat Hunting
• SentinelOne Forensics Rollback and Remediation