- Stage: 0 (strawperson)
- Date: 2020-07-27
Numerous SaaS Cloud Providers provide event data where the event reflects an action (Typically a CRUD action) on what can broadly be considered an "object." For some providers that Object may be a "file" wherein the existing ECS file fields are adequate; however other providers (Workday, Salesforce, Service Now, Zoom, etc.) an object can represent some other concept like a "record" or "setting" or "meeting." There presently isn't any location within ECS to document these as there is with "file," forcing any representation to be pushed into a custom field. This RFC proposes a new top-level field called object that will represent these instances.
This RFC calls for the introduction of a top-level object field with an initial fieldset of the following child fields:
| field | type | description |
|---|---|---|
object.name |
keyword | Name of the Object |
object.id |
keyword | ID of the Object |
object.type |
keyword | Type of Object Represented (e.g. record, meeting, repository, organization, etc.) |
object.additional_details |
object | Custom Key/Value pairs representing data relevant to the object |
object.owner.id |
keyword | ID of the Object Owner |
object.owner.name |
keyword | Name of the Object Owner |
object.owner.email |
keyword | Email of the Object Owner |
Object fields would allow for normalization of event/audit data provided by SaaS providers and facilitate the usage of ECS normalized event data to track, detect, and investigate activity across a broad spectrum of SaaS provider logs.
For example; an analyst could leverage the fields here to identify access into specific records on Salesforce; cases on Service Now; or meetings on Zoom without needing to know service specific field names and/or custom field names; They would simply be able to pivot their query on the respective object field and cloud.provider field.
- Cloud SaaS Providers
- Salesforce
- Zoom
- Box
- Microsoft/Office365
- Github
No breaking changes are anticipated as this is a net new introduction of fields.
An object is a very broad categorization, in some situations it may be hard to determine when something should be normalized into this field or another field like file or package. Additionally given the genericness of this field, a lot of finer details about the object may not be represented by this field, but rather addressed in custom key/value pairs nested under this field. Also due to the genericness of the field, the object.type field becomes rather critical to designate what exactly is represented within this field (e.g. is it a record or a meeting); some context might be derived from other fields in the event, but that would require some foreknowledge in order to properly search or sort. Designating specific acceptable values for object.type could minimize any confusion around the object being represented; however that would require specific updates to ECS to support new object "types".
The following are the people that consulted on the contents of this RFC.
- @drewgatchell | author
- Stage 0: #883