Samsara/audit/REMEDIATION_PLAN.md

Remediation and production acceptance plan

Audit only: none of the following changes was implemented. Priorities are approval gates, not CVSS scores: a P0 production blocker can arise from an unverified assurance without a demonstrated critical exploit. The source-only audit does not authorize production testing, package changes, policy changes or network access. Each future action needs its own CHS-approved scope.

P0 — Critical production blockers

P0-1: Resolve the PHI-processing model before deployment

• Findings: S-01, S-02, S-03. Affected: all powershell/Get-Server*.ps1; samsara/collectors/linux.py, linux_schedules.py, importer.py; samsara/models/inventory.py; samsara/analyzers/dependencies.py; samsara/reporting/export.py.
• Suggested implementation: obtain CHS privacy/security/data-owner approval of every source and field. If management requires no PHI collection/processing, disable unrestricted SMB open-file/task/certificate/free-text acquisition by default and redesign around pre-approved numeric/enumerated or upstream-minimized information. Approve source naming/data standards rather than assuming an infrastructure string is safe. If sensitive acquisition is essential, explicitly reclassify the application/workflow as potentially processing PHI and obtain the corresponding organizational controls; do not retain a contradictory PHI-free claim.
• Verification: isolated synthetic host with privacy-canary strings in service/task names, accounts, share/file paths, certificate subjects, registry fields and provider errors. Trace provider acquisition as well as outputs, temp files, process memory exposure and native logs. No actual patient data. Review full task/certificate object materialization and SMB result contents.
• Acceptance: a signed field/source register and data-flow approval. For a no-processing claim, unapproved raw fields never enter the application/provider acquisition scope. If that cannot be established, claim remains Unverified and the workflow cannot be approved under that claim. A clean-looking HTML report or regex replacement alone does not pass.

P0-2: Create one enforceable privacy contract across processing and outputs

• Findings: S-01, S-03, S-08. Affected: schemas/inventory-v1.schema.json; samsara/models/inventory.py; collectors/windows.py, importer.py, linux.py; analyzer/summary/report/UI boundaries.
• Suggested implementation: explicit field approval, complete scalar types/enums/ranges, bounded strings/arrays/depth, closed nested objects and fixed check identifiers. Reject or quarantine unapproved fields; do not quietly preserve them inside allowed containers. Apply a central reviewed privacy projection before evidence construction and every UI/export/log path, including direct exporter/API callers and sidecars. Do not treat schema validation or HTML escaping as PHI redaction. Ensure the importer does not claim that filtering after deserialization prevented initial sensitive processing.
• Verification: synthetic canaries in every allowed free-text key, nested data in weakly typed retained keys, arbitrary check names, unknown/error fields and direct export function inputs. Attempt malformed/large/deep JSON and demonstrate fail-closed handling without logging rejected values. Verify required timestamp format checks actually exist under the installed locked dependency set.
• Acceptance: approved inputs only; no unapproved value reaches assessment, UI, temp outputs or exports. Rejection reports contain fixed diagnostic codes only. All exporter entry points enforce the same contract. Any unavoidable pre-redaction acquisition is documented and governed under P0-1.

P0-3: Approve and enforce storage, temporary data and network destinations

• Findings: S-03, S-04, S-05, S-09. Affected: samsara/collectors/windows.py:51-92; linux.py:20-53; samsara/reporting/export.py; UI file dialogs; CLI output handlers; tools/validate_windows_host.py.
• Suggested implementation: an approved bounded IPC or protected spool design; approved encrypted output/spool roots; restrictive inherited and newly created ACLs; canonical path validation and safe handle-based creation. Prohibit unapproved UNC, mapped, mounted-remote and reparse/symlink routes or put them behind a separately approved transfer workflow. Make full raw export an explicit privileged choice instead of an automatic companion to minimal HTML. Bound history/retention, apply output classification and document backup/cleanup behavior. Environment controls can be compensating controls only when documented and verified for this exact deployment.
• Verification: synthetic-only path matrix: allowed/denied roots, UNC/mapped shares, symlinks/reparse points, existing-file collisions, hostile writable directories, access failures, interrupted exports, temporary cleanup and restricted users. Verify DACLs and encrypted-at-rest posture under intended accounts. Trace egress and OS authentication without using real clinical data.
• Acceptance: full inventory cannot be written or transmitted outside approved destinations through application paths; all artifacts and temporary copies are protected by verified policy. Failure leaves no uncontrolled partial sensitive artifact. Security/privacy owners approve retention, backup and transfer. Closing a file is not accepted as secure-erasure evidence.

P0-4: Establish the release being approved and complete independent acceptance

• Findings: S-07, S-10 and scope/provenance limitation. Affected: release packaging/deployment, Python/PowerShell/schema/assets; available .git placeholder and Samsara.bundle; organizational approval process.
• Suggested implementation: identify the actual upstream release/commit, reconcile any newer task/certificate changes and audit the exact bytes. Deploy an immutable ACL-protected reviewed release, with organizationally approved signatures/provenance and execution controls. Provide a clear read-only operational definition (no intentional configuration changes, separately approved report/temp/log writes). No blind assessment-time dependency installation or policy bypass.
• Verification: authorized isolated Windows Server matrix with before/after registry/service/task/certificate/configuration and filesystem/process/network traces; compare standard/delegated tokens. Verify tamper/unsigned-code rejection and metadata-only behavior under actual script signing, AppLocker/WDAC and logging policy. No production execution in this audit.
• Acceptance: CHS security, privacy and operations review the exact release's evidence, granted permissions, residual risks and rollback/incident plan. No production approval based solely on mock tests or the source's “read-only” label. Latest remote source/history is verified without overwriting unreviewed changes.

P1 — Required before production approval

P1-1: Reproducible dependency lock, minimal distribution and complete SBOM

• Findings: S-07. Affected: requirements.txt, future target-specific locks/build manifests; Qt/native distribution; approved build/deployment pipeline.
• Suggested implementation: pin/hash the entire resolved dependency set for each approved Windows/Linux/Python target. Evaluate replacing the broad Qt meta-package with only required components, preserving existing UI/branding compatibility. Include native Qt/WebEngine/PDF/codecs/runtime libraries and OS/PowerShell module baseline in CycloneDX/SPDX. Verify provenance, license obligations and scanner/vendor coverage.
• Verification: clean approved offline install from a reviewed wheelhouse; no unresolved dependencies or undeclared downloads. Later authorized advisory scans and binary SBOM review using DEPENDENCY_INVENTORY.md commands. Review collection failures, vendor maintenance and native component gaps.
• Acceptance: reproducible installation and startup on approved platforms, every shipped component identified/justified, no unexplained runtime downloads, signed inventory/provenance and approved vulnerability/license exceptions. No invented CVE or “zero vulnerabilities” claim from an incomplete scan.

P1-2: Demonstrate offline operation and authorized egress boundaries

• Findings: S-09. Affected: file-path handlers, samsara/main.py, Qt/native runtime, schemas, PowerShell/OS providers and deployment network policy.
• Suggested implementation: define approved destinations and deny other egress, including remote filesystem/authentication paths. Restrict schema references to approved local resources and protect schema provenance. Inventory native dialogs, IPC, code-signature validation, revocation lookups and host security tooling separately from direct application requests. Keep required enterprise security logging enabled.
• Verification: isolated synthetic runtime with network observation and denied egress; exercise GUI/local/CLI/import/policy/report/failure flows and dependency bootstrap separately. Attribute any connection to executable, destination, payload category and host policy. Do not infer no traffic merely from absence of requests/httpx imports.
• Acceptance: zero unauthorized assessment-data or credential/authentication egress, documented necessary OS/IPC traffic and working assessment/reporting without general Internet access. Any future remote collector requires a separate threat model/authorization.

P1-3: Least-privilege execution and environment/deployment integrity

• Findings: S-06, S-07, S-10. Affected: samsara/collectors/windows.py:35-64; PowerShell driver/helpers/modules; deployment directories; samsara/core/startup.py native loading.
• Suggested implementation: tested minimum Windows child environment; no unrelated credential variables. Explicit registry value-type/non-expansion handling. Keep NoProfile, fixed arguments, system executable resolution, no bypass and no auto elevation. Define provider/task/store/registry read access by scope. Protect code/schema/policy/assets and search/plugin paths from modification by less-trusted accounts. Do not assume a self-hash inside editable Python is a security boundary.
• Verification: synthetic secret environment and REG_EXPAND_SZ canaries; standard/delegated tokens; missing/inaccessible modules/scopes; malicious executable/plugin/profile/module path attempts in an isolated lab. Verify no canary enters reports/logs/temp beyond the approved model.
• Acceptance: permissions matrix signed by operations; no Domain Administrator requirement; non-elevated assessments fail/mark partial safely; no inherited unrelated secrets or untrusted code path. Sensitive open-file collection disabled unless specifically approved.

P1-4: Protected artifact creation and integrity

• Findings: S-03, S-04. Affected: samsara/reporting/export.py; CLI output; validation helper; UI save workflow.
• Suggested implementation: safe approved file handles, restrictive ACLs, explicit overwrite authorization, transactional report/artifact creation and bounded existing-artifact reads. Separate content hashes from authenticity; use organizational signing/attestation where required without storing signing keys in the project. Data minimization takes precedence over preserving unsafe raw content.
• Verification: link/race/collision tests, interrupted write, low-disk/access failure, tampered sidecar/HTML, unprivileged reader and unauthorized recipient scenarios with synthetic content.
• Acceptance: no unauthorized read/write/clobber, no unintended leftover full inventory, complete artifact set with clear classification and integrity provenance. A SHA-256 printed in an editable HTML file is not accepted as an authenticity guarantee.

P1-5: Complete structural, format and resource-bound validation

• Findings: S-05, S-08. Affected: samsara/models/inventory.py; schemas/inventory-v1.schema.json; samsara/collectors/importer.py, windows.py; samsara/analyzers/policy.py; PowerShell full-envelope driver.
• Suggested implementation: reliable date/type validation and bounded JSON depth/collection sizes; explicit safe handling of RecursionError/invalid encodings/unknown keys. Bound direct PowerShell full mode as well as supervised Python use or remove unsupported unbounded paths from production instructions. Make byte/memory/time limits enforceable and account for temporary-output overshoot/provider enumeration cost.
• Verification: exact locked environment tests for malformed timestamps, nested retained fields/check identifiers, large provider results/JSON, output bursts, cancellation and native process cleanup. Test adversarial inputs only in an isolated lab.
• Acceptance: invalid input rejected with fixed safe diagnostics; guaranteed documented resource envelope; no uncontrolled collection or UI hang/partial artifact outside the approved policy.

P1-6: Logging, incident handling and operational authorization

• Findings: S-01-S-05, S-09-S-10. Affected: error/status handling, console/validation outputs, deployment logging/EDR/transcription, operational documentation and release procedure.
• Suggested implementation: metadata-only audit events for operator/approved scope/tool version/status/artifact disposition, without raw inventory/error/PHI. Document OS logging and crash/pagefile behavior, incident response, retention and authorized assessment windows. Ensure user-interface labels do not substitute for actual host ownership/data authorization. Obtain privacy/security review of the exact validation-summary contents.
• Verification: synthetic canaries through all success/error/cancel/import/report paths, configured transcripts/EDR/dumps and approved log collectors. Verify expected attribution without leaking raw values. Simulate privacy incident handling without real patients.
• Acceptance: meaningful access/activity audit evidence with no unapproved content or destinations; agreed response/escalation and retention ownership. No HIPAA compliance assertion without separate organizational determination.

P2 — Recommended security improvements

P2-1: Make the test harness completely host-isolated

• Affected: tests/test_linux.py:36-65, tests/test_powershell.py:9-16, native mocks, future privacy regression tests.
• Implementation: inject all host filesystem/provider boundaries, isolate runtime binary resolution and separate explicitly authorized integration tests from unit tests. Never rely on a comment that a test is synthetic. Preserve existing behavioral/risk tests.
• Verification: deny real /proc/cron/registry/network/provider access while unit tests run against fixture-only data; ensure forbidden attempts fail visibly.
• Acceptance: unit test suite produces only test-owned artifacts and no real host inventory; integration tests require explicit opt-in and approved lab scope. Tests were not run during this audit.

P2-2: Reduce display/session exposure

• Affected: samsara/ui/window.py:401-479; summary/evidence models.
• Implementation: privacy-reduced summary by default, explicit authorized detailed view, bounded session history, clear-session controls and data lifetime documentation. Avoid claiming secure erasure of immutable runtime strings.
• Verification: synthetic data through navigation/history/cancel/close/screenshots/accessibility and OS dump policies.
• Acceptance: no unnecessary sensitive display/retention beyond the approved operator workflow; ownership of external screen-sharing/support policies documented.

P2-3: Harden offline HTML and sharing workflow

• Affected: samsara/reporting/export.py; report distribution documentation.
• Implementation: preserve escaping/relative encoded links, add appropriate restrictive content policy where meaningful for offline reports, clear classification banners and approved recipient/workflow guidance. Minimal reports should not silently depend on full raw data.
• Verification: synthetic HTML/URL/control-character injection attempts and offline browser behavior on approved clients; test all artifact links and no remote content fetch.
• Acceptance: inert escaped content, no unauthorized active/remote content and reviewed file-sharing/retention behavior. Browser policy is not a substitute for data minimization.

P2-4: Continuous provenance and security checks

• Affected: future CI/release process, Python/PowerShell/schema/policy artifacts and security documentation.
• Implementation: signed release manifests, recurring dependency/native advisory review, artifact/secret scans of current source and history, and explicit review of changed collector fields/commands. Treat clinical-output artifacts as excluded from source control and verify staging rather than relying on .gitignore.
• Verification: tamper, unsigned release, changed dependency and attempted sensitive-artifact staging tests in CI.
• Acceptance: traceable release/control owner, blocked unauthorized changes and current signed evidence for each promoted build.

P3 — Optional enhancements

P3-1: Approved external aggregation adapter

• Affected: future collector interface and organizational monitoring integration; not the current application.
• Implementation: assess a read-only interface to already approved aggregated activity/asset identifiers, avoiding raw clinical filenames/task definitions. Any new connection requires separate security/privacy review and explicit destination controls.
• Verification: synthetic contract, least privilege, no patient-bearing source fields or unauthorized egress.
• Acceptance: the adapter reduces raw acquisition without adding unapproved telemetry, credentials or infrastructure configuration.

P3-2: Structured control evidence package

• Affected: future audit/report tooling and deployment documentation.
• Implementation: machine-readable control/field registers, signed SBOM/provenance and automated acceptance summaries without raw host/patient data. Keep assessment risk separate from security/privacy compliance status.
• Verification: independent reviewers can reproduce the release/control mapping using approved artifacts.
• Acceptance: useful review evidence, no automatic “HIPAA compliant,” “PHI-free” or “safe to retire” certification.

Approval gates and final disposition

1. Reconcile and identify the exact release and intended local execution model.
2. Privacy/data owners resolve P0-1 and approve the data boundary; an absolute no-PHI claim must be withdrawn unless actually established.
3. Close P0/P1 code and environment control gaps in a separately authorized change effort.
4. Validate the exact artifact on a synthetic isolated Windows matrix with least-privilege, filesystem/configuration/egress/logging evidence; complete native and dependency/security review.
5. CHS information security, privacy and operations accept documented residual risks and approve any narrowly scoped pilot. Any later production use still follows organizational authorization/change/incident requirements.

Current disposition: do not approve healthcare production deployment on the available evidence. No actual PHI incident, malicious code, intentional destructive collector or verified CVE has been established. Equally, absence of such evidence is not proof of PHI-free processing, zero writes, no network activity or HIPAA compliance.