Classification: Ingress Hardening & Attack Surface Reduction
Status: Implemented & Verified

Executive Summary

This report documents the architectural lifecycle of container management on Bastion: from initially deploying a web-based GUI (Portainer) to overcome early CLI friction, to identifying the inherent security risks of host-socket mounting, and finally decommissioning the interface in favor of key-authenticated, terminal-native tooling (lazydocker).

Phase 1: Initial Deployment & Context

Why Portainer Was Introduced

When initially transitioning to Docker and container orchestration, early CLI management presented significant friction. Debugging multi-container networks, diagnosing container start failures, and managing persistent volume paths purely through raw shell commands often led to silent errors and operational overhead.

Classification: Perimeter Defense & Mail Authentication
Status: Implemented & Verified

Executive Summary

This report covers auditing, remediating, and enforcing cryptographic and domain-level email authentication records (SPF, DKIM, and DMARC) across a multi-service custom domain. The objective was resolving silent delivery failures for automated application notifications, aligning third-party transactional mail providers, and enforcing a strict quarantine policy to protect domain reputation against spoofing and phishing attempts.

Threat Model & Problem Statement

When operating self-hosted services alongside third-party transactional email relays and professional mail routing, misaligned authentication headers lead to two major failure modes:

Classification: Business Continuity & Disaster Recovery (BC/DR)
Status: Implemented & Verified

Executive Summary

This report details the implementation, cryptographic architecture, and verification lifecycle of Bastion’s automated disaster recovery pipeline. Moving beyond passive snapshots, the architecture enforces client-side AES-256 encryption, offsite repository replication, and regular cold-restore validation drills to guarantee deterministic recovery in the event of catastrophic storage or hardware loss.

Threat Model & Failure Scenarios

A backup strategy that has not been restored is merely a hypothesis. The backup architecture was designed to mitigate four specific failure modes:

Classification: Filesystem Security & Runtime Sandboxing Status: Implemented & Verified

Executive Summary

This report analyzes permission boundaries, filesystem isolation, and execution failures encountered when integrating sandboxed application formats (Flatpak and AppImage) with external storage vaults (such as /mnt/lacie). It details the diagnostic triage of permission denials, FUSE execution restrictions, and the decision to standardize core system tooling on native package management.

Threat Model & Problem Statement

Application isolation frameworks (Flatpak, AppImage) provide sandboxing by restricting default access to the host filesystem. However, when operational workflows require direct access to designated storage mounts, isolated runtimes introduce specific operational failure modes:

Classification: Digital Sovereignty & Identity Threat Modeling
Status: Implemented & Verified

Executive Summary

This report details the execution of an identity attack surface reduction campaign. By systematically auditing third-party service dependencies, invoking statutory Data Subject Requests (DSR / “Right to be Forgotten”), and deploying automated data broker removal pipelines, legacy identity sprawl and third-party data exposure risks were remediated.

Threat Model: Third-Party Exposure Footprint

Security perimeters extend beyond host firewalls into third-party SaaS platforms and data aggregation brokers: