Hoeveel onafhankelijke afhankelijkheden heeft uw privacyketen?

Tel de vakjes in de meeste privacydiagrammen en u krijgt drie of vijf hops, elk met het logo van een ander bedrijf. Tel de organisaties die daadwerkelijk op die vakjes kunnen handelen en het aantal valt vaak terug naar twee. Een keten scheidt vertrouwen alleen voor zover de afhankelijkheden onafhankelijk zijn, en een hopaantal meet daar niets van. Precies die kloof is de hele vraag die het stellen waard is.

Twee kaarten helpen. De ene volgt waar pakketten heen gaan; de andere legt vast wie elk element beheert, betaalt, administreert en tot handelen gedwongen kan worden. De tweede kaart is niet glanzend, meestal onvolledig en veel waarschijnlijker om een beslissing te veranderen.

Teken het verkeerspad, dan het controlespoor

Een gehuurde proxy voor twee tunneldiensten lijkt drie partijen. Schrijf hostingprovider, account van het controlepaneel, factuuridentiteit en het adres waarop een juridisch verzoek zou worden betekend op, en de drie kunnen terugvallen tot één cloudhuurder met één herstelmailbox. Niets aan het verkeerspad veranderde; de beschrijving van onafhankelijkheid wel.

Label elke rij als bekend, afgeleid of onbekend, en noteer waarop het label rust. Een merknaam stelt vast wie u de dienst verkocht. Het stelt niet vast wie de machine bezit, en zeker niet of klantgegevens in dezelfde database staan als de gegevens van een andere dienst.

De discipline is belangrijker dan de spreadsheet. Zodra «onbekend» een toegestane waarde is, houdt het diagram op zichzelf te vleien en begint het te tonen welk ontbrekend feit de conclusie zou omkeren.

Wat een hopaantal niet kan zien

Hops beschrijven inkapseling en doorsturen. Ze zeggen niets over gedeeld beheer, gedeelde upstream-transit, gedeelde betaalinstrumenten of gedeelde herstelkanalen, en juist die vier plekken zijn waar twee nominaal verschillende diensten stilzwijgend één worden.

Neem een ontwerp waarvan de eerste en laatste hop bij verschillende bedrijven horen maar beide achter dezelfde transitprovider zitten. Vanuit het standpunt van die provider reist een groot deel van de metadata over beide uiteinden door dezelfde infrastructuur. Dat is geen bewijs van identificatie; het is een afhankelijkheid die een hopaantal-samenvatting volledig weglaat.

De omgekeerde fout is even gangbaar. Aannemen dat gescheiden eigendom scheiding garandeert, negeert dat operators op dezelfde manieren worden gecompromitteerd, gedwongen of simpelweg nalatig zijn. Onafhankelijkheid wordt punt voor punt vastgesteld, niet verleend door een logo.

Een autonoom systeem is een routeringsgrens

Een AS-nummer identificeert een domein dat zijn peers een samenhangend routeringsbeeld presenteert. Die uitspraak gaat over routeringsbeleid, niet over bedrijfseigendom, personeel, jurisdictie of scheiding van inloggegevens. Twee diensten achter verschillende AS-nummers kunnen één eigenaar delen, en één dienst verspreid over meerdere AS-nummers is nog steeds één operator.

AS-nummers van een looking glass lezen is een redelijke eerste stap voor de transitrij van uw kaart. Het is geen meting van de route die uw verkeer op een bepaalde avond nam, en dat moet er ook niet van gemaakt worden. Waar de route onbekend is, schrijft u onbekend.

Vier rijen om voor elke hop in te vullen

Loop elk eindpunt door met dezelfde vier vragen in dezelfde volgorde, zodat hiaten zichtbaar blijven in plaats van te worden weggemiddeld door een zelfverzekerde samenvattende zin.

• Wie kan de inhoud lezen? Noem de partij die de beschermingslaag beëindigt en welke platte tekst of sleutels zij bezit.
• Wie kan de machine bedienen? Onderscheid de eigenaar van de infrastructuur van degene met consoletoegang, en controleer of die toegang met een andere dienst in de keten wordt gedeeld.
• Wiens gegevens kunnen het aan iets anders koppelen? Factuuridentiteit, hersteladres, supportaccount en betaalinstrument zijn de gebruikelijke bruggen.
• Wie beantwoordt een verzoek om gegevens? Identificeer de juridische entiteit en de jurisdictie waarin zij zetelt, en vraag dan welke gegevens die entiteit überhaupt bewaart.

Noteer vervolgens waar elk antwoord vandaan kwam: leveranciersdocumentatie, gepubliceerd beleid, directe observatie of een gevolgtrekking die u maakte omdat het alternatief ongemakkelijk was. Een rij die door een concrete bewaarverklaring wordt gestaafd, is sterker bewijs dan een rij die wordt gestaafd door het feit dat de website professioneel leek.

Wanneer een gedeelde afhankelijkheid echt telt

De privacyvraag is nooit of er een gedeelde afhankelijkheid bestaat, maar wat die afhankelijkheid zou kunnen verbinden. Gedeelde beheerderstoegang is een andere blootstelling dan passieve zichtbaarheid van versleuteld verkeer, en accountkoppeling verschilt van beide. Noem de observatie, het privilege en het bewaarde record voordat u iets concludeert.

De bespreking van waarnemers en correlatie in RFC 6973 geeft een bruikbare structuur: som op wat elke entiteit leert, en vraag dan wat het combineren van die kennis zou opleveren. Dat twee partijen vergelijkbare metadata waarnemen is een reden om correlatie te onderzoeken. Het is geen gemeten waarschijnlijkheid van identificatie, en het moet niet als zodanig worden gepresenteerd.

Uitgewerkt valt het voorbeeld met drie partijen uiteen in afzonderlijke bevindingen. Gedeelde hosting zonder gedeelde consoletoegang is een concentratie in de toeleveringsketen. Een gedeelde herstelmailbox is een administratieve brug. Beide zijn echt; alleen de tweede laat één compromis twee grenzen overschrijden.

Waarmee u eindigt is geen anonimiteitscertificaat. Het is een verdedigbare uitspraak over waar onafhankelijkheid werd geverifieerd, waar zij werd aangenomen en welk enkel feit uw mening zou veranderen. Dat is beter dan nog een pijl op het diagram.