Beim Durchsehen der Newton-Protocol-Richtlinien wurde Folgendes deutlich:
default allow := false wirkt streng – aber es stellt kein garantiert strenges System dar.
Eine Richtlinie wird erst dann sicher, wenn jeder mögliche „allow“-Pfad sorgfältig eingeschränkt wird.
Der gefährliche Teil ist nicht die Fallback-Verweigerung. Der gefährliche Teil ist die Annahme, dass eine alleinige Verweigerung beweist, dass die Richtlinie konservativ ist.
Eine einzelne, weit gefasste Ausnahme kann die beabsichtigten Schutzmaßnahmen leise außer Kraft setzen. Ein Administrator-Bypass, eine unvollständige Validierung oder eine überstürzt erlassene temporäre Regel kann aus einer „secure-by-default“-Richtlinie eine permissive machen.
Darum lebt echte Sicherheit nicht in der Default-Aussage. Sie steckt in jeder Bedingung, die eine Genehmigung zurückgeben kann.
Im Bereich der Richtlinien-Engineering definiert die schwächste „allow“-Regel gewöhnlich die tatsächliche Vertrauensgrenze.
#NewtonProtocol #NEWT #CyberSecurity #Rego
$NEWT
default allow := false wirkt streng – aber es stellt kein garantiert strenges System dar.
Eine Richtlinie wird erst dann sicher, wenn jeder mögliche „allow“-Pfad sorgfältig eingeschränkt wird.
Der gefährliche Teil ist nicht die Fallback-Verweigerung. Der gefährliche Teil ist die Annahme, dass eine alleinige Verweigerung beweist, dass die Richtlinie konservativ ist.
Eine einzelne, weit gefasste Ausnahme kann die beabsichtigten Schutzmaßnahmen leise außer Kraft setzen. Ein Administrator-Bypass, eine unvollständige Validierung oder eine überstürzt erlassene temporäre Regel kann aus einer „secure-by-default“-Richtlinie eine permissive machen.
Darum lebt echte Sicherheit nicht in der Default-Aussage. Sie steckt in jeder Bedingung, die eine Genehmigung zurückgeben kann.
Im Bereich der Richtlinien-Engineering definiert die schwächste „allow“-Regel gewöhnlich die tatsächliche Vertrauensgrenze.
#NewtonProtocol #NEWT #CyberSecurity #Rego
$NEWT