Kan een VPN-log het browsegedrag tonen? Wat het bewijs aantoont
Een sessielog, een resolverquery en een stroomrecord bewijzen verschillende dingen. Kies de vraag, koppel identiteit en tijd, en zeg alleen wat is aangetoond.
Twee auditvragen klinken vergelijkbaar en vragen bewijs van verschillende aard. Welke sessie dit adres heeft benaderd, is te beantwoorden uit verbindings- en stroomrecords. Welke persoon deze pagina heeft geopend, is dat doorgaans niet, althans niet uit die records. Een verzamelaar kiezen voordat je de vraag kiest, is hoe een netwerkteam uiteindelijk een hostnaam als browsegeschiedenis presenteert.
Begin bij de gebeurtenis die de audit moet vaststellen
Schrijf de vraag als een zin met een onderwerp, een werkwoord en een tijd. Alleen die discipline al legt de kloof tussen een sessierecord en een paginaweergave bloot. Een sessielog stelt vast dat een identiteit werd geaccepteerd, voor een interval, met een toegewezen adres onder een vastgelegd beleid, en het kan niet vaststellen welke pagina iemand las, omdat het het verzoek nooit heeft gezien.
Label de waarneming voordat je de verzameling ontwerpt. Een veld dat is vernoemd naar een bezochte site maar feitelijk een opgeloste naam opslaat, is een toekomstige fout en geen gemak. Veldnamen leven langer dan de mensen die ze kozen, dus kies namen die het bewijs beschrijven en niet de conclusie.
Wat elk record wel en niet kan onderbouwen
Vier recordtypen komen in vrijwel elk auditontwerp voor, en elk beantwoordt een andere vraag. Houd ze gescheiden in het rapport én in de pijplijn, want ze door elkaar halen is hoe een verdedigbare bevinding gênant wordt.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
Lees de laatste kolom even aandachtig als de middelste. Een stroomrecord beschrijft adressen en poorten, en een reverse lookup van een adres reconstrueert niet de naam die een browser gebruikte, omdat één adres vele ongerelateerde sites kan huisvesten. Een resolverquery bewijst dat er een vraag is gesteld, niet dat er een pagina is getoond. Een hostnaam die zichtbaar is tijdens een TLS-onderhandeling is ook niet het versleutelde verzoekpad.
Elk daarvan is een echte waarneming, en geen ervan is de waarneming die mensen veronderstellen. Een browser die op zijn eigen versleutelde resolver staat, valt buiten het gecontroleerde bereik, en analyse kan niet terugvinden wat logging nooit heeft gezien. Die kloof hoort als uitgesproken beperking in het rapport en niet als voetnoot.
Speculatieve opzoekingen en antwoorden uit de cache
Browsers lossen namen vooraf op, soms zonder iets te laden. Ze antwoorden ook uit de cache zonder een nieuwe query naar de resolver te sturen die je in de gaten houdt, wat betekent dat het ontbreken van een query niet het ontbreken van een bezoek is. Beide gedragingen breken de naïeve vergelijking tussen een DNS-log en browsegeschiedenis.
DNS over HTTPS voegt een tweede grens toe: een browser of gastapplicatie met een eigen resolver vraagt de logger van de organisatie nooit iets. Exacte transacties komen alleen uit de gebeurtenissen van de applicatie zelf of uit een proxy waarvan je de logging uitdrukkelijk ondersteunt. Een gewone HTTPS CONNECT-tunnel laat de proxy geen zicht houden op de paginapaden erbinnen. Het netwerk bezitten is geen toestemming om het vertrouwensmodel van de applicatie stilzwijgend te vervangen.
Het adres hoort bij een sessie, niet bij een persoon
Een stroomrecord met een adres uit het tunnelbereik is een startpunt en geen antwoord. Koppel dat adres en die tijdsaanduiding aan de sessietoewijzing die op dat moment actief was, want dat adres kan een uur later aan een andere sessie worden toegewezen. Statische adressering is één manier om die associatie te bewaren en niet de enige.
Waar een vertaalstap meerdere apparaten samenvoegt tot één bronadres stroomopwaarts van de sensor, kan de koppeling alleen de gedeelde gatewaysessie benoemen. Een gedeeld account of een certificaat dat door meerdere mensen wordt gebruikt, beperkt de toeschrijving hoe volledig de netwerkgegevens er ook uitzien. Beide horen als beperkingen in het rapport en niet als voorbehoud voor later.
Leg de tijdzone, de klokbron, het waarnemingspunt en elke vertaalgrens daartussen vast. Afwezigheid verdient dezelfde zorg als aanwezigheid, want een ontbrekend record kan betekenen dat een stroomregel is verlopen, dat een sensor het pakket nooit heeft gezien of dat een applicatielog was uitgeschakeld.
Ontwerp voor het gestelde doel en bewijs daarna de pijplijn
Zodra de vraag vaststaat, bepaal je welke velden nodig zijn, wie ze mag lezen en hoe lang ze worden bewaard. Meer verzamelen omdat opslag goedkoop is, schept een last die het onderzoek overleeft. Het privacymodel in RFC 6973 ziet correlatie, verkeerde toeschrijving en onnodige verzameling als ontwerpproblemen en niet als bijzaak.
Bescherm de koppeling en de records als één object, want elk afzonderlijk is veel minder gevoelig dan het paar. Valideer het ontwerp daarna tegen activiteit die je mag genereren en al begrijpt, met de kleinste query waarop het rapport steunt. Een pijplijn die een bekende gebeurtenis niet kan reproduceren, zal een onbekende ook niet reproduceren. Rapporteer de gebeurtenis die het bewijs ondersteunt, in de woorden die het bewijs toelaat, en laat de lezer de grotere conclusie zelf trekken.
Schrijf de beperkingen naast de bevinding: wat is gekoppeld, wat is vertaald en welke log bleef stil. Een bevinding die haar eigen grenzen noemt, doorstaat een toets die een zelfverzekerde samenvatting niet doorstaat. Dat is het verschil tussen bewijs en een verhaal over bewijs.