[jamf_compliance_reporter] JAMF Compliance Reporter.#3210
Conversation
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
🌐 Coverage report
|
14814bf to
9e6390c
Compare
|
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). |
andrewkroh
left a comment
There was a problem hiding this comment.
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.
| 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.
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, subjectsections. 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.
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.
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.
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.
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.
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.
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.
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 |
| 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.
can go into process.parent.pid
| @@ -0,0 +1,130 @@ | |||
| --- | |||
There was a problem hiding this comment.
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. |
r00tu53r
left a comment
There was a problem hiding this comment.
Thank you for making the changes. LGTM
| processors: | ||
| - set: | ||
| field: ecs.version | ||
| value: '8.2.0' |
There was a problem hiding this comment.
This should match 8.3.0 in the build manifest.
…r. (elastic#3210) Generated the skeleton of the JAMF Compliance Reporter integration package. Added a data stream. Added data collection logic to the data stream. Added the ingest pipeline for the 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 the data stream. Added system test cases for the data stream. NOTE: This integration has been tested using a mock server and with sample events only.
What does this PR do?
NOTE: This integration has been tested using a mock server and with sample events only.
Checklist
changelog.ymlfile.manifest.ymlfile to point to the latest Elastic stack release (e.g.^7.17.0 || ^8.0.0).How to test this PR locally
Screenshots