SOX 404 Compliance¶

Sarbanes-Oxley Act, Section 404: Management Assessment of Internal Controls

Overview¶

The Sarbanes-Oxley Act (SOX) Section 404 requires publicly traded companies to establish and maintain adequate IT General Controls (ITGC) for systems that support financial reporting. Bindy, as a critical DNS infrastructure component in a regulated banking environment, must comply with SOX 404 controls.

Key Requirement: Companies must document, test, and certify the effectiveness of IT controls that affect financial data integrity, availability, and security.

Why Bindy Must Comply with SOX 404¶

Even though Bindy is DNS infrastructure (not a financial application), it falls under SOX 404 because:

Supports Financial Systems: Bindy provides DNS resolution for financial applications (trading platforms, payment systems, customer portals)
Service Availability: DNS outages prevent access to financial reporting systems (material impact)
Change Management: Unauthorized DNS changes could redirect traffic to fraudulent systems (data integrity risk)
Audit Trail: DNS logs provide evidence for financial transaction tracking and fraud detection

In Scope for SOX 404: - ✅ Change management (code changes, configuration changes) - ✅ Access controls (who can modify DNS zones, RBAC) - ✅ Audit logging (7-year retention, immutability) - ✅ Segregation of duties (2+ reviewers for changes) - ✅ Incident response (service restoration, root cause analysis)

SOX 404 Control Objectives¶

SOX 404 defines 5 categories of IT General Controls:

Control Category	Description	Bindy Implementation
Change Management	All changes to IT systems must be authorized, tested, and documented	✅ GitHub PR process, signed commits, CI/CD testing
Access Controls	Restrict access to systems based on job responsibilities (least privilege)	✅ RBAC, signed commits, 2FA, quarterly reviews
Backup and Recovery	Data backups and disaster recovery procedures	⚠️ Partial - DNS data in etcd (Kubernetes), zone backups in Git
Computer Operations	System availability, monitoring, incident response	✅ Prometheus monitoring, incident playbooks (P1-P7)
Program Development	Secure software development lifecycle (SDLC)	✅ Code review, security scanning, SBOM, reproducible builds

Bindy's SOX 404 Compliance Controls¶

1. Change Management (CRITICAL)¶

SOX 404 Requirement: All code and configuration changes must be authorized, tested, and traceable.

Bindy Implementation:

Control	Implementation	Evidence Location
Cryptographic Commit Signing	All commits must be GPG/SSH signed	Git history, branch protection rules
Two-Person Approval	2+ maintainers must approve PRs	GitHub PR approval logs
Automated Testing	CI/CD runs unit + integration tests before merge	GitHub Actions workflow logs
Change Documentation	All changes documented in `CHANGELOG.md` with author attribution	`CHANGELOG.md`
Audit Trail	Git history provides immutable record of all changes	Git log, signed commits
Rollback Procedures	Documented in incident response playbooks	Incident Response - P3, P5

Evidence for Auditors:

# Show all commits with signatures (last 90 days)
git log --show-signature --since="90 days ago" --oneline

# Show PR approval history
gh pr list --state merged --limit 100 --json number,title,reviews

# Show CI/CD test results
gh run list --workflow ci.yaml --limit 50

Audit Questions: - ✅ Q: Are all changes authorized? Yes, 2+ approvals required via GitHub branch protection - ✅ Q: Are changes traceable? Yes, signed commits with author name, timestamp, and description - ✅ Q: Are changes tested? Yes, CI/CD runs cargo test, cargo clippy, cargo audit on every PR - ✅ Q: Can you prove no unauthorized changes? Yes, branch protection prevents direct pushes, all changes via PR

2. Access Controls (CRITICAL)¶

SOX 404 Requirement: Restrict access to production systems and enforce least privilege.

Bindy Implementation:

Control	Implementation	Evidence Location
Least Privilege RBAC	Operator has minimal RBAC (create/delete secrets for RNDC lifecycle, delete managed resources for cleanup)	`deploy/rbac/clusterrole.yaml`
Minimal Delete Permissions	Operator delete limited to managed resources (finalizer cleanup, scaling)	RBAC verification script output
Separation of Duties	2+ reviewers required for all code changes	GitHub branch protection settings
2FA Enforcement	GitHub requires 2FA for all contributors	GitHub organization settings
Access Reviews	Quarterly review of repository access	Access review reports (Q1/Q2/Q3/Q4)
Secret Access Audit Trail	All secret access logged with 7-year retention	Secret Access Audit Trail

RBAC Verification:

# Verify operator has minimal required permissions
./deploy/rbac/verify-rbac.sh

# Expected output:
# ✅ Operator has get/list/watch on secrets
# ✅ Operator can create/delete secrets (RNDC key lifecycle)
# ✅ Operator CANNOT update/patch secrets (immutable pattern)
# ✅ Operator can delete managed resources (Bind9Instance, Bind9Cluster, finalizer cleanup)
# ✅ Operator CANNOT delete user resources (DNSZone, Records, ClusterBind9Provider)

Evidence for Auditors:

RBAC Policy: deploy/rbac/clusterrole.yaml - Shows minimal required permissions with detailed rationale
RBAC Verification: CI/CD artifact rbac-verification.txt - Proves least-privilege access (delete only for lifecycle management)
Secret Access Logs: Elasticsearch query Q1 - Shows only bindy-operator accessed secrets
Quarterly Access Reviews: docs/compliance/access-reviews/YYYY-QN.md - Shows regular access audits

Audit Questions: - ✅ Q: Are access rights restricted? Yes, operator has minimal RBAC (create/delete secrets for RNDC lifecycle only, delete managed resources for finalizer cleanup only) - ✅ Q: Are privileged accounts monitored? Yes, all secret access logged and alerted - ✅ Q: Are access reviews conducted? Yes, quarterly reviews with security team approval

3. Audit Logging (CRITICAL)¶

SOX 404 Requirement: Maintain audit logs for 7 years with tamper-proof storage.

Bindy Implementation:

Control	Implementation	Evidence Location
7-Year Retention	Audit logs retained for 7 years (SOX requirement)	S3 lifecycle policy, WORM configuration
Immutable Storage	S3 Object Lock (WORM) prevents log tampering	S3 bucket configuration
Log Integrity	SHA-256 checksums verify logs not altered	Daily CronJob output, checksum files
Comprehensive Logging	Logs all CRD operations, secret access, DNS changes	Kubernetes audit policy
Access Logging	S3 access logs track who reads audit logs (meta-logging)	S3 server access logs
Automated Backup	Logs replicated across 3 AWS regions	S3 cross-region replication

Log Types (7-Year Retention):

Log Type	What's Logged	Storage Location	Retention
Kubernetes Audit Logs	All API server requests (CRD create/update/delete, secret access)	S3 `bindy-audit-logs/audit/`	7 years
Operator Logs	Reconciliation loops, errors, DNS zone updates	S3 `bindy-audit-logs/operator/`	7 years
Secret Access Logs	All secret get/list/watch operations	S3 `bindy-audit-logs/audit/secrets/`	7 years
CI/CD Logs	Build logs, security scans, deploy history	GitHub Actions artifacts + S3	7 years
Incident Logs	Security incidents, playbook execution, post-mortems	S3 `bindy-audit-logs/incidents/`	7 years

Evidence for Auditors:

# Show 7-year retention policy
aws s3api get-bucket-lifecycle-configuration --bucket bindy-audit-logs

# Show WORM (Object Lock) enabled
aws s3api get-object-lock-configuration --bucket bindy-audit-logs

# Show log integrity (checksum verification)
kubectl logs -n dns-system -l app=audit-log-verifier --since 24h

# Query audit logs for specific time period
# (Example: All DNS zone changes in Q4 2025)
curl -X POST "https://elasticsearch:9200/bindy-audit-*/_search" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "bool": {
        "must": [
          { "term": { "objectRef.resource": "dnszones" } },
          { "range": { "requestReceivedTimestamp": {
              "gte": "2025-10-01T00:00:00Z",
              "lte": "2025-12-31T23:59:59Z"
            }
          }}
        ]
      }
    }
  }'

Audit Questions: - ✅ Q: Are logs retained for 7 years? Yes, S3 lifecycle policy enforces 7-year retention - ✅ Q: Can logs be tampered with? No, S3 Object Lock (WORM) prevents deletion/modification - ✅ Q: How do you verify log integrity? Daily SHA-256 checksum verification via CronJob - ✅ Q: Can you provide logs from 5 years ago? Yes, S3 Glacier retrieval (1-5 minutes)

4. Segregation of Duties¶

SOX 404 Requirement: No single person can authorize, execute, and approve changes.

Bindy Implementation:

Control	Implementation	Evidence
2+ Reviewers Required	GitHub branch protection enforces 2 approvals	Branch protection rules
No Self-Approval	PR author cannot approve their own PR	GitHub settings
Separate Roles	Developers cannot merge without approvals	CODEOWNERS file
No Direct Pushes	All changes via PR (even admins)	Branch protection rules
Audit Trail	PR approval history provides evidence	GitHub API, audit logs

Evidence for Auditors:

# Show branch protection requires 2 approvals
gh api repos/firestoned/bindy/branches/main/protection | jq '.required_pull_request_reviews'

# Expected output:
# {
#   "required_approving_review_count": 2,
#   "dismiss_stale_reviews": true,
#   "require_code_owner_reviews": false
# }

Audit Questions: - ✅ Q: Can one person make and approve changes? No, 2+ approvers required, PR author excluded - ✅ Q: Can admins bypass controls? No, branch protection applies to admins - ✅ Q: How do you verify segregation? GitHub audit logs show separate approver identities

5. Evidence Collection for SOX 404 Audits¶

What Auditors Need:

Provide the following evidence package for SOX 404 auditors:

Change Management Evidence:
Git commit log (last 12 months) with signatures: git log --show-signature --since="1 year ago" > commits.txt
PR approval history: gh pr list --state merged --since "1 year ago" --json number,title,reviews > pr-approvals.json
CI/CD test results: GitHub Actions workflow artifacts
CHANGELOG.md showing all changes with author attribution
Access Control Evidence:
RBAC policy: deploy/rbac/clusterrole.yaml
RBAC verification output: CI/CD artifact rbac-verification.txt
Quarterly access review reports: docs/compliance/access-reviews/
Secret access audit trail: Elasticsearch query Q1 results (last 12 months)
Audit Logging Evidence:
S3 bucket configuration (lifecycle, WORM, encryption): aws s3api describe-bucket.json
Log integrity verification results: CronJob output (last 12 months)
Sample audit logs (redacted): Elasticsearch export for specific date range
Audit log access logs (meta-logging): S3 server access logs
Incident Response Evidence:
Incident response playbooks: docs/security/incident-response.md
Incident logs (if any occurred): S3 bindy-audit-logs/incidents/
Tabletop exercise results: Semi-annual drill reports

SOX 404 Audit Readiness Checklist¶

Use this checklist quarterly to ensure SOX 404 audit readiness:

Quarterly SOX 404 Attestation¶

Sample Attestation Letter (for CFO/CIO signature):

[Company Letterhead]

SOX 404 IT General Controls Attestation
Q4 2025 - Bindy DNS Infrastructure

I, [CFO Name], certify that for the quarter ended December 31, 2025, the Bindy DNS
infrastructure has maintained effective IT General Controls in compliance with
Sarbanes-Oxley Act Section 404:

1. Change Management Controls:
   - ✅ 127 code changes reviewed and approved via 2+ person process
   - ✅ 100% of commits cryptographically signed
   - ✅ 0 unauthorized changes detected

2. Access Control Controls:
   - ✅ RBAC least privilege verified (automated script passes)
   - ✅ Quarterly access review completed (2025-12-15)
   - ✅ 0 unauthorized secret access events detected

3. Audit Logging Controls:
   - ✅ 7-year audit log retention enforced (WORM storage)
   - ✅ Daily log integrity verification passed (100% checksums valid)
   - ✅ Audit logs available for entire quarter

4. Segregation of Duties:
   - ✅ 2+ approvers required for all code changes
   - ✅ No self-approvals detected
   - ✅ Branch protection enforced (no direct pushes to main)

Based on my review and testing, I conclude that internal controls over Bindy DNS
infrastructure were operating effectively as of December 31, 2025.

Signature: ___________________________
[CFO Name], Chief Financial Officer
Date: 2025-12-31

Common SOX 404 Audit Findings (And How Bindy Addresses Them)¶

Common Finding	How Bindy Addresses It	Evidence
Unsigned commits	✅ All commits GPG/SSH signed, branch protection enforces	Git log, GitHub branch protection
Single approver for changes	✅ 2+ approvers required, enforced by GitHub	PR approval history
No audit trail for changes	✅ `CHANGELOG.md` + Git history + signed commits	CHANGELOG.md, git log
Logs not retained 7 years	✅ S3 lifecycle policy enforces 7-year retention	S3 bucket configuration
Logs can be tampered with	✅ S3 Object Lock (WORM) prevents tampering	S3 bucket configuration
No access reviews	✅ Quarterly access reviews documented	`docs/compliance/access-reviews/`
Excessive privileges	✅ Operator minimal RBAC (delete only for lifecycle management)	RBAC policy, verification script
No incident response plan	✅ 7 incident playbooks (P1-P7) documented	`docs/security/incident-response.md`

SOX 404 Compliance¶

Overview¶

Why Bindy Must Comply with SOX 404¶

SOX 404 Control Objectives¶

Bindy's SOX 404 Compliance Controls¶

1. Change Management (CRITICAL)¶

2. Access Controls (CRITICAL)¶

3. Audit Logging (CRITICAL)¶

4. Segregation of Duties¶

5. Evidence Collection for SOX 404 Audits¶

SOX 404 Audit Readiness Checklist¶

Quarterly SOX 404 Attestation¶

Common SOX 404 Audit Findings (And How Bindy Addresses Them)¶

See Also¶