Logging & Monitoring
What gets logged, how logs are protected, and how the platform is watched.
Covers the NIST SP 800-171 Audit & Accountability (AU) family and the monitoring portions of System & Information Integrity (SI).
What gets logged
| Layer | What's recorded |
|---|---|
| Application | Every write operation, attributed to the authenticated user ID, with timestamp and action — in a dedicated audit log |
| API service | Structured application logs streamed to CloudWatch |
| AWS control plane | Every AWS API call, attributed to an IAM identity, via CloudTrail (multi-region) |
| Network | VPC Flow Logs and load balancer access logs |
Every audit record traces to an individual — application actions to a unique user ID carried in the session token, infrastructure actions to an IAM identity. All timestamps are UTC from NTP-synchronized AWS time sources, so events correlate cleanly across layers.
How logs are protected
- CloudTrail runs with log file validation (cryptographic tamper evidence), KMS encryption, and delivery to a restricted, versioned bucket with public access blocked.
- Log access follows least privilege; the application's audit views are read-only, with no delete capability exposed.
- Alarms fire if audit logging itself fails.
Continuous monitoring and threat detection
- Amazon GuardDuty — managed threat detection over network, DNS, and API activity, with continuously updated threat intelligence.
- AWS Security Hub — aggregates and correlates findings from GuardDuty, CloudTrail, and AWS Config into one security posture view.
- AWS Config — watches for configuration drift against expected state.
- CloudWatch alarms — operational and security alerts routed to the Foxx Cyber support channel for triage.
Organization administrators also get an in-app view: the platform exposes audit activity for your own organization (who did what, when) so you can run your own reviews without filing a ticket.