SentinelOne Ranger Network Discovery and IoT Visibility

SCENARIO

Modern enterprise networks contain a complex mix of managed endpoints (workstations, servers), IoT devices (IP cameras, printers, smart building systems), mobile devices, and shadow IT assets that connect without IT oversight. Traditional endpoint security only protects devices where agents are installed, leaving significant blind spots in network visibility and control.

Use this guide when you need to:

• Discover all IP-enabled devices on your network without deploying additional agents or hardware
• Identify rogue devices, shadow IT, and unmanaged endpoints that bypass security controls
• Fingerprint IoT devices (printers, cameras, industrial control systems, smart TVs) for inventory
• Detect unauthorized network access or devices connecting to sensitive network segments
• Enforce network isolation policies for non-compliant or malicious devices
• Maintain compliance requirements for asset inventory and network segmentation (PCI-DSS, HIPAA)

Business Impact:

• Attack surface reduction: Identify and isolate vulnerable IoT devices before attackers exploit them
• Shadow IT visibility: Detect employee-installed devices (personal routers, smart speakers) that bypass security policies
• Compliance gaps: Automated asset discovery ensures audit-ready inventory without manual surveys
• Lateral movement prevention: Block rogue devices from accessing SentinelOne-protected endpoints
• Zero-trust enforcement: Validate that only known, authorized devices communicate with managed assets

SentinelOne Ranger (now called Singularity Network Discovery) provides agentless network visibility using distributed passive and active scanning techniques orchestrated by existing SentinelOne agents, eliminating the need for additional network appliances or agents.

REQUIREMENTS & ASSUMPTIONS

Prerequisites:

• SentinelOne Singularity Complete or Core license: Ranger is included with Complete tier
• Minimum agent version: 21.6 or later (verify with sentinelctl.exe status)
• Console access: Admin or Security Analyst role with Network Discovery permissions
• Network connectivity: SentinelOne agents must have local network access for scanning
• Firewall rules: Allow agents to perform ICMP, SNMP, and TCP probes (if using active scanning)

Required SentinelOne Agents:

• At least one SentinelOne agent deployed per network subnet to be scanned
• Agents act as distributed scanners to discover devices in their local broadcast domain
• More agents per subnet = faster discovery and more accurate fingerprinting

Network Assumptions:

• Network subnets are defined and routable
• DHCP or static IP addressing is documented
• Administrator understands sensitive networks (OT/SCADA) that require passive-only scanning
• Network segmentation is in place (if enforcing isolation policies)

License Verification: Check your console for Ranger/Network Discovery availability:

Console > Settings > License > Modules: "Network Discovery" should be listed

Supported Scanning Techniques:

• Passive Network Listening: Monitors ARP tables, DNS queries, DHCP requests (non-intrusive)
• ICMP Probes: Ping sweeps to detect active devices
• SNMP Queries: Device fingerprinting via SNMP community strings (if configured)
• TCP Connect Scans: Port scanning for service identification (optional, can be disabled for sensitive networks)

PROCESS

Step 1: Enable Ranger/Network Discovery in the console

1. Log in to SentinelOne Management Console

2. Navigate to Sentinels → Network Discovery

3. Verify module status:

   • If "Network Discovery" tab is visible, the module is licensed
   • If not visible, contact your SentinelOne account manager to upgrade license

4. Enable Network Discovery globally or per-site:

   • Click Settings (gear icon in top-right)
   • Navigate to Settings → Network Discovery → Configuration
   • Toggle Enable Network Discovery to ON
   • Select scope: Global (all sites) or Specific Sites (select from dropdown)

5. Configure global discovery settings:

   • Discovery Interval: How often agents scan (default: 24 hours, range: 1-168 hours)
   • Data Retention: How long to keep device records (default: 90 days)
   • Automatic Fingerprinting: Enable OS and device type identification (recommended)

Result: Network Discovery is now active. Agents will begin scanning their local networks based on policy settings.

Step 2: Define network discovery policies

Network Discovery policies control what networks are scanned and which scanning techniques are used.

1. Navigate to Settings → Network Discovery → Policies

2. Click + New Policy to create a network discovery policy

3. Configure policy details:

   Policy Name: Office_Network_Full_Scan (descriptive name for network type)

   Scope: Select which sites or groups this policy applies to

   Networks to Scan: Define target networks using CIDR notation

   Examples:
   10.1.0.0/16         # Corporate office network
   192.168.1.0/24      # Guest WiFi network
   172.20.0.0/22       # Data center subnet
   

   Excluded Networks (optional): Subnets to ignore

   Examples:
   172.20.5.0/24       # Management VLAN (already monitored separately)
   10.1.255.0/24       # Out-of-band network
   

4. Select scanning techniques (customize per network sensitivity):

   Scanning Technique	Description	Use Case	Recommended For
   Passive Listening	Monitors ARP, DNS, DHCP traffic	Non-intrusive discovery	All networks
   ICMP Probes	Ping sweeps to detect active hosts	Fast discovery	Office, data center
   SNMP Queries	Device fingerprinting via SNMP	Detailed device info	Networks with SNMP enabled
   TCP Connect Scans	Port scanning for service identification	Comprehensive discovery	Non-sensitive networks

   Recommended configurations by network type:

   Corporate Office Networks (low sensitivity):

   • ✅ Passive Listening
   • ✅ ICMP Probes
   • ✅ SNMP Queries (if SNMP community strings are configured)
   • ✅ TCP Connect Scans

   Guest WiFi / BYOD Networks (medium sensitivity):

   • ✅ Passive Listening
   • ✅ ICMP Probes
   • ❌ SNMP Queries (guest devices won't respond)
   • ⚠️ TCP Connect Scans (optional, may slow down guest devices)

   OT/SCADA/ICS Networks (high sensitivity):

   • ✅ Passive Listening ONLY
   • ❌ ICMP Probes (may disrupt industrial controllers)
   • ❌ SNMP Queries
   • ❌ TCP Connect Scans (risk of crashing legacy systems)

5. Configure discovery frequency:

   • Scan Interval: 24 hours (default) or custom (1-168 hours)
   • Scan Window: Restrict scans to maintenance windows (e.g., 2-5 AM) to minimize business impact

6. Save and activate the policy

Result: SentinelOne agents in the specified scope will begin scanning the defined networks using the selected techniques.

Step 3: Monitor network discovery results

1. Navigate to Sentinels → Network Discovery → Devices

2. Review discovered device inventory: The Devices dashboard displays all detected network assets with the following information:

   Column	Description	Example
   Device Name	Hostname (if resolved via DNS/DHCP)	PRINTER-FLOOR3, 192.168.1.45
   IP Address	IPv4 address	10.1.50.22
   MAC Address	Physical hardware address	00:1A:2B:3C:4D:5E
   Device Type	Fingerprinted category	Printer, IP Camera, Server, Workstation, IoT
   OS	Detected operating system	Windows 10, Linux, iOS, Android, Embedded
   Vendor	Manufacturer (from MAC OUI lookup)	HP, Cisco, Hikvision, Amazon
   First Seen	When device was first discovered	2025-11-15 14:30:22
   Last Seen	Most recent detection	2025-11-26 08:15:10
   Status	Active, Inactive, Rogue	Active
   Agent Coverage	Whether SentinelOne agent is installed	✅ Managed / ❌ Unmanaged
   Network	Subnet where device was discovered	10.1.50.0/24

3. Filter and search devices:

   • By Device Type: Device Type = IP Camera to find all security cameras
   • By Vendor: Vendor = Hikvision to audit specific manufacturers
   • By Status: Status = Rogue to identify unauthorized devices
   • Unmanaged Devices: Agent Coverage = No to find devices without SentinelOne agents
   • By Network: Network = 10.1.50.0/24 to review devices in a specific subnet

4. Review device details: Click on a device to view detailed information:

   • Open Ports: Detected network services (TCP 22, 80, 443, etc.)
   • MAC Vendor: Manufacturer name resolved from OUI database
   • DNS Records: Associated hostnames
   • SNMP Info: Device description, system uptime (if SNMP is enabled)
   • Connection History: Timeline of when device appeared on network
   • Communication Map: Which SentinelOne-managed endpoints this device communicates with

Result: You now have complete visibility into all network-connected devices, managed and unmanaged.

Step 4: Fingerprint and categorize IoT devices

1. Navigate to Sentinels → Network Discovery → Devices

2. Filter for unidentified devices: Device Type = Unknown or OS = Unknown

3. Manually classify devices (if automatic fingerprinting is incomplete):

   • Click on a device entry
   • Click Edit Device (pencil icon)
   • Set Device Type: Printer, IP Camera, Access Point, Smart TV, Industrial Controller, etc.
   • Set OS (if known): Embedded Linux, VxWorks, Windows IoT, etc.
   • Add Tags: critical-infrastructure, legacy-system, approved-iot, shadow-it
   • Add Notes: "Canon printer in Accounting department - approved by IT"
   • Save changes

4. Create device groups for bulk management:

   • Navigate to Settings → Network Discovery → Device Groups
   • Click + New Device Group
   • Group Name: IP_Cameras, Printers, OT_Devices, Guest_Devices
   • Membership Criteria: Define filters

     Example - IP Cameras Group:
     Device Type = IP Camera
     OR Vendor IN (Hikvision, Dahua, Axis, Hanwha)
     OR Open Ports CONTAINS 554 (RTSP port)
     

   • Actions: Assign group-level policies (allow/block, isolation rules)

5. Review and approve legitimate devices:

   • For devices identified as approved business assets, tag them as approved
   • For devices identified as shadow IT (personal routers, smart speakers), tag as review-required

Result: All discovered devices are categorized and tagged for policy enforcement.

Step 5: Detect and investigate rogue devices

Rogue devices are network-connected assets that:

• Appear on restricted networks without authorization
• Match known malicious device fingerprints
• Violate network segmentation policies
• Are flagged by custom detection rules

1. Navigate to Sentinels → Network Discovery → Devices

2. Filter for rogue devices: Status = Rogue

3. Review rogue device alerts:

   • Click on a rogue device entry
   • Review Alert Reason: Why the device was flagged
     • Unauthorized device on restricted network
     • Known malicious device signature
     • Device violates policy: Guest network access to corporate subnet

4. Investigate device details:

   • MAC Address: Cross-reference with DHCP logs to identify user
   • First Seen: When did this device appear? (matches security incident timeline?)
   • Network: Which subnet is it on? (should it be there?)
   • Open Ports: What services is it running? (backdoor? C2 server?)
   • Communication Map: What SentinelOne-managed endpoints has it contacted?

5. Common rogue device scenarios:

   Scenario A: Employee Personal Router (Shadow IT)

   Device Type: Access Point
   Vendor: Linksys
   Network: 10.1.50.0/24 (corporate office)
   First Seen: 2025-11-20 09:15
   Alert: "Unauthorized WiFi access point detected"
   
   Investigation: Check physical location via network switch port mapping
   Action: Contact employee, remove device, provide approved WiFi access
   

   Scenario B: IP Camera on Corporate Network (Security Risk)

   Device Type: IP Camera
   Vendor: Unknown (Chinese manufacturer)
   Network: 10.1.10.0/24 (corporate data subnet)
   Open Ports: 23 (Telnet), 8080 (HTTP), 554 (RTSP)
   Alert: "IoT device on restricted network"
   
   Investigation: Telnet access with default credentials = HIGH RISK
   Action: Isolate device, migrate to isolated IoT VLAN, change default password
   

   Scenario C: Unauthorized Raspberry Pi (Potential Backdoor)

   Device Type: Single Board Computer
   Vendor: Raspberry Pi Foundation
   Network: 10.1.1.0/24 (server VLAN)
   Open Ports: 22 (SSH), 5900 (VNC)
   Alert: "Unauthorized device on server network"
   
   Investigation: Unknown owner, SSH active = potential insider threat or attacker pivot
   Action: Immediately isolate, investigate logs, security incident response
   

Result: Rogue devices are identified and triaged for remediation.

Step 6: Isolate rogue or non-compliant devices

When a rogue or malicious device is confirmed, use Network Isolation to block communication with SentinelOne-managed endpoints.

1. Navigate to the rogue device details page

2. Click Actions → Isolate Device

3. Configure isolation policy:

   • Isolation Type:

     • Full Isolation: Block all communication with SentinelOne-managed endpoints
     • Partial Isolation: Block only specific endpoints or networks (advanced)

   • Scope: Which SentinelOne agents should enforce the block?

     • All Agents (global isolation)
     • Specific Sites/Groups (limit to affected network segment)

   • Isolation Method:

     • Firewall Rules: SentinelOne agents add OS firewall rules blocking the rogue device's IP/MAC
     • ARP Spoofing (advanced): Agent sends ARP responses to poison the rogue device's network cache

4. Confirm isolation:

   • Click Isolate to apply the policy
   • Isolation takes effect within 60 seconds (agents receive policy update via console)

5. Verify isolation is active:

   • Device status changes to Isolated in the Devices dashboard
   • Rogue device can no longer communicate with SentinelOne-protected endpoints
   • Note: Rogue device can still communicate with unmanaged devices (printers without agents, non-SentinelOne endpoints)

6. Remediate and restore access (after investigation):

   • Physically locate and remove the device, OR
   • Reconfigure the device to comply with security policies (change default passwords, update firmware)
   • Navigate to device details → Actions → Remove Isolation
   • Device regains network access to SentinelOne-managed endpoints

Result: Rogue device is quarantined and unable to spread malware or exfiltrate data via SentinelOne-protected endpoints.

Step 7: Create custom detection rules for automated rogue device identification

1. Navigate to Settings → Network Discovery → Detection Rules

2. Click + New Detection Rule

3. Define rule criteria:

   Example Rule 1: Detect Unauthorized WiFi Access Points

   Rule Name: Unauthorized_Access_Points
   Description: Flag any WiFi access point/router detected on corporate network
   
   Conditions:
   - Device Type = Access Point OR Router
   - Network IN (10.1.0.0/16, 172.20.0.0/22)  # Corporate networks
   - Agent Coverage = No  # Not a managed device
   
   Action: Mark as Rogue
   Alert Severity: High
   Notification: Email to security@company.com
   

   Example Rule 2: Detect IoT Devices with Telnet Open

   Rule Name: IoT_Telnet_Vulnerability
   Description: Flag IoT devices with insecure Telnet access
   
   Conditions:
   - Device Type IN (IP Camera, Printer, IoT, Industrial Controller)
   - Open Ports CONTAINS 23  # Telnet port
   
   Action: Mark as Rogue
   Alert Severity: Critical
   Notification: Email + SIEM webhook
   

   Example Rule 3: Detect Devices on Restricted Networks

   Rule Name: Unauthorized_PCI_Network_Access
   Description: Flag any unmanaged device on PCI-DSS cardholder data network
   
   Conditions:
   - Network = 10.5.0.0/24  # PCI network
   - Agent Coverage = No
   - Device Type NOT IN (Server, Workstation)  # Exclude known asset types
   
   Action: Mark as Rogue + Isolate Automatically
   Alert Severity: Critical
   Notification: Email + SMS + SIEM webhook
   

4. Configure automated actions:

   • Alert Only: Send notification, no automatic remediation
   • Mark as Rogue: Change device status to Rogue (manual isolation required)
   • Isolate Automatically: Immediately block device without admin approval (use cautiously)
   • Create Ticket: Integrate with ticketing system (ServiceNow, Jira)

5. Save and activate the rule

Result: Custom detection rules continuously monitor network discovery results and automatically flag/isolate rogue devices based on your organization's security policies.

Step 8: Integrate Ranger with SIEM and ticketing systems

Webhook Integration for Real-Time Alerts:

1. Navigate to Settings → Integrations → Webhooks

2. Click + New Webhook

3. Configure webhook:

   • Webhook Name: SIEM_Rogue_Device_Alerts
   • Webhook URL: https://siem.company.com/api/sentinelone/webhook
   • Authentication: API key or OAuth token
   • Trigger Events:
     • ✅ New Rogue Device Detected
     • ✅ Device Isolated
     • ✅ Device Reclassified
     • ✅ Network Discovery Policy Violation

4. Test webhook: Click Test Connection to verify SIEM receives alert

5. Save webhook configuration

Example Webhook Payload:

{
  "event": "rogue_device_detected",
  "timestamp": "2025-11-26T14:30:00Z",
  "device": {
    "ip_address": "192.168.1.99",
    "mac_address": "00:1A:2B:3C:4D:5E",
    "device_type": "Access Point",
    "vendor": "Linksys",
    "network": "10.1.50.0/24",
    "first_seen": "2025-11-26T14:25:00Z",
    "alert_reason": "Unauthorized WiFi access point on corporate network"
  },
  "site": "Corporate HQ",
  "severity": "high"
}

Ticketing System Integration (ServiceNow, Jira):

1. Use SentinelOne's native integrations or webhook forwarding
2. Configure ticket creation rules:
   • Create ticket when: Rogue Device Detected + Severity = High or Critical
   • Assign to: Security Operations team
   • Include details: Device IP, MAC, network, first seen, alert reason

Result: Rogue device detections automatically trigger SIEM alerts and create incident tickets for investigation.

Step 9: Maintain and tune network discovery

Regular Maintenance Tasks:

1. Weekly: Review unmanaged device inventory

   • Navigate to Devices → Filter: Agent Coverage = No
   • Identify devices that should have SentinelOne agents installed
   • Schedule agent deployment for unmanaged workstations/servers

2. Weekly: Audit rogue device alerts

   • Review false positives (legitimate devices incorrectly flagged)
   • Update detection rules to reduce noise
   • Update device groups and tags

3. Monthly: Clean up stale device records

   • Navigate to Devices → Filter: Last Seen > 30 days ago
   • Review inactive devices (decommissioned, offline, or mobile devices)
   • Archive or delete stale records

4. Quarterly: Review network discovery policies

   • Verify target networks match current infrastructure
   • Adjust scanning techniques based on network changes
   • Review excluded networks (are they still valid?)

5. Quarterly: Update device fingerprinting rules

   • Check for new device types on network
   • Update device groups and classification rules
   • Tune SNMP community strings if changed

Performance Tuning:

If network discovery scans are impacting performance:

• Increase scan interval (from 24 hours to 48-72 hours)
• Disable TCP connect scans on high-latency networks
• Schedule scans during maintenance windows (2-5 AM)
• Reduce scan scope (exclude networks with thousands of devices)

Result: Network Discovery operates efficiently with minimal false positives and comprehensive coverage.

VERIFICATION

Verify Ranger is operational:

1. Check discovery status:

   Console → Network Discovery → Dashboard
   - Last Scan: <timestamp should be recent>
   - Devices Discovered: >0
   - Active Policies: >0
   

2. Verify agents are scanning:

   • Navigate to Sentinels → All Endpoints
   • Select a managed endpoint
   • Check Agent Details → Network Discovery:
     • Last Network Scan: <recent timestamp>
     • Devices Discovered by This Agent: <count>

3. Verify device discovery is working:

   • Connect a test device (laptop, phone) to monitored network
   • Wait 1-5 minutes (passive discovery) or force a scan
   • Check Network Discovery → Devices for the new device

4. Test rogue device detection:

   • Connect an unauthorized device (personal router, test device)
   • Verify it appears in Devices dashboard within 5 minutes
   • Verify custom detection rules flag it as Rogue (if configured)

5. Test device isolation:

   • Isolate a test device
   • From a SentinelOne-managed endpoint, attempt to ping/connect to the isolated device
   • Expected result: Connection blocked
   • From a non-SentinelOne endpoint, attempt connection
   • Expected result: Connection succeeds (isolation only affects managed endpoints)

TROUBLESHOOTING

Issue: No devices are being discovered

Symptoms: Network Discovery is enabled, but Devices dashboard shows zero devices

Solutions:

1. Verify agents have network access:

   # On a SentinelOne-managed endpoint
   ipconfig /all  # Verify network connectivity
   ping 8.8.8.8   # Test internet connectivity
   ping `<local gateway>`  # Test local network connectivity

2. Check agent version:

   • Minimum agent version: 21.6
   • Verify: sentinelctl.exe status → Agent version
   • Upgrade agents if needed

3. Verify network discovery policy:

   • Console → Settings → Network Discovery → Policies
   • Ensure at least one active policy exists
   • Verify target networks match actual subnets (check CIDR notation)
   • Verify policy is assigned to correct sites/groups

4. Check firewall rules:

   • Agents need outbound access for scanning:
     • ICMP (ping)
     • SNMP (UDP 161)
     • TCP probes (various ports)
   • Verify Windows Firewall or network firewall allows outbound traffic

5. Force a manual scan:

   • Console → Sentinels → All Endpoints
   • Select an endpoint
   • Actions → Initiate Network Discovery Scan
   • Wait 5-10 minutes, check Devices dashboard

Issue: Devices discovered but not fingerprinted correctly

Symptoms: Devices appear in dashboard but show "Device Type = Unknown" or "OS = Unknown"

Solutions:

1. Enable SNMP if available:

   • Configure SNMP community strings on network devices (routers, switches, printers)
   • Add SNMP community strings to SentinelOne policy:
     • Console → Settings → Network Discovery → SNMP Configuration
     • Add community strings: public, private, custom strings

2. Enable TCP connect scans:

   • Console → Settings → Network Discovery → Policies → [Policy Name]
   • Enable TCP Connect Scans
   • Port scanning improves fingerprinting accuracy

3. Manually classify devices:

   • Navigate to device details
   • Click Edit Device
   • Set Device Type and OS manually
   • SentinelOne learns from manual classifications over time

4. Update SentinelOne agents:

   • Newer agent versions have improved fingerprinting databases
   • Upgrade to latest agent version

Issue: False positives - legitimate devices flagged as rogue

Symptoms: Approved business devices are marked as Rogue

Solutions:

1. Review detection rule criteria:

   • Console → Settings → Network Discovery → Detection Rules
   • Identify which rule flagged the device
   • Adjust rule conditions to exclude legitimate devices:

     Example: Exclude approved WiFi access points
     
     Original Rule:
     Device Type = Access Point → Mark as Rogue
     
     Updated Rule:
     Device Type = Access Point
     AND MAC Address NOT IN (00:1A:2B:..., 00:2C:3D:...)  # Approved APs
     → Mark as Rogue
     

2. Create exclusion list:

   • Console → Settings → Network Discovery → Exclusions
   • Add device by IP, MAC, or device name
   • Excluded devices will never be flagged as Rogue

3. Tag approved devices:

   • Navigate to device details
   • Add tag: approved or trusted
   • Update detection rules to exclude devices with approved tag

4. Whitelist by device group:

   • Create device group for approved IoT devices
   • Update detection rules to exclude this device group

Issue: Device isolation not working

Symptoms: Device marked as Isolated but can still communicate with managed endpoints

Solutions:

1. Verify agent receives isolation policy:

   • Console → Sentinels → All Endpoints
   • Select the endpoint that should block the rogue device
   • Check Agent Details → Policies → Network Discovery Isolation
   • Verify rogue device IP/MAC is listed in firewall rules

2. Check agent connectivity:

   • Agent must be online and connected to console to receive isolation policy
   • Verify agent status: sentinelctl.exe status → Management connectivity

3. Restart SentinelOne agent (forces policy refresh):

   Restart-Service -Name "SentinelAgent" -Force

4. Verify firewall is not disabled:

   • Windows: Check Windows Firewall is enabled
   • macOS: Check firewall in System Preferences → Security & Privacy
   • Linux: Check iptables/nftables are active

5. Manually verify firewall rule:

   # Windows: Check firewall rules
   Get-NetFirewallRule | Where-Object {$_.DisplayName -match "SentinelOne"}
    
   # Should show rules blocking the rogue device IP

6. Re-apply isolation:

   • Console → Devices → [Rogue Device]
   • Actions → Remove Isolation
   • Wait 30 seconds
   • Actions → Isolate Device

Issue: Network scans impacting performance

Symptoms: Endpoints slow down during network discovery scans, network bandwidth spikes

Solutions:

1. Adjust scan frequency:

   • Console → Settings → Network Discovery → Policies → [Policy Name]
   • Change scan interval from 24 hours to 48-72 hours

2. Disable TCP connect scans (most resource-intensive):

   • Console → Settings → Network Discovery → Policies → [Policy Name]
   • Uncheck TCP Connect Scans
   • Use only Passive Listening + ICMP Probes

3. Schedule scans during maintenance windows:

   • Console → Settings → Network Discovery → Policies → [Policy Name]
   • Set Scan Window: 2:00 AM - 5:00 AM

4. Reduce scan scope:

   • Exclude large networks with thousands of devices
   • Focus scanning on critical subnets only

5. Increase agent deployment density:

   • Deploy more SentinelOne agents per subnet
   • Scanning workload is distributed across more agents
   • Each agent scans fewer devices

COMMANDS/SCRIPTS

PowerShell script to export Network Discovery inventory:

<#
.SYNOPSIS
    Export SentinelOne Network Discovery device inventory to CSV
.DESCRIPTION
    Retrieves all discovered devices from SentinelOne console via API
    Exports to CSV for asset inventory and compliance reporting
.PARAMETER ApiToken
    SentinelOne API token with read permissions
.PARAMETER ConsoleUrl
    SentinelOne console URL
.EXAMPLE
    .\Export-S1NetworkDiscovery.ps1 -ApiToken "abc123..." -ConsoleUrl "https://yourtenant.sentinelone.net"
#>
 
param(
    [Parameter(Mandatory=$true)]
    [string]$ApiToken,
 
    [Parameter(Mandatory=$true)]
    [string]$ConsoleUrl
)
 
$ErrorActionPreference = 'Stop'
 
# API headers
$headers = @{
    "Authorization" = "ApiToken $ApiToken"
    "Content-Type" = "application/json"
}
 
Write-Host "=== SentinelOne Network Discovery Inventory Export ===" -ForegroundColor Cyan
 
# Retrieve all discovered devices
Write-Host "[1/2] Retrieving discovered devices from SentinelOne API..." -ForegroundColor Yellow
try {
    $devices = Invoke-RestMethod -Uri "$ConsoleUrl/web/api/v2.1/ranger/devices" -Headers $headers -Method Get -ErrorAction Stop
 
    Write-Host "[SUCCESS] Retrieved $($devices.data.Count) devices" -ForegroundColor Green
}
catch {
    Write-Host "[ERROR] Failed to retrieve devices: $($_.Exception.Message)" -ForegroundColor Red
    exit 1
}
 
# Parse and format device data
Write-Host "[2/2] Formatting device inventory..." -ForegroundColor Yellow
 
$deviceInventory = @()
foreach ($device in $devices.data) {
    $deviceInventory += [PSCustomObject]@{
        DeviceName = $device.deviceName
        IPAddress = $device.ipAddress
        MACAddress = $device.macAddress
        DeviceType = $device.deviceType
        OperatingSystem = $device.osName
        Vendor = $device.manufacturer
        FirstSeen = $device.firstSeen
        LastSeen = $device.lastSeen
        Status = $device.status
        AgentCoverage = if ($device.hasAgent) { "Managed" } else { "Unmanaged" }
        Network = $device.networkName
        Site = $device.siteName
        IsRogue = $device.isRogue
    }
}
 
# Export to CSV
$outputPath = "C:\Temp\SentinelOne-NetworkDiscovery-$(Get-Date -Format 'yyyyMMdd-HHmmss').csv"
$deviceInventory | Export-Csv -Path $outputPath -NoTypeInformation -Encoding UTF8
 
Write-Host "[SUCCESS] Inventory exported to: $outputPath" -ForegroundColor Green
Write-Host "`nSummary:" -ForegroundColor Cyan
Write-Host "  Total Devices: $($deviceInventory.Count)"
Write-Host "  Managed: $(($deviceInventory | Where-Object {$_.AgentCoverage -eq 'Managed'}).Count)"
Write-Host "  Unmanaged: $(($deviceInventory | Where-Object {$_.AgentCoverage -eq 'Unmanaged'}).Count)"
Write-Host "  Rogue: $(($deviceInventory | Where-Object {$_.IsRogue -eq $true}).Count)"

Bash script to test device isolation:

#!/bin/bash
# Test SentinelOne Ranger device isolation
 
ROGUE_IP="192.168.1.99"  # IP of isolated device
 
echo "=== Testing SentinelOne Ranger Device Isolation ==="
echo "Target Device: $ROGUE_IP"
echo ""
 
echo "[1/3] Testing ICMP (ping)..."
if ping -c 3 -W 2 $ROGUE_IP > /dev/null 2>&1; then
    echo "  [FAIL] Device is reachable via ping (isolation not working)"
else
    echo "  [PASS] Device is not reachable via ping"
fi
 
echo "[2/3] Testing TCP connection (port 80)..."
if timeout 5 bash -c "cat < /dev/null > /dev/tcp/$ROGUE_IP/80" 2>/dev/null; then
    echo "  [FAIL] TCP connection successful (isolation not working)"
else
    echo "  [PASS] TCP connection blocked"
fi
 
echo "[3/3] Testing TCP connection (port 22)..."
if timeout 5 bash -c "cat < /dev/null > /dev/tcp/$ROGUE_IP/22" 2>/dev/null; then
    echo "  [FAIL] SSH connection successful (isolation not working)"
else
    echo "  [PASS] SSH connection blocked"
fi
 
echo ""
echo "=== Isolation Test Complete ==="

REFERENCES

• SentinelOne Singularity Network Discovery (Official)
• IoT Discovery and Control with Ranger
• Ranger IoT Technology Preview
• Network Discovery Webinar

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