-
Notifications
You must be signed in to change notification settings - Fork 387
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
[jamf_compliance_reporter] JAMF Compliance Reporter. #3210
[jamf_compliance_reporter] JAMF Compliance Reporter. #3210
Conversation
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
🌐 Coverage report
|
14814bf
to
9e6390c
Compare
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.
I've only looked at audit
data stream. Looking good have a few comments around mapping to ECS fields etc.
In general since this is for macos
. The main pipeline could also set host.os.type
to macos
.
packages/jamf_compliance_reporter/data_stream/audit/manifest.yml
Outdated
Show resolved
Hide resolved
packages/jamf_compliance_reporter/data_stream/audit/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
packages/jamf_compliance_reporter/data_stream/audit/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
packages/jamf_compliance_reporter/data_stream/audit/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
packages/jamf_compliance_reporter/data_stream/audit/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
packages/jamf_compliance_reporter/data_stream/audit/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
Hey @r00tu53r, We are looking into the field mapping changes which you suggested. We will get back to you with the updates. |
Missing some
Duplicate field definitions.
Please make sure the MAC addresses are valid. See my comment at #3232 (comment).
|
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.
Can you please update the dashboards to embed the visualizations into the dashboards.
ignore_missing: true | ||
- script: | ||
lang: painless | ||
if: ctx?.json?.app_metric_info?.cpu_percentage != null |
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.
if: ctx?.json?.app_metric_info?.cpu_percentage != null | |
if: ctx.json?.app_metric_info?.cpu_percentage != null |
ctx
is always going to be present. Can you apply this change everywhere.
…lastic/integrations into package_jamf_compliance_reporter
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.
Sorry for taking long to come back to this. Thank you for making the earlier suggested changes. Its looking good.
I see a few more cases where I have comments around ECS and duplication of data.
- In general avoid duplicate storage. If a value is stored in ECS then no need to store it in the field group.
- Convert access_mode to octal representation so users can search 755 or 666 etc. instead of 33261.
- All the syscall audit events seem to have
header, host_info, identity, return, subject
sections. Perhaps the pipeline can be arranged to take advantage of this ? - The subject group fields can be mapped to ECS as shown below.
subject
{
"audit_id"|"user_id" --> process.real_user.id
"audit_user_name"|"user_name" --> process.real_user.name
"effective_group_id": process.group.id
"effective_group_name": --> process.group.name
"effective_user_id": --> process.user.id
"effective_user_name": --> process.user.name
"group_id": -> process.real_group.id
"group_name": --> process.real_group.name
}
5.I saw instances of PID (Process ID) in some pipelines which can be mapped to process.pid
or equivalent.
The [Jamf Compliance Reporter](https://docs.jamf.com/compliance-reporter/documentation/Compliance_Reporter_Overview.html) Integration collects and parses data received from Jamf Compliance Reporter using TLS or HTTP Endpoint. | ||
|
||
## Requirements | ||
- Enable the Integration with the TLS or HTTP Endpoint input. |
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.
The integration involves making configuration changes on two sides Elastic and Jamf. That could be made clearer in the documentation. The doc could state what needs to be done and then point to the exact documentation on Jamf so the user can view the how part. You could refer to this doc for the headings etc. that have been used in other packages too.
|
||
## Setup Steps | ||
|
||
- After validating settings, you can use a configuration profile in Jamf Pro to deploy certificates to endpoints in production. |
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 might be a good idea to take the user through a series of steps and point them to the exact Jamf link / page for each step that needs to be performed in that order. Also I see the Remote Endpoint Logging Preference Keys page here shows a list of configurations. I presume that user must choose generic TLS Logging endpoint ? If so can that be explicitly specified in the steps.
ignore_missing: true | ||
- date: | ||
field: json.header.time_seconds_epoch | ||
target_field: '@timestamp' |
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.
nit: @timestamp
is the default target for the date
processor.
- convert: | ||
field: json.app_metric_info.cpu_percentage | ||
type: double | ||
target_field: jamf_compliance_reporter.app_metrics.app_metric_info.cpu_percentage | ||
ignore_failure: true | ||
- convert: | ||
field: json.app_metric_info.cpu_time_seconds | ||
type: double | ||
target_field: jamf_compliance_reporter.app_metrics.app_metric_info.cpu_time_seconds | ||
ignore_failure: true | ||
- convert: | ||
field: json.app_metric_info.interrupt_wakeups | ||
type: long | ||
target_field: jamf_compliance_reporter.app_metrics.app_metric_info.interrupt_wakeups | ||
ignore_failure: true | ||
- convert: | ||
field: json.app_metric_info.platform_idle_wakeups | ||
type: long | ||
target_field: jamf_compliance_reporter.app_metrics.app_metric_info.platform_idle_wakeups | ||
ignore_failure: true | ||
- convert: | ||
field: json.app_metric_info.resident_memory_size_mb | ||
type: double | ||
target_field: jamf_compliance_reporter.app_metrics.app_metric_info.resident_memory_size_mb | ||
ignore_failure: true | ||
- convert: | ||
field: json.app_metric_info.virtual_memory_size_mb | ||
type: double | ||
target_field: jamf_compliance_reporter.app_metrics.app_metric_info.virtual_memory_size_mb | ||
ignore_failure: true |
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.
I wonder if it is worth making app_metric_info
a flattened
field and storing the values as-is. Unless there is a plan to raise an alert for configured CPU thresholds.
field: json.header.event_name | ||
target_field: jamf_compliance_reporter.header.event_name | ||
ignore_missing: true | ||
- set: |
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.
Could be renamed instead of set as it gets duplicated.
ignore_failure: true | ||
- rename: | ||
field: json.host_info.host_uuid | ||
target_field: host.id |
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.
Saving serial_number in host.id
might be more useful as its more likely for users to query by serial number than UUID
- remove: | ||
field: json.arguments.known_UID_ | ||
ignore_missing: true |
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.
Is this required ? The json
object is being removed in the end during cleanup.
processors: | ||
- convert: | ||
field: json.arguments.pid | ||
target_field: jamf_compliance_reporter.audit.arguments.pid |
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.
Can go into process.pid
ignore_missing: true | ||
- convert: | ||
field: json.exec_chain_child.parent_pid | ||
target_field: jamf_compliance_reporter.audit.exec_chain_child.parent.pid |
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.
can go into process.parent.pid
@@ -0,0 +1,130 @@ | |||
--- |
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.
Many of the fields here jamf_compliance_reporter.audit.process.*
can go into process.*
, process.user.*
, process.group.*
etc.
Hey @r00tu53r, Sorry for the delayed response. We are working on the changes. |
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.
Thank you for making the changes. LGTM
packages/jamf_compliance_reporter/data_stream/log/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
packages/jamf_compliance_reporter/data_stream/log/elasticsearch/ingest_pipeline/default.yml
Show resolved
Hide resolved
...es/jamf_compliance_reporter/data_stream/log/elasticsearch/ingest_pipeline/pipeline_audit.yml
Outdated
Show resolved
Hide resolved
...f_compliance_reporter/data_stream/log/elasticsearch/ingest_pipeline/pipeline_app_metrics.yml
Outdated
Show resolved
Hide resolved
...iance_reporter/data_stream/log/elasticsearch/ingest_pipeline/pipeline_license_info_event.yml
Outdated
Show resolved
Hide resolved
...compliance_reporter/data_stream/log/_dev/test/pipeline/test-pipeline-audit.log-expected.json
Outdated
Show resolved
Hide resolved
...liance_reporter/data_stream/log/elasticsearch/ingest_pipeline/pipeline_unified_log_event.yml
Outdated
Show resolved
Hide resolved
processors: | ||
- set: | ||
field: ecs.version | ||
value: '8.2.0' |
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 should match 8.3.0 in the build manifest.
What does this PR do?
NOTE: This integration has been tested using a mock server and with sample events only.
Checklist
changelog.yml
file.manifest.yml
file to point to the latest Elastic stack release (e.g.^7.17.0 || ^8.0.0
).How to test this PR locally
Screenshots