Mens testeren arbejder, skal driften kunne se, om systemerne i opgaven har det godt. Det handler ikke om sikkerhedsalarmer, men om det almindelige: belastning, svartider, fejl i programmer og advarsler fra platformene. Svaret på, hvad driften skal holde øje med, hviler på en enkel tanke: kend det normale billede før testen, følg de systemer, testen rører, og aftal på forhånd, hvornår en afvigelse er stor nok til at ringe. Ifølge det britiske NCSC kan en tester nok bestræbe sig på at undgå unødig påvirkning, men ingen kan garantere mod uventede reaktioner i systemerne. Driftsovervågningen er jeres måde at opdage dem på, mens der stadig er tid til at handle.
Forskellen på driftsovervågning og sikkerhedsalarmer
Sikkerhedsovervågningen spørger, om nogen gør noget, de ikke må. Driftsovervågningen spørger, om systemerne virker. Under en test kan begge slå ud på grund af den samme aktivitet, men de skal håndteres forskelligt.
En sikkerhedsalarm kræver, at det bekræftes, om aktiviteten er testen eller en angriber. → Alarmer under testen
En driftsadvarsel kræver, at det vurderes, om systemet tager skade, og om testen skal sænke tempoet eller stoppe. Hold de to spor adskilt i håndteringen, men lad dem tale sammen. En stigning i fejl på en webserver kan være interessant for begge. I en lille IT-afdeling kan det være de samme personer, der ser på begge dele, og så er det især vigtigt at spørge sig selv, hvilket af de to spørgsmål en given advarsel rejser.
Kend det normale billede før start
En afvigelse kan kun ses, hvis man ved, hvad der er normalt. Tag et øjebliksbillede af de vigtigste målinger for systemerne i opgaven i dagene før testen.
- Belastning · processor, hukommelse og lager på de servere, testen rører.
- Netværk · trafik på de forbindelser, testen bruger, især forbindelser til internettet og mellem segmenter.
- Svartider · for de webapplikationer og tjenester, der testes.
- Fejl · niveauet af fejl i logs og programmer på en almindelig dag.
- Logvolumen · hvor meget de centrale logsystemer modtager.
Notér også de faste job, der påvirker billedet, som backup, opdateringer og rapportkørsler. Så kan en top i belastningen holdes op mod jobplanen, før den tilskrives testen. → Driftslog over testperioden
Det, der skal følges under testen
Under testen følger driften de samme målinger, men med særlig opmærksomhed på de systemer, testeren arbejder på den pågældende dag. Bed om at få at vide, hvad testeren planlægger, så overvågningen kan fokusere. → Status undervejs
- Tjenester, der holder op med at svare · det tydeligste tegn på, at noget er galt.
- Svartider, der stiger · især på systemer, som brugerne arbejder i.
- Fejl, der hober sig op · i webservere, databaser eller forretningssystemer.
- Køer, der vokser · fx mailkøer eller beskedkøer mellem systemer.
- Lager, der fyldes · logs og midlertidige filer kan vokse hurtigere end normalt.
- Licenser og grænser · platforme med loft over forespørgsler eller logmængde kan nå grænsen.
Lagerpladsen er let at overse. En test kan få logsystemer til at modtage langt mere end normalt, og et logsystem, der løber fuldt, mister både testens spor og alt andet.
Hvornår der skal ringes
Aftal tærskler før testen, så vagten ikke skal vurdere fra bunden hver gang. Tærsklerne er jeres egne og afhænger af systemerne, men de kan beskrives i tre trin.
- Notér · en afvigelse, der er synlig, men ikke påvirker brugerne. Den skrives i driftsloggen og nævnes i den næste status.
- Spørg · en afvigelse, der vokser, eller som rammer et system, brugerne er afhængige af. Kontaktpersonen spørger testeren, om aktiviteten kan sænkes.
- Stop · en tjeneste, der er nede, eller en afvigelse, der truer data eller andre systemer. Testen mod systemet stopper med det samme. → Beredskab under testen
Den amerikanske standardorganisation NIST skriver i sin vejledning om sikkerhedstest, at enhver test, der arbejder direkte mod et system, kan føre til uventede stop, og at organisationen selv må fastlægge, hvor indgribende testen må være. Tærsklerne er jeres praktiske version af den beslutning. Del dem med testeren før start, så begge parter ved, hvornår der bliver ringet, og hvad der forventes, når telefonen går.
Skrøbelige systemer og tidspunkter
Nogle systemer tåler mindre end andre: ældre servere, styringer tæt på produktionen og fagsystemer, som kun få kender. De skal være udpeget før testen og overvåges tættere, mens testeren arbejder på dem. → Skrøbelige systemer
NCSC nævner, at test uden for normal arbejdstid og kritiske systemer med særlige hensyn skal drøftes, når opgaven afgrænses. Arbejder testeren om aftenen, skal nogen også se på overvågningen om aftenen. En test, der kører, mens ingen holder øje, flytter risikoen fra testeren til driften uden at nogen har besluttet det.
Når andre står for overvågningen
Overvåges en del af systemerne af en driftsleverandør eller af en cloudplatform, skal de også vide, at der er en test i perioden. Leverandørens vagt kan ellers reagere på en advarsel ved at genstarte en tjeneste eller lukke en forbindelse, uden at nogen hos jer ved det. Det kan både påvirke testen og skjule, hvad der skete.
Aftal, at advarsler om systemerne i opgaven går til jeres kontaktperson i testperioden, eller at leverandøren ringer, før den handler. Spørg også, hvilke målinger leverandøren faktisk ser. Har I kun adgang til et overordnet billede, er det godt at vide før testen, så I ikke tror, at alt er roligt, blot fordi jeres egen skærm er det.
Det skal I lade være med
- At overvåge alt lige meget. Fokusér på de systemer, testen rører den dag.
- At tolke enhver top som testen. Sammenhold med jobplanen og testerens aktivitet først.
- At glemme lagerplads og logvolumen. Et fuldt logsystem mister også det, I skal bruge bagefter.
- At justere tærsklerne ned for at få ro. Så forsvinder netop de advarsler, der skulle fange et problem.
- At lade testen køre uden for arbejdstid uden overvågning. Nogen skal kunne se og reagere.
Hvad kan og ikke kan konkluderes
En test, der ikke gav driftsadvarsler, har ikke nødvendigvis været skånsom. Overvågningen ser kun det, den er sat op til at måle. Omvendt er en driftsadvarsel under testen ikke i sig selv et sikkerhedsfund, men den kan pege på systemer, der tåler for lidt, og som bør have opmærksomhed uafhængigt af testen. Notér den slags i driftsloggen, så den kan tages med i opfølgningen.
Tjekliste til driftsovervågningen
- ☐ Er det normale billede målt for systemerne i opgaven?
- ☐ Er faste job i testperioden noteret?
- ☐ Ved driften, hvilke systemer testeren arbejder på hver dag?
- ☐ Er tærskler for notér, spørg og stop aftalt?
- ☐ Følges lagerplads og logvolumen?
- ☐ Er der overvågning, når testeren arbejder uden for arbejdstid?
Kilder
- NCSC (UK): Penetration testing: testerne skal undgå unødig påvirkning, men uventede reaktioner kan ikke udelukkes; test uden for arbejdstid og kritiske systemer drøftes ved afgrænsningen.
- NIST SP 800-115: direkte test af systemer kan føre til uventede stop, og organisationen fastlægger det acceptable niveau af indgriben.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Alarmer under testen · Backup og gendannelsespunkt før testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
