Gravityzone solution v3.0.0

[gbarbieru]

Change(s):
- Creating a Sentinel solution for Bitdefender GravityZone. This solution uses a push-based approach using just a DCR, a DCE, custom table and an App registration with credentials to push data to Sentinel. An analytic rule that uses custom ASIM parsers is used to generate Incidents.

Reason for Change(s):

• New Sentinel solution

Version Updated:

• No. Version is 3.0.0 is the initial version.

Testing Completed:

• Yes

Checked that the validations are passing and have addressed any issues that are present:
Before going into this topic I want to disclose that development in my team is done on Linux workstations and the available tooling and guides offered by Microsoft kinda lack in this department. Local YAML testing was eventually achieved, but KQL validation failed. Due to time constraints additional effort in making them work Linux environments was abandoned and testing was eventually done on Microsoft Sentinel accounts via end-to-end testing.

• KQL: Tested using smoke tests directly on a Microsoft Sentinel account. No issues so far. Failed to test locally.
• YAML: Some issues are reported on the JSON that was compiled from bicep (data connector deployment template), but no issues were present when actually deploying and using the data connector.

**Notes**
- If/when the PR is approved for merge please hold off for an approval from us. We want the solution to actually go to market with something on our part (GravityZone).

[github-actions]

🔒 Security Approval Required

This fork PR requires manual approval before automated testing can run.

For security, a maintainer must:

1. 📝 Review the code changes carefully
2. ✅ Verify file types - This PR should only contain .yml, .yaml, or .json files. Check for any executable scripts (.ps1, .py, .sh, .exe, etc.) which are not allowed in this context.
3. 🏷️ Add the SafeToRun label if the changes are safe to execute

Note: If new commits are added later, simply remove and re-add the SafeToRun label.

---

🤖 Automated security check • Created: 2025-12-11T13:23:47.021Z
Learn more: GitHub Security Lab - Preventing PWN Requests

[github-actions]

🔒 Security Approval Required

This fork PR requires manual approval before automated testing can run.

For security, a maintainer must:

1. 📝 Review the code changes carefully
2. ✅ Verify file types - This PR should only contain .yml, .yaml, or .json files. Check for any executable scripts (.ps1, .py, .sh, .exe, etc.) which are not allowed in this context.
3. 🏷️ Add the SafeToRun label if the changes are safe to execute

Note: If new commits are added later, simply remove and re-add the SafeToRun label.

---

🤖 Automated security check • Created: 2025-12-11T13:31:55.590Z
Learn more: GitHub Security Lab - Preventing PWN Requests

[github-actions]

🔒 Security Approval Required

This fork PR requires manual approval before automated testing can run.

For security, a maintainer must:

1. 📝 Review the code changes carefully
2. ✅ Verify file types - This PR should only contain .yml, .yaml, or .json files. Check for any executable scripts (.ps1, .py, .sh, .exe, etc.) which are not allowed in this context.
3. 🏷️ Add the SafeToRun label if the changes are safe to execute

Note: If new commits are added later, simply remove and re-add the SafeToRun label.

---

🤖 Automated security check • Created: 2025-12-11T13:34:23.033Z
Learn more: GitHub Security Lab - Preventing PWN Requests

[ashantyk]

just did a rebase and it seems github just went crazy with this PR. i'll have to delete the branch and PR and start over.

on the topic of keeping the ASIM modification separate. how important is it for the first release?
we are using a private repo for the actual code and the CI/CD pipeline just creates a branch on the forked repo on an action.
in order to alter it to make detections/decisions and create separate PRs would take time and i'm not sure the time is justified if we just keep an eye out for next PRs just to be punctual

[gbarbieru]

new PR: #13299