SECURITY
Security Operations
A documented view of my monitoring environment: architecture, tooling, detections, and response workflow. Live demo widgets will be added after VPS2 is deployed.
API: https://api.ihowlett.com/v1/secops
Architecture
Segmented design • blast-radius reduction • monitoring integrityCurrent monitoring layout (portfolio simulation):
- Web layer: Vercel (public site)
- VPS1: API + database access layer
- VPS2: SIEM / monitoring (Wazuh stack)
- VPS3: Connect (digital card + supporting services)
- Endpoints: laptop + iPhone (plus lab VMs when needed)
Key design principles:
- Segmentation: each VPS has a clear role to reduce blast radius.
- Least privilege: service accounts and keys scoped to purpose.
- Immutable evidence: config versions + change notes after updates.
This is intentionally small, but structured like an enterprise: defined trust boundaries, centralized visibility, and repeatable incident handling.
Overview
This section documents how I run monitoring and incident response across a small, real environment: public web → API → VPS → endpoints. The goal is not flashy dashboards — it’s measurable detection coverage and repeatable response.
SecurePath SecOps is built around three rules:
1) Collect the right telemetry (security-relevant, not noise).
2) Make detections testable (simulate, verify alerting, tune).
3) Leave evidence (configs, screenshots, runbooks, change notes).
If a detection can’t be validated and explained, it doesn’t count.
Monitoring Stack
SIEM: Wazuh (VPS2)
Intrusion Prevention: Fail2Ban (all VPS)
Firewall: host-level rules (per VPS)
Planned: Network monitoring (Security Onion), vulnerability scanning (Greenbone/OpenVAS).
Detection Use Cases
Detections are treated like products: they must be testable, tuned, and documented.
Baseline detection categories:
- Brute force / password spraying attempts (SSH + app auth)
- Suspicious privilege escalation patterns (sudo misuse, unexpected admin actions)
- Persistence indicators (cron modifications, new services, startup changes)
- Web/API abuse patterns (enumeration, path traversal attempts, auth anomalies)
- Integrity changes (critical config files, key directories)
Alert quality standards:
- Each alert has a clear title, severity, and investigation steps.
- Each alert maps to an outcome: block, contain, confirm benign, or tune rule.
- Each alert has a “proof path”: how to reproduce safely for verification.
Incident Response Workflow
1) Alert triggers in SIEM
2) Validate and triage (severity + scope)
3) Collect evidence (logs, timestamps, affected host)
4) Contain (block, isolate, revoke)
5) Eradicate + recover (patch, restore, harden)
6) Lessons learned (tune detection + update baseline)
Evidence
Screenshots, dashboards, alert examples, and sanitized logs will appear here once VPS2 is deployed and demo endpoints are enabled.