8000 New Event Structure · Issue #2870 · aquasecurity/tracee · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
New Event Structure #2870
New issue
New issue
Open
Open
New Event Structure#2870
Assignees
josedonizetti
Labels
area/eventskind/feature
Milestone
 
v0.25.0
@itaysk

Description

@itaysk
itaysk
opened on Mar 14, 2023

#2355 changed the primary user experience of Tracee to be event oriented (previously events were considered internal and hidden from the user). Therefore:

  1. The event schema needs to be formalized and stabilized. Since it's no longer internal.
  2. The event structure needs to be generalized. Since events are will now be used for detections, captures and more.

Following is the updated event schema based on the comments below:

  1. timestamp
  2. name
  3. id - machine readable id (integer). Note: current event id isn't good since it is architecture specific
  4. // version - use semver where major is a breaking change in the event (e.g. one of the event's fields under data has been changed or removed), minor is a non breaking change (e.g. a new field was added to the event under data) and patch (e.g. a bug fix). Since this data is static, we may remove this or make optional
  5. // tags - since this data is static, we may remove this or make optional
  6. labels - doesn't exist. For future use.
  7. policies
    1. matched
    2. actions - doesn't exist, for future use - list of actions taken (currently the only action we have is print).
  8. workload
    1. process
      1. executable
        1. path
        2. name - the binary name (basename of the path) - doesn't exist, consider adding (in another issue)
      2. uniqueId - unique id of the process
      3. pid
      4. hostPid
      5. executionTime - time of last exec. Doesn't exist, consider adding (in another issue)
      6. realUser
        1. id
        2. name - doesn't exist, consider adding (in another issue)
      7. user - effective user. Doesn't exist, consider adding (in another issue)
        1. id
        2. name
      8. ancestors - process ancestors array. Only direct parent will be populated by default with the following fields:
        1. uniqueId
        2. pid
        3. hostPid
        4. Other ancestor fields may be populated by threat detection events
      9. thread
        1. startTime
        2. name (aka "comm")
        3. tid
        4. hostTid
        5. capabilities - doesn't exist, consider adding (in another issue)
        6. syscall - the syscall that triggered this event
        7. compat - boolean. moved from flags.compat
        8. userStackTrace - if enabled, will be here
    2. container
      1. id
      2. name
      3. image
        1. id
        2. repoDigest
        3. name
      4. isRunning - boolean. moved from flags
      5. startTime - Timestamp of container start time. Doesn’t exist. Will replace started
      6. pid - entrypoint's pid. Doesn’t exists, consider adding
    3. k8s
      1. pod
        1. name
        2. uid
        3. labels
      2. namespace
        1. name
  9. data
    1. Any relevant field (per-event schema)
    2. returnValue (if relevant will appear here)
  10. threat (if relevant will appear here) - static data about threats (can be omitted)
    1. description
    2. mitre
      1. tactic
        1. name
      2. technique
        1. name
        2. id
    3. severity
  11. triggeredBy (will appear on threat detection events)
    1. name
    2. id
    3. data

We also discussed versioning the event schema, but not including the version with each event, for efficiency.

Metadata

Metadata

Assignees

Labels

area/eventskind/feature

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions
    0