To revisionsspørgsmål lyder ens og kræver forskellige slags bevis. Hvilken session der kontaktede denne adresse, kan besvares ud fra forbindelses- og flowposter. Hvilken person der åbnede denne side, kan normalt ikke, i det mindste ikke ud fra de poster. At vælge en indsamler før spørgsmålet er valgt, er hvordan et netværksteam ender med at præsentere et hostname som en browserhistorik.

Begynd med den hændelse, revisionen skal fastslå

Skriv spørgsmålet som en sætning med subjekt, verbum og tid. Alene den disciplin blotlægger kløften mellem en sessionspost og en sidevisning. En sessionslog fastslår, at en identitet blev accepteret i et interval med en tildelt adresse under en registreret politik, og den kan ikke fastslå, hvilken side nogen læste, fordi den aldrig så anmodningen.

Navngiv observationen, før indsamlingen designes. Et felt opkaldt efter et besøgt websted, som faktisk gemmer et opløst navn, er en fremtidig fejl snarere end en bekvemmelighed. Feltnavne lever længere end de mennesker, der valgte dem, så vælg nogle, der beskriver beviset snarere end konklusionen.

Hvad hver post kan og ikke kan understøtte

Fire posttyper optræder i næsten ethvert revisionsdesign, og hver svarer på et forskelligt spørgsmål. Hold dem adskilt i rapporten såvel som i pipelinen, fordi blanding af dem er, hvordan et forsvarligt fund bliver et pinligt et.

The question being askedRecord that can answer itWhat that record provesWhat still needs a join
Was this address contacted?Flow recordThe connection five-tuple and when it was seenWhich session held the address at that moment
Which account held that address?Session logWhich identity authenticated and the tunnel address it receivedWhich device or person used that account
Was this name looked up?Resolver queryThat this resolver was asked for this nameWhether a page was fetched, and by whom
Was this page viewed?Proxy or application transactionThe request and identity recorded inside that application's scopeTraffic outside that application's visibility
Who was the person?None of the four on its ownAn account in use, at bestA named human, whenever accounts are shared

Læs den sidste kolonne lige så omhyggeligt som den midterste. En flowpost beskriver adresser og porte, og et omvendt opslag på en adresse genskaber ikke det navn, en browser brugte, fordi én adresse kan være vært for mange ubeslægtede websteder. En resolverforespørgsel beviser, at et spørgsmål blev stillet, ikke at en side blev vist. Et hostname, der er synligt under en TLS-forhandling, er heller ikke den krypterede anmodningssti.

Hver af disse er en rigtig observation, og ingen af dem er den observation, folk forventer. En browser, der insisterer på sin egen krypterede resolver, ligger uden for det overvågede område, og analyse kan ikke genskabe, hvad logningen aldrig så. Den kløft hører hjemme i rapporten som en angivet begrænsning og ikke som en fodnote.

Foregribende opslag og cachede svar

Browsere opløser navne på forhånd, nogle gange uden at indlæse noget som helst. De svarer også fra cachen uden at sende en ny forespørgsel til den resolver, du overvåger, hvilket betyder, at fraværet af en forespørgsel ikke er fraværet af et besøg. Begge adfærdsmønstre bryder den naive ligning mellem en DNS-log og en browserhistorik.

DNS over HTTPS tilføjer en anden grænse: en browser eller en gæsteapplikation med sin egen resolver spørger aldrig organisationens logger om noget. Præcise transaktioner kommer kun fra applikationens egne hændelser eller fra en proxy, hvis logning du udtrykkeligt understøtter. En almindelig HTTPS CONNECT-tunnel efterlader proxyen uden noget som helst indblik i sidestierne indeni. At eje netværket er ikke tilladelse til stille at udskifte applikationens tillidsmodel.

Adressen tilhører en session, ikke en person

En flowpost med en adresse fra tunnelområdet er et udgangspunkt snarere end et svar. Sammenkobl den adresse og det tidsstempel med den sessionstildeling, der var aktiv i det øjeblik, fordi den adresse kan blive tildelt en anden session en time senere. Statisk adressering er én måde at bevare den sammenhæng på og ikke den eneste.

Når et oversættelsestrin presser flere enheder sammen til én kildeadresse opstrøms for sensoren, kan sammenkoblingen kun navngive den delte gateway-session. En delt konto eller et certifikat, der bruges af flere personer, begrænser tilskrivningen, uanset hvor komplette netværksdata ser ud. Begge hører hjemme i rapporten som begrænsninger snarere end som forbehold for senere.

Registrer tidszonen, urkilden, observationspunktet og hver oversættelsesgrænse indimellem. Fravær fortjener samme omhu som tilstedeværelse, fordi en manglende post kan betyde, at en flowpost er udløbet, at en sensor aldrig så pakken, eller at en applikationslog blev slået fra.

Design til det angivne formål, og bevis så pipelinen

Når spørgsmålet er fastlagt, skal du definere, hvilke felter der er nødvendige, hvem der må læse dem, og hvor længe de gemmes. At indsamle mere, fordi lagring er billigt, skaber en forpligtelse, der overlever undersøgelsen. Privatlivsmodellen i RFC 6973 betragter korrelation, fejltilskrivning og unødvendig indsamling som designproblemer snarere end eftertanker.

Beskyt kortlægningen og posterne som ét objekt, fordi hver for sig er langt mindre følsom end parret. Validér derefter designet mod aktivitet, du har tilladelse til at generere og allerede forstår, med den mindste forespørgsel, som rapporten vil hvile på. En pipeline, der ikke kan genskabe en kendt hændelse, genskaber heller ikke en ukendt. Rapportér den hændelse, beviserne understøtter, med de ord, beviserne tillader, og lad læseren selv nå den større konklusion.

Skriv begrænsningerne ved siden af fundet: hvad der blev sammenkoblet, hvad der blev oversat, og hvilken log der forblev tavs. Et fund, der angiver sine egne grænser, overlever en gennemgang, som et selvsikkert resumé ikke gør. Det er forskellen mellem bevis og en historie om bevis.

Relaterede artikler