You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Draft “initial contents” for Security Posture, Hardening, SBOM note, and HA brief



Below are concise, shippable first drafts you can paste into docs. They align with your SSoT features: RBAC, Secrets, Git-JSON config, Health/management APIs, and container-ready deployment.   



A) Security Posture (draft)



Overview

FrameworX is designed for industrial environments with RBAC, a built-in secrets vault, auditable operations, and configuration-as-code (Git-tracked JSON). All network services support TLS; platform health and management endpoints enable safe automation. 


Identity & RBAC


  • Built-in roles: Admin, Engineer, Operator, Viewer (custom roles allowed).

  • Permissions cover: project changes, runtime control, tag writes, alarm ACK, script execution, connector admin, user/role admin.

  • Least privilege defaults; deny-by-default on write operations.



Secrets Management


  • Credentials, keys, and connection strings stored as secret types, never inline in project JSON.

  • Secrets are encrypted at rest; retrieval occurs only at runtime by privileged services.

  • Rotate via API/CLI; all rotations are audited.



Audit Logging


  • Immutable logs for: auth events, role/permission changes, config commits, runtime writes (by user + origin), alarm actions, connector reconfigurations.

  • Export to SIEM (file/JSON/HTTPS).



Configuration as Code (Git JSON)


  • All configuration stored in Git-tracked JSON with branching, reviews, and signed commits.

  • CI checks: schema validation, secret-leak prevention, style/lint; deploy via approved pipeline. 



Network & Protocol Security


  • MQTT: TLS (server + optional client cert), broker ACLs; Sparkplug B topics namespace-scoped.

  • OPC UA: Sign+Encrypt with modern suites; truststore management documented.

  • HTTP APIs: TLS only; tokens short-lived; per-role routes.



Operations & Monitoring


  • Health and management APIs expose liveness/readiness, queue depths, driver states, and last config commit; integrate with Prometheus/OTEL exporters. 



Vulnerability & Patch


  • Monthly security bulletin; CVE watching for bundled components; emergency out-of-band updates for critical issues.





B) Hardening Guide (draft checklist)



Before install


  • Place runtimes on isolated VLANs; restrict inbound to OPC UA, MQTT, HTTPS only.

  • Prepare non-interactive service accounts; implement time-bound admin access.



Install


  • Use container images or signed installers; validate checksums.

  • Provide certs (server + client) and broker ACLs before enabling MQTT/OPC UA.



Post-install


  • Change all defaults; create RBAC roles with least privilege; enforce MFA for Admin.

  • Disable unused drivers/connectors; set write-rate limits and tag write approvals on OT zones.

  • Turn on audit to remote sink; set retention & rotation.

  • Lock down health/management endpoints to ops subnets only.

  • Configure backup & key escrow for project JSON and secrets.

  • Performance baselines: capture CPU/mem/disk IO and driver/messaging throughput at idle and under expected load (retain snapshot with project).

  • Quarterly re-hardening: rotate secrets, review roles, re-pin versions, renew certs.





C) SBOM Note (draft)



Scope

We publish an SBOM for FrameworX runtimes and standard connectors each GA release using CycloneDX (JSON) with component name, version, source, license, and hash.


Generation & Distribution


  • SBOM generated in CI at build time; signed and shipped alongside installers and container images.

  • Public SBOM page lists versions with hashes and known advisories.



Vulnerability Handling


  • Continuous scans map SBOM components to CVEs; monthly advisories; critical CVEs come with mitigations and timelines.



Customer Use


  • Import SBOM into third-party scanners; verify hashes; subscribe to advisories feed.





D) High Availability Brief (draft)



Offer & licensing

HA is supported via a Primary + Standby topology; standby is licensed at +50% of the selected edition.   


Architecture


  • Nodes share project configuration via Git JSON; stateful services (historian, alarms) use write-ahead logs + store-and-forward to prevent loss.

  • Failover: health heartbeats; on primary loss, standby assumes virtual IP / broker role; split-brain avoided via fencing/quorum.

  • RPO/RTO targets (typical): RPO ≤ 30s with store-and-forward; RTO 60–120s depending on driver count and historian size.



Prereqs


  • Shared DNS or VIP, synchronized time (NTP), mirrored secrets vault, identical versions and drivers, tested broker/OPC UA cert sets.



Testing & Ops


  • Quarterly switchover tests; validate alarm resume, historian continuity, MQTT session resumes (Sparkplug lifecycle).

  • Monitor audit for failover events; export health metrics to your monitoring system.



Limits (document transparently)


  • Long-running custom scripts may restart on failover; confirm idempotency.

  • For remote sites with unstable links, consider EdgeConnect autonomy plus eventual federation to enterprise UNS. 


  • No labels