På en arbejdsplads uden kontrol med programmer kan en medarbejder køre næsten hvad som helst: et program fra en hjemmeside, et script fra en kollega, en makro i et regneark fra en leverandør. Det er bekvemt, men det betyder, at alt, hvad brugeren åbner, kører med brugerens adgang til data. Svaret på titlens spørgsmål hviler på et skifte i udgangspunkt: fra at alt må køre, med mindre beskyttelsen genkender det som skadeligt, til at kun det, organisationen har godkendt, må køre.
Det skifte kaldes programkontrol eller en godkendt liste over programmer. Det er et princip, ikke et bestemt produkt, og det kan indføres gradvist.
Princippet bag programkontrol
Microsoft beskriver forskellen sådan, at Windows går fra et sted, hvor al kode kører, med mindre beskyttelsesprogrammet med sikkerhed forudser, at den er skadelig, til et sted, hvor kode kun kører, hvis politikken tillader det. NIST har en vejledning om emnet, der beskriver en liste over godkendte programmer som en måde at forhindre skadelig kode, programmer uden licens og andre uautoriserede programmer i at køre.
Programkontrol er ikke en erstatning for beskyttelsesprogrammer. Microsoft understreger, at de to skal bruges sammen. Beskyttelsen leder efter det, der er kendt som dårligt. Programkontrollen tillader kun det, der er kendt som godt. → Endpoint-beskyttelse og testen
Hvad der er omfattet
Det er let at tænke på programkontrol som et spørgsmål om installerede programmer. I praksis er området bredere.
- Programmer · det, brugeren installerer eller kører direkte fra en mappe, også uden installation.
- Scripts · små programmer i de scriptsprog, der følger med styresystemet, eller som kan hentes.
- Makroer · kode i regneark, dokumenter og præsentationer. Microsoft blokerer som standard makroer i filer fra internettet i de nyere udgaver af Office, men indstillingerne kan være ændret lokalt.
- Udvidelser · tilføjelser til browser og kontorprogrammer, som brugerne selv kan installere.
- Interne værktøjer · scripts og små programmer, IT selv har lavet, og som skal kunne køre. → Interne værktøjer bygget af IT selv
Det, testen afprøver
En klienttest eller en intern test kan undersøge, hvad en almindelig bruger kan få til at køre på sin maskine og på de servere, brugeren kan nå. Testen beskriver resultatet som en konstatering af, hvad der var muligt, ikke som en opskrift.
- Findes der en politik · er programkontrol slået til, og i givet fald i hvilken tilstand: kun registrering eller faktisk blokering?
- Hvor bred er den · er der brede undtagelser, fx for mapper, hvor brugeren selv kan skrive?
- Makroindstillinger · er makroer i filer udefra blokeret, og kan brugeren selv ændre indstillingen?
- Scripts · kan brugeren køre scripts frit, eller er de begrænset?
- Afhængighed af rettigheder · kan kontrollen slås fra af brugeren selv? Det kan den, hvis brugeren er administrator. → Brugere med administratorrettigheder på egen maskine
Hvad fundene betyder
Fundene i området er ikke nødvendigvis alvorlige alene. De vejer tungere, når de kombineres med andet, fordi de gør det lettere for skadelig kode at nå videre fra den første maskine.
- Ingen programkontrol · udgangspunktet er, at alt må køre. Det er et valg, mange har truffet uden at tænke over det, og fundet beskriver den beslutning.
- Kontrol i registreringstilstand · politikken findes, men stopper intet. Det er et godt første trin, men ikke en beskyttelse.
- Brede undtagelser · en politik, der tillader alt i mapper, brugeren kan skrive i, har et hul, der er let at finde.
- Makroer tilladt fra alle kilder · en klassisk vej for skadelig kode i vedhæftede filer.
Læs fundene sammen med rapportens fund om rettigheder og beskyttelse. Det er kombinationen, der afgør vægten.
Sådan indfører I programkontrol
Programkontrol, der indføres på én dag, stopper arbejdet og bliver slået fra igen. Indført i trin kan den blive en stabil del af opsætningen.
- Kortlæg · hvilke programmer, scripts og makroer bruges faktisk? En politik i registreringstilstand kan give svaret uden at stoppe noget.
- Begynd med det enkle · bloker makroer i filer fra internettet og kørsel fra mapper, hvor brugeren selv kan skrive.
- Godkend kendte kilder · programmer fra leverandører, I stoler på, og interne værktøjer, der er signeret eller placeret, hvor kun IT kan skrive.
- Afprøv på en pilotgruppe · før blokering rulles ud til alle.
- Lav en proces for nye behov · brugerne skal kunne bede om et program og få svar hurtigt, ellers opstår der undtagelser.
- Tag serverne med · servere kan have et mere fast sæt af programmer og er derfor lettere at låse. → Servere som testområde
Ændringen mærkes af brugerne. Forbered servicedesken og fortæl, hvorfor det sker. → Skærpelser, brugerne mærker
Hvem ejer listen
En liste over godkendte programmer er kun så god som den proces, der holder den ved lige. Uden en ejer bliver den enten for stram, så brugerne presser på for undtagelser, eller for bred, så den ikke længere beskytter.
- En fast ejer · én funktion i IT eller hos driftsleverandøren har ansvaret for politikken og for at godkende ændringer.
- Kriterier for godkendelse · hvad skal et program opfylde for at komme på listen, og hvem skal spørges, hvis det rører ved følsomme data?
- Fjernelse · programmer, der ikke længere bruges, tages af listen igen. Ellers vokser den kun.
- Sammenhæng med indkøb · nye systemer, som en afdeling køber, skal vurderes, før de rulles ud, ikke efter.
For en MSP er spørgsmålet om ejerskab ekstra vigtigt. Er listen fælles for flere kunder, kan en godkendelse hos én kunde åbne for et program hos alle.
Det skal I lade være med
- At slå blokering til uden kortlægning. Forretningskritiske programmer kan stoppe.
- At blive stående i registreringstilstand. Politikken giver først beskyttelse, når den blokerer.
- At undtage hele mapper, brugerne kan skrive i. Så kan alt køre derfra.
- At lade brugerne være administratorer. Så kan de slå kontrollen fra.
- At glemme makroer og scripts. De er en del af området, ikke en sidesag.
Hvad kan og ikke kan konkluderes
Testen viser, hvad testbrugeren kunne få til at køre på de maskiner, der var med. Den viser ikke, hvordan politikken er sat op på maskiner med en anden opsætning, eller om alle maskiner faktisk har politikken. Et resultat, hvor intet kunne køre, siger heller ikke noget om de programmer, der allerede er godkendt, og om de selv er sikre. → Klienttest for IT-afdelingen
Tjekliste til programkontrol
- ☐ Ved I, hvilke programmer, scripts og makroer der bruges i dag?
- ☐ Er makroer i filer fra internettet blokeret?
- ☐ Er kørsel fra mapper, brugeren kan skrive i, begrænset?
- ☐ Er der en plan for at gå fra registrering til blokering?
- ☐ Findes der en hurtig proces for nye programbehov?
- ☐ Er serverne med i planen?
Kilder
- NIST SP 800-167: Guide to Application Whitelisting: vejledning fra 2015 om lister over godkendte programmer som måde at forhindre skadelig kode og uautoriserede programmer i at køre, og om planlægning og indførelse.
- Microsoft Learn: Application Control for Windows: skiftet fra at al kode kører til at kode kun kører efter politik; programkontrol dækker også scripts og installationsfiler og er ikke en erstatning for beskyttelsesprogrammer.
- Microsoft Learn: Macros from the internet are blocked by default in Office: standardblokering af makroer i filer fra internettet og anbefalede politikker for makroer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Klienttest for IT-afdelingen · Hærdning forklaret
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
