收集 Avaya Aura 記錄

支援的國家/地區:

本文說明如何使用 Bindplane,將 Avaya Aura 記錄擷取至 Google Security Operations。剖析器會先使用規則運算式和「grok」篩選器,從原始 Avaya Aura 系統記錄訊息中擷取欄位。然後,系統會將擷取的欄位對應至統一資料模型 (UDM),並根據嚴重程度等值進行正規化,以及根據關鍵字識別特定事件類型,例如使用者登入或登出。

事前準備

請確認您已完成下列事前準備事項:

  • Google SecOps 執行個體
  • Windows 2016 以上版本,或搭載 systemd 的 Linux 主機
  • 如果透過 Proxy 執行,防火牆通訊埠已開啟
  • Avaya Aura 的特殊存取權

取得 Google SecOps 擷取驗證檔案

  1. 登入 Google SecOps 控制台。
  2. 依序前往「SIEM 設定」>「收集代理程式」
  3. 下載擷取驗證檔案。將檔案安全地儲存在要安裝 Bindplane 的系統上。

取得 Google SecOps 客戶 ID

  1. 登入 Google SecOps 控制台。
  2. 依序前往「SIEM 設定」>「設定檔」
  3. 複製並儲存「機構詳細資料」專區中的客戶 ID

安裝 Bindplane 代理程式

Windows 安裝

  1. 以系統管理員身分開啟「命令提示字元」或「PowerShell」
  2. 執行下列指令:

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

Linux 安裝

  1. 開啟具有根層級或 sudo 權限的終端機。
  2. 執行下列指令:

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

其他安裝資源

如需其他安裝選項,請參閱安裝指南

設定 Bindplane 代理程式,擷取系統記錄檔並傳送至 Google SecOps

  1. 存取設定檔:
    • 找出 config.yaml 檔案。通常位於 Linux 的 /etc/bindplane-agent/ 目錄,或 Windows 的安裝目錄。
    • 使用文字編輯器 (例如 nanovi 或記事本) 開啟檔案。
  2. 按照下列方式編輯 config.yaml 檔案:

    receivers:
        udolog:
            # Replace the port and IP address as required
            listen_address: "0.0.0.0:514"
    
    exporters:
        chronicle/chronicle_w_labels:
            compression: gzip
            # Adjust the path to the credentials file you downloaded in Step 1
            creds: '/path/to/ingestion-authentication-file.json'
            # Replace with your actual customer ID from Step 2
            customer_id: <customer_id>
            endpoint: malachiteingestion-pa.googleapis.com
            # Add optional ingestion labels for better organization
            ingestion_labels:
                log_type: 'AVAYA_AURA'
                raw_log_field: body
    
    service:
        pipelines:
            logs/source0__chronicle_w_labels-0:
                receivers:
                    - udplog
                exporters:
                    - chronicle/chronicle_w_labels
    
  3. 視基礎架構需求,替換通訊埠和 IP 位址。

  4. <customer_id> 替換為實際的客戶 ID。

  5. /path/to/ingestion-authentication-file.json 更新為「取得 Google SecOps 擷取驗證檔案」一節中驗證檔案的儲存路徑。

重新啟動 Bindplane 代理程式,以套用變更

  • 如要在 Linux 中重新啟動 Bindplane 代理程式,請執行下列指令:

    sudo systemctl restart bindplane-agent
    
  • 如要在 Windows 中重新啟動 Bindplane 代理程式,可以使用「服務」控制台,或輸入下列指令:

    net stop BindPlaneAgent && net start BindPlaneAgent
    

在 Avaya Aura 中設定系統記錄檔

  1. 登入 Avaya Aura 控制台。
  2. 依序前往「EM」>「System Configuration」(系統設定) >「Logging Settings」(記錄設定) >「Syslog」(系統記錄)
  3. 啟用「透過 SYSLOG 傳送記錄」
  4. 按一下「新增」
  5. 提供下列設定詳細資料:
    • 伺服器位址:輸入 Bindplane 代理程式 IP 位址。
    • 「Port」(通訊埠):輸入 Bindplane 代理程式監聽通訊埠。
  6. 按一下 [儲存]
  7. 按一下「確認」。
  8. 重新啟動 Avaya Aura。

UDM 對應表

記錄欄位 UDM 對應 邏輯
data{}.@timestamp metadata.event_timestamp 系統會使用 grok 模式從資料欄位剖析事件時間戳記,並指派給 UDM 中繼資料部分的 event_timestamp 欄位。
data{}.host principal.hostname 主機值會使用 grok 模式從資料欄位中擷取,並指派給 UDM 主體部分的 hostname 欄位。
data{}.portal security_result.about.resource.attribute.labels.value 系統會使用 grok 模式從資料欄位擷取入口網站值,並在 UDM 的 security_result 中,將該值指派為 about.resource.attribute.labels 區段內的 Portal 標籤值。
data{}.prod_log_id metadata.product_log_id 系統會使用 grok 模式從資料欄位擷取 prod_log_id 值,並指派給 UDM 中繼資料部分的 product_log_id 欄位。
data{}.sec_cat security_result.category_details 系統會使用 grok 模式從資料欄位擷取 sec_cat 值,並指派給 UDM 安全性結果部分的 category_details 欄位。
data{}.sec_desc security_result.description 系統會使用 grok 模式從資料欄位擷取 sec_desc 值,並指派給 UDM 的 security_result 區段中的說明欄位。
data{}.severity security_result.severity 嚴重程度值會使用 grok 模式從資料欄位中擷取。如果嚴重程度為 warnfatalerror (不分大小寫),則會對應至 UDM 的 security_result.severity 欄位中的 HIGH。否則,如果嚴重程度為 info (不分大小寫),則會對應至 LOW
data{}.summary security_result.summary 系統會使用 grok 模式從資料欄位擷取摘要值,並指派給 UDM 的 security_result 區段中的摘要欄位。
data{}.user_id target.user.userid 系統會使用 grok 模式從資料欄位中擷取 user_id 值,並指派給 UDM target.user 區段中的 userid 欄位。
extensions.auth.type 如果 event_name 欄位包含 log(in|on)logoff (不區分大小寫),或者 summary 欄位包含 loginlogoff (不區分大小寫) 且 user_id 欄位不為空白,auth.type 欄位會設為 AUTHTYPE_UNSPECIFIED
metadata.description 如果 desc 欄位不為空白,系統會將該欄位的值填入說明欄位。
metadata.event_type 系統會根據下列邏輯判斷 event_type 欄位: - 如果 event_name 欄位包含 log(in|on) 或 summary 欄位包含 login (不區分大小寫),且 user_id 欄位不為空白,則 event_type 會設為 USER_LOGIN。 - 如果 event_name 欄位包含 logoff 或摘要欄位包含 logoff (不區分大小寫),且 user_id 欄位不是空白,則 event_type 會設為 USER_LOGOUT。 - 如果 has_principal 欄位為 true,則 event_type 會設為 STATUS_UPDATE。 - 否則,event_type 會維持 GENERIC_EVENT (預設值)。
metadata.log_type log_type 會硬式編碼為 AVAYA_AURA
metadata.product_event_type 如果 event_name 欄位不為空白,系統會將該欄位的值填入 product_event_type 欄位。
metadata.product_name product_name 會硬式編碼為 AVAYA AURA
metadata.vendor_name vendor_name 的硬式編碼為 AVAYA AURA
security_result.action 系統會根據下列邏輯設定 security_result 區段中的動作欄位: - 如果摘要欄位包含 failfailed (不區分大小寫),動作會設為 BLOCK。 - 如果摘要欄位包含 success (不區分大小寫),則動作會設為 ALLOW
security_result.severity_details 如果 severity_details 欄位不為空白,系統會填入該欄位的值。
timestamp.nanos metadata.event_timestamp.nanos 時間戳記欄位的 nanos 值會直接對應至 UDM 中繼資料 event_timestamp 區段的 nanos 欄位。
timestamp.seconds metadata.event_timestamp.seconds 時間戳記欄位的秒數值會直接對應至 UDM 中繼資料 event_timestamp 區段的秒數欄位。

還有其他問題嗎?向社群成員和 Google SecOps 專業人員尋求答案。