Giter Site home page Giter Site logo

ocsf-schema's People

Contributors

ablyler avatar adplotzk avatar alanisaac avatar alvinnieto avatar aniak5 avatar ashishvermarox avatar awhite456 avatar brandikuritz avatar floydtree avatar irakledibm avatar jasonbreimer avatar jfagoagas avatar jonrau-at-queryai avatar jp-harvey avatar liamsennitt avatar magnologan avatar maxhotta avatar mikeradka avatar mtharp0 avatar odianosen avatar pagbabian-splunk avatar paveljos avatar pladam avatar rmouritzen-splunk avatar rroupski avatar rroupski-splunk avatar shellcromancer avatar suraj07011 avatar zschmerber avatar zschmerber-atlassian avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ocsf-schema's Issues

Merge Reputation and Domain Security profiles

The goal is simplify (reduce) the number of profiles define is OCSF v1.0 release. The Reputation and Domain Security profiles looks somewhat similar and we might be able to merge them.

Cloud Activity ID Update

Propose to alter cloud activity_id to:

{
  "enum": {
    "1": {
      "caption": "Login",
      "description": "The event pertains to login activity."
    },
    "2": {
      "caption": "Management",
      "description": "The event pertains to management activity (e.g. policy updates, user creations, subnet creations, etc.)."
    },
    "3": {
      "caption": "Operational",
      "description": "The event pertains to cloud resource operations activity (e.g. data downloads, launched virtual machines, etc.)."
    }
  }
}

Determine the reserved attributes

Discussed in #84

Originally posted by rroupski July 19, 2022
Attributes that are either generated or derived by the collection, post-collection processing, or storage systems other than the mapping process are designated Reserved. The current list of the reserved attributes is:

  • _log_time (from metadata), rename as _logged_time
  • _type_uid
  • _type_name
  • _time
  • _observables
  • _raw_data
  • _unmapped

This discussion is about whether the last 3 attributes should be reserved or not.

  • _observables

  • _raw_data

  • _unmapped

  • The observables should generated based the input data and the schema. In other words, the observables data should not be manually added by the source that generated the event.

  • The raw_data is attribute that contains the original data as generated by the source. If the event source creates events in the OCSF Schema, then the raw_data should not be used.

  • The unmapped is attribute that contains the attributes, which are not defined by the OCSF Schema. If the event source creates events in the OCSF Schema, then the unmapped attribute could be used to add additional attribute, which are not defined by the schema.

Define details about container hash

In the container schema, the following item is defined:

  "sha2": {
      "description": "Commit hash of image created for docker or the SHA256 hash of the container. For example: a3bf90e006b2.",
      "group": "context",
      "requirement": "optional"
    },

The field "sha2" is ambiguous in a few respects:

  • the hash should be of the container image, not the container itself.
  • sha2 itself is a set of six cryptographic hash functions: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Some of these hashed have the same output size, so you can't always meaningfully tell them apart.
  • The encoding should be explicitly defined. Hex is probably the most common, but there are other candidates that yield shorter strings.

Finally, it may make sense to define this as a set of hashes. If sha256 is broken, it'll be easier to adapt to a set of hashes rather than a specifically hard coded value. One good example we can follow is from the In-Toto project where hashes are presented in a dictionary object with each hash explicitly listed, rather than attached to the root object. See https://github.com/in-toto/docs/blob/v0.9/in-toto-spec.md#421-hash-object-format for more information.

Hope this all helps! I'm happy to open these changes as a pull request if that would be useful.

Cloud Activity Activity ID

Propose to update the activity_id for cloud activity category. Specifically to:
{ "enum": { "1": { "caption": "Success", "description": "The API call was successful." }, "2": { "caption": "Failed", "description": "The API call failed." } } }

We could get a bit more specific, but maybe we can leave that up to some event classes that extend the cloud activity class. Below are some examples of event outcomes for various cloud logs (small samples so might not be comprehensive):

Azure Audit:
image

Azure Sign in:
image

Azure Activity:
image

CloudTrail Error Codes (small sample but these can essentially be mapped to success and fail):
image

GCP Audit have a variety too but could be easily mapped the success and fail.

What is the value of Account Type?

In order to promote interoperability, OCSF must define a "schema", not just a "schema framework". The data that goes into logging information must be defined across vendors, not just "captioned".

Consider dictionary.json:

    "account_type": {
      "caption": "Account Type ID",
      "description": "The user account type (e.g. AWS, LDAP, Windows account, etc.).",
      "type": "string_t"
    },
    "account_type_id": {
      "caption": "Account Type ID",
      "description": "The user account type identifier (e.g. AWS, LDAP, Windows account, etc.).",
      "enum": {
        "-1": {
          "caption": "Other",
          "description": "The user account type is not mapped."
        },
        "0": {
          "caption": "Unknown",
          "description": "The user account type is unknown."
        },
        "1": {
          "caption": "LDAP Account"
        },
        "2": {
          "caption": "Windows Account"
        },
        "3": {
          "caption": "AWS IAM Account"
        },
        "4": {
          "caption": "GCP Account"
        },
        "5": {
          "caption": "Azure AD Account"
        }
      },
      "type": "integer_t"
    },

This is a framework for an enumeration, but OCSF defines no value for the "account_type" "string_t". An information model (abstract schema) does define enumerations:

ID Name Description
-1 ? Other: The user account type is not mapped.
0 ? Unknown: The user account type is unknown.
1 ? LDAP Account:
2 ? Windows Account:
3 ? AWS IAM Account:
4 ? GCP Account:
5 ? Azure AD Account:

The name column (the string_t account_type) is undefined. Which means that when looking at, for example, Splunk logs, OCSF provides no guidance:

<TS> phonenumber=333-444-4444, app=angrybirds, installdate=xx/xx/xx, acct=Windows Account
<TS> phonenumber=333-444-4444, app=facebook, installdate=yy/yy/yy, acct=Azure AD Account

Using captions might work for comma-separated data fields (assuming captions prohibit commas), but it definitely will not work for space-separated data:

<TS>
USER ACCT PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
Root Windows Account 41 21.9 1.7 3233968 143624 ?? Rs 7Jul11 48:09.67 /System/Library/foo
Rdas Azure AD Account 790 4.5 0.4 4924432 32324 ?? S 8Jul11 9:00.57 /System/Library/baz

Enumeration names enable interchangeable logging data:

ID Name Description
-1 other Other: The user account type is not mapped.
0 unknown Unknown: The user account type is unknown.
1 ldap LDAP Account:
2 windows Windows Account:
3 aws_iam AWS IAM Account:
4 gcp GCP Account:
5 azure_ad Azure AD Account:

enables

<TS>
USER ACCT PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
Root windows 41 21.9 1.7 3233968 143624 ?? Rs 7Jul11 48:09.67 /System/Library/foo
Rdas azure_ad 790 4.5 0.4 4924432 32324 ?? S 8Jul11 9:00.57 /System/Library/baz

Defining enumerated strings is the rationale for formatting "enum" entries with both a property name and an integer id, as proposed in Issue #214:

    "account_type_id": {
      "caption": "Account Type ID",
      "name": "AccountType",
      "description": "The user account type identifier (e.g. AWS, LDAP, Windows account, etc.).",
      "enum": {
        "other": {
          "caption": "Other",
          "description": "The user account type is not mapped."
          "id": -1
        },
      ...

An example schema containing just Enumerated data types defined in the OCSF enums folder is available here. The OCSF files could easily be updated to define both datatype names and property names.

All first release objects merged into main

First release Objects, checkbox checked when merged into main.

  • API Details
  • Attack
  • Authorization Information
  • CVSS Scores
  • Client
  • Cloud
  • Compliance Details
  • Container
  • DNS Answer
  • DNS Query
  • Device
  • Device Hardware Info
  • Digital Certificate
  • Digital Signature
  • Display
  • Distributed Computing Environment/Remote Procedure Call (DCE/RPC)
  • Endpoint
  • Enrichment
  • Event Origin
  • Event Source
  • Extended User
  • Feature
  • File
  • Finding Details
  • Fingerprint
  • Geo Location
  • Group
  • HTTP Cookie
  • HTTP Header
  • HTTP Request
  • HTTP Response
  • Identity
  • Identity Provider
  • Image
  • Job
  • Kernel Resource
  • Keyboard Information
  • Malware
  • Managed Entity
  • Metadata
  • Module
  • Network Connection Information
  • Network Endpoint
  • Network Interface
  • Network Proxy
  • Network Traffic
  • OS
  • Object
  • Observable
  • Peripheral Device
  • Process
  • Product
  • Registry Key
  • Registry Value
  • Related Findings
  • Remediation Details
  • Request Elements
  • Resource
  • Response Elements
  • Rule
  • Server
  • Service
  • Session
  • Subject Alternative Name
  • TLS Extension
  • Transport Layer Security (TLS)
  • Uniform Resource Locator
  • User
  • Vulnerability Details

Reference to Missing https://github.com/ocsf/ocsf-server

I want to review OCSF as a consumer of OCSF schema.
After reviewing all the available documentation, only related reference I could find was in Contributing.MD

However, the linked repo is not accessible.

Kindly share the link to updated repository.

Thanks,

## Using OCSF as a consumer 

See [ocsf-server](https://github.com/ocsf/ocsf-server) documentation.

Use a Server Mode to add datetime_t Attributes Across Event Classes

For the new datetime_t data type, Proposal 11 had a profile that would overlay a companion attribute everywhere there is a timestamp_t data type. Rather than use an actual profile, the schema server can have a switch or mode where this can be done globally (i.e. wherever there is a timestamp_t attribute in any event class). How that is detected via the API or schema is yet to be determined but I like the idea. Otherwise it is the same as Proposal 11. The original timestamp_t field must still be populated.

All Required Attributes within Classes Must Have a Default

The intention of Required attributes within event classes is that the attribute is always present in every instance of the event. To be useful, reasonable default values must be spelled out so that the event can be validated, and that the semantics of the event can be reasonably (if not completely) represented.

For Enum attributes, the default is Unknown. For process PID integer attributes, the default may be 1, the primordial OS process (e.g. init).

However many other required attributes have not been documented as to what their default value should be.

Is Categories an enum or an object?

categories.json appears to be an enumerated list of items, but the items are called "attributes" as if they were properties of an object.:

{
  "caption": "Categories",
  "name": "category",
  "description": "Initial working list of categories (work in progress).",
  "attributes": {
    "system": {
      "caption": "System Activity",
      "description": "System Activity events.",
      "uid": 1
    },
    "findings": {
      "caption": "Findings",
      "description": "Findings events report findings, detections, and possible resolutions of malware, anomalies, or other actions performed by security products.",
      "uid": 2
    },
   ...

represents a list of enumerated items:

UID Name Description
1 system System Activity: System Activity events
2 findings Findings: Findings events report findings, detections, and possible resolutions of malware, anomalies, or other actions performed by security products.
... ... ...

But an example enum file is JSON data in a different format that represents the identical kind of enumerated list:

{
  "enum": {
    "1": {
      "caption": "Login",
      "description": "The event pertains to login activity."
    },
    "2": {
      "caption": "IAM",
      "description": "The event pertains to Identity and Access Management (IAM) activity (e.g. policy updates, user creations, etc.)."
    },
    "3": {
      "caption": "Operational",
      "description": "The event pertains to cloud resource operations activity (e.g. data downloads, launched virtual machines, etc.)."
    }
  }
}
UID Name Description
1 Login The event pertains to login activity.
2 IAM The event pertains to Identity and Access Management (IAM) activity (e.g. policy updates, user creations, etc.).
3 Operational The event pertains to cloud resource operations activity (e.g. data downloads, launched virtual machines, etc.).

Proposal

Use the same data structure for enumerated lists in categories.json, all files in the enums directory, and other files where enums are embedded.

Using different data to represent the same kind of information is unnecessary. Putting numeric UIDs into strings is confusing because strings are often displayed in lexical order instead of numeric order (as can be seen in URL Categories). And using caption as a name may be unsuitable when the item should have an identifier but the caption (e.g. "System Activity") is not an identifier.

  1. Rename the "attributes" property in categories.json to "enum"
  2. Restructure all enums to have the same structure as categories.json, with a numeric "uid" property instead of putting the number in a string, and with an explicit property name (e.g. "login", "iam", "operational") instead of using the caption as the item name.

Network Profiles

Determine what profiles/traits we would like to add to the network event classes. Once that decision is made we need to decide whether the dns/http classes should extend the network class or the base event class.

System Activity > Process Activity: Clean up injection_type_id, add module.start_address attribute

From our Systems Activity Workstreams sync on 9/7, we discussed the following path forward to address some of the gaps for Process Injection events within the System Activity category & Process Injection class:

  1. injection_type_id: Change the enums as follows:
    • -1 Other
    • 0 Unknown
    • 1 Remote Thread
    • 2 Load Library
  2. module object: Add a start_address field:
    • module.start_address: The start address of the execution.
    • Supporting Example: Sysmon Event ID 8
  3. module.file: Change from Required to Recommended
    • Supporting Example: In the case of module.load_type_id = ShellCode and other cases, there is no file path.

CVSS Score Object Update

Current CVSS Score Object is inconsistent with CVSS specs and requires an adjustment. There are three major versions of the CVSS (v1, v2 and v3) and each have different set of the associated attributes that contribute to CVSS score calculation.

https://www.first.org/cvss/v1/guide
https://www.first.org/cvss/v2/guide
https://www.first.org/cvss/specification-document

ocsf cvss score object proposed cvss score object cvss v1 cvss v2 cvss v3 group
score n/a
depth n/a
severity n/a
base_score n/a
base_vector n/a
risk n/a
version version n/a
access_complexity_id access_complexity_id access_complexity access_complexity base
attack_vector_id attack_vector_id attack_vector base
authentication_id authentication_id authentication authentication base
availability_impact_id availability_impact_id availability_impact availability_impact availability_impact base
confidentiality_impact_id confidentiality_impact_id confidentiality_impact confidentiality_impact confidentiality_impact base
integrity_impact_id integrity_impact_id integrity_impact integrity_impact integrity_impact base
privileges_required_id privileges_required_id privileges_required base
user_interaction_id user_interaction_id user_interaction base
attack_complexity_id attack_complexity_id attack_complexity base
scope_id scope base
impact_bias_id impact_bias base
attack_complexity_id attack_complexity base
exploitability_id exploitability exploitability temporal
exploit_code_maturity_id exploit_code_maturity temporal
remediation_level_id remediation_level remediation_level remediation_level temporal
report_confidence_id report_confidence report_confidence report_confidence temporal
collateral_damage_potential_id collateral_damage_potential collateral_damage_potential environmental
target_distribution_id target_distribution target_distribution environmental
confidentiality_requirement_id confidentiality_requirement confidentiality_requirement environmental
integrity_requirement_id integrity_requirement integrity_requirement environmental
availability_requirement_id availability_requirement availability_requirement environmental
modified_base_metrics_id modified_base_metrics environmental

Proposed Options:

Option 1: keep one CVSS Score Object with all attributes from v1, v2 and v3. All attributes are optional and would be pulled based on version and depth attributes values.

Option 2: Create objects CVSS_V1. CVSS_V2 and CVSS_V3, include those objects in CVSS Score Object as an optional. Based on version attribute value appropriate object is expected.

Option 3: Since most data will include only Score value and potentially depth and version information, keep only Score, Depth, Sevirity and Version in CVSS Score Object.

Option 4: Keep CVSS Score Object as is today.

ASW lb_actions attribute name

The lb_actions attribute is a plural noun, so does it hold a single action or multiple actions value?

   "lb_actions": {
      "description": "The actions performed by the load balancer",
      "name": "Load Balancer Actions"
    }

DNS Activity class has the same caption (Failed) for different activity_id values

The DNS Activity class has the same caption (Failed) for 2 different activity_id values:

400302 DNS Activity: Failed The DNS request has failed.
400304 DNS Activity: Failed The network connection failed. For example a connection timeout or no route to host.

The enum captions must be unique, so that users can distinguish values without looking the enum integer value.

New Data Type: ByteString

It is common to transport some data, such as payloads etc in form of byte array, without converting it. To cover those use cases we need to add new data type "bytestring_t" to represent immutable sequence of bytes. We can add it as subset of String with base64 encoding or as base type.

Rename dns_id attribute

The _id postfix is received for enum attributes, thus the dns_id should be renamed as dns_uid, dns_query_uid, dns_packet_uid, query_identifier. Or perhaps use the general purpose uid attribute.

Create Domain Object

Create a domain object which contains information about the domain registrar, creation date, etc. Replace uses of domain string_t type dictionary attribute with hostname. Also, create a domain profile to be used by network class and potentially other classes.

Time attributes name consistency

There are many time attribute, see the picture. The names are not very consistent. Some use nouns, others use past tense verbs. We should pick one form only.

image

Rename event_uid/name as type_uid/name

The problem with event_uid is -- it gives a notion that the identifier is uniquely identifying an event (a unique occurrence of an activity as recorded by a log, think Cloudtrail event), thats going by what an Incident responder would think, at least based on my own experience.

However, the way we currently have event_uid it is simply saying this is a unique type of an event within OCSF which is akin to an event code/type.

All first release event classes complete and merged into main

First release Event Classes, checkbox checked if class complete and merged into main

  • Account Change Audit
  • Application Lifecycle
  • Authentication Audit
  • Authorization Audit
  • Base Inventory
  • Cloud API
  • Container Lifecycle
  • DHCP Activity
  • DNS Activity
  • Database Lifecycle
  • Device Status
  • Entity Audit
  • File Access Activity
  • File Activity
  • Folder Activity
  • HTTP Activity
  • Kernel Activity
  • Memory Activity
  • Module Activity
  • Network Activity
  • Peripheral Activity
  • Process Activity
  • RDP Activity
  • Registry Key Activity
  • Registry Value Activity
  • Resource Activity
  • SMB Activity
  • Scheduled Job Activity
  • Security Finding

Remove object_type

To simplify the object definitions remove the object_type and use the type only. For example:

Current definition:

{
  "caption":"Metadata",
  "description":"The metadata associated with the event.",
  "group":"context",
  "object_type":"metadata",
  "requirement":"required",
  "type":"object_t"
}

New definition:

{
  "caption":"Metadata",
  "description":"The metadata associated with the event.",
  "group":"context",
  "requirement":"required",
  "type":"metadata"
}

System Activity | Authentication Audit [3001] | Add failure_code & failure_code_desc Fields

I am in the process of translating Windows Security Event 4771 (Kerberos pre-authentication failed) .

Since this is a failure event, the status_id is always 2: Failure .

  • However, this windows event also provides a Failure Code field.
  • Initially, I planned to map Failure Code to status_detail
  • Failure Code is a hexadecimal value that represents a string, such as 0x18 == Pre-authentication information was invalid

After discussion with the endpoint-activity team, we found it useful to add two fields for Failure Code:

  1. failure_code
  2. failure_code_desc

Consider defining a JSON schema

As far as I checked, none of the JSON files currently refers to a JSON schema. I would like to suggest to define JSON schemas to make sure that changes in these files are valid according to the rules.

I'm happy to submit a PR but I might need some help to fully understand some design decisions.

'session_uid' is redundant in System Activiy -> Authentication/Authorization Audit Classes

The session_uid attribute in System Activity -> Authentication/Authorization Audit is redundant, as it is already covered within two other places: src_user.session_uid and dst_user.session_uid. Resolve this redunancy by removing the top-level session_uid object from the two classes.

  1. Remove the top-level session_uid from the Authentication Audit and Authorization Audit classes.
  2. Give examples of the session_uid attribute in the dictionary.
  3. Add an optional session_uuid object to map session guids, such as Windows Logon GUID

Review cloud activity event classes

Determine whether we need the storage event class or any additional classes within the cloud category or whether the cloud api class suffices.

Audit Category: Remove Redundant 'Audit' label from Class Names

Currently, the classes under the 'Audit' category all end with 'Audit'. This is an unnecessary redundancy.

image

Also, the includes/authentication.json and enums/authentication.json includes are only used by the Authentication class. They should be removed as include files and consolidated into the main Authentication class.

image

v1.0 producer / log source compatibility

OCSF is a framework where the base event classes should produce the same outcome for an event regardless of the vendor generating that event. To that end, "supporting" log sources means ensuring that multiple producers confirm that the schema is robust and flexible enough to accommodate the data they produce / report on.

For example, if product A and product B both send process_activity logs, the end result after conversion to OCSF should look structurally the same, with the exception of optional attributes and any producer / vendor specific fields and objects which would be supported via an extension.

This issue aims to track the requirement for v1.0 that a minimum of 2 vendors or producers have confirmed that their data / logs can be converted into OCSF format, and as a secondary objective to confirm that two producers converting the same event data to OCSF format yield the same result.

OCSF Class Producer / Log Maintainers / Verifiers Notes / Status
FileSystem Activity [1000] DTEX, Splunk
Kernel Activity [1003] DTEX, Splunk
Memory Activity [1004] DTEX, Splunk
Module Activity [1005] DTEX, Splunk
Process Activity [1007] DTEX, Splunk
Registry Key Activity [1008] DTEX, Splunk
Registry Value Activity [1009] DTEX, Splunk
Resource Activity [1010] DTEX, Splunk
Scheduled Job Activity [1011] DTEX, Splunk
Security Finding [2001] AWS, IBM
Account Change [3001]
  • Sumo Logic
Sumo Logic
Authentication [3002]
  • Sumo Logic
Sumo Logic
Authorization [3003]
  • Sumo Logic
Sumo Logic
Entity Management Audit [3004]
  • Sumo Logic
Sumo Logic
Network Activity [4001] Splunk
HTTP Activity [4002]
DNS Activity [4003]
    Splunk
    DHCP Activity [4004]
      Splunk
      RDP Activity [4005]
        Splunk
        SMB Activity [4006]
          Splunk
          SSH Activity [4007]
            Splunk
            FTP Activity [4008]
              Splunk
              Cloud API [5001]
              • AWS
              AWS
              Cloud Storage Activity [5002]
              • AWS
              AWS
              Cloud Virtual Machine [5003]
              • AWS
              AWS
              Container Lifecycle Activity [6001]
              • Trend Micro
              • AWS
              Trend Micro
              Database Lifecycle (example) [7000]
                IBM
                Application Lifecycle (example) [8000]
                Device Inventory Info [9001] Tanium
                Device Config State [9002]
                • Tanium
                Tanium

                Update the reserved attributes

                This is the new list of reserved attributes that must not be used by the event producers:

                • _time: timestamp_t, required
                  The normalized event occurrence time. Normalized time means the original event time ref_time was corrected for the clock skew and it was converted to the OCSF timestamp_t.

                • metadata._uid: string, required
                  The unique identifier of an event instance. The attribute is used in the metadata object.

                • _raw_data: string, optional
                  The event data as received from the event source. This attribute must be used when events are translated from some other that OCSF format. If the event is created using the OCSF schema, then the _raw_data must not be used.

                Define a new Configuration State event class

                {
                "category": "configuration",
                "description": "Basic attributes that capture configuration state.",
                "extends": "base_event",
                "caption": "Base Configuration",
                "name": "base_configuration",
                "uid": 4,
                "attributes": {
                "mac": {
                "description": "The device Media Access Control (MAC) address.",
                "group": "primary",
                "requirement": "recommended"
                },
                "ip": {
                "description": "The device IP address, in either IPv4 or IPv6 format.",
                "group": "context",
                "requirement": "optional"
                },
                "hostname": {
                "description": "The device hostname.",
                "group": "context",
                "requirement": "optional"
                },
                "name": {
                "description": "The alternate device name, ordinarily as assigned by an administrator. ",
                "group": "context",
                "requirement": "optional"
                },
                "cis": {
                "requirement": "optional"
                },
                "os": {
                "requirement": "optional"
                }
                }
                }

                Missing customer_uid attribute

                The customer_uid attribute is missing from the base event. We need it to handle multi-tenant systems such as Splunk on cloud that handles events from multiple customers.

                Event Origin object

                1. Define structure of the origin object
                2. Clean up & refine originally present attributes under the origin object
                3. Move origin under metadata
                4. Revert related changes made in this 1e5b116

                More context - slack convo
                Original object for reference -

                {
                  "caption": "Event Origin",
                  "name": "event_origin",
                  "description": "The event origin is where the event was created.",
                  "extends": "object",
                  "attributes": {
                    "cloud": {},
                    "container": {},
                    "customer_uid": {},
                    "device": {
                      "requirement": "recommended"
                    },
                    "feature": {},
                    "product": {
                      "requirement": "recommended"
                    }
                  },
                  "constraints": {
                    "at_least_one": [
                      "device",
                      "product"
                    ]
                  }
                }
                

                Recommend Projects

                • React photo React

                  A declarative, efficient, and flexible JavaScript library for building user interfaces.

                • Vue.js photo Vue.js

                  ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

                • Typescript photo Typescript

                  TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

                • TensorFlow photo TensorFlow

                  An Open Source Machine Learning Framework for Everyone

                • Django photo Django

                  The Web framework for perfectionists with deadlines.

                • D3 photo D3

                  Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

                Recommend Topics

                • javascript

                  JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

                • web

                  Some thing interesting about web. New door for the world.

                • server

                  A server is a program made to process requests and deliver data to clients.

                • Machine learning

                  Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

                • Game

                  Some thing interesting about game, make everyone happy.

                Recommend Org

                • Facebook photo Facebook

                  We are working to build community through open source technology. NB: members must have two-factor auth.

                • Microsoft photo Microsoft

                  Open source projects and samples from Microsoft.

                • Google photo Google

                  Google โค๏ธ Open Source for everyone.

                • D3 photo D3

                  Data-Driven Documents codes.