Developer Roll Up: June 2022

The team at LimaCharlie continues on its mission to develop the concept of Security Infrastructure as a Service. We added three new team members during the month of June with more coming!

We also hosted a webinar on securing your CI/CD pipeline built around some new capabilities we added which allow for the ingestion and monitoring of GitHub audit logs. You can watch a recording of that webinar here: SecDevOps & LimaCharlie - Automating and auditing of GitHub access

Sensor 4.27.2

• Fix possible performance degradation issue on hosts with heavy process / network activity.

• Report User of processes in Windows instead of the Owner (small distinction in some cases).

• Report a specific error code on artifact_get where the file is empty (0 bytes).

Audit Changes

You will be progressively seeing some changes to Audit logs in LimaCharlie.

We're refactoring the Audit logs to merge together the Audit and Management logs that currently exist in the Platform Logs section.

This means that starting shortly, you will see some Management events (like a User being added to an Org) in the Audit Output stream.

Beyond the merge, the format of the Audit logs will also evolve to be more usable and well-parsed, The currently existing fields of the Audit stream will remain as-is. This means that if you're ingesting them in a data lake like ELK, we will not be modifying existing field schemas. Instead, we will be adding some new fields (which we call Audit v2).

For the near to medium future, we will leave the Audit v1 fields present in the Audit Output stream, simply adding the new fields so that you may adapt to the new format at your own pace.

Here is an example of what the Audit v1+v2 events will look like:

{

  "oid": "8aaaaaaa-bfa1-aaaa-ba19-138cd51389cd",

  "ts": "2022-06-16 22:20:27",

  "etype": "output_enabled",

  "msg": "Output enabled: tmp_live_0d758594-6885-43fc-aa7b-39bfee2d5691 / syslog / event",

  "origin": "maxime@limacharlie.io",

  "time": 1655418026997,

  "ident": "maxime@limacharlie.io",

  "entity": {

    "output_name": "tmp_live_0d758594-6885-43fc-aa7b-39bfee2d5691"

  },

  "mtd": {

    "module": "syslog",

    "stream": "event"

  }

}

Over time, when we deprecate the old v1 fields, the clean Audit v2 messages will look like:

{

  "oid": "8aaaaaaa-bfa1-aaaa-ba19-138cd51389cd",

  "etype": "output_enabled",

  "msg": "Output enabled: tmp_live_0d758594-6885-43fc-aa7b-39bfee2d5691 / syslog / event",

  "time": 1655418026997,

  "ident": "maxime@limacharlie.io",

  "entity": {

    "output_name": "tmp_live_0d758594-6885-43fc-aa7b-39bfee2d5691"

  },

  "mtd": {

    "module": "syslog",

    "stream": "event"

  }

}

As a summary of the v2 field definitions:

• oid: the Organization ID this audit message relates to.

• etype: the Event Type of the audit message.

• msg: a human readable version of the action the audit message relates to.

• time: a millisecond based epoch timestamp when the event ocured.

• ident: the identity of the thing performing the action. It could be maxime@limacharlie.io for a User, my-api-key-name for an API key, or my-api-key@maxime@limacharlie.io for a User API key.

• entity: this is the object the action is performed on.

• mtd: this is relevant metadata about the specific action being performed.

We hope that this new format, along with the Output system and its filtering capabilities will allow you to integrate Audit events into your infrastructure and operations.

Note that these changes apply to the Audit Outputs only initially, NOT the visualization of audit logs in the webapp or the audit log API. As we transition to v2-only these interfaces will be updated to reflect the new format.

If you have any questions, concerns, thoughts or requirements, please don't hesitate to get in touch!