Device Management

Device management corresponds to the Data Sources and Devices page in the WebUI. It manages access to security devices and data sources in one place. It maintains a device or data source along three dimensions: API access, web2cli (Web-to-CLI page automation) actions, and device Skill.

1. Purpose

1.1 What Device Management Solves

Device management connects Flocks to enterprise security devices and data sources. It does more than record a device inventory; it focuses on how each device can be used by the platform.

A device or data source usually needs to maintain:

• Basic information: instance name, vendor, product, version, and deployment location.
• Health status: online, abnormal, or not configured.
• Last synchronization time and connectivity test result.
• API access capabilities.
• web2cli (Web-to-CLI page automation) capabilities.
• Device Skill and default Workflow bindings.

1.2 Three Capability Dimensions

Dimension	Description	Best for
Device API Access	Access alerts, assets, health status, rules, evidence, and other data through interfaces.	Devices with stable APIs or APIs that can be captured and formalized.
Device web2cli	Record or convert Web console operations into executable page-automation actions.	Devices that only have a Web management console or incomplete APIs.
Device Skill	Capture device inspection methods, field explanations, alert triage logic, and operating rules.	Device scenarios that require team experience and judgment criteria.

2. Page Structure

The device management page usually includes:

• Total connected count, online count, abnormal count, and not-configured count.
• Data source / device filters.
• Filters for the three dimensions: API, web2cli, and device Skill.
• A data source list showing type, instance, vendor product, location, status, version, synchronization time, connectivity, and three-dimensional capability status.
• An access wizard.
• A mapping table showing supported objects and the default Workflow.

The page title in the product is "Data Sources and Devices"; in navigation, it can be understood as device management.

3. Integration Process

3.1 Select a Type

First determine the object type to integrate, for example:

• Firewall.
• NDR.
• HIDS.
• SIEM.
• Threat intelligence.
• Asset system.
• Ticketing system.

3.2 Enter Address and Credentials

Enter the endpoint, Token, AK/SK, Secret, or account credentials based on the device type. Sensitive credentials should be managed through secret references. Do not write them into Prompts, scripts, or public documents.

3.3 Test the Connection

After integration, run a connectivity test to confirm:

• The network is reachable.
• Credentials are valid.
• The version is compatible.
• Returned fields can be consumed by tools, Agents, or Workflow.

3.4 Select Capabilities

Select capabilities based on the device conditions:

• If the API is complete, prioritize API tools.
• If the API is incomplete but the Web management console can perform the operation, add web2cli.
• After inspection and triage methods become stable, capture them as a device Skill.
• After the process becomes stable, bind a default Workflow.

3.5 Link Orchestration

Device capabilities can be further bound to:

• Tool Inventory: maintain API tools and MCP tools.
• Skills: maintain device usage methods and inspection rules.
• Workflow: bind fixed processes.
• Task Center: configure periodic inspections or scheduled execution.

4. Device Integration Guides

• Custom Device Integration: integrate devices that are not preset, private APIs, or Web consoles.
• TDP Integration: configure the API Key, Secret, and Base URL for ThreatBook TDP.
• OneSEC Integration: enable the OneSEC Open API and copy api_key and secret.
• OneSIG Integration: add an API verification configuration in OneSIG API Linkage, then enter ApiKey, Secret, and Base URL.
• NGTIP Integration: configure API Keys for the ThreatBook HVV intelligence platform's intelligence query and platform function APIs.
• SkyEye Integration: configure Qi An Xin SkyEye. Note that Base URL must include the /skyeye suffix.
• Sangfor SIP Integration: configure the SIP third-party platform and Flocks-side connection parameters.

5. Usage Recommendations

5.1 API First, web2cli as a Supplement

If the device provides a stable API, integrate it through API tools first. APIs are better suited to scheduled execution, recurring tasks, and batch processing.

When the API is incomplete and the Web console provides richer capabilities, use web2cli to turn key page actions into executable capabilities, such as viewing License expiration, rule-hit details, and device health pages.

5.2 Use Device Skills to Capture Experience

A device Skill is not the same as the full Skills management entry point on the Skills page, but it indicates that methodology assets already exist for this device. Suitable content includes:

• Inspection items.
• Field explanations.
• Health judgment criteria.
• Common abnormal-condition handling suggestions.
• Device version differences.

5.3 Connect with SOC Device Inspection

Device management is responsible for integration and capability status. SOC device inspection is responsible for viewing inspection results. After integration is complete, go to the SOC device inspection page to view device inspection reports and execution results.

6. Related Modules

• Tool Inventory: maintain device API tools and MCP capabilities.
• Skills: maintain device methodology and inspection rules.
• Workflow: turn device operations into repeatable processes.
• Task Center: configure periodic device inspections.
• Scenario Practice · Device Integration and Inspection: scenario guidance after device integration.