Säkerhetsloggning

Beskriver säkerhetsloggen i Privera: vad som loggas, hur loggen skyddas mot ändring, hur organisationen styr den och hur den samlas in till SIEM. Säkerhetsloggen finns från version 0.9.0-beta20. Äldre versioner har bara exportloggen (avsnitt 9) och loggar inte stoppade exportförsök eller andra säkerhetshändelser. Dokumentet beskriver 0.9.0-beta22. Det som är nytt i den versionen står utskrivet. Licensserverns logg beskrivs i avsnitt 11.

1. Sammanfattning

2. Var loggen skrivs

Fil. En fil per dator och Windows-konto:

privera-sakerhetslogg-<DATORNAMN>-<konto>.jsonl

Tecken utanför A-Z a-z 0-9 . _ - blir _. Förvald katalog är programmets datamapp, %APPDATA%\privera-desktop\sakerhetslogg\. Med policyn SecurityLogDirectory skrivs filen i stället i den katalog organisationen anger, lokal eller UNC. Flera datorer kan dela en katalog, eftersom varje dator och konto har sin egen fil och sin egen kedja.

Går policyns katalog inte att skriva till (den saknas, nätet är nere eller behörighet saknas) skrivs loggen i den förvalda katalogen, och den första posten där är logg.skrivfel (fel). Den går också till händelseloggen. Filen i reservkatalogen har samma namn men en egen kedja som börjar på seq 1. När policyns katalog nås igen fortsätter policyfilens kedja där den slutade, och filen prövas mot sitt ankare (avsnitt 4).

Ankare. I programmets datamapp ligger ett ankare per dator och konto, sakerhetslogg-ankare-<DATORNAMN>-<konto>.json. Det minns, för varje loggfil som datorn och kontot har använt, löpnummer och hash för den senast skrivna posten, filens längd i byte och SHA-256 av hela filen efter programmets senaste skrivning, samt den senast använda filen och programversionen. Med roamande %APPDATA% skriver varje dator bara sitt eget ankare. Ankaret ligger aldrig i policyns katalog.

Loggfilen identifieras av sin verkliga sökväg på disk: junctions, symboliska länkar, subst och korta 8.3-namn löses upp, så att en annan stavning av samma katalog inte blir en annan fil. Nätverkssökvägar (UNC, mappade enheter) lämnas som de anges.

Windows händelselogg. Loggen Application, källan Privera. Varje post i filen skrivs också dit, med samma rad och radens egen hash. Posterna samlas i upp till 750 millisekunder och skrivs sedan i ett anrop till Windows PowerShell.

Exporten står i händelseloggen innan utfilen skrivs (från 0.9.0-beta22). Sist före motorn, efter programmets egna kontroller, skrivs export.paborjad (3006). Den skickas till händelseloggen direkt, och exporten väntar på kvittot från PowerShell, högst tio sekunder. Det gör exporten ungefär en sekund långsammare: i ett prov mot den riktiga händelseloggen fanns posten där 1,1 sekunder efter anropet. Varje påbörjad export följs av export.lyckad, export.stoppad eller export.lackkontroll_stopp. En påbörjad export utan slutpost betyder att programmet avslutades under exporten, till exempel genom att processen dödades, och då kan utfilen finnas.

Kommer inget kvitto inom tio sekunder fortsätter exporten, och posten skrivs till händelseloggen så snart det går. Med policyn RequireEventLogForExport = 1 vägras exporten i stället, och export.stoppad med orsak HANDELSELOGG skrivs i filen. Kravet gäller bara när händelseloggen är påslagen, och inte en start då registret inte gick att läsa (avsnitt 7.1). På en dator där händelseloggen inte fungerar, till exempel för att PowerShell är spärrat för användarna, vägras med policyn alla exporter. Varje export försöker då skriva till händelseloggen igen, och om PowerShell hänger väntar exporten upp till cirka tio sekunder innan den vägras. Pröva därför att händelseloggen fungerar innan policyn sätts.

När loggen startar. Direkt när programmet har startat. Händelser under de första millisekunderna, till exempel licensens första bedömning, hålls i minnet och skrivs efter startposten med sin egen tidpunkt.

3. Format

En rad per post, UTF-8, radslut \n (aldrig \r\n). Nyckelordningen är fast.

{"v":1,"seq":42,"tid":"2026-10-05T07:41:12.311Z","kod":"export.stoppad","id":3001,"niva":"varning","app":"0.9.0-beta20","dator":"KOMMUN-PC17","konto":"anna.handlaggare","data":{"steg":"fore_motor","orsak":"KALLFIL_ANDRAD","dokumenttyp":"pdf","kalla_sha256":"9f2c…"},"prev":"5be1…"}

4. Hashkedjan och hur den kontrolleras

Varje post bär hashen av raden före. Radens egen hash står inte i raden; den bärs av nästa post och skickas med till händelseloggen. Det ger:

• En ändrad post, även ett enda blanksteg, bryter länken till nästa rad.
• En borttagen eller omkastad post bryter länken och löpnumret.
• Borttagna poster i början syns på att första raden inte börjar kedjan.
• En fil som sparats om med Windows radslut syns på första raden efter den första.

Kedjan ensam visar inte att de sista posterna har tagits bort, att hela filen har skrivits om med nyräknade hashar eller att en korrekt länkad post har lagts till sist. Därför finns två skydd till.

Ankaret. Vid varje start jämförs filen med sitt ankare, även om loggen emellan har skrivits på en annan plats (reservkatalogen, eller en annan dator med samma roamande profil). Saknas filen, är den kortare än ankaret, eller har posten som ankaret pekar på ändrats, skrivs logg.kedjebrott med orsak fil_saknas, fil_kortad eller ankarpost_andrad. Börjar filen inte med exakt de byte programmet har skrivit, rapporteras första brottet i filen, eller fil_andrad om kedjan ändå håller. Hela rader efter programmets senaste skrivning som programmet inte skrev ger frammande_rad, även när de länkar korrekt. En krasch lämnar högst en ofullständig rad, aldrig en hel. Kedjan fortsätter sedan från filens sista rad. Den som raderar både filen och ankaret syns inte i filen, men mot SIEM. En fil som aldrig har använts på datorn förut prövas bara mot sin egen kedja.

Ankaret ligger i användarens egen datamapp och har ingen hemlighet. Det skyddar mot den som bara kommer åt loggfilen, till exempel med rätten att lägga till data i katalogen i avsnitt 7.2. Användaren själv kan räkna om ankaret. Mot användaren är skyddet att posterna redan finns i SIEM.

Händelseloggen. Samma poster ligger i Windows händelselogg. Där kan användaren inte ta bort enskilda poster, men en vanlig användare kan skriva så många poster till loggen Application att äldre poster skrivs över när loggen når sin maxstorlek, och en administratör kan rensa loggen. Samlar organisationen in händelseloggen till SIEM kan användaren inte ändra det som redan har samlats in. Skyddet beror alltså på att insamlingen sker innan posterna hinner skrivas över.

Ett brott rapporteras en gång, så länge resten av filen är orörd. En rad som avbröts vid ett strömavbrott ger ett logg.kedjebrott vid nästa start, inte vid varje start. Ändras något i filen efteråt rapporteras första brottet på nytt. Ett nytt logg.kedjebrott med samma rad som ett tidigare betyder alltså att filen har ändrats igen. Den post som står närmast före en trasig rad skyddas inte av länkningen; den finns kvar i händelseloggen.

Verifieringsskript

Itha AB har ett verifieringsskript för Windows PowerShell 5.1 som jämför filen med händelseloggen eller med det SIEM har tagit emot. Det kräver ingen installation och ändrar ingenting. Skriptet lämnas ut på begäran till [email protected].

powershell -NoProfile -ExecutionPolicy Bypass -File .\Verifiera-PriveraSakerhetslogg.ps1 `
  -Path '\\loggserver\privera$\privera-sakerhetslogg-KOMMUN-PC17-anna.handlaggare.jsonl'

# På datorn själv: jämför också med händelseloggen
.\Verifiera-PriveraSakerhetslogg.ps1 -Path <fil> -JamforHandelselogg

# Med senaste hash som SIEM har tagit emot
.\Verifiera-PriveraSakerhetslogg.ps1 -Path <fil> -ForvantadSistaSha256 <hex>

# Med de poster SIEM har tagit emot (en postrad per rad, i mottagningsordning),
# och var programmet skriver filen
.\Verifiera-PriveraSakerhetslogg.ps1 -Path <fil> -MottagnaPoster .\siem-export.jsonl `
  -Loggfil '\\loggserver\privera$\privera-sakerhetslogg-KOMMUN-PC17-anna.handlaggare.jsonl'

Vid jämförelsen delas de mottagna posterna i kedjor efter hur de länkar. Samma dator och konto kan ha flera kedjor med samma filnamn, till exempel policyfilen och filen i reservkatalogen. Varje app.start bär loggfilens identitet (loggfil, SHA-256 av filens verkliga sökväg). Den är densamma för en fil som har raderats och skapats om.

Ange -Loggfil. Identiteten i filens egna app.start kan användaren skriva själv, eftersom källan Privera är öppen för alla (avsnitt 7.3). Med -Loggfil anger administratören var programmet skriver filen, som sökvägen ser ut på användarens dator: policyns katalog eller C:\Users\<konto>\AppData\Roaming\privera-desktop\sakerhetslogg, plus filnamnet. Ange den verkliga katalogen, inte en junction, ett kort 8.3-namn eller en mappad enhetsbokstav för en lokal katalog. -Path får vara en kopia. Utan -Loggfil tas identiteten ur filen, och varje kedja med en annan identitet fäller kontrollen.

Skriptet fäller kontrollen när:

• en mottagen post saknas i filen (HandelserSomSaknasIFilen),
• en mottagen kedja med filens identitet saknas helt i filen, alltså när filen har raderats och skapats på nytt (KedjorSomSaknasIFilen),
• en app.start i filen har en annan identitet än -Loggfil (StartposterMedAnnanLoggfil): filen är omskriven, eller -Loggfil är fel angiven,
• en mottagen kedja har en annan identitet och -Loggfil saknas (AndraKedjor, AndraKedjorKraverLoggfil),
• en mottagen kedja utan poster i filen inte går att knyta till någon loggfil (KedjorUtanLoggfil); exportera då ett längre tidsfönster,
• en post i filen saknas hos mottagaren fast mottagaren har poster både före och efter den (PosterSomSaknasHosMottagaren): posten är inlagd i filen utanför programmet, eller nådde aldrig händelseloggen,
• programmet självt har skrivit logg.kedjebrott i filen (KedjebrottIFilen), även när kedjan efter brottet håller,
• filen har poster men ingen mottagen kedja motsvarar den (IngenKedjaMotsvararFilen): filen kan vara omskriven i sin helhet.

Med -Loggfil räknas en kedja med en annan loggfil, till exempel reservkatalogens, i AndraKedjor utan att fälla kontrollen. Poster efter den sista mottagna redovisas i PosterEfterSistaMottagna men fäller inte, eftersom insamlingen kan ligga efter. Exportera alla händelser från källan Privera för datorn, inte ett urval av händelse-ID.

Jämförelsen visar borttagna poster och poster som bara finns i filen. Den visar inte att en post som finns både i filen och i händelseloggen skrevs av programmet.

Utgångskod 0 betyder att kedjan håller och jämförelserna stämmer, 1 brott eller avvikelse (första felet anges med radnummer), 2 att filen inte gick att läsa och 3 att PowerShell körs i Constrained Language Mode. Skriptet kräver FullLanguage. Under AppLocker eller WDAC körs det på en administrativ arbetsstation eller tillåts i policyn.

Skriptet är provat mot programmets egen kedja, en ändrad post, en borttagen sista post, två loggplatser med samma filnamn, en fil som har raderats och skapats om (också via en junction), en fil omskriven med påhittad identitet och en korrekt länkad post som lagts in i filen men inte nått SIEM.

Kontroll i SIEM. Varje händelse i händelseloggen bär raden och sha256=<radens hash>. Kedjorna följs per dator och konto: varje händelse ska ha en prev som är sha256 för en tidigare mottagen händelse från samma dator och konto, eller 64 nollor och seq 1, vilket är början på en ny kedja (en ny loggplats, se logg.plats_andrad och loggkatalog i app.start). En prev som inte motsvarar någon mottagen händelse betyder att en post saknas i insamlingen, att filen är raderad eller kortad, eller att en post har lagts in i filen utanför programmet. Två händelser med samma prev betyder att filen har kortats och skrivits vidare. Villkoret "nästa händelse har prev lika med föregående hash" ger falsklarm när datorn växlar mellan policyns katalog och reservkatalogen.

5. Händelsekoder

Händelse-ID:n är stabila: en kod byter aldrig ID, och nya koder får nya ID.

Orsaker i export.stoppad

LACKKONTROLL har en egen händelse (3002), så att SIEM kan larma på just den.

6. Vad som aldrig loggas

Varje händelse har en fast lista med typade fält: sant eller falskt, antal, SHA-256, versionsnummer eller ett värde ur en fast lista. Det finns inga fritextfält. Ett fält som inte står i listan, eller ett värde av fel typ, kommer inte in i posten; det räknas i avvisade_falt. Därför står aldrig följande i säkerhetsloggen:

• dokumentinnehåll, fyndens text, etiketter eller sidpositioner,
• filnamn och sökvägar, inte heller hashade, eftersom ett filnamn går att gissa fram ur sin hash. Enda undantaget är säkerhetsloggens egen fil: loggfil i app.start är SHA-256 av dess sökväg, som består av loggkatalogen samt datornamn och konto, som redan står i posten,
• felmeddelanden, eftersom de kan bära filnamn och sidnummer,
• licensnyckel, e-post, licens-id eller maskin-id.

Dokument identifieras med SHA-256 av filens innehåll, samma värde som i exportloggen. Innehållet går inte att räkna fram ur hashen, men den som har en fil kan visa om det var just den som exporterades.

Det som är personuppgift i posten är Windows-kontots namn och datornamnet. De finns med för att loggen ska kunna svara på vem som gjorde vad.

Automatiska tester planterar personnummer, namn, sökvägar och felmeddelanden i varje exportväg och kontrollerar att inget av det hamnar i fil eller händelselogg.

7. Organisationens inställningar

7.1 Policy i registret

Nyckeln HKLM\Software\Policies\Privera läses vid start med reg.exe (64-bitarsvyn). Nyckeln är bara skrivbar för administratörer.

Från 0.9.0-beta22 startar programmet reg.exe, och Windows PowerShell för händelseloggen och för signaturkontrollen av uppdateringar, med full sökväg i katalogen System32 under Windows-katalogen. Katalogen tar programmet ur den plats som Windows laddade systembiblioteket ntdll.dll från, inte ur miljövariabeln SystemRoot, och programmen startas med en egen, minimal miljö i stället för processens. Variabler som SystemRoot och PSModulePath styr alltså inte längre vilket program som svarar eller vilken kod PowerShell laddar.

Före 0.9.0-beta22 togs katalogen ur SystemRoot, som programmet ärver från den som startar det. En användare som kunde köra egna program kunde därför låta ett annat program svara i stället för reg.exe eller PowerShell, och på så sätt få programmet att använda andra policyvärden eller att inte skriva till händelseloggen. I de versionerna kan den signerade programfilen dessutom användas för att köra egen kod (se IT-drift avsnitt 4.1).

Registerpolicyn är ändå en styrning för vanlig användning, inte ett skydd mot en användare som avsiktligt vill kringgå den. I en installation per användare kan användaren byta ut programmets filer (se IT-drift avsnitt 4.1), och en katalog av typen REG_EXPAND_SZ i SecurityLogDirectory expanderas med användarens egna miljövariabler.

Ett värde av fel typ ignoreras och förvalet gäller (utom för UpdateMode, se tabellen); antalet står i app.start som ogiltiga_policyvarden. Saknas nyckeln gäller förvalen. Gick registret inte att läsa (tidsgräns på fem sekunder, eller reg.exe saknas eller startar inte) gäller förvalen för loggningen, aldrig avstängd logg, men "Rensa mappen" nekas och app.start får policy_lasfel = true. Förvalen gäller då också RequireEventLogForExport, så kravet på kvitto gäller inte den starten. "Rensa mappen" väntar också in policyn: har den inte lästs inom tio sekunder från klicket nekas rensningen.

reg add HKLM\Software\Policies\Privera /v SecurityLogDirectory /t REG_SZ /d "\\loggserver\privera$" /f
reg add HKLM\Software\Policies\Privera /v AllowClearExportLogs /t REG_DWORD /d 0 /f

Samma värden kan sättas med grupprincip eller Intune, med ADMX-mallen som beskrivs i IT-drift avsnitt 6 eller som registerinställning. Policyn läses vid start, och en ändring gäller från nästa start.

AllowClearExportLogs=0 stoppar bara programmets egen rensning. Filer kan fortfarande tas bort i Utforskaren om användaren har behörighet till mappen.

7.2 Append-only-katalog för loggfilen

Programmet öppnar loggfilen bara för tillägg. Då räcker rätten att lägga till data (Append Data), och organisationen kan neka användaren rätten att skriva om, radera eller byta namn på filen. Katalogen ska skapas av en administratör, så att användaren inte äger den.

mkdir C:\ProgramData\Privera\Sakerhetslogg
icacls C:\ProgramData\Privera\Sakerhetslogg /inheritance:r ^
  /grant:r "SYSTEM:(OI)(CI)F" "BUILTIN\Administratörer:(OI)(CI)F" ^
  /grant:r "BUILTIN\Användare:(RX,WD,AD)" ^
  /grant:r "BUILTIN\Användare:(OI)(IO)(RX,AD,WA,WEA)" ^
  /grant:r "*S-1-3-4:(OI)(IO)(RX,AD,WA,WEA)"

S-1-3-4 (Ägarrättigheter) tar bort den rätt att ändra behörigheten som filens ägare annars har. På en svensk Windows heter grupperna BUILTIN\Administratörer och BUILTIN\Användare. SID:erna *S-1-5-32-544 och *S-1-5-32-545 fungerar på alla språk.

Provat på ett administratörskonto utan förhöjning (UAC-filtrerad token), inte på ett rent standardkonto: programmets sätt att skriva skapade filen och lade till rader, medan överskrivning, radering och namnbyte nekades, och kontot kunde inte ändra filens behörighet. Resultatet bör gälla ett standardkonto likadant, men det är inte provat. Att användaren inte heller kan ändra katalogens behörighet förutsätter att katalogen ägs av en administratör. Det är inte provat.

7.3 Registrering av händelsekällan

Registreringen är valfri och kräver administratör en gång. Programmet skriver till händelseloggen utan administratörsrätt och utan registrering. Oregistrerat visar Loggboken raden "Beskrivningen för händelse-ID … hittades inte", men källa, ID, nivå och posten (i EventData) är korrekta, och det är det SIEM läser.

Registreras källan vid utrullningen visas posten som meddelandetext:

New-EventLog -LogName Application -Source Privera

Constrained Language Mode (AppLocker, WDAC). Utan registrerad källa skriver programmet via Add-Type, som är spärrat där. Efter tre misslyckade försök i rad skrivs logg.handelselogg_fel, och programmet väntar sedan 5 sekunder, 30 sekunder, 2 minuter och därefter 5 minuter mellan nya försök. En export gör alltid ett nytt försök direkt. Under en lång störning hålls högst 2 000 poster i kö till händelseloggen; äldre poster faller då bort ur kön till händelseloggen men står kvar i filen, om filloggen är på. Före 0.9.0-beta22 slutade programmet försöka för resten av sessionen. I låsta miljöer behöver källan registreras. Med registrerad källa anropar programmets PowerShell-skript inga .NET-metoder före Write-EventLog. Det är provat i en PowerShell-session i Constrained Language Mode med Write-EventLog utbytt mot en provfunktion: id, nivå och text kom fram tecken för tecken, även å, ä, ö, radbrytningar och citattecken. Det är inte provat under en riktig AppLocker- eller WDAC-policy med registrerad källa, och inte heller att en standardanvändare kan skriva till en registrerad källa.

Vem som kan skriva med källan Privera. Att programmet kan skriva utan administratörsrätt betyder att varje användare kan det, med eller utan registrerad källa. En händelse med källan Privera bevisar alltså inte att programmet skrev den. Det som går att lita på är att det som organisationens SIEM har samlat in inte kan tas bort av användaren. I den lokala händelseloggen kan användaren inte ta bort enskilda poster, men kan få äldre poster att skrivas över, och en administratör kan rensa loggen. Ingen av dem visar att en post är äkta (avsnitt 4).

Installern registrerar inte källan, eftersom den förvalt körs utan administratörsrätt. Lägg raden i organisationens utrullningsskript (Intune, Configuration Manager eller grupprincip). Ett exempel står i IT-drift avsnitt 2.5.

8. Så läser SIEM loggen

Exemplen i avsnittet är inte provade. Insamlingen är inte provad med Windows Event Forwarding, Microsoft Sentinel, Splunk eller något annat SIEM.

Windows händelselogg (rekommenderat). Samla in loggen Application med filtret källa Privera. Med Windows Event Forwarding:

<QueryList><Query Id="0" Path="Application">
  <Select Path="Application">*[System[Provider[@Name='Privera']]]</Select>
</Query></QueryList>

Microsoft Sentinel (Azure Monitor Agent, datainsamlingsregel med samma XPath) lägger händelserna i tabellen Event:

Event
| where Source == "Privera"
| extend Rad = tostring(split(RenderedDescription, "\nsha256=")[0])
| extend Post = parse_json(extract(@"(\{.*\})", 1, Rad))
| project TimeGenerated, Computer, EventID, Kod = tostring(Post.kod), Seq = toint(Post.seq), Konto = tostring(Post.konto), Data = Post.data

Hur RenderedDescription och EventData ser ut beror på om källan är registrerad och på agenten. Kontrollera mot en första insamlad händelse. Med oregistrerad källa är nivåns namn tomt, eftersom ingen meddelandefil finns. Filtrera därför på nivåns tal (Level: 2 = fel, 3 = varning, 4 = information) eller på händelse-ID, inte på nivåns namn.

Splunk Universal Forwarder: [WinEventLog://Application] med whitelist = SourceName=Privera.

Händelse-ID att larma på: 1002, 1004, 1005, 1006, 3002, 3004 och 5003, samt 2003 med till = clock_tampered eller machine_mismatch och 3001 med orsak = HANDELSELOGG. En 3006 som inte följs av 3000, 3001 eller 3002 från samma dator och konto betyder att programmet avslutades under en export.

Filen. Peka SecurityLogDirectory mot en katalog som SIEM-agenten läser (Splunk [monitor://…\*.jsonl], NXLog im_file, Filebeat eller Elastic Agent filestream med JSON-avkodning). Filerna växer bara genom tillägg och roteras inte.

Programmet skickar ingenting över nätet för loggningen. Insamlingen sker med organisationens egna verktyg.

9. Exportloggen (.audit.json)

Exportloggen per export finns kvar: källa och utfil, SHA-256 för båda, tider, Windows-konto, varje maskering med kategori och position, och fel. Den är lika känslig som källdokumentet och ska inte till SIEM.

Nytt från 0.9.0-beta20 är fältet stopp_kod när en export stoppas i motorn: LACKKONTROLL, GEOMETRI, KALLFIL_ANDRAD, ETIKETT, TOLKNING eller OVRIGT. Koden sätts ur felets klass, aldrig ur felets text. Fältet är additivt, och schema_version är fortfarande 5. Säkerhetsloggen hänvisar till exportloggen genom källfilens SHA-256.

10. Begränsningar

• Versioner. Säkerhetsloggen finns från 0.9.0-beta20. Äldre versioner har bara exportloggen och loggar inte stoppade exportförsök eller andra säkerhetshändelser. Händelserna 1006, 3006, 3007, 3008 och 5003, kvittot före export och policyn RequireEventLogForExport finns från 0.9.0-beta22.
• Kedjan har ingen hemlighet. En användare med skrivrätt till både loggfilen och programmets datamapp kan skriva om allt lokalt. Skyddet mot borttagning är append-only-katalogen (7.2) och händelseloggen i SIEM, inte filen. Mot inlagda poster finns inget fullständigt skydd: en användare kan skriva en korrekt länkad post både i filen och i händelseloggen, och den går inte att skilja från programmets. Programmet upptäcker rader i filen som det inte skrev så länge ankaret är orört, och verifieringsskriptet fäller poster som bara finns i filen när SIEM har poster efter dem.
• Filens identitet är en sökväg. Junctions, symboliska länkar, subst och korta namn löses upp lokalt, men inte nätverkssökvägar: samma resurs under två UNC-namn, eller via en mappad enhet och UNC, ger två identiteter. Användaren kan också peka om %APPDATA% till en annan katalog. Verifieringsskriptet fäller båda fallen när -Loggfil anger var programmet ska skriva.
• Händelseloggen utan registrerad källa kräver PowerShell med Add-Type. I Constrained Language Mode misslyckas den vägen (7.3). Den oregistrerade vägen är provad på riktigt; den registrerade bara i en provsession.
• Verifieringsskriptet kräver FullLanguage. I Constrained Language Mode avslutas det med kod 3.
• Två exportstopp rapporteras av programmets gränssnitt (saknat fingeravtryck före spardialogen och utfil som är källfilen). Kod som har tagit över gränssnittet kan låta bli att rapportera dem. Övriga stopp avgör programmets huvudprocess själv.
• Inställningsändringar rapporteras av gränssnittet, med samma förbehåll. Exportloggens plats, som är den inställning som påverkar spårbarheten, står dessutom i varje export.lyckad, satt av huvudprocessen.
• Avslut. Vid ett ordnat avslut väntar programmet högst tre sekunder på att det som har registrerats strax före avslutet ska nå händelseloggen. Hinner det inte, eller avslutas programmet utan ordnat avslut (Windows stängs av, användaren loggar ut, strömavbrott, dödad process), kan de sista posterna finnas bara i filen. SIEM ser då en prev som saknas fram till nästa post. Undantaget är export.paborjad, som från 0.9.0-beta22 når händelseloggen innan utfilen skrivs, om kvittot kommer inom tio sekunder (avsnitt 2).
• Kvittot stoppar inte exporten förvalt. Utan RequireEventLogForExport = 1 fortsätter en export som inte fick kvitto inom tio sekunder. Kravet gäller inte heller en start då registret inte gick att läsa (avsnitt 7.1).
• Tiden kommer från datorns klocka. Händelseloggens egen tidsstämpel och SIEM:s mottagningstid är oberoende av den.
• Händelseloggen kan fyllas och rensas. En vanlig användare kan skriva till loggen Application och få äldre poster att skrivas över, och en administratör kan rensa den. Det som redan har samlats in till SIEM påverkas inte.
• Policyn går att kringgå för den som kan ändra programmets filer. Från 0.9.0-beta22 väljer miljövariablerna inte längre vilket reg.exe eller PowerShell som startas. I en installation per användare kan användaren ändå byta ut programmets filer, och REG_EXPAND_SZ expanderas med användarens miljö (avsnitt 7.1). I 0.9.0-beta21 och äldre startades reg.exe och PowerShell från den Windows-katalog som miljövariabeln SystemRoot anger.
• Inte provad mot SIEM. Insamlingen är inte provad med Windows Event Forwarding eller i något SIEM.
• Licensserverns säkerhetslogg sparas inte. Raderna syns bara medan de skrivs och når inte organisationens SIEM (avsnitt 11).
• Ingen rotation och ingen gallring av loggfilen, och ingen logg av att programmet avslutas. Analys av dokument loggas från 0.9.0-beta22 (3007 och 3008).

11. Licensservern

Licensservern licens.privera.se drivs av Itha AB hos Cloudflare (Workers) och sköter aktivering, förnyelse, uppdateringar och nedladdning av installern. Den tar inte emot dokument. Säkerhetsloggen ovan gäller programmet på datorn. Det här avsnittet gäller licensservern.

Vad som loggas. Licensservern skriver en rad i JSON per säkerhetshändelse: aktivering, flytt av licensen till en annan dator, förnyelse, frånkoppling, ändrad licensstatus efter avstämningen mot Stripe, hämtning av licensnyckeln efter köpet, inloggning på kundsidan med licensnyckeln, nedladdning av installer och uppdateringar, anrop från Stripes webhook (med utfallet nekad när signaturen inte stämmer), administrativa anrop, taktbegränsning, oväntade serverfel och anrop till sökvägar som inte finns. Varje rad har händelsekod, nivå (info, varning eller fel), utfall (lyckad, nekad eller fel), orsak, HTTP-status och Cloudflares id för anropet, och när de är kända licensens id i licensdatabasen och Stripes händelse-id.

Vad som aldrig loggas. Licensnyckeln och klientens IP-adress står bara som pseudonym: HMAC-SHA-256, avkortad till 64 bitar, med en nyckel som bara finns i licensservern. Samma nyckel eller adress ger samma pseudonym, så upprepade försök syns, men pseudonymen går inte att vända utan nyckeln. E-postadresser, kassans session-id, felmeddelanden, anropens innehåll och sökvägen i ett anrop till en okänd adress loggas inte. Värdena prövas mot fasta mönster, och ett värde som ser ut att bära en licensnyckel kommer inte med.

Driftloggen. Felmeddelanden i licensserverns driftlogg tvättas innan de skrivs: licensnyckeln i alla former som servern godtar, e-postadresser och IP-adresser byts mot en markering, och av kassans session-id står bara de sista åtta tecknen kvar.

Raderna sparas inte. Cloudflares lagring av loggar (Workers Logs) är avstängd för licensservern. Skälet är att licensnyckeln och kassans session-id fortfarande skickas i adressen vid nedladdningen av installern (/v1/installer?key= och ?id=) och vid hämtningen av nyckeln efter köpet (/v1/session?id=), och Cloudflare kan spara adressen tillsammans med loggraderna. Säkerhetsraderna och driftloggen syns därför bara medan de skrivs, för Itha AB i Cloudflares realtidsvisning. Ingenting av det sparas, och ingenting når organisationens SIEM.

Planerat. Att flytta licensnyckeln och session-id:t ur adressen och därefter slå på lagringen. Export till organisationens SIEM kräver dessutom Cloudflares betalda Workers-abonnemang och Logpush. Inget datum är fastställt.

Det som finns i licensdatabasen. Licensdatabasen visar vilka licenser som har hämtat installationsfiler och vilka datorer som är aktiverade. Det är inte en logg över misslyckade försök.