Daten während der Bewegung schützen.
CC6.7 betrifft die Einschränkung und den Schutz der Übertragung und Bewegung von Daten: Daten während der Übertragung müssen geschützt werden, und die Bewegung von Daten außerhalb einer Grenze muss kontrolliert werden. Vieles davon wird durch die Transportkonfiguration und durch die Verknüpfung neuer Datenflüsse entschieden, was es zu einer Angelegenheit für Pull Requests macht.
The shapes the same control failure takes.
CC6.7 wird geschwächt, wenn ein Transport nicht mehr geschützt ist oder wenn Daten an einen neuen Ort bewegt werden, ohne die erwarteten Kontrollen. Die wiederkehrenden Muster:
TLS-Mindestversion wird herabgesetzt
Eine minimale TLS-Version wird gesenkt, eine Anforderung an starke Verschlüsselung wird gelockert oder ein Downgrade wird auf einem Pfad möglich, der sensible Daten überträgt.
Ein interner Hop wird unverschlüsselt
Ein Service-zu-Service-Aufruf, der sensible Daten übertrug, wird auf reines HTTP geändert, oder ein interner Endpunkt verlangt kein TLS mehr, in der Annahme, dass das Netzwerk vertrauenswürdig ist.
Zertifikatsprüfung wird deaktiviert
Die Überprüfung wird deaktiviert, um ein Zertifikatsproblem zu umgehen, sodass der Kanal nicht mehr authentifiziert ist und abgefangen werden kann.
Ein neuer Export sendet Daten aus
Ein Webhook, eine Synchronisation oder eine Integration eines Drittanbieters beginnt, Daten außerhalb seiner Grenze zu bewegen, ohne die Kontrollen, die das Kriterium für diese Bewegung erwartet.
Ein geschütztes Feld wird protokollierbar
Sensible Daten, die zuvor nicht über einen Transport gesendet wurden, werden nun an eine Senke (ein Log-Forwarder, eine Analyse-Pipeline) gesendet, die nicht dafür vorgesehen war, sie zu übertragen.
Ein interner Aufruf, der auf reines HTTP zurückfällt.
Ein neuer interner Client wird für einen Dienst hinzugefügt, der sowohl HTTP als auch HTTPS anbietet. Um ihn schnell zum Laufen zu bringen, wird der Aufruf mit dem reinen HTTP-Port verbunden. Es funktioniert, und die sensiblen Nutzlasten, die er überträgt, durchqueren das Netzwerk nun ungeschützt.
- const BILLING_URL = "https://billing.internal:8443"+ const BILLING_URL = "http://billing.internal:8080"const res = await post(`${BILLING_URL}/charge`, { card, amount })Die Nutzlast für die Belastung durchquert das Netzwerk nun im Klartext. CC6.7 erwartet, dass Daten während der Übertragung geschützt werden, und 'es ist nur das interne Netzwerk' ist nicht die Kontrolle, die das Kriterium beschreibt. Richten Sie den Client auf den HTTPS-Endpunkt und behalten Sie TLS auf jedem Hop, der sensible Daten überträgt.
Der Schutz während der Übertragung wird End-to-End geprüft.
Ein Prüfer bestätigt nicht nur, dass Ihre öffentlichen Endpunkte TLS verwenden; er prüft, wohin sensible Daten bewegt werden und ob sie den gesamten Weg über geschützt sind, einschließlich interner Hops und neuer Integrationen. Ein einzelner Aufruf, der leise auf reines HTTP umgestellt wurde, oder ein neuer Export ohne Kontrollen ist die Art von Lücke, die eine Konfigurationsprüfung aufdeckt. Die Änderung, die sie eingeführt hat, war ein Diff, und das ist der günstigste Ort, um sie zu erkennen.
Eine Prüfung, kein Netzwerk-Audit.
heygrc markiert Änderungen, die CC6.7 betreffen, und zitiert das Kriterium, damit die Korrektur im Pull Request erfolgt. Es erstellt keine vollständige Topologie Ihres Datenflusses oder führt Ihre Bewertung durch. Es erkennt den Moment, in dem ein Transport nicht mehr geschützt ist, im Diff.