docs: require air-gapped deployment and add switch hardening guidance - #58
Open
sunilnom wants to merge 2 commits into
Open
docs: require air-gapped deployment and add switch hardening guidance#58sunilnom wants to merge 2 commits into
sunilnom wants to merge 2 commits into
Conversation
Threat modelling shows most identified attacks require in-band access to
the TX host, and that the air gap is the only control protecting content
confidentiality on the ST 2110-20 path. The previous wording
("network-isolated", "isolation") was too weak to convey this.
- State air-gapping as a hard requirement in README, Security.md and the
assumptions document
- Define what an air gap is and list what does not count (VLAN on a
shared switch, firewall/ACL, jump host, enabled BMC, gated SSH)
- Add deployment assumption: no in-band management access to the TX host
- Add switch hardening requirements (port security, blackhole VLAN for
disabled ports, DTP off, IGMP snooping, storm control, BPDU/root
guard, DHCP snooping/DAI, switch management plane)
- Add controlled ingress guidance for configuration and video content,
which becomes the primary untrusted input path once air-gapped
- Record missing security properties: no config signing/versioning, no
video source integrity, no tamper-evident logging
- Add residual risk rows for content substitution, log tampering and
unattributable console changes
- Add a commissioning validation checklist
Review feedback was that the previous wording read as an external assessment of the code rather than product documentation, and understated the controls the application does implement. - Lead with the layered security model and describe transport-level limits as a property of the ST 2110 standards, common to all ST 2110 equipment, rather than as a gap in this implementation - Present air-gapping as the recommended deployment model for a secure installation instead of a hard requirement; rename switch hardening from requirements to recommendations - Replace the "security properties not provided" list with a section describing the controls dvledtx implements (parse-time validation, symlink rejection, log path restriction, decoder watchdog, source size cap, signal-safe shutdown, static analysis, fuzzing, CVE tracking) and a section attributing the remaining properties to the deployment or to procedure - Expand the accepted risk note to state what has been accepted, for which deployment profile, what the outstanding adversarial-testing exercise covers, and what would change the position - Soften the residual risk framing to name the physical and procedural controls that handle each item
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Threat modelling shows most identified attacks require in-band access to the TX host, and that the air gap is the only control protecting content confidentiality on the ST 2110-20 path. The previous wording ("network-isolated", "isolation") was too weak to convey this.
Description
Checklist
Code Quality
Testing
Review Readiness
Documentation
Security
PR Type
What kind of change does this PR introduce?