<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Security on Ownchain Systems</title>
    <link>https://ownchain.systems/tags/security/</link>
    <description>Recent content in Security on Ownchain Systems</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 30 Aug 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ownchain.systems/tags/security/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CODEX-001: Decommissioning Socket-Mounted Web UIs &amp; Enforcing Terminal-Native Ops</title>
      <link>https://ownchain.systems/codex/001-socket-hardening/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/001-socket-hardening/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Ingress Hardening &amp;amp; Attack Surface Reduction&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;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 (&lt;code&gt;lazydocker&lt;/code&gt;).&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;phase-1-initial-deployment--context&#34;&gt;Phase 1: Initial Deployment &amp;amp; Context&lt;/h2&gt;&#xA;&lt;h3 id=&#34;why-portainer-was-introduced&#34;&gt;Why Portainer Was Introduced&lt;/h3&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-002: Hardening the Domain Mail Perimeter (SPF, DKIM, DMARC)</title>
      <link>https://ownchain.systems/codex/002-mail-auth/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/002-mail-auth/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Perimeter Defense &amp;amp; Mail Authentication&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model--problem-statement&#34;&gt;Threat Model &amp;amp; Problem Statement&lt;/h2&gt;&#xA;&lt;p&gt;When operating self-hosted services alongside third-party transactional email relays and professional mail routing, misaligned authentication headers lead to two major failure modes:&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-004: Validated Backups &amp; Disaster Recovery Drills</title>
      <link>https://ownchain.systems/codex/004-disaster-recovery/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/004-disaster-recovery/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Business Continuity &amp;amp; Disaster Recovery (BC/DR)&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;This report details the implementation, cryptographic architecture, and verification lifecycle of Bastion&amp;rsquo;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.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model--failure-scenarios&#34;&gt;Threat Model &amp;amp; Failure Scenarios&lt;/h2&gt;&#xA;&lt;p&gt;A backup strategy that has not been restored is merely a hypothesis. The backup architecture was designed to mitigate four specific failure modes:&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-005: Sandboxing vs. Storage Vaults: Flatpak, AppImage, and Native Packaging</title>
      <link>https://ownchain.systems/codex/005-sanbox-storage-boundaries/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/005-sanbox-storage-boundaries/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Filesystem Security &amp;amp; Runtime Sandboxing&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;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 &lt;code&gt;/mnt/lacie&lt;/code&gt;). It details the diagnostic triage of permission denials, FUSE execution restrictions, and the decision to standardize core system tooling on native package management.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model--problem-statement&#34;&gt;Threat Model &amp;amp; Problem Statement&lt;/h2&gt;&#xA;&lt;p&gt;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:&lt;/p&gt;</description>
    </item>
    <item>
      <title>CODEX-007: Digital Identity Excision &amp; Data Broker Surface Reduction</title>
      <link>https://ownchain.systems/codex/007-identity-perimeter-excision/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://ownchain.systems/codex/007-identity-perimeter-excision/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Classification:&lt;/strong&gt; Digital Sovereignty &amp;amp; Identity Threat Modeling&lt;br&gt;&#xA;&lt;strong&gt;Status:&lt;/strong&gt; Implemented &amp;amp; Verified&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;executive-summary&#34;&gt;Executive Summary&lt;/h2&gt;&#xA;&lt;p&gt;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 / &amp;ldquo;Right to be Forgotten&amp;rdquo;), and deploying automated data broker removal pipelines, legacy identity sprawl and third-party data exposure risks were remediated.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;threat-model-third-party-exposure-footprint&#34;&gt;Threat Model: Third-Party Exposure Footprint&lt;/h2&gt;&#xA;&lt;p&gt;Security perimeters extend beyond host firewalls into third-party SaaS platforms and data aggregation brokers:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
