sameerk27/vigil365: m365 Security Alert Dashboard

A self-hosted, real-time Microsoft 365 security monitoring dashboard that aggregates alerts from Defender XDR, Entra ID Protection, Intune, Exchange Online, Compliance, and more — all in one place.

No third-party SaaS required. Runs entirely on your own Windows host using Microsoft Graph API.

---

Features

Pages & Monitoring Coverage

Enterprise Features

• Alert Policy Engine — define custom policies (MFA drop, risky user spike, device breach) with thresholds; auto-evaluates against live data and tracks triggered alerts in browser localStorage
• 9 Pre-built Alert Templates — one-click templates for common security scenarios
• Detail Modals — click any alert, user, device, or policy to see all available fields and a direct "View in M365 Portal →" deep link
• Search, Filter, Sort, Export — every page has full-text search, dropdown filters, sortable columns, and CSV export
• Saved Filter Presets — save and reload custom filter combinations per page (localStorage)
• Dark Mode — full dark/light theme toggle, persisted across sessions
• Collapsible Sidebar — icon-only collapsed mode with hover tooltips
• Toast Notifications — on export, preset save, policy actions
• Sticky Filter Bars — filter controls stay visible while scrolling long lists
• Responsive Layout — collapses to single-column below 900px

Stack

Prerequisites

1. Windows host (Windows 10/11 or Windows Server 2019+)
2. .NET 8 SDK or ASP.NET Core 8 Hosting Bundle
3. SQL Server Express (free)
4. Node.js 20+

Microsoft Entra App Registration

Create the app

1. Go to Entra admin center → App registrations → New registration
2. Name it (e.g. M365SecurityDashboard)
3. Select Accounts in this organizational directory only
4. No redirect URI needed
5. Click Register
6. Note the Tenant ID and Application (client) ID
7. Go to Certificates & secrets → New client secret — note the secret value immediately

Required API permissions (Application, not Delegated)

Grant admin consent for all of these:

Some features (IRM, Attack Simulation, Identity Health) require additional Purview/Defender licensing in your tenant. The dashboard gracefully shows a permission error card for unavailable features.

Setup

1. Clone and configure secrets

git clone https://github.com/YOUR_ORG/m365-security-dashboard.git
cd m365-security-dashboard

cd src\M365SecurityDashboard.Api
dotnet user-secrets init
dotnet user-secrets set "Graph:TenantId"     "YOUR_TENANT_ID"
dotnet user-secrets set "Graph:ClientId"     "YOUR_CLIENT_ID"
dotnet user-secrets set "Graph:ClientSecret" "YOUR_CLIENT_SECRET"

Never put real credentials in appsettings.json — use User Secrets for development and environment variables or appsettings.Production.json (gitignored) for production.

2. Set up the database

# Option A: let the API auto-create on first run (requires db-create rights)
# Option B: pre-create manually
sqlcmd -S .\SQLEXPRESS -E -i .\database\schema.sql

3. Build the frontend

cd src\m365-security-dashboard-client
npm install
npm run build
Copy-Item -Recurse -Force .\dist\* ..\M365SecurityDashboard.Api\wwwroot\

4. Run the API

cd src\M365SecurityDashboard.Api
$env:ASPNETCORE_ENVIRONMENT = "Development"
dotnet run

Open http://localhost:5000

Development (hot-reload)

Run both simultaneously:

# Terminal 1 — backend
cd src\M365SecurityDashboard.Api
$env:ASPNETCORE_ENVIRONMENT = "Development"
dotnet watch run

# Terminal 2 — frontend
cd src\m365-security-dashboard-client
npm run dev

Frontend dev server: http://localhost:5173 (proxies API calls to backend)

Production Deployment (Windows Service)

# 1. Build frontend
cd src\m365-security-dashboard-client
npm install && npm run build
Copy-Item -Recurse -Force .\dist\* ..\M365SecurityDashboard.Api\wwwroot\

# 2. Publish API
cd ..\M365SecurityDashboard.Api
dotnet publish -c Release -o C:\Apps\M365SecurityDashboard

# 3. Create appsettings.Production.json in publish folder
# (see template below — this file is gitignored)

# 4. Install as Windows Service
sc.exe create M365SecurityDashboard `
  binPath= "C:\Apps\M365SecurityDashboard\M365SecurityDashboard.Api.exe --environment Production --urls http://localhost:8080" `
  start= auto
sc.exe start M365SecurityDashboard

appsettings.Production.json template (create this file manually, never commit it):

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=.\\SQLEXPRESS;Database=M365SecurityDashboard;Trusted_Connection=True;Encrypt=False"
  },
  "Graph": {
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientSecret": "YOUR_CLIENT_SECRET",
    "CollectionIntervalMinutes": 15,
    "DevicesNotCheckedInDays": 7,
    "SignInLookbackHours": 24
  }
}

API Reference

Security & Maturity

Read this before relying on Vigil365. This is an open-source read-only visibility aggregator, currently beta. It surfaces signals that already exist across your Microsoft 365 admin centers in one place. It is not a replacement for native Microsoft security tooling (Defender XDR, Entra ID Protection, Purview), and it does not make security decisions or change configuration for you. Treat its output as a convenience view, verify findings in the source portal before acting, and do your own review of the code before deploying it in a sensitive environment.

What is in scope by design

• Read-only, least privilege. Every Graph permission requested is *.Read.All. The app cannot modify users, devices, policies, or tenant settings even if the host is compromised.
• No remediation automation. "View in M365 Portal →" links only deep-link you to the correct blade. The app never tells you what to change and never makes changes — remediation stays in Microsoft's tooling where it belongs.
• No inbound exposure by default. The API binds to localhost. Remote access requires you to deliberately open a firewall port (and you should front it with TLS + auth if you do).
• App-only client-credentials flow via MSAL (Azure.Identity). Standard Microsoft auth, not a homegrown scheme. All Graph traffic is HTTPS/TLS.

How credentials and secrets are handled

• The Graph client secret is never committed to source. Use .NET User Secrets (dev) or appsettings.Production.json / environment variables (prod, both gitignored).
• Notification secrets stored in the database (SMTP password, Teams/Slack & generic webhook URLs) are encrypted at rest with the Windows Data Protection API (DPAPI), machine scope — a leaked database row cannot be decrypted on another machine. Secrets are decrypted only in memory at send time and the SMTP password is never returned by the API.
• Recommended: use certificate-based authentication instead of a client secret for production (planned/optional). A non-exportable certificate in the Windows cert store removes the plaintext shared secret entirely. (Not yet wired into the app — track this in Issues.)

Host hardening checklist (your responsibility)

The security of this app is only as good as the box it runs on. Before production use:

• Run on a dedicated, patched, hardened Windows host — not a shared workstation or a machine that handles untrusted input
• Run the service under a dedicated low-privilege service account, not an admin or your own login
• Enable BitLocker / full-disk encryption so the database and secrets are protected at rest
• Keep the host off the public internet; access the dashboard over the LAN/VPN only
• If you must expose it, put it behind a reverse proxy with TLS and authentication
• Ensure the host has endpoint protection and is monitored — a compromised host can read tokens in memory while the app runs
• Rotate the Graph secret/certificate on a schedule and immediately if the host is ever suspected compromised
• Restrict who can read appsettings.Production.json and the SQL database with NTFS/SQL permissions

Operational resilience

• Rate limiting is handled automatically (429 Retry-After respected).
• A failed individual Graph source does not stop the whole collection run; each card degrades independently.

Found a security issue? See SECURITY.md — please report privately, not in a public issue.