我们已重新整理文档导航结构，使其与您的运营工作流程直接保持一致。如需了解详情，请参阅版本说明和演示视频。

Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

收集 AlgoSec 安全管理日志

解析器版本：4.0

支持的平台：

Google SecOps SIEM

本文档介绍了如何使用 Bindplane 代理将 AlgoSec Security Management 日志注入到 Google Security Operations。

AlgoSec Security Management Suite (ASMS) 可跨防火墙、SDN 和云平台提供网络安全政策管理。它包括用于风险和合规性分析的防火墙分析器、用于变更管理自动化的 FireFlow，以及用于应用连接可见性的 AppViz。

准备工作

请确保满足以下前提条件：

Google SecOps 实例
Windows Server 2016 或更高版本，或者具有 systemd 的 Linux 主机
Bindplane 代理与 AlgoSec 设备之间的网络连接
如果在代理后面运行，请确保防火墙端口已根据 Bindplane 代理要求打开
对 AlgoSec Firewall Analyzer、FireFlow 和 AppViz 的特权访问权限

获取 Google SecOps 注入身份验证文件

登录 Google SecOps 控制台。
依次前往 SIEM 设置 > 收集代理。
下载数据注入身份验证文件。
将文件安全地保存在将要安装 Bindplane 代理的系统上。

注意：此 JSON 文件包含用于向 Google SecOps 验证 Bindplane 代理身份的凭据。

获取 Google SecOps 客户 ID

登录 Google SecOps 控制台。
依次前往 SIEM 设置 > 配置文件。
复制并保存组织详细信息部分中的客户 ID。

注意：配置 Bindplane 代理导出器时需要客户 ID。

安装 Bindplane 代理

按照以下说明在 Windows 或 Linux 操作系统上安装 Bindplane 代理。

Windows 安装

以管理员身份打开命令提示符或 PowerShell。

运行以下命令：

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

等待安装完成。
运行以下命令，验证安装是否成功：
```
sc query observiq-otel-collector
```
该服务应显示为 正在运行。

Linux 安装

打开具有 root 或 sudo 权限的终端。

运行以下命令：

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

等待安装完成。
运行以下命令，验证安装是否成功：
```
sudo systemctl status observiq-otel-collector
```
该服务应显示为有效（正在运行）。

其他安装资源

如需了解其他安装选项和问题排查信息，请参阅 Bindplane 代理安装指南。

配置 Bindplane 代理以注入 syslog 并将其发送到 Google SecOps

找到配置文件

Linux：

sudo nano /etc/bindplane-agent/config.yaml

Windows：

notepad "C:\Program Files\observIQ OpenTelemetry Collector\config.yaml"

修改配置文件

将 config.yaml 的全部内容替换为以下配置：

receivers:
    udplog:
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/algosec:
        compression: gzip
        creds_file_path: '/etc/bindplane-agent/ingestion-auth.json'
        customer_id: '<customer_id>'
        endpoint: malachiteingestion-pa.googleapis.com
        log_type: ALGOSEC
        raw_log_field: body

service:
    pipelines:
        logs/algosec_to_chronicle:
            receivers:
                - udplog
            exporters:
                - chronicle/algosec

配置参数

替换以下占位符：

接收器配置：
- listen_address：要监听的 IP 地址和端口：
  - 0.0.0.0 侦听所有接口（推荐）
  - 端口 514 是标准 syslog 端口（在 Linux 上需要 root 权限；对于非 root 用户，请使用 1514）
导出器配置：
- creds_file_path：提取身份验证文件的完整路径：
  - Linux：/etc/bindplane-agent/ingestion-auth.json
  - Windows：C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json
- customer_id：从 Google SecOps 控制台复制的客户 ID
- endpoint：区域端点网址：
  - 美国：malachiteingestion-pa.googleapis.com
  - 欧洲：europe-malachiteingestion-pa.googleapis.com
  - 亚洲：asia-southeast1-malachiteingestion-pa.googleapis.com
  - 如需查看完整列表，请参阅区域级端点

保存配置文件

修改后，保存文件：
- Linux：依次按 Ctrl+O、Enter 和 Ctrl+X
- Windows：依次点击文件 > 保存

重启 Bindplane 代理以应用更改

如需在 Linux 中重启 Bindplane 代理，请运行以下命令：

sudo systemctl restart observiq-otel-collector

验证服务是否正在运行：

sudo systemctl status observiq-otel-collector

检查日志是否存在错误：

sudo journalctl -u observiq-otel-collector -f

如需在 Windows 中重启 Bindplane 代理，请选择以下选项之一：
- 以管理员身份运行命令提示符或 PowerShell：
```
net stop observiq-otel-collector && net start observiq-otel-collector
```
- 服务控制台：
  1. 按 Win+R，输入 services.msc，然后按 Enter 键。
  2. 找到 observIQ OpenTelemetry 收集器。
  3. 右键点击并选择重新启动。
  4. 验证服务是否正在运行：
```
sc query observiq-otel-collector
```
  5. 检查日志是否存在错误：
```
type "C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log"
```

为 Firewall Analyzer 配置 syslog

使用 SSH 登录 AFA 设备。
前往 syslog-ng 配置目录：
```
cd /etc/syslog-ng
```
备份现有配置：
```
cp syslog-ng.conf syslog-ng.conf.orig
```
修改 syslog-ng 配置文件：
```
vi syslog-ng.conf
```
添加以下行以定义远程 syslog 服务器：
```
destination d_remote { udp("<BINDPLANE_IP>" port(514)); };
log { source(s_sys); destination(d_remote); };
```
- 将 <BINDPLANE_IP> 替换为 Bindplane 代理的 IP 地址。
保存并退出编辑器。
重启 syslog-ng 服务以应用更改：
```
service syslog-ng restart
```
可选：验证 Syslog 配置：
1. 依次前往管理 > Syslog 服务器设置。
2. 点击测试连接。

为 FireFlow 配置 syslog

以 root 身份登录 FireFlow 机器。
打开 /etc/syslog.conf 文件进行修改：
```
vi /etc/syslog.conf
```
将以下代码行添加到文件中：
```
local0.*@<BINDPLANE_IP>
```
- 将 <BINDPLANE_IP> 替换为 Bindplane 代理服务器的 IP 地址。

为 AppViz 配置 Syslog

通过 SSH 登录 AppViz 设备。
前往 syslog-ng 配置目录：
```
cd /etc/syslog-ng
```
备份现有配置：
```
cp syslog-ng.conf syslog-ng.conf.orig
```
修改 syslog-ng 配置文件：
```
vi syslog-ng.conf
```
添加以下内容以定义远程 syslog 服务器：
```
destination d_remote { udp("<BINDPLANE_IP>" port(514)); };
log { source(s_sys); destination(d_remote); };
```
- 将 <BINDPLANE_IP> 替换为 Bindplane 代理的 IP 地址。
保存并退出编辑器。
重启 syslog-ng 服务以应用更改：
```
service syslog-ng restart
```
验证 syslog 配置：
1. 在 AppViz 界面中，依次前往管理 > Syslog 服务器设置。
2. 点击测试连接。

为登录和退出事件配置 syslog

通过 SSH 登录 ASMS 设备。
前往 syslog-ng 配置目录：
```
cd /etc/syslog-ng
```
备份现有配置：
```
cp syslog-ng.conf syslog-ng.conf.orig
```
修改 syslog-ng 配置文件：
```
vi syslog-ng.conf
```
添加以下内容以定义远程 syslog 服务器：
```
destination d_remote { udp("<BINDPLANE_IP>" port(514)); };
log { source(s_sys); destination(d_remote); };
```
- 将 <BINDPLANE_IP> 替换为 Bindplane 代理的 IP 地址。
保存并退出编辑器。
重启 syslog-ng 服务以应用更改：
```
service syslog-ng restart
```

UDM 映射表

日志字段	UDM 映射	逻辑
`by_user`	`principal.user.user_display_name`	原始日志中的 `by_user` 字段的值会分配给此 UDM 字段。
`collection_time`	`metadata.event_timestamp`	系统会将 seconds 和 nanos 字段合并以创建时间戳。
`comm`	`target.process.command_line`	使用 grok 从 `desc` 字段提取的 `comm` 字段的值会分配给此 UDM 字段。
`datetime`	`metadata.event_timestamp`	系统会从原始日志中提取日期和时间，并使用这些信息填充事件时间戳。
`desc`	`metadata.description`	如果没有其他说明，则原始日志中的 `desc` 字段的值会分配给此 UDM 字段。
`dest_ip`	`target.ip`	原始日志中的 `dest_ip` 字段的值会分配给此 UDM 字段。
`dest_port`	`target.port`	原始日志中的 `dest_port` 字段的值会分配给此 UDM 字段。
`details`	`security_result.summary`	原始日志中的 `details` 字段的值会分配给此 UDM 字段。
`device`	`principal.asset.hostname`	原始日志中的 `device` 字段的值会分配给此 UDM 字段。
`dst_ip`	`target.ip`	原始日志中的 `dst_ip` 字段的值会分配给此 UDM 字段。
`dst_port`	`target.port`	原始日志中的 `dst_port` 字段的值会分配给此 UDM 字段。
`event_id`	`metadata.product_event_type`	原始日志中 `event_id` 字段的值会分配给此 UDM 字段。它还用于解析器逻辑，以确定 `metadata.event_type` 和其他字段。
`event_name`	`metadata.product_event_type`	原始日志中的 `event_name` 字段的值会分配给此 UDM 字段。
`firewall`	`target.hostname`	原始日志中的 `firewall` 字段的值会分配给此 UDM 字段。
`host`	`principal.hostname`	原始日志中的 `host` 字段的值会分配给此 UDM 字段。
`host_type`	`principal.asset.category`	原始日志中的 `host_type` 字段的值会分配给此 UDM 字段。
`iporhost`	`principal.ip/principal.hostname/target.ip/target.hostname/observer.ip/observer.hostname`	如果该值为 IP 地址，则会根据日志源和事件类型将其映射到 `principal.ip,target.ip,` 或 `observer.ip`。如果是主机名，则会映射到 `principal.hostname,target.hostname,` 或 `observer.hostname`。
`IP`	`principal.ip`	原始日志中的 `IP` 字段的值会分配给此 UDM 字段。
`kv_data`	`security_result.summary`	原始日志中的 `kv_data` 字段的值会分配给此 UDM 字段。
`log_type`	`metadata.log_type`	硬编码为 `ALGOSEC`。
`metric`	`security_result.action_details`	原始日志中的 `metric` 字段的值会分配给此 UDM 字段。
`msg`	`security_result.summary/security_result.description`	原始日志中 `msg` 字段的值用于填充安全结果的摘要或说明（具体取决于上下文）。它还用于 `extractrisk_level,risk_count,risk_code,` 和 `risk_title` 字段。
`pid`	`target.process.pid`	使用 grok 从 `desc` 字段提取的 `pid` 字段的值会分配给此 UDM 字段。
`product`	`metadata.product_name`	原始日志中的 `product` 字段的值会分配给此 UDM 字段。
`report`	`security_result.description`	原始日志中 `report` 字段的值包含在安全结果的说明中。
`report_data.Device IP`	`target.ip`	已解析的 JSON 数据中 `Device IP` 字段的值会分配给此 UDM 字段。
`report_data.Highest Risk Level`	`security_result.description`	解析后的 JSON 数据中的 `Highest Risk Level` 字段的值包含在安全结果的说明中。它还用于确定安全结果的严重程度。
`report_data.Security Rating Score`	`security_result.description`	解析后的 JSON 数据中 `Security Rating Score` 字段的值包含在安全结果的说明中。
`Requestor.Email`	`principal.user.email_addresses`	已解析的 JSON 数据中 `Request` 对象内的 `Email` 字段的值会分配给此 UDM 字段。
`Requestor.Name`	`principal.user.user_display_name`	已解析的 JSON 数据中 `Requestor` 对象内的 `Name` 字段的值会分配给此 UDM 字段。
`RequestType`	`target.resource.attribute.labels`	原始日志中 `RequestType` 字段的值会作为标签添加到目标资源。
`risk_title`	`security_result.summary`	原始日志中的 `risk_title` 字段的值会分配给此 UDM 字段。
`src_ip`	`principal.ip`	原始日志中的 `src_ip` 字段的值会分配给此 UDM 字段。
`src_port`	`principal.port`	原始日志中的 `src_port` 字段的值会分配给此 UDM 字段。
`status`	`security_result.description/security_result.action_details`	原始日志中 `status` 字段的值会包含在安全结果或操作详情的说明中，具体取决于上下文。它还用于确定安全结果的严重程度。
`target_app`	`target.application`	原始日志中的 `target_app` 字段的值会分配给此 UDM 字段。
`TemplateName`	`metadata.description`	原始日志中的 `TemplateName` 字段的值会分配给此 UDM 字段。
`url`	`security_result.url_back_to_product`	原始日志中的 `url` 字段的值会分配给此 UDM 字段。
`user`	`principal.user.userid`	原始日志中的 `user` 字段的值会分配给此 UDM 字段。
`vendor`	`metadata.vendor_name`	原始日志中的 `vendor` 字段的值会分配给此 UDM 字段。
`version`	`metadata.product_version`	原始日志中的 `version` 字段的值会分配给此 UDM 字段。
`WorkFlow`	`target.resource.attribute.labels`	原始日志中 `WorkFlow` 字段的值会作为标签添加到目标资源。
`(Parser Logic)`	`extensions.auth.type`	硬编码为 `MACHINE`。
`(Parser Logic)`	`security_result.action`	根据 `event_id` 和其他字段确定。通常设置为 `ALLOW or BLOCK`。
`(Parser Logic)`	`security_result.category`	对于防火墙分析器事件，硬编码为 `POLICY_VIOLATION`。
`(Parser Logic)`	`security_result.description`	根据其他字段构建，提供有关事件的背景信息和详细信息。
`(Parser Logic)`	`security_result.severity`	根据 `event_id,msg,` 和其他字段确定。通常设置为 `LOW,MEDIUM,` 或“HIGH”。
`(Parser Logic)`	`metadata.event_type`	根据 `event_id` 和其他字段确定。例如 `USER_LOGIN,USER_LOGOUT,USER_RESOURCE_ACCESS,GENERIC_EVENT,STATUS_UNCATEGORIZED,SCAN_HOST,NETWORK_CONNECTION,` 和 `STATUS_UPDATE`。

更新日志

查看相应解析器的更改日志