Ordbog for penetrationstest: begreberne fra A til Å

En penetrationstest har sit eget sprog, og meget af det er engelsk. Ordene bruges af testere, leverandører, revisorer og kunder, men ikke altid med samme betydning. Denne ordbog samler de begreber, en køber møder fra den første snak om en test, gennem tilbud, aftale og selve testen, til rapporten og opfølgningen.

Hvert opslag forklarer, hvad ordet dækker, og hvorfor det betyder noget for jer som bestiller. Hvor et emne er uddybet i en artikel, står der et link. Ordbogen fastlægger ikke en kontraktdefinition. Bruger et tilbud et ord anderledes, er det tilbuddets betydning, der gælder for jeres opgave, og den bør skrives ind i opgavebeskrivelsen.

Nogle ord hører hjemme i bestemte situationer, fx når en kunde stiller NIS2-krav, eller når der planlægges en red team-øvelse. De er forklaret kort her.

A

• Accepteret risiko · en dokumenteret beslutning om at lade et kendt forhold stå, fordi en rettelse ikke kan betale sig, ikke er mulig endnu eller skal vente på en større ændring. Beslutningen træffes af den, der ejer risikoen i virksomheden, ikke af testeren og ikke af IT alene. Den bør have en begrundelse, en dato for ny vurdering og eventuelle tiltag, der mindsker risikoen i mellemtiden. → Risikoaccept
• Afhængighed · en forbindelse fra det testede system til noget andet, fx en betalingsudbyder, et fælles login eller en database hos en leverandør. Afhængigheder skal nævnes i opgaven, enten som en del af testen, som en udtrykkelig undtagelse eller som en forudsætning, testeren skal kende. Ellers kan et fund i grænsefladen falde mellem to stole.
• Afslutningsmøde · mødet efter testen, hvor testeren gennemgår resultatet med jer. Det er stedet at stille spørgsmål til fund, alvorlighed og anbefalinger, før rapporten bliver endelig, og at få faktuelle misforståelser rettet. Et godt møde ender med en klar idé om de første skridt. → Afslutningsmødet
• Aktiv · alt det, virksomheden vil beskytte: et system, en tjeneste, en database, et netværk eller en bestemt type oplysninger. I en opgave skal et aktiv kunne identificeres entydigt, fx med adresse, navn eller version, så både I og testeren ved, hvad der menes.
• Alvorlighed · rapportens vurdering af, hvor meget et fund betyder, ofte på en skala som kritisk, høj, middel og lav. Vurderingen bygger på testerens skala, som skal være forklaret i rapporten. To leverandørers “høj” er ikke nødvendigvis det samme, og alvorlighed er ikke det samme som jeres risiko. → Sådan læser I en pentestrapport · Uenighed om et funds alvorlighed
• Anbefaling · testerens forslag til, hvordan et fund kan håndteres. Den er et teknisk råd, ikke en beslutning. I skal selv vurdere, om anbefalingen passer til systemets brug, til leverandørens muligheder og til jeres øvrige krav, og omsætte den til en opgave med en ejer. → Anbefalingerne i rapporten
• Angrebsflade · summen af de steder, hvor en angriber kan forsøge at komme ind eller påvirke jer: adresser på internettet, logins, API’er, fjernadgange, mail og medarbejdere. Jo større angrebsflade, jo mere skal en test dække for at give et dækkende billede. → Angrebsflade
• Angrebsvej · den rækkefølge af skridt, en angriber kan tage fra et udgangspunkt til et mål, fx fra et svagt login over en udleveret rettighed til følsomme data. Rapporten kan vise, hvordan flere mindre fund tilsammen giver en alvorlig angrebsvej. Det er ofte her, en manuel test adskiller sig fra en scanning.
• Ansvarlig offentliggørelse · en fremgangsmåde, hvor den, der finder en sårbarhed, giver ejeren besked og tid til at rette, før noget offentliggøres. Mange virksomheder oplyser en kontaktadresse til den slags henvendelser, fx i en security.txt-fil på hjemmesiden. → Uopfordrede henvendelser om sårbarheder
• Assume breach · en test, der starter med, at angriberen allerede er kommet ind, fx med en almindelig medarbejders konto eller en computer på kontornettet. Formen springer det første indbrud over og bruger tiden på spørgsmålet om, hvor langt en angriber kan komme derfra. → Assume breach
• Automatisk test · en undersøgelse, hvor værktøjer selv leder efter kendte svagheder. Den er hurtig og bred, men vurderer ikke sammenhænge og forretningslogik. En automatisk test kan være en del af en penetrationstest, men kan ikke stå alene som en. → Automatisk eller manuel penetrationstest

B

• Begrænsning · alt det, der har påvirket, hvad testen kunne belyse: manglende adgang, et miljø, der afveg fra det aftalte, en tidsramme, der blev kortere, eller en del, der ikke måtte røres. Begrænsninger skal stå i rapporten. Uden dem kan et pænt resultat blive læst bredere, end det er.
• Black box · et udgangspunkt, hvor testeren på forhånd kun får de oplysninger, en udefrakommende ville have, typisk adresser eller et domænenavn. Det ligner en ekstern angribers situation, men bruger meget af tiden på at finde ud af det, I kunne have fortalt. → Hvor meget skal testeren vide?
• Blue team · de personer og funktioner, der forsvarer virksomheden: overvågning, drift og beredskab. Ordet bruges især ved red team-øvelser, hvor blue team skal opdage og håndtere angrebet uden at vide, at det er en øvelse.
• Brud på persondatasikkerheden · et sikkerhedsbrud, der fører til, at personoplysninger hændeligt eller ulovligt bliver ødelagt, mistet, ændret eller kommer uvedkommende i hænde. Et testfund er ikke i sig selv et brud, men viser testen tegn på, at nogen faktisk har haft adgang, skal det vurderes efter databeskyttelsesreglerne, som kan kræve anmeldelse til Datatilsynet inden for 72 timer.
• Bug bounty · en ordning, hvor eksterne sikkerhedsfolk kan indsende fund mod en dusør efter offentliggjorte regler. Den kan finde svagheder løbende, men har ingen aftalt dækning, og I ved ikke, hvad der er undersøgt. Den erstatter derfor ikke en bestilt test med et beskrevet omfang. → Bug bounty eller penetrationstest

C

• CIS Controls · en prioriteret liste over sikkerhedskontroller fra Center for Internet Security. Den bruges som rettesnor for, hvad en virksomhed bør have på plads, og indeholder også en kontrol om penetrationstest. Listen er frivillig, men nyttig til at se testen i sammenhæng med det øvrige arbejde. → CIS Controls og NIST CSF
• CVE · et fast nummer, som en offentligt kendt sårbarhed i et bestemt produkt får, skrevet som CVE efterfulgt af årstal og løbenummer. Nummeret gør det muligt at tale om den samme sårbarhed på tværs af leverandører og værktøjer. Det siger ikke, om sårbarheden kan udnyttes hos jer. → CVE forklaret
• CVSS · Common Vulnerability Scoring System, en metode fra organisationen FIRST til at beregne et tal mellem 0 og 10 for en sårbarhed ud fra en række fastlagte spørgsmål. Scoren beskriver sårbarhedens alvor i almindelighed. Den tager ikke stilling til, hvad det berørte system betyder for netop jer. → CVSS-score
• CWE · Common Weakness Enumeration, et katalog over typer af svagheder i software og hardware, fx manglende kontrol af input. Hvor et CVE-nummer peger på en bestemt sårbarhed i et bestemt produkt, beskriver en CWE-kategori den slags fejl, den er et eksempel på. Rapporter kan bruge kategorierne til at vise mønstre.
• Cyber Resilience Act · EU-forordningen, ofte forkortet CRA, der stiller sikkerhedskrav til software og udstyr, som sælges på det europæiske marked. Kravene gælder producenten gennem hele produktets levetid, og de fleste træder i kraft i december 2027. For den, der udvikler software, kan testrapporter indgå i dokumentationen af produktet.

D

• Delt ansvar · princippet i cloud om, at udbyderen sikrer platformen, mens kunden selv har ansvaret for sin opsætning, sine brugere og sine data. Grænsen afhænger af tjenesten. En test af jeres cloudmiljø handler om jeres del, og udbyderens regler for test skal overholdes. → Delt ansvar i cloud
• Detektion · evnen til at opdage, at noget usædvanligt foregår, fx gennem logning og overvågning. En almindelig penetrationstest måler sjældent detektion, men I kan aftale, at testeren noterer tidspunkter, så I bagefter kan se, om overvågningen reagerede.
• DORA · EU-forordningen om digital operationel modstandsdygtighed i den finansielle sektor, som har gældt siden januar 2025. Den kræver løbende test af IT-systemer og for udvalgte finansielle enheder en avanceret trusselsstyret test. → Finansielle virksomheder: DORA og TLPT kort fortalt
• Driftsleverandør · den virksomhed, der driver jeres servere, net eller systemer. Den skal næsten altid kende til testen, ofte give tilladelse og være klar til at hjælpe, hvis noget går galt. Dens rolle bør afklares før opstart. → Driftsleverandøren og testen

E

• Ekstern test · en test fra internettet mod de adresser og tjenester, I viser udadtil, fx hjemmeside, mail, fjernadgang og kundeportal. Testen svarer på, hvad en angriber uden adgang kan nå. Den siger intet om, hvad der sker, når en angriber først er inde. → Ekstern eller intern penetrationstest
• Etisk hacker · en person, der bruger angriberens metoder med tilladelse og inden for aftalte rammer for at finde svagheder, før andre gør det. Ordet bruges ofte som synonym for penetrationstester. Det afgørende er tilladelsen, ikke betegnelsen. → Etisk hacker
• Evidens · dokumentationen for et fund: skærmbilleder, forespørgsler og svar, logudtræk eller en kort beskrivelse af, hvordan fundet blev bekræftet. Evidens gør det muligt at genskabe og rette fundet. Den kan indeholde følsomme oplysninger og skal opbevares derefter. → Bevis for fundet
• Exploit · en metode eller et stykke kode, der udnytter en svaghed til at opnå noget, systemet ikke burde tillade. At en svaghed kan udnyttes, er ofte det, der flytter et fund fra teoretisk til alvorligt. → Exploit

F

• Falsk negativ · en svaghed, der findes, men ikke bliver fundet. Ingen test kan udelukke falske negativer helt, og derfor betyder et resultat uden fund ikke, at der ingen svagheder er. → Falsk positiv og falsk negativ
• Falsk positiv · et resultat, typisk fra et værktøj, der ser ud som en svaghed, men som ved nærmere eftersyn ikke er det. En god rapport har sorteret dem fra. Rå resultater fra en scanning bør derfor ikke behandles som færdige fund.
• Fortrolighedsaftale · på engelsk NDA. En aftale om, at testeren holder oplysninger om jeres systemer og fund fortrolige. Den er især relevant, når testeren skal se dokumentation før testen, og den bør dække både data, rapport og testerens noter. → Fortrolighedsaftale før penetrationstesten
• Fund · et forhold, testeren har konstateret og beskrevet i rapporten med placering, observation, betydning og anbefaling. Et fund er ikke det samme som en sårbarhed: det kan også være en svag opsætning eller en manglende proces. Fundet bør have et nummer, der følger det til rettelse og retest. → Sårbarhed, fund og risiko
• Fysisk adgangstest · en test af, om uvedkommende kan komme ind i bygninger eller lokaler, fx via døre, adgangskort eller receptionen. Den kræver særskilt tilladelse og omtanke over for medarbejderne og bestilles ofte som tillæg til en teknisk test. → Fysisk adgang som tillæg til testen

G

• Gentaget fund · et fund, der også stod i sidste rapport. Det kan betyde, at rettelsen ikke virkede, at den kun blev lavet ét sted, eller at årsagen er en proces og ikke en enkelt fejl. Gentagne fund er et af de mest nyttige signaler, en række af test giver. → Fund, der går igen
• Grey box · et udgangspunkt, hvor testeren får udvalgte oplysninger eller adgange, fx testkonti med bestemte roller eller en oversigt over systemets dele. Det giver mere dækning for den samme tid end black box. Hvad testeren præcis får, skal stå i planen.

H

• Hacker · en person, der finder og udnytter svagheder i IT-systemer. Ordet er neutralt i fagkredse og dækker både dem, der arbejder med tilladelse, og dem, der ikke gør. → Hackere og deres hatte
• Handlingsplan · planen for, hvordan fundene bliver til opgaver med ejer, frist og status. Rapporten er grundlaget, men handlingsplanen er jeres. Den er også det, ledelsen og revisorer typisk vil se, når de spørger til opfølgningen. → Fra rapport til handlingsplan
• Hændelse · noget, der faktisk har påvirket eller kunne have påvirket sikkerheden, fx et angreb, et datatab eller et nedbrud. En svaghed, testeren finder, er ikke en hændelse. Opdager testeren tegn på et rigtigt angreb, skal testen stoppe og beredskabet i gang. → Tegn på et rigtigt angreb under testen
• Hærdning · at stramme opsætningen af et system, så det kun kan det nødvendige: unødvendige tjenester slås fra, standardkonti fjernes, og rettigheder begrænses. Mange fund handler om manglende hærdning, og rettelsen bør lægges ind i jeres standardopsætning, så den ikke skal laves igen.

I

• Intern test · en test fra en position inde på jeres net, fx en medarbejders computer, en netværksport på kontoret eller gæstenettet. Den viser, hvad en angriber eller en utro medarbejder kan nå, når den første barriere er passeret. Startpunktet skal beskrives præcist.
• ISAE 3000 og ISAE 3402 · standarder, revisorer følger, når de afgiver en erklæring med sikkerhed om en virksomheds kontroller. Typisk handler en 3402-erklæring om de kontroller hos en leverandør, som kundernes revisorer skal kunne regne med, og en 3000-erklæring om sikkerhed eller persondata mere bredt. Revisor kan bede om at se, om og hvordan I tester, og en penetrationstest kan derfor nævnes i erklæringen.
• ISO/IEC 27001 · den internationale standard for et ledelsessystem for informationssikkerhed, som virksomheder kan certificeres efter. Standarden beskriver, hvordan risici skal styres, og om og hvordan en penetrationstest indgår, følger af virksomhedens egen vurdering. → ISO 27001-certificering

K

• Kompenserende tiltag · et midlertidigt værn, der gør et fund mindre farligt, mens den egentlige rettelse venter, fx at en adgang begrænses til få brugere eller overvåges tættere. Et kompenserende tiltag er ikke en rettelse, og det bør stå tydeligt i opfølgningen.
• Konklusion · rapportens samlede svar på det spørgsmål, testen skulle besvare. Den gælder kun inden for det aftalte omfang og den periode, testen fandt sted i. Læs den derfor sammen med udgangspunkt, undtagelser og begrænsninger.
• Kontaktperson · den person hos jer, som testeren kan få fat i under hele testen, og som kan træffe beslutninger eller hurtigt finde den, der kan. Rollen bør have en stedfortræder, og testeren bør have en tilsvarende kontakt hos sig. → Før penetrationstesten
• Kritisk fund · et fund af højeste alvor, typisk fordi det giver en angriber let adgang til noget vigtigt. Mange testere melder kritiske fund med det samme i stedet for at vente på rapporten. Aftal på forhånd, hvem der skal have beskeden, og hvem der beslutter, hvad der sker. → Kritiske fund i rapporten · Kritisk fund midt i testen
• Kronjuveler · de få systemer eller data, som virksomheden mindst kan undvære eller miste kontrollen over. At pege dem ud før en test hjælper med at prioritere omfanget og gør resultatet lettere at forklare for ledelsen.
• Kundeversion · en udgave af rapporten, der er skrevet eller redigeret til at kunne deles med kunder, typisk uden tekniske detaljer om åbne fund. Den bruges, når kunder vil se dokumentation, men den fulde rapport er for følsom. Den skal stemme med den fulde rapport.

L

• Lateral bevægelse · når en angriber, der har fået fodfæste ét sted, bevæger sig videre til andre systemer på nettet, ofte ved at bruge stjålne adgange. En intern test eller en assume breach-test viser, hvor let det er, og hvor jeres net mangler skillevægge.
• Ledelsesresumé · rapportens første del, skrevet til dem, der skal træffe beslutninger. Det bør forklare, hvad der blev testet, hvad hovedresultatet er, og hvad der skal ske nu, i et sprog uden teknik. Det erstatter ikke de detaljer, de ansvarlige for rettelserne har brug for. → Resuméet i pentestrapporten
• Logning · registrering af hændelser i systemer og net, fx login, ændringer og fejl. Logning er forudsætningen for at kunne opdage et angreb og bagefter forstå, hvad der skete. En test kan vise, om de vigtige ting faktisk bliver logget.

M

• Manuel test · den del af en penetrationstest, hvor testeren selv undersøger, vurderer og kombinerer, fx forretningslogik, roller og sammenhænge mellem fund. Det er den del, værktøjer ikke kan levere, og den bør fylde tydeligt i tilbuddet.
• MITRE ATT&CK · en offentlig vidensbase over de taktikker og teknikker, angribere er set bruge i virkelige angreb. Den bruges til at beskrive angreb i et fælles sprog og til at planlægge, hvad en test eller en øvelse skal efterligne.
• Multi-tenant · en løsning, hvor flere kunder deler den samme installation, men skal holdes adskilt. Adskillelsen mellem kunderne er ofte det vigtigste, en test af sådan en løsning skal afprøve. → Kunders oplysninger skal holdes adskilt

N

• NIS2 · EU-direktivet om et højt fælles cybersikkerhedsniveau, som i Danmark er gennemført med NIS 2-loven. Det stiller krav til virksomheder i en række sektorer, og mange af dem sender krav videre til deres leverandører. Direktivet kræver ikke ordret en penetrationstest, men test kan være en måde at vise, at sikkerheden virker. → NIS2 i leverandørkæden
• NIST SP 800-115 · en vejledning fra det amerikanske standardiseringsinstitut NIST om teknisk sikkerhedstest og vurdering. Mange tilbud henviser til den, når de skal forklare, hvordan testen planlægges, udføres og afrapporteres. → Metoden i tilbuddet

O

• Observation · noget testeren har bemærket, men som ikke er vurderet som et egentligt fund, fx en opsætning, der er i orden, men kunne være strammere. Leverandører bruger ordet forskelligt, så spørg, hvordan observationer adskiller sig fra fund i deres rapporter.
• Opgavebeskrivelse · dokumentet, hvor I beskriver, hvad der skal testes, hvorfor, hvornår og med hvilke forudsætninger. Den sendes til de testere, der skal give tilbud, og bliver bagefter grundlaget for at vurdere, om rapporten dækker det aftalte. → Opgavebeskrivelsen
• Oprydning · at fjerne alt det, testen har efterladt: testkonti, filer, ændrede indstillinger og undtagelser i firewall eller overvågning. Oprydningen bør stå i aftalen, og testeren bør give en liste over, hvad der er oprettet. → Testkonti og adgange efter testen
• OSSTMM · en åben metode fra organisationen ISECOM, der beskriver sikkerhedstest bredt, også af mennesker og fysiske forhold. Den nævnes sammen med PTES og OWASP som metodegrundlag.
• OWASP ASVS · Application Security Verification Standard, en liste over sikkerhedskrav til webapplikationer i tre niveauer. Den bruges til at beskrive, hvor grundigt en applikation skal kontrolleres, og kan bruges som tjekliste i en opgavebeskrivelse.
• OWASP Top 10 · en liste over de mest udbredte risikokategorier i webapplikationer, udgivet af fællesskabet OWASP. Den er nyttig som fælles sprog, men den er ikke en testmetode, og en test, der kun dækker listen, kan overse forretningslogik. → OWASP Top 10 for købere
• OWASP WSTG · Web Security Testing Guide, OWASP’s vejledning i, hvordan webapplikationer testes, område for område. Den henvises der ofte til i tilbud på test af webløsninger.

P

• Patch · en opdatering, der retter en kendt fejl eller sårbarhed. God patchstyring fjerner mange fund, før de opstår, men en test finder også det, opdateringer ikke løser: opsætning, rettigheder og egen kode. → Opdateringer og penetrationstest
• PCI DSS · sikkerhedsstandarden for virksomheder, der behandler betalingskortdata. Den kræver penetrationstest af kortmiljøet med faste mellemrum og efter væsentlige ændringer, og den stiller krav til, hvordan testen gennemføres. → Penetrationstest og standarder
• Penetrationstest · en aftalt undersøgelse, hvor en tester går til bestemte systemer, som en angriber ville, for at vise, hvor langt det er muligt at komme, og hvad det betyder. Ordet siger i sig selv ikke, hvad der testes, eller hvor grundigt. Det skal opgaven og rapporten sige. → Typer af penetrationstest
• Phishing-test · en kontrolleret udsendelse af falske mails til medarbejdere for at se, hvor mange der klikker eller afleverer oplysninger. Testen måler adfærd, ikke teknik, og kræver omtanke om, hvordan resultatet bruges over for medarbejderne. → Phishing-test
• Privilegieeskalering · når en angriber går fra en begrænset adgang til flere rettigheder, fx fra almindelig bruger til administrator. Mange alvorlige angrebsveje går gennem netop det skridt, og en intern test bruger ofte meget tid på det.
• Produktionsmiljø · det miljø, hvor jeres rigtige brugere og data er. En test her giver det mest retvisende resultat, men kræver flere hensyn, aftaler om tidspunkt og en plan for, hvad der sker, hvis noget påvirkes. → Penetrationstest i produktion eller testmiljø
• PTES · Penetration Testing Execution Standard, en beskrivelse af en penetrationstests forløb i syv faser fra de indledende aftaler over efterforskning og udnyttelse til afrapporteringen. Styrken er beskrivelsen af hele forløbet, mens selve teknikken står i de tilhørende vejledninger.
• Purple team · et samarbejde, hvor angriberne og forsvarerne arbejder sammen og gennemgår angrebet trin for trin, så forsvaret kan forbedre sin evne til at opdage det. Ordet bruges mest i forbindelse med red teaming.

R

• Rammeaftale · en aftale om flere test over en periode med faste vilkår, så hver enkelt test ikke skal forhandles fra bunden. Den passer bedst til virksomheder med mange systemer eller faste krav om løbende test. → Rammeaftale om penetrationstest
• Rapportens alder · tiden fra testen blev udført, til rapporten bruges. Kunder og revisorer spørger ofte, hvor gammel rapporten er, fordi systemet kan have ændret sig siden. Det er testperioden, der tæller, ikke datoen på forsiden. → Rapportens alder
• Red team · en længerevarende, målrettet øvelse, hvor et hold efterligner en rigtig angriber med alle midler, der er aftalt, og hvor forsvarets evne til at opdage og reagere er en del af det, der måles. Det er en anden ydelse end en penetrationstest. → Red teaming eller penetrationstest
• Restrisiko · den risiko, der står tilbage, når fundene er rettet eller accepteret. Den består af det, testen ikke dækkede, det, der ikke er rettet, og det, ingen test kan udelukke. → Restrisiko
• Retest · en opfølgende kontrol, der kun ser på de fund, I har rettet. Den dækker kun de fund, der er aftalt, og bør give jer dokumentation for hvert fund med status og dato. En retest er ikke en ny penetrationstest. → Retest efter penetrationstest
• Rettelse · det, der bliver gjort ved systemet for at få et fund til at forsvinde. At nogen melder en rettelse færdig, viser endnu ikke, at fundet er væk. Skeln mellem rettet, kontrolleret og lukket i jeres opfølgning.
• Risiko · sandsynligheden for, at noget uønsket sker, sammenholdt med konsekvensen, hvis det gør. Rapporten beskriver fund og alvorlighed, men risikoen afhænger af, hvad systemet betyder for jer, og den vurdering skal I selv foretage.
• Rodårsag · den underliggende grund til, at et fund opstod, fx en manglende procedure, en standardopsætning eller et uklart ansvar. Rettes kun symptomet, kommer fundet igen. → Fund, der kræver en ny proces
• Rules of engagement · spillereglerne for testen: hvad der må gøres, hvornår, fra hvilke adresser, hvem der kontaktes, og hvad der sker, hvis noget går galt. De skal være aftalt skriftligt, før testen begynder. → Rules of engagement

S

• Scope · det aftalte omfang af testen: hvilke systemer, adresser, funktioner, roller og miljøer der er med, og hvad der udtrykkeligt er holdt ude. Scope er det, rapportens konklusion skal læses op imod. → Scope i en penetrationstest
• Segmentering · opdelingen af et net i adskilte dele, så en angriber, der kommer ind ét sted, ikke frit kan nå resten. En test af segmenteringen undersøger, om skillevæggene holder i praksis. → Netværkssegmentering
• Sikkerhedsspørgeskema · et skema, hvor en kunde spørger ind til jeres sikkerhed, ofte med et spørgsmål om penetrationstest. Svaret bør være præcist og stemme med jeres rapport. Ordlisten på pentestrapport.dk forklarer de udbredte skemaformater.
• Sikkerhedstjek · en bred betegnelse, der kan dække alt fra en kort gennemgang til en scanning. Spørg, hvad der konkret indgår, før I sammenligner et sikkerhedstjek med en penetrationstest. → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest?
• Sikkerhedsvurdering · en samlet betegnelse for undersøgelser af sikkerheden, som kan omfatte interviews, gennemgang af dokumenter, test eller en kombination. Ordet beskriver ikke en bestemt leverance, så tilbuddet skal forklare indholdet.
• Single sign-on · fælles login, hvor én konto giver adgang til mange systemer. Det samler adgangen ét sted, og derfor skal testen se både på selve login og på, hvad en konto giver adgang til bagefter. → Fælles login i testen
• SOC · Security Operations Center, den funktion der overvåger jeres systemer og reagerer på alarmer, enten internt eller hos en leverandør. Skal SOC’en vide, at der testes, eller skal testen også vise, om den opdager noget? → Skal overvågningen have besked?
• SOC 2 · en rapport fra en revisor efter den amerikanske revisororganisation AICPA’s kriterier, der beskriver en leverandørs kontroller med bl.a. sikkerhed og tilgængelighed. Udenlandske kunder spørger ofte efter den. Er der testet, kan det fremgå af rapporten som en af kontrollerne.
• Social engineering · angreb, der går gennem mennesker frem for teknik, fx falske mails, opkald eller personer, der udgiver sig for at være nogen andre. En test af det kræver særskilt tilladelse og beskrivelse og hører ikke automatisk med i en teknisk test. → Social engineering i en sikkerhedstest
• Stopkriterium · en på forhånd aftalt situation, hvor testen skal stoppe eller holde pause, fx hvis et system bliver ustabilt, eller der er tegn på et rigtigt angreb. Det skal kunne forstås af både testeren og jeres drift.
• Sårbarhed · et sted, hvor et system ikke beskytter sig selv, som det burde, fx på grund af en programfejl, en forkert opsætning eller en manglende kontrol, så en angriber kan få noget ud af det. Ikke alle sårbarheder kan nås eller udnyttes i jeres miljø, og det er en af de ting, en test afklarer.
• Sårbarhedsscanning · en automatisk undersøgelse, der leder efter kendte sårbarheder ud fra versioner og svar fra systemerne. Den er nyttig og billig at gentage, men resultatet skal vurderes, før det kan bruges som dokumentation.
• Sårbarhedsstyring · den løbende proces med at finde, vurdere, rette og følge op på sårbarheder. Testen giver et billede af én periode, mens sårbarhedsstyringen er det daglige arbejde før, imellem og efter testene. → Sårbarhedsstyring og penetrationstest

T

• Teknisk bilag · den del af rapporten, der indeholder detaljerne: forespørgsler, svar, skærmbilleder og fremgangsmåde. Bilaget er skrevet til dem, der skal rette fundene, og er rapportens mest følsomme del. → Tekniske bilag i pentestrapporten
• Testerklæring · testerens skriftlige bekræftelse af, at en test har fundet sted, hvilket omfang den havde, og hvornår den lå. Fundene gengives ikke i detaljer. Erklæringen er tænkt til kunder og samarbejdspartnere, der vil have bevis for testen, men ikke har brug for, eller bør få, selve rapporten. → Testerklæring til kunder
• Testkonto · en konto, der er oprettet til testen, med de roller og rettigheder, testen skal undersøge. Den skal kunne skelnes fra rigtige brugere og lukkes igen bagefter. → Testkonti og testdata
• Testmiljø · en kopi eller en særskilt udgave af systemet, som bruges til testen i stedet for produktionen. Resultatet gælder kun for produktionen, hvis forskellene mellem de to miljøer er kendte og beskrevne.
• Testvindue · det tidsrum, testen må foregå i, fx bestemte dage eller uden for arbejdstiden. Det skal passe med jeres drift, med testerens arbejde og med jeres muligheder for at reagere, hvis noget går galt. → Test i arbejdstiden eller uden for?
• TIBER-DK · den danske udgave af den europæiske ramme TIBER-EU, som Nationalbanken står for. Den beskriver, hvordan finansielle virksomheder gennemfører red team-test bygget på efterretning om virkelige trusler, med myndigheden med i processen. Ordbogen for red teaming på red-teaming.dk forklarer rammens begreber.
• Tilladelse · den skriftlige accept fra dem, der ejer eller råder over de systemer, der skal testes. Uden den kan en test være ulovlig, også når den er bestilt i god tro. Ligger systemerne hos en leverandør, skal deres accept ofte også med. → Er en penetrationstest lovlig?
• TLPT · forkortelse for threat-led penetration testing. Betegnelsen hører til DORA og bruges om den særlige trusselsstyrede test, som nogle finansielle virksomheder skal gennemføre efter fastlagte regler. En grundig penetrationstest bliver ikke en TLPT af den grund.
• Tofaktor · login, hvor en adgangskode suppleres med noget andet, fx en kode på telefonen. Det mindsker risikoen markant, men testen bør se efter undtagelser, gamle loginmetoder og konti uden tofaktor. → Tofaktorlogin i testen
• Trusselsbaseret test · en test, hvor scenarierne bygger på de trusler, der realistisk rammer netop jeres branche eller virksomhed, frem for en generel gennemgang. → Trusselsbaseret test
• Trusselsmodellering · en systematisk gennemgang af, hvem der kunne angribe et system, hvordan og med hvilket mål. Den kan bruges til at vælge, hvad en test skal fokusere på, og giver et bedre grundlag for at vurdere rapportens fund.

U

• Uafhængig test · en test, der udføres af en anden end den, der har bygget eller driver systemet. Kunder og revisorer lægger vægt på uafhængigheden, fordi den, der tester sit eget arbejde, let overser de samme ting to gange. → Uafhængig penetrationstest
• Udgangspunkt · det sted og den viden, testen starter fra: udefra uden adgang, med en almindelig brugerkonto eller fra en computer på kontornettet. Udgangspunktet afgør, hvilket spørgsmål testen kan svare på. → Test med og uden login
• Undtagelse · noget, der er tæt på eller inden for opgaven, men som udtrykkeligt ikke må eller kan testes, fx et system hos en tredjepart. Undtagelser skal stå i rapporten, så konklusionen ikke læses som gældende for dem. → Et for snævert scope

W

• Webapplikationstest · en test af en webløsning med brugere, roller og funktioner, fx en kundeportal eller en webshop. Den fokuserer på login, adgangskontrol, input og forretningslogik og kræver ofte testkonti. → Penetrationstest af webapplikationer
• White box · et udgangspunkt, hvor testeren får omfattende viden om systemet, fx arkitektur, opsætning og i nogle tilfælde kildekode. Det giver den mest grundige test for tiden, men betyder ikke, at alt automatisk er med i omfanget.
• White team · de få personer, der er indviet i en red team-øvelse og har ansvaret for, at den forløber forsvarligt. I en almindelig penetrationstest svarer rollen nogenlunde til jeres kontaktperson og den, der kan beslutte at stoppe testen.
• Whitelisting · at undtage testerens adresser fra blokering i firewall eller overvågning, så testen ikke stoppes af forsvaret. Det giver mere tid til selve testen, men betyder, at testen ikke viser, om forsvaret ville have reageret. → Skal testeren undtages i firewall og overvågning?

Z

• Zero-day · en sårbarhed, som producenten endnu ikke kender eller har rettet. En penetrationstest leder normalt ikke efter zero-days, men efter kendte svagheder og fejl i jeres opsætning og egen kode. → Zero-day

Ø

• Øjebliksbillede · en betegnelse for, at testen kun viser tilstanden i den periode, den blev udført. Ændringer i systemet bagefter er ikke dækket, og derfor skal rapportens dato og omfang altid følge resultatet. → Penetrationstesten er et øjebliksbillede

Kilder

• NIST SP 800-115: plan, gennemførelse, dokumentation og opfølgning af teknisk sikkerhedstest.
• FIRST CVSS v4.0: CVSS som mål for alvorlighed og afgrænsningen fra risiko.
• OWASP Web Security Testing Guide og OWASP ASVS: begreber ved test af webapplikationer.
• CVE-programmet, CWE og MITRE ATT&CK: fælles kataloger over sårbarheder, svaghedstyper og angrebsteknikker.
• Cyber Resilience Act, forordning (EU) 2024/2847 og DORA, forordning (EU) 2022/2554: anvendelsesdatoer og krav om test.
• Databeskyttelsesforordningen (EU) 2016/679, artikel 4, nr. 12, og artikel 33: brud på persondatasikkerheden og anmeldelse.

Senest gennemgået: oktober 2026.

Næste skridt

• Penetrationstest fra start til slut
• Sammenlign tilbud på penetrationstest

Del af: Artikler om penetrationstest

Læs også: Spørgsmål og svar · Penetrationstest forklaret

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT