Populate host.type for consideration by the detection engine

[randomuserid]

Summary

Design and implement a scheme for populating host.type. The refs talk about populating with data like instance type / size like t2.medium but wouldn’t more generic classes of types be useful? For example; endpoint, desktop, laptop, p-server, v-server, member server, domain controller, host (hypervisor), etc; these are some types I would use to apply differential logic to.

Motivation:

For example, one ML job currently exists that might be used mostly on domain controllers, or on member servers, with a higher risk score on DCs. Other detections like gapping data from a beat would need exemptions for laptops, ephemeral VMs, and maybe desktops that sleep, but not member servers and DCs. Another example could be JVM behavior which can be pretty diverse and could be useful to ignore endpoints vs. server. In general, a member server may deserve a higher risk score than an endpoint, a p-server higher than a v-server, and a DC higher than a member server.

Detailed Design:

Devise approved values for the host.type field. In order to manage this at scale, users would probably need a way to manage the population of this field across a fleet of beats. We might also need a new rule type or a new operator to adjust risk scores based on host.type

• Field names
• Example values for the fields

endpoint, desktop, laptop, p-server, v-server, member server, domain controller, host (hypervisor)

• Suggested appropriate datatypes

• Any example events that map to the proposed use case(s)

[dainperkins]

@randomuserid Would an asset fieldset - encompassing type (laptop, server, vm, cloud instance, container, etc), services (web, dns, etc), other standard cmdb fields, and associated nested fields for e.g. owner, custodian, risk, etc. work to address the need?

[randomuserid]

A capability to differentiate between clients and servers, and critical servers, is the more immediate need that I would use first. In the case linked above, we could be more aggressive on critical infrastructure like auto-update servers in addition to domain controllers and DNS servers.

[randomuserid]

Another use case from discussion today. Excluding pseudorandom names is useful on containers, but we'd like to know about odd names on non-K8 workloads and clients. If we had an instance.type = container, we could apply this exception more precisely.