Appearance
Security activity and detections #
Security activity is the organisation's record of security-relevant signals. Detections are the policies and integrations that create or enrich that activity. Use this guide when a security owner, analyst, or auditor needs to see signals, change policy, or send events to an external workspace.
Availability depends on organisation entitlements. A role can include security.read and still see nothing if security detections are off for the organisation.
Who does which job #
| Role | Grant | What they do |
|---|---|---|
| Security Admin | security.read, security.write | Change detection policy and security integrations |
| Security Analyst | security.read plus fleet context | Investigate activity with device and ops context; do not own detection policy |
| Security Viewer | security.read only | See security activity for compliance review without fleet write access |
Assign these from Set up roles. Do not give every investigator Security Admin. Investigation is not detection-policy ownership. See Permission areas for the full grant catalogue.
Separate security signals from fleet incidents #
Alerts can represent device connectivity, monitor state, metric rules, or security activity. They still carry severity, audience, status, and resource context.
| Path | Use it when |
|---|---|
| Security activity / detections | The question is security policy, suspicious activity, or SIEM export |
| Incidents and on-call | A monitor-backed outage needs acknowledgement, escalation, and recovery |
| Logging | You need retained log lines, including security-classified events where enabled |
Do not treat a security export as proof that an on-call incident opened, or an incident acknowledgement as proof that a detection policy changed.
Investigate safely #
- Confirm the actor has the intended security role and that detections are enabled for the organisation.
- Open the security activity for the time window and resource in question.
- Correlate with device timeline, logs, and audit trails when the investigation spans access and operational actions.
- Preserve findings in the investigation record your organisation uses; coverage and retention differ across surfaces.
Where log analytics is enabled, security events can appear in directional rollups. Confirm a finding against the underlying records before you change policy or customer communication.
Export to security tooling #
Where the Microsoft Sentinel integration is enabled, security activity can be exported to the configured workspace.
- Use a dedicated credential with only required access.
- Validate field mapping with a test event.
- Monitor delivery, retry, and flush status.
- Confirm the event in Sentinel, including timestamp and organisation context.
- Test the downstream detection rule and retention policy.
An export is not proof of ingestion into a Sentinel rule. Rotate credentials after exposure and keep a documented failover path for security review. Setup steps live under Operations integrations.
Related identity controls #
Security operations usually sits beside directory and access controls:
- SSO and SCIM for sign-in and provisioning
- API keys for server-to-server access
- Trust on someone else's network for platform and device boundaries
- Multi-factor authentication for personal logins