Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding various OCSF 1.1 fields to log type static mappings #1403

Merged
merged 5 commits into from
Nov 25, 2024

Conversation

toepkerd
Copy link
Contributor

@toepkerd toepkerd commented Oct 30, 2024

Description

Adds various OCSF 1.1 field mappings to the static mappings repository in Security Analytics, allowing for more automatic field mappings during detector creation on indices ingesting OCSF 1.1 logs from Security Lake.

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff.
  • Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

// Verify unmapped index fields
List<String> unmappedIndexFields = (List<String>) respMap.get("unmapped_index_fields");
assertEquals(28, unmappedIndexFields.size());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to change the count of these tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests check for the number of mapped and unmapped fields. Since we've added new static mappings, fields that didn't have mappings before now do, so the counts in the tests are adjusted to reflect this.

@AWSHurneyt AWSHurneyt merged commit 189b9e5 into opensearch-project:main Nov 25, 2024
9 checks passed
@@ -114,12 +115,23 @@
{
"raw_field":"firewall_rule_action",
"ecs":"aws.route53.srcids.firewall_rule_action",
"ocsf": "disposition_id"
"ocsf": "disposition_id",
"ocsf11": "disposition"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this match with the ocsf mapping?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're referring to replacing the "ocsf" field to have value "disposition" instead of "disposition_id" (and not introducing the "ocsf11" field at all), this runs the risk of creating mapping conflicts with existing customer detectors who already used the old static mappings to create that detector's mappings alias indices. Adding instead of replacing fields (despite the fact that both disposition and disposition_id exist in both OCSF1.0 and OCSF1.1) works around this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants