-
Notifications
You must be signed in to change notification settings - Fork 469
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
[prisma_access] Initial release of the Prisma Access #10399
Conversation
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
/test |
🚀 Benchmarks reportTo see the full report comment with |
@@ -0,0 +1,70 @@ | |||
format_version: 3.1.4 | |||
name: prisma_access |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamiehynds, can you confirm the name of the integration?
It seems to me that it should be panw_prisma_access
just like panw_cortex_xdr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch @kcreddy. Probably best to keep the name inline with other Palo integrations and include panw
. Does this impact custom field names too or just the name in the manifest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does impact the field names too.
cc: @muskan-agarwal26
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do we use for prisma cloud? is it panw_prisma_cloud or prisma_cloud?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do we use for prisma cloud? is it panw_prisma_cloud or prisma_cloud?
We seem to use prisma_cloud
as both package name and also in field names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, goes against the grain a bit, but lets keep prisma_access
here to align with prisma_cloud
which has been around for awhile.
packages/prisma_access/data_stream/event/_dev/test/pipeline/test-event.json-expected.json
Outdated
Show resolved
Hide resolved
packages/prisma_access/data_stream/event/_dev/test/pipeline/test-event.json-expected.json
Outdated
Show resolved
Hide resolved
packages/prisma_access/data_stream/event/_dev/test/pipeline/test-event.json-expected.json
Outdated
Show resolved
Hide resolved
packages/prisma_access/data_stream/event/_dev/test/pipeline/test-event.json-expected.json
Outdated
Show resolved
Hide resolved
packages/prisma_access/data_stream/event/_dev/test/pipeline/test-event.json
Show resolved
Hide resolved
1. Implemented the Readme changes. 2. Added network category in the manifest. 3. Added comments for the scripts used. 4. Changed the context of the test-logs. 5. Split user.domain.user.name for the user fields.
@@ -0,0 +1,187 @@ | |||
{ | |||
"@timestamp": "2019-07-25T23:30:12.000Z", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This timestamp should be derived with event.timezone
offset
"cortex_data_lake_tenant_id": "xxxxxxxxxxxxx", | ||
"destination": { | ||
"address": { | ||
"v6": "FE80:CD00:0000:0CDE:1257:0000:211E:729C" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets make this lowercase as per RFC5952
1. Derived timestamo from event.timezone. 2. Lowercase the ipv6.
/test |
@@ -2836,6 +2831,54 @@ processors: | |||
tag: set_event_timezone_from_event_log_source_timezone_offset | |||
copy_from: prisma_access.event.log.source.timezone_offset | |||
ignore_empty_value: true | |||
- date: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of null, non-null conditions and defining date processors for each case, can you follow this approach to set event.timezone
to UTC
default before the single date
processor?
/test |
💚 Build Succeeded
History
|
Quality Gate passedIssues Measures |
Package prisma_access - 0.1.0 containing this change is available at https://epr.elastic.co/search?package=prisma_access |
Initial release of the Prisma Access. - Added an event data stream. - Added data collection logic for event data stream. - Added the ingest pipeline for event data stream. - Mapped fields according to the ECS schema and added Fields metadata in the appropriate yml files. - Added dashboards and visualizations. - Added test for pipeline for event data stream. - Added system test cases for event data stream.
Initial release of the Prisma Access. - Added an event data stream. - Added data collection logic for event data stream. - Added the ingest pipeline for event data stream. - Mapped fields according to the ECS schema and added Fields metadata in the appropriate yml files. - Added dashboards and visualizations. - Added test for pipeline for event data stream. - Added system test cases for event data stream.
Proposed commit message
Checklist
changelog.yml
file.How to test this PR locally
Screenshots