Data Model
AVM が内部でどのように構成されているか
AVM は、observed inventory、canonical references、 vulnerability intelligence、operational results、 review records を、それぞれ区別しつつ相互接続された entities として扱います。 この構造自体が、システムを inspectable に保つための一部です。
データモデルがシステムを説明する
AVM は、inventory、reference data、matching results を 別々の層として保存します。 raw software observations は、assets に紐付く software records として保持されます。 canonical vendor / product references は、 normalized targets を提供します。 vulnerability records と criteria は、 何が affected になり得るかを定義します。 alerts は、それらの条件に対して software を評価した operational result を表します。
import staging、unresolved mappings、aliases、settings、audit records も、 background processing の中に隠すのではなく、 明示的にモデル化されています。 これにより、system が何を知っているのか、 何を inferred したのか、 そして何がまだ review を必要としているのかを理解しやすくなります。
Design principle: データ構造そのものが、システムの挙動を説明できるようであるべきです。
高レベルなモデル
高いレベルでは、AVM は次の 5 つの接続された層として捉えられます。
import staging と administration は、 このモデルの外側にあるのではなく、 このモデルを支える要素です。
中核となる operational entities
Asset
server、workstation、laptop、VM などの monitored system を表します。 assets は、software と alerts に対する host context を提供します。
SoftwareInstall
asset 上で観測された software を表します。 canonical linking と vulnerability evaluation の主要な出発点です。
Vulnerability
import された vulnerability intelligence と、 downstream の matching / prioritization に使われる関連 metadata を表します。
Alert
installed software を stored vulnerability conditions に対して評価した operational result を表します。
Assets
asset は、AVM モデルにおける host-level anchor です。 software が観測され、 alerts が operationally meaningful になる system 自体を表します。
assets は通常、identity と context を持ちます。 たとえば、names、external identifiers、platform / OS information、 hardware-related details、observation timestamps などです。
なぜ assets が重要か
matching の結果は、現実の system に結び付けられて初めて有用になります。
典型的な役割
一つの asset は、多数の software rows と、 そこから生まれる多数の alerts の host context になります。
Software installs
SoftwareInstall records は、 assets に紐付いた observed software を表します。 これは、system がそれをどう map したり評価したりするかを決める前の、 inventory-side の見え方を保持する entity です。
この entity は意図的に多くの情報を持ちます。 AVM は、source context、raw naming、version information、 import linkage、canonical linkage state を保持する必要があるからです。
Raw inventory values
raw vendor、product、publisher、version values は、 source evidence を保持し、 後の review を支えるために重要です。
Canonical linkage fields
software rows は、link 済みになれば canonical vendor / product records を参照できます。
Source and provenance
import source、source type、package-related information、 timestamps などは、 row がどのように system に入ったかを保持します。
Operational control
一部の software rows は、意図的に canonical linking workflows から除外されることがあり、 それが downstream matching behavior に影響します。
Reference and canonical entities
AVM は、import で現れた文字列だけに依存しないように、 canonical references を使います。 canonical vendor / product tables は、 inventory と vulnerability logic を接続する stable identifiers を提供します。
CpeVendor
多くの software records、aliases、vulnerability relationships で共有される normalized vendor reference です。
CpeProduct
canonical vendor の配下にある normalized product reference です。 vulnerability matching への主要な橋渡しになります。
CpeVendorAlias
代替 vendor names を canonical vendor identities に結び付ける 明示的な mapping です。
CpeProductAlias
代替 product names を、 canonical vendors 配下の canonical products に結び付ける 明示的な mapping です。
AVM にはさらに、 common naming variation を candidate selection や review の前後で解消するための synonym-driven normalization logic もあります。
Vulnerability and criteria entities
AVM における vulnerability matching は、 flat な affected products の一覧だけで動いているわけではありません。 data model は、conditions として評価できる structured criteria も保持します。
Vulnerability
evaluation と prioritization に使われる、 main vulnerability record と supporting metadata を保存します。
VulnerabilityAffectedCpe
direct affected-CPE style の matching や lookups に使う、 affected canonical pairs を保存します。
VulnerabilityCriteriaNode
criteria tree の node structure を保存します。 これにより logical conditions を、 flatten せずに評価できます。
VulnerabilityCriteriaCpe
criteria nodes に紐付く CPE predicates を保存します。 version-aware evaluation に必要な情報も含まれます。
この分離は重要です。 vulnerability は単一の単純な product string ではなく、 product、platform、version conditions の組み合わせで記述されることがあるからです。
Alerts and review entities
alerts は matching の operational outcome を表しますが、 AVM は完全には解決されていないケースのために、 review-oriented entities も保持します。
Alert
software record と vulnerability result を結び付け、 operators が review / action できる形にしたものです。
UnresolvedMapping
canonical vendor / product references にまだ十分な確信を持って linked されていない software naming cases を記録します。
これは AVM における重要な区別です。 すべての unresolved inventory row が alert になるわけではなく、 すべての review task が matching の裏に隠れているわけでもありません。
alerts には certainty value もあります。 CONFIRMED は、 AVM が vulnerability applicability を十分な精度で確認できたことを意味します。 UNCONFIRMED は、 vulnerability が適用される可能性はあるが、 available evidence だけでは full confirmation に足りなかったことを意味します。 典型的には、version-related ambiguity がある場合です。
alert が UNCONFIRMED の場合、 AVM は uncertainty reason も保持できます。 たとえば、missing software version、unparseable version、 あるいは vulnerability data 側に usable version constraint がない場合などです。
Import and staging
AVM は staged import を明示的にモデル化しています。 imported data は、main operational inventory の一部になる前に、 staging entities に validation 付きで保存されます。
ImportRun
一回の import execution を追跡し、 staged data、outcomes、後の review のための shared reference を提供します。
ImportStagingAsset
final import の前に、 validation / preview 中の staged asset rows を保持します。
ImportStagingSoftware
validation / preview 中の staged software rows を保持します。 ここには、後から review や canonical resolution が必要になるかもしれない inventory-side values も含まれます。
なぜ staging があるのか
import behavior を visible / reviewable に保つためです。 すべてを直接 core tables に書き込まないようにしています。
Security and administration
AVM は、operational control と traceability も明示的にモデル化しています。 administration は単なる UI behavior ではなく、 stored system state の一部です。
AppUser
authenticated application user と、 関連する account state を表します。
AppRole
access control に使われる application roles を表します。
SystemSetting
configurable system behavior を保存し、 matching / review に関わる重要な選択が visible なままになるようにします。
SecurityAuditLog
security-relevant な administrative / account events を保存し、 traceability を支えます。
各要素はどうつながるか
AVM における典型的な operational path は次のようになります。
canonical linking が不完全な場合、 software row は alert ではなく、 unresolved mapping / review workflows 側に visible なまま残ることがあります。
Example
ある asset に、次の software が installed されているとします。
- vendor (raw): Microsoft Corporation
- product (raw): Microsoft Windows Notepad
- version (raw): 10.0.19045
この raw record は、observed evidence として保存されます。 この段階では、AVM はこれらの values を すでに stable product identity だとはみなしません。
canonical linking の過程で、この row は次のように linked されるかもしれません。
- canonical vendor: microsoft
- canonical product: windows_notepad
別の層では、AVM は次のような vulnerability definitions を保存しています。
- CVE-XXXX-YYYY affects microsoft:windows_notepad
- version condition: < 10.0.20000
alerts を生成する際、 AVM は software の canonical identity と version が、 これらの条件を満たすかを評価します。
この例では、version 10.0.19045 は affected range の中に入るため、 alert が作成されます。 もし version がそれより高ければ、 あるいは product が正しく linked されていなければ、 alert は作成されないか、 あるいは uncertain result になります。
これは次の分離を示しています。 raw observation、canonical identity、vulnerability conditions、 alert generation はつながっていますが、 各ステップは明示的に評価されます。
なぜこの構造が重要なのか
evidence を保持できる
raw inventory values と staging records は、 row がどのように system に入ったかを説明するのに役立ちます。
reference truth を保持できる
canonical tables と vulnerability criteria は、 stable で再利用可能な matching inputs を提供します。
review surfaces を保持できる
unresolved mappings、aliases、settings、audit records は、 operational improvement を明示的なものにします。
result traceability を保持できる
alerts は、hidden logic の implicit by-product ではなく、 独立した operational result として存在します。