Unified path for log source/vendor name (POLL #2)

[paveljos]

Background:
OCSF needs a unified place to identify a data source. Previously, OCSF implementations utilized origin.product for certain types of data, but origin.cloud.service for others. For this essential, central, identification mechanism, OCSF would benefit from a unified path.

Cascading proposals:
These are stand-alone considerations that, when considered holistically, should address the whole proposal of identifying source data. This is NOT intended to represent other logging facilities that may be a part of the transmission of the log (log scrapers, forwarders, parsers, proxies, etc.); these fields are meant to provide a universal path for data that identifies the VENDOR of the data provided and the TYPE of data provided; e.g.,

  "Apache" "HTTP Access Log"
  "Apache" "HTTP Error Log"
  "Microsoft" "Windows Security Event Log"
  "AWS" "VPC Flowlogs"

While it is certain that there are scenarios where this may be challenging (e.g., when a 3rd party gathers raw data about Windows processes - that could conceivably be a vendor of "Microsoft" or the 3rd party), these fields should allow for the data that conforms to this schema to be identified.

Open questions:
Is it fair to expect ALL data to be represented in OCSF to have a vendor and a name?
Is there a desire to extend an enum for vendors/names? (HTTP Access Log vs. httpd_access)

Future considerations (acknowledged, but not in scope for this proposal):
Do we want to provide a place in the schema for data transmission to be logged? e.g., ETL timestamps, log forwarder(s), etc.

This poll should be considered simultaneously with the polls with the same title.

---

The original and primary "home" for these fields was the "product" object, with a minimal representation below::

{
  "product": {
    "feature": {
      "uid"
      "name"
      "version"
    }
    "lang"
    "uid"
    "name"
    "path"
    "version"  
  }
}

The "product" object is also used in the client object, the file object, and the server object. OCSF's description describes it simply as "a software product".

Objections have been raised that the term and definition of "product" is diverse enough from "services" which may deliver logs (AWS Cloudtrail, Akamai Access Logs) to cause some degree of confusion.

1. Use the "product" object (note: the product object would not go away if it is not used in this context)
2. "origin" (which has a history and potential connotation for good/bad with caching services)
3. "producer" (anecdotally, we've noticed the term "product" and "consumer" seem to be representations of where data comes from compared to those who utilize it)
4. NO OBJECT (base event reserved fields, e.g., _product_name, _vendor_name, _product_version):

Any additional names for consideration can be including as a comment to this poll.