En revisjon av privilegert tilgang må som regel slå fast fire ting: hvem som hadde administratorrettigheter, hvilken regel som ga dem, hvor lenge, og hva hevingen omfattet. Logging av heving av rettigheter besvarer tre av dem direkte. Det fjerde – hvilken regel – kommer fra policysettet ditt, og når du kjenner den fordelingen før revisjonen starter, slipper du to uker med leting på feil sted. Virksomheter som utformet loggen rundt disse spørsmålene, svarer på en ettermiddag. Virksomheter som tok vare på logger for feilsøking, bruker to uker på å rekonstruere et svar fra data som aldri var ment å bære det.
Forskjellen ligger ikke i hvor mye du logger. Den ligger i om feltene du registrerer, samsvarer med spørsmålene en revisor stiller. Det er en designbeslutning, og den er langt billigere å ta før den første revisjonen enn etterpå.
Dette spør en revisjon av privilegert tilgang faktisk etter
Spørsmålene er smalere enn uroen rundt dem skulle tilsi.
«Hvem har administratorrettigheter?»
For administrerte endepunkter er den reneste grunnlinjen null faste lokale administratorrettigheter. Den grunnlinjen kan etterprøves – en revisor kan kontrollere den direkte i stedet for å ta en liste på tro. Privilegerte identiteter andre steder i virksomheten er en egen samtale; denne handler om endepunktet. Det er også svaret som eldes godt: En liste over administratorkontoer er utdatert uken etter at noen har laget den, mens en håndhevet grunnlinje forblir sann hele tiden.
Der faste rettigheter fortsatt finnes, trenger unntakene navn, eiere og en dokumentert begrunnelse. Ett uforklart unntak er verre enn mange forklarte.
«Hvordan ble tilgangen gitt?»
Her sjekker revisoren om tildelingene følger en regel eller et innfall. CapaOne Privilege Manager, en del av CapaOne-plattformen for endepunktadministrasjon, gir heving av rettigheter etter policy innenfor et definert omfang, slik at svaret er en policy og ikke en erindring.
Det er verdt å være presis om hvor det svaret finnes. Policysettet dokumenterer hvilken regel som tillater hvilken handling; loggen registrerer at en heving skjedde, og hva den omfattet. Dokumentasjonen for dette spørsmålet kommer fra begge, og en revisor som ber om å se regelen, vil ha konfigurasjonen, ikke loggfilen. Break-glass-tildelinger utgjør et eget, mindre sett – og fordi de er unntaket, er det dette settet som blir gransket nøyest.
«Hvor lenge?»
Tidsbegrenset tilgang er mekanismen som gjør minste privilegium til virkelighet og ikke bare en ambisjon, så loggen må vise grensen i tillegg til tildelingen. Hvis den viser at en heving skjedde, men ikke når den tok slutt, kan du ikke dokumentere kontrollen, selv når den finnes.
«Hva omfattet hevingen?»
Hver heving registrerer brukeren, endepunktet, navnet på den kjørbare filen og programbanen, tidspunktet, varigheten og utfallet.
Hvor fullstendig det besvarer spørsmålet, avhenger av hvilken type heving du ga. For heving per prosess er loggen eksakt: én navngitt kjørbar fil på én bane, hevet og senket igjen. For heving per økt beskriver den et tidsbegrenset vindu med administrativt omfang, ikke en liste over alt som ble gjort i løpet av det. Begge kan forsvares – de svarer med ulik oppløsning, og det er verdt å vite hvilken oppløsning dine egne policyer gir, før noen spør.
Dette fanger loggingen opp, og derfor fortjener hvert felt sin plass
Hvert felt svarer på ett av de fire spørsmålene. Brukeren og endepunktet besvarer hvem og hvor. Navnet på den kjørbare filen og programbanen besvarer hva – og banen veier tungt her, fordi to kjørbare filer med samme navn på ulike steder ikke er det samme for en revisor eller en angriper. Tidspunkt og varighet besvarer spørsmålet de fleste logger ikke har svar på. Utfallet lukker sløyfen ved å vise om handlingen lyktes.
Oppføringene kan eksporteres for gjennomgang, og det er det som gjør dem fra telemetri til revisjonsbevis. En revisor kan selvsagt gå gjennom en konsoll sammen med deg, men en eksport kan sendes videre: Du kan ta stikkprøver i den, arkivere den, sammenligne den med fjorårets og levere den fra deg uten å gi noen tilgang til selve plattformen.
Det er loggens jobb, og den er smalere enn styring. Hvem som eier praksisen rundt heving av rettigheter, hvem som godkjenner policyer, og hvordan styret ser det, er egne spørsmål, som vi tar for oss i innlegget vårt om styring av privilegert tilgang. Feltutformingen her er det alt dette hviler på.
Kombiner loggen med eksponeringsdata for hele enhetsparken fra CapaOne Security Monitor når revisjonen kommer til konfigurasjon og patchstatus, siden privilegert tilgang sjelden gjennomgås isolert.
Slik blir en logg til noe du kan levere fra deg
Tre vaner skiller en brukbar logg fra et arkiv.
Bestem lagringstiden bevisst. Uansett hva informasjonssikkerhetspolicyen din sier, må loggen stemme med den. Revisorer sammenligner de to, og et avvik ser ut som en kontroll som bare finnes på papiret.
Gjennomgå etter en fast rytme, og etterlat et spor av gjennomgangen. Månedlig for break-glass-bruk og kvartalsvis for unntak i policyen er et fornuftig utgangspunkt, ikke et krav – sett den rytmen som passer ditt eget risikobilde. Gjennomgangen betyr mindre for hva den finner, enn for at den dokumenterer at noen faktisk ser etter. Break-glass-bruk som ingen gjennomgår, slutter å fungere som et unntak og begynner å fungere som en ekstra, stillere vei inn – et poeng vi tok opp i innlegget vårt om just-in-time-rettigheter i praksis.
Skill den som gjennomgår, fra den som gir tilgangen. Uavhengig gjennomgang styrker funksjonsdelingen, og den betyr mest for break-glass og manuelt godkjente hevinger – tilfellene der én persons skjønn erstattet en regel. Det gjelder særlig der servicedesken godkjenner hevinger direkte – innlegget vårt om heving av rettigheter fra servicedesken uten å dele det lokale administratorpassordet forklarer hvorfor en godkjenning basert på påloggingsinformasjon etterlater et tynnere spor enn en policybasert.
For virksomheter som bruker Microsoft Entra ID, retter policyene seg mot eksisterende grupper, slik at identitetsstrukturen du allerede vedlikeholder og dokumenterer, blir strukturen dokumentasjonen din viser til. CapaOne kjører som en komplett plattform på egen hånd, og for team som har Microsoft Intune på plass, fungerer den side om side med eksisterende policyer for samsvar og konfigurasjon uten å duplisere dem.
Revisjoner går greit av en kjedeligere grunn enn de fleste forventer. Ikke fordi kontrollene er mange, men fordi det daglige arbeidet allerede produserer dokumentasjonen – ingen trenger å sette sammen noe, fordi noen valgte feltene med spørsmålet i tankene. Oversikten vår over styring av administratorrettigheter på endepunkter viser hvor dette passer inn i en bredere endepunktstrategi, og siden vår om sikkerhet og etterlevelse viser hvordan revisjonssporet passer sammen med rapportering om patching og konfigurasjon.
Se hvordan loggen ser ut i ditt eget IT-miljø – book en demo av CapaOne-plattformen for endepunktadministrasjon, så går vi gjennom en eksport sammen med deg.