CBOM Documentation

CBOM Secure

  • Product Overview
    • Overview
    • Dashboard Interface
    • Dashboard Operations
    • Data Visualization
    • Overview
    • Host
    • Template
      • Networked Deployments
      • Cloud Deployments
      • Off-Grid Deployments
    • Discovery History
      • Tags
      • Tag Scope
      • Integrations
      • Cloud Servers
      • CycloneDX Export
    • Sensors Reference
    • Overview
    • Summary Report
    • PQC Report
    • AI Services
    • Source Code Visualizer
    • Key
    • Certificate
    • CipherSuites
    • Analysis
    • Policy Management
    • User Policy
    • Standard Policy
    • Overview
    • Cases
    • Criteria
    • Notification Format
    • Rules
      • Connections
      • Health
    • User Management
    • Roles & Permissions
    • Audit Trail
    • System Logs
    • Top Bar and User Menu
    • System Configuration
  • Login and Authentication
    • Introduction
      • Components
      • Data Flows
      • Execution Models
      • Incremental Scanning
      • Security Model
      • Topologies
      • Sizing Guide
      • HA and Scaling
      • Ports and Firewall
      • Prerequisites
      • Docker Compose
      • Native on Linux
      • Deployment Server
      • Install Troubleshooting
      • Validation Checklist
      • Managing Services
      • Logging
      • Certificates
      • Configuration
      • Backup and Recovery
      • Ops Troubleshooting
      • Methods
      • SAML 2.0 SSO
      • OIDC and Entra ID
      • Token Authentication
      • Password Policy
      • Sensor vs Connector
      • Sensor Guide Structure
      • Capability Matrix
      • GitHub Sensor
        • AWS
        • Azure
        • Google Cloud
        • Active Directory
        • LDAP Directories
        • AD CS
        • Thales Luna HSM
        • Entrust nShield HSM
        • HashiCorp Vault KMIP
        • Windows Cert Store
        • Linux Trust Store
        • MSSQL TDE
      • Roadmap
      • Integration Model
      • CrowdStrike
      • ServiceNow
      • ServiceNow and Jira Setup
      • Notification Engine
  • Administrative Guide
    • Glossary
    • Configuration Reference
    • Data Model Reference
    • API Reference
    • API Authentication
    • CycloneDX Export Specification
    • Risk and PQC Scoring
    • Built-in Standards
    • Widget Catalogue
    • AI Services Data Handling

6.2 CrowdStrike Host Scan Guide

6.2.1 How It Fits

This integration serves two purposes, and they are worth separating because a deployment may want one without the other.

  • Host inventory: Falcon knows every managed endpoint. Synchronising that inventory into CBOM Secure removes the need to maintain a host list by hand and means new endpoints become scan candidates automatically.

  • Scan delivery and execution: the Falcon agent is already deployed, already trusted and already has local privilege. Using Real Time Response to deliver and run the discovery sensor avoids opening SSH or WinRM across the estate.

The second point is the one that wins the argument with a customer security team. It is not a convenience; it removes a whole class of firewall exception from the project.

6.2.2 Prerequisites

  • A Falcon subscription including Real Time Response with the response scripting capability.

  • API client credentials with the scopes needed for host enumeration, package upload, script management and workflow execution — those scopes and no more.

  • Optionally a host group scoping which endpoints are in scope. Recommended for a first deployment.

  • Network access outbound from the platform to the Falcon API endpoint for the relevant cloud region.

  • The discovery sensor package for each target platform in scope.

6.2.3 Configure the Integration

  • Add a CrowdStrike integration in the platform, supplying the API client identifier, secret and cloud region.

  • Save. The credential is encrypted at rest and masked on subsequent reads.

  • Verify authentication. The platform obtains an access token, caches it, and refreshes it shortly before expiry — so a working first call does not have to be repeated to prove the integration is healthy.

  • If the credential is later rotated at the Falcon end, update it here. An unrotated credential fails at the next token refresh, which may be well after the change.

6.2.4 Host Synchronisation

  • Trigger a synchronisation, or configure it to run on a schedule.

  • The platform enumerates hosts from Falcon and reconciles them into the host inventory — matching existing entries rather than duplicating them, and recording the Falcon identifier so that subsequent synchronisations match correctly.

  • Synchronised hosts carry their Falcon identity and can be selected as scan targets like any other host.

  • The reconciliation rule matters: which field is matched on, and what happens to a host that appears in Falcon under a changed name. That detail determines whether the second synchronisation duplicates the estate.

6.2.5 Deploy and Run the Sensor

  • Download the sensor package for the target platform from the platform.

  • Upload it to Falcon as a Real Time Response put file.

  • Create three response scripts: one to check whether the sensor is already present on a host, one to run it, and one to remove it. Separating check from run makes the workflow idempotent, which matters when it runs across thousands of endpoints.

  • Create a workflow that targets the host group, runs the check script, deploys the package where absent, runs the sensor, and collects the result.

  • Execute the workflow, either on demand or on a schedule.

  • Results are emitted to the collector and appear in the inventory attributed to the host they came from.

6.2.6 Undeploy

  • Run the undeploy script through a workflow to remove the sensor from hosts once scanning is complete.

  • Undeploying is the right default for a periodic scan: the sensor is delivered, runs, reports and is removed, leaving no persistent footprint. That is a materially easier proposition to get approved than a permanently installed agent, and it is the recommended pattern.

6.2.7 Operational Notes

  • Deploying a new sensor package version requires uploading the new package and updating the workflow. Old packages should be removed once no workflow references them.

  • Findings from EDR-delivered scans deduplicate against findings from any other source for the same material. A certificate found by both a network scan and a host scan is one material with two deployment records.

  • Alert on integration authentication failures and on host synchronisation returning zero hosts. Both are silent failures.

  • Scope the host group deliberately. A workflow across an unscoped estate is a large simultaneous operation.

On this Page:
Support Privacy Policy Terms of Service

Copyright 2026 Encryption Consulting LLC. All rights reserved.