elastic/ecs

New geo.division (large), geo.district (medium), and geo.center (small) fields

bonifield opened this issue · 2 comments

Summary

These are additional nested geo fields for large geographical divisions (such as the Midwestern States Division), smaller districts within each division (Central Plains District), and individual centers within each district (ABC Agricultural Support Center). Smaller structure, floor, and room names are also included in this proposal.

Motivation:

Businesses organized into divisions, subdivided into districts, then further subdivided into centers or sites, track metrics using these regional categorizations. A typical use case would include performing a security audit across all division assets starting with district A, then district B, and so forth. This would allow network and host logging to be properly categorized within the appropriate geographical scope for business or security needs. Further dividing into centers allows for identifying a specific campus or building for security remediation. Static environments such as laboratories, agriculture sites, and industrial control systems may also leverage structure, floor, and room categorizations. These geo fields would nest in accordance with existing reuse expectations.

The distinction between geo.division and (existing) geo.region is that one or more states or territories are typically included within a division. A district may also cross state or territory borders and include multiple counties, parishes, and cities.

The distinction between geo.structure, floor, room, and (existing) geo.name is that granular labelling of static environments is supported, further facilitating incident response and automation. For example, this would allow all grain bins within a specific agriculture site to be monitored separately under the same geo.center or geo.site umbrella. This would also allow for granular monitoring of geo.room access on a geo.floor inside of a geo.structure.

Detailed Design:

Primary proposal:

  • geo.division (keyword): A large regional categorization just below country; one or more divisions may exist within a country and include multiple states or territories; may contain one or more districts. Example: Midwestern States Division
  • geo.district (keyword): A medium regional categorization just below division; one or more districts may exist within a division; may contain one or more centers or sites. Example: Central Plains District
  • geo.center OR geo.site (keyword): A small regional categorization just below district; one or more centers or sites may exist within a district; specific campus, installation, or building names. Example: ABC Agricultural Support Center

Secondary proposal:

  • geo.structure (keyword): A tiny regional categorization just below center; one or more structures may exist within a center; specific building names. Example: Grain Bin 3
  • geo.floor (long): A tiny regional categorization just below center or structure; one or more floors may exist within a center or structure; specific numbered floors. Example: 3
  • geo.room (keyword): A tiny regional categorization just below floor; one or more rooms may exist within a floor; specific room or zone names. Example: Billing Office

Breaking my response up into two sections:

Standardizing location data

The geo.* fields are commonly populated using the geoip processor to provide geo enrichment using IP addresses found in an event. The naming convention aligns between the processor and ECS. This alignment provides nice symmetry and a convenient, built-in way for users to enrich their events with geo data.

It's also recognized geo data may also be user supplied. Users are welcomed to populate the geo.* fields using a different means, and ECS includes geo.name as a user-defined option too.

The definitions proposed seem very sensible. But unless there's a well-defined, international standard for terminology, it's challenging to make an argument to set common descriptions for terms like division, district, center or site into ECS. One organization may consider a division to be a division of the business, where a country like India describes divisions as a further division of its states and territories.

Do building/organization details belong under geo.*?

Under the current definitions, the geo.* fields focus on geopositioning details related to a set of geographic coordinates. This definition works well for all the places geo.* is nested today in ECS. Expanding geo.* to include attributes of a campus, data center, office space, etc. starts to create some not-so-useful fields with the current nestings; for example, threat.indicator.geo.floor.

One idea from past discussions is an asset field set. Such a field set would be a good location for building/business specific details like department, floor, building, campus, etc. but also details like a physical serial number or rack unit.

Expanding Geo Field Access

Because geo.name is user-defined and already "Not typically used in automated geolocation", situations where both "Western States Division" and "San Francisco District" exist would be able to use geo.division and geo.district effectively.

The language for the definitions should be updated to be more inclusive of possibilities, such as the mention of India's divisions, but still user-defined as with geo.name. Below are some new definition proposals:

  • geo.division (keyword): Regional categorization that may include multiple sub-regions such as geo.district. Example: Midwestern States Division, Ambala Division, Bangalore Division
  • geo.district (keyword): Regional categorization that may include multiple sub-regions such as geo.site. Example: Central Plains District, Kurukshetra, Chikkaballapur, Alameda
  • geo.center OR geo.site (keyword): Regional categorization that may include a specific campus, installation, or building. Example: ABC Agricultural Support Center, Brahma Sarovar, University of California Berkeley

Additionally geo.site should likely be used in place of geo.center however it is included due to being referenced in the original proposal.

Case For Buildings Within geo.site

It is certainly possible for geo.center or geo.site to get nested under something like threats.*, however if the fields are only used in the same user-defined sense as geo.name then this will likely not affect most users. By creating a site-level breakout, a university campus or other multi-structure location can have an ECS-aligned field to fit into while avoiding the granularity of an asset field. geo.center or geo.site are intended to cover areas potentially bigger than a city (but smaller than a county or district), but also something like a single building or cluster of nearby structures considered to be "one place".

Asset Fields for floor and room

It does make more sense to have floor and room under an asset field rather than geo. Asset would be more inclusive of business-unit details that would not work outside of that organization.