EAS Sentinel XDR

Enterprise Exchange ActiveSync Security Platform

An enterprise cybersecurity platform that unifies Microsoft Exchange ActiveSync gateway monitoring, real attachment analysis, threat intelligence, device management, incident response and executive reporting in one premium operations console.

Developed & Engineered by: Abdualrhman Auqla Alanazi

---

What it does

Module	Capability
Command Dashboard	Live security score, fleet posture, risk distribution, inline mail-flow visualization, gateway telemetry and real-time activity feed.
SOC Command Center	Live threat feed, streaming event log, gateway health and response queue.
Gateway Monitor	Health, throughput and synchronization queues across regional ActiveSync nodes.
Exchange ActiveSync	Synchronization session records and enforceable device security policies.
Devices	Managed-device fleet with live compliance and per-device security scoring.
Attachment Analyzer	Real 16-stage static analysis pipeline with a deterministic risk engine.
Threat Intelligence	Campaign intelligence mapped to MITRE ATT&CK with IOCs and recommended actions.
Analytics	Trends across detections, file types, sync volume and device activity.
Reports	Branded, print-ready executive and technical security reports.
Audit Logs	Immutable, filterable trail of every significant action.
Settings	Appearance, motion, notifications, scanning sensitivity and accessibility.

The analysis engine is real

The Attachment Analyzer performs genuine static inspection — nothing is faked:

1. Metadata → 2. MIME type → 3. Extension verification → 4. Magic bytes →
2. SHA-256 → 6. SHA-1 → 7. MD5 → 8. Shannon entropy → 9. Embedded objects →
3. Office macros → 11. Suspicious JavaScript → 12. PowerShell →
4. Executable sections → 14. Structure → 15. Risk engine → 16. Executive report

Hashing, entropy, magic-byte identification, OOXML/OLE macro detection, PE header parsing and script heuristics all run against the uploaded bytes. The risk engine is a transparent weighted model — the same file always produces the same score. Files are analyzed in an isolated quarantine and are never executed.

---

Architecture

Browser (Next.js)  ──REST──▶  FastAPI  ──▶  PostgreSQL
      │            ──WS────▶   (routers → services → repositories)
      │                        ├─ Simulation engine (asyncio)
      └── NGINX (prod)         ├─ Analysis pipeline (16 stages)
                               ├─ Event bus → WebSocket manager
                               └─ Cache (Redis / in-memory)

Frontend — Next.js (App Router), React, TypeScript, Tailwind, Framer Motion, Recharts, TanStack Table, Zustand, React Hook Form + Zod. Backend — FastAPI, SQLAlchemy 2 (async), JWT auth with refresh rotation, RBAC, rate limiting, an asyncio simulation engine and topic-based WebSockets. Data — PostgreSQL in production, SQLite for local development (same models); Redis cache in production, in-memory fallback locally.

---

Quick start (local development)

Two processes, no Docker required. The backend auto-creates and seeds a SQLite database.

Backend

cd backend
python -m venv .venv
.venv/Scripts/python -m pip install -r requirements.txt   # Windows
# source .venv/bin/activate && pip install -r requirements.txt   # macOS/Linux
python -m uvicorn app.main:app --reload --port 8000

Frontend

cd frontend
npm install --legacy-peer-deps
npm run dev

Open the printed URL (http://localhost:3000). The platform boots, then presents the sign-in screen.

Local evaluation accounts

Role	Email	Password	Can
Demonstration	demo@eas-sentinel.com	SentinelDemo2026	Read the console and submit files for analysis — nothing else
Administrator	admin@eas-sentinel.com	SentinelAdmin#2026	Everything, including platform settings
Analyst	analyst@eas-sentinel.com	SentinelAnalyst#2026	Investigate, act on devices, generate reports
Viewer	viewer@eas-sentinel.com	SentinelViewer#2026	Read only

The sign-in card's "Use the demonstration workspace" button fills the demo credentials, and refuses to offer any other account.

These passwords are published, so they are not secrets.

The three privileged accounts above exist for local evaluation only. A deployment with SENTINEL_ENVIRONMENT=production refuses to start until SENTINEL_SEED_ADMIN_PASSWORD, SENTINEL_SEED_ANALYST_PASSWORD and SENTINEL_SEED_VIEWER_PASSWORD are all supplied — see DEPLOY.md.

demo is deliberately exempt: it is a public identity whose password is meant to be known, which is safe only because the DEMO role cannot change anything, cannot see other visitors' uploads, and cannot alter even its own account.

---

Security posture

The platform is built to be exposed to the internet, so the boundaries are asserted in tests rather than assumed. backend/tests/test_security_hardening.py covers each one and runs in CI.

Area	Control
Sessions	15-minute access tokens; refresh tokens rotate on every use, and replaying a consumed one revokes every session for that account
Passwords	scrypt (N=2¹⁴) with per-user salts; a 12-character floor with checks for padded common bases, keyboard runs and self-referencing values
Brute force	Per-address throttling and per-account lockout, so rotating source addresses buys no extra guesses
Client identity	X-Forwarded-For is counted from the right against a declared proxy depth, never read from the left
Authorization	Role checks on every route; the demo identity is scoped to its own scans and sees masked owner addresses
Browser	Nonce-based CSP with strict-dynamic, HSTS, frame-ancestors 'none', and no unsafe-inline for scripts
Realtime	Origin-checked WebSocket handshake, token carried in the subprotocol rather than the URL, socket closed when its token expires
Uploads	Type allowlist, streamed size cap, per-user hourly quota, bounded analysis concurrency, and a 24-hour quarantine purge
Reports	Printable documents render in a sandboxed frame with script execution withheld entirely

---

Production (Docker)

cp .env.example .env      # then set SENTINEL_JWT_SECRET to a long random value
cd deploy
SENTINEL_JWT_SECRET="$(openssl rand -base64 48)" docker compose up --build

This starts PostgreSQL, Redis, the FastAPI backend (Gunicorn + Uvicorn workers), the Next.js frontend, and an NGINX reverse proxy with gzip, rate limiting and WebSocket support. The console is served on http://localhost (override with PUBLIC_PORT).

---

Testing

cd backend && .venv/Scripts/python -m pytest tests/test_analysis.py -q   # engine unit tests
cd frontend && npx tsc --noEmit && npm run build                          # type-check + build

CI (GitHub Actions) runs the backend tests, the frontend type-check and build, and validates both Docker images on every push and pull request.

---

Project layout

eas-sentinel-xdr/
├── frontend/    Next.js app — app routes, components (scene, ui, layout, charts,
│                data, analyzer, dashboard), lib, hooks, stores, types
├── backend/     FastAPI app — core, db, models, schemas, api/v1, services,
│                analysis (16 stages + risk engine), intel, tests
├── deploy/      Dockerfiles, docker-compose, NGINX config
└── .github/     CI workflow

---

© EAS Sentinel XDR. Developed & Engineered by Abdualrhman Auqla Alanazi.