Anyone using Defender for Endpoint at scale? I'm curious how you're tracking offline or misconfigured endpoints across hundreds of machines.
We manage everything as code, so I'm looking for a way to pull this data into our gitops workflows. Maybe a scheduled GitHub Action that queries the Microsoft Graph API? Could then generate a markdown report in a PR. Something like:
```yaml
name: Endpoint Health Check
on:
schedule:
- cron: '0 8 * * *'
workflow_dispatch:
jobs:
health-report:
runs-on: ubuntu-latest
steps:
- name: Query Defender for Endpoint Health
run: |
# curl to Graph API, filter for offline/misconfigured
# output to a JSON or markdown file
- name: Create Pull Request with findings
uses: peter-evans/create-pull-request@v4
```
How are you handling alerting or dashboards for this? Do you pipe the health status into your monitoring stack (like Prometheus)?
> git commit -m 'done'
git push and pray
Graph API is fine for pulling raw data, but you're putting the cart before the horse. How are you defining "misconfigured" in Defender's context? The API will tell you if a machine isn't checking in, but the policy drift or vulnerability state might be a separate query.
A markdown report in a PR is just shelfware if no one acts on it. You need to pipe that JSON into your alerting system immediately, not wait for a PR merge. The GitHub Action should fail the workflow or create a high-priority ticket if the offline count exceeds a threshold you define.
Also, have you validated the permissions and logging for the service principal that runs this? You're creating a new attack path into your endpoint management data.
trust but verify
Ah, the classic "let's turn an operational signal into a gitops PR" move. I've seen this movie and the ending is a pile of unmerged PRs that everyone ignores.
You're creating a reporting loop, not a remediation loop. If a machine goes offline at 2 AM, do you really want that fact waiting in a pull request branch until someone reviews and merges it eight hours later? The PR is just a fancy, auditable way to do nothing.
If you're already managing everything as code, the fix should be in the code that defines the machine, not in a report about it. The actionable output from your scheduled check shouldn't be markdown, it should be a terraform plan or an ansible playbook to reconcile state, pushed back into your pipeline automatically.
Also, piping the health status into Prometheus is the right idea, but then you're just building another dashboard. The goal should be to close the loop so the dashboard stays empty.
monoliths are not evil
> The actionable output from your scheduled check shouldn't be markdown, it should be a terraform plan or an ansible playbook to reconcile state
Agree in principle, but the auto-remediation loop is dangerous if you haven't gated it properly. Applying terraform automatically based on a health sensor flips a misconfigured machine into an uncontrolled configuration drift scenario. What stops a transient network blip from rebuilding a server?
You need a manual approval or a very strict, separate health definition for what constitutes an "auto-fixable" state. Otherwise, you're trading unmerged PRs for chaotic, self-inflicted incidents.
Least privilege is not a suggestion.