Protéger les données pendant leur déplacement.
CC6.7 concerne la restriction et la protection de la transmission et du déplacement des données : les données en transit doivent être protégées, et le déplacement des données hors d'une limite doit être contrôlé. Une grande partie de cela est décidée par la configuration du transport et par l'endroit où de nouveaux flux de données sont connectés, ce qui en fait une préoccupation liée aux pull requests.
The shapes the same control failure takes.
CC6.7 est affaibli lorsqu'un transport cesse d'être protégé ou lorsque des données commencent à se déplacer vers un nouvel endroit sans les contrôles attendus. Les formes récurrentes :
Une version TLS minimale est abaissée
Une version TLS minimale est réduite, une exigence de chiffrement fort est assouplie, ou une rétrogradation devient possible sur un chemin transportant des données sensibles.
Un saut interne passe en texte brut
Un appel de service à service transportant des données sensibles est modifié pour utiliser HTTP non sécurisé, ou un point de terminaison interne cesse d'exiger TLS, sous l'hypothèse que le réseau est de confiance.
La vérification des certificats est désactivée
La vérification est désactivée pour contourner un problème de certificat, de sorte que le canal n'est plus authentifié et peut être intercepté.
Une nouvelle exportation envoie des données à l'extérieur
Un webhook, une synchronisation ou une intégration tierce commence à déplacer des données hors de sa limite sans les contrôles attendus par le critère sur ce déplacement.
Un champ protégé devient journalisable
Des données sensibles qui étaient exclues d'un transport commencent à être envoyées vers un récepteur (un expéditeur de logs, un pipeline d'analyse) qui n'était pas prévu pour les transporter.
Un appel interne qui bascule vers HTTP non sécurisé.
Un nouveau client interne est ajouté pour un service qui expose à la fois HTTP et HTTPS. Pour le faire fonctionner rapidement, l'appel est connecté au port HTTP non sécurisé. Cela fonctionne, et la charge utile sensible qu'il transporte traverse désormais le réseau sans protection.
- const BILLING_URL = "https://billing.internal:8443"+ const BILLING_URL = "http://billing.internal:8080"const res = await post(`${BILLING_URL}/charge`, { card, amount })La charge utile traverse désormais le réseau en texte brut. CC6.7 exige que les données en transit soient protégées, et 'c'est seulement le réseau interne' n'est pas le contrôle décrit par le critère. Pointez le client vers le point de terminaison HTTPS et maintenez TLS sur chaque saut transportant des données sensibles.
La protection en transit est vérifiée de bout en bout.
Un évaluateur ne se contente pas de confirmer que vos points de terminaison publics utilisent TLS ; il examine où les données sensibles se déplacent et si elles sont protégées tout au long du trajet, y compris les sauts internes et les nouvelles intégrations. Un seul appel discrètement passé en HTTP non sécurisé, ou une nouvelle exportation sans contrôles, est le type de faille qu'une revue de configuration révèle. Le changement qui l'a introduit était un diff, ce qui est l'endroit le moins coûteux pour l'intercepter.
Une revue, pas un audit réseau.
heygrc signale les modifications qui concernent CC6.7 et cite le critère afin que la correction ait lieu dans la pull request. Il ne cartographie pas toute la topologie de vos flux de données ni n'exécute votre évaluation. Il détecte le moment où un transport cesse d'être protégé, au niveau du diff.