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 Divisiongeo.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 Districtgeo.center
ORgeo.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 3geo.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: 3geo.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 asgeo.district
. Example: Midwestern States Division, Ambala Division, Bangalore Divisiongeo.district
(keyword): Regional categorization that may include multiple sub-regions such asgeo.site
. Example: Central Plains District, Kurukshetra, Chikkaballapur, Alamedageo.center
ORgeo.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.