データが AVM に入るまで

Import はプロセスの終わりではない

AVM は staged workflows を通じて inventory を import します。 asset data と software data は、まず staging records として validation され、 その後 main operational tables に commit されます。 これにより、import behavior が見える形で review 可能になります。

software import では、vendor、publisher、product、version などの raw values が保持されます。 これらの raw values は重要です。 canonical resolution や vulnerability matching は、 import の後に行われるのであって、 import の代わりに行われるわけではないからです。

まず assets、その後 software

AVM では、software rows は assets に紐付く前提です。 実際には、software を import する前に asset records が存在している必要があります。

asset は、後続の software review や alert generation における host anchor になります。 そのため、software import は asset identity が利用可能であることに依存します。

assets と software はどう結び付くか

AVM の import では、 software rows は internal IDs で assets に結び付けられるわけではありません。 代わりに、asset JSON と software JSON の両方で 同じ external_key を使って関連付けます。

つまり、asset とその software は、 import 時に同じ stable external identifier を共有している必要があります。

最小の asset 例

{
  "external_key": "example-uuid-0001",
  "name": "server-01"
}

最小の software 例

{
  "external_key": "example-uuid-0001",
  "product": "Docker Desktop",
  "vendor": "Docker Inc.",
  "version": "4.60.1"
}

import 時に、AVM はこの共有された external_key を internal asset_id に解決します。 その後 software row は、その asset に紐付いた record として保存されます。

external_key は imports をまたいで stable であるべきです。 これが変わると、AVM はその asset を別の system と見なします。

osquery query の例

以下は、同様のデータを osquery で取得する例です。 実際には、これらの結果を AVM の JSON format に変換して import します。

Asset-side の例

osqueryi --json "
SELECT
  uuid AS external_key,
  hostname AS name
FROM system_info;
"

system_info table は、 uuid や hostname といった stable host identity を提供し、 AVM の asset fields にマッピングできます。

Software-side の例（Windows）

osqueryi --json "
SELECT
  (SELECT uuid FROM system_info LIMIT 1) AS external_key,
  name AS product,
  publisher AS vendor,
  version
FROM programs;
"

programs table は installed software inventory を提供します。 external_key は通常、変換時に付与され、 software rows を対応する asset に結び付けるために使われます。

より詳細な asset の例

AVM の assets は、 最小限の external_key と name よりも はるかに多くの host context を保持できます。 source がすでに operating system、hardware、CPU、 host identity details を持っている場合、 それらの context を AVM 内にも残せるようになります。

{
  "arch": "64-bit",
  "asset_type": "endpoint",
  "computer_name": "example-host-01",
  "cpu_brand": "Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz",
  "cpu_logical_cores": "2",
  "cpu_physical_cores": "2",
  "cpu_sockets": "1",
  "external_key": "example-uuid-0001",
  "hardware_model": "VirtualBox",
  "hardware_vendor": "innotek GmbH",
  "hardware_version": "-1",
  "hostname": "example-host-01",
  "local_hostname": "example-host-01",
  "name": "example-host-01",
  "os_build": "26200",
  "os_major": "10",
  "os_minor": "0",
  "os_name": "Microsoft Windows 11 Pro",
  "os_version": "10.0.26200",
  "owner": "example-team",
  "physical_memory": "-1",
  "platform": "windows",
  "serial_number": "example-serial-1234",
  "source": "OSQUERY",
  "system_uuid": "example-uuid-0001"
}

これは assets table の asset-side fields に自然に対応します。 たとえば host identity （external_key、name、 hostname、computer_name、 local_hostname、system_uuid、 serial_number）、 platform と OS （platform、os_name、 os_version、os_build、 os_major、os_minor、 os_patch、arch）、 hardware （hardware_vendor、hardware_model、 hardware_version、board_vendor、 board_model、board_version、 board_serial）、 CPU / memory context （cpu_brand、cpu_physical_cores、 cpu_logical_cores、cpu_sockets、 physical_memory）などです。

osquery data が AVM records にどう対応するか

osquery は通常、AVM に one-to-one で取り込まれるわけではありません。 代わりに、osquery tables を読み取る transformation step が入り、 AVM が実際に保存できる fields に合わせた asset / software JSON を生成します。