Kundens rapport er kommet, og et af de alvorlige fund ligger i et system, I ikke har ansvaret for: forretningssystemet hos en branchespecifik leverandør, hjemmesiden hos et webbureau eller en firewall, som en anden partner passer. Som driftsleverandør skal I ikke rette det, men I er sandsynligvis dem, der opdager, at ingen andre gør det. Rollen hviler på tre ting: at fundet når den rette ejer, at kunden ved, hvor det ligger, og at nogen følger op, til det er lukket.
Det lyder enkelt. I praksis kan et fund i et grænseområde blive liggende, fordi alle parter tror, det er en andens opgave.
Hvorfor fund havner mellem leverandørerne
En kundes IT kan være drevet af flere leverandører på én gang. Der kan være driftsaftalen med jer, en aftale om forretningssystemet, en webaftale og måske en hostingaftale. Testeren afprøver det, kunden har bestilt, uanset hvem der drifter det. Rapporten følger systemerne og ikke kontrakterne.
Den fælles vejledning fra NCSC (UK), CISA og andre myndigheder om MSP’er anbefaler, at leverandøren tydeligt forklarer, hvilke ydelser kunden køber, og hvilke den ikke køber, og at kunden selv tager hånd om de huller, der ligger uden for aftalen. Et fund uden for jeres aftale er netop sådan et hul.
Første skridt: afgør, hvor fundet sidder
Før fundet sendes videre, skal det placeres præcist. Det er ikke altid åbenlyst.
- I produktet · svagheden ligger i selve softwaren og kan kun rettes af producenten.
- I opsætningen hos den anden leverandør · produktet er fint, men indstillingerne er ikke.
- I grænsefladen · systemet er sårbart, fordi jeres net eller jeres regler giver adgang til det.
- Hos jer alligevel · servere eller netværk under systemet kan være jeres, selv om programmet ikke er.
Den sidste gruppe er vigtig. Hvis forretningssystemet er eksponeret, fordi en firewallregel, I administrerer, åbner for det, så er en del af rettelsen jeres. → Rettelser efter kundens test
Hvem fortæller hvem
Kunden ejer rapporten og relationen til den anden leverandør. Fundet skal derfor sendes videre efter kundens ønske. Aftal med kunden, om I sender fundet direkte, eller om kunden gør det. Begge dele kan fungere, men det skal være klart.
Når fundet sendes, skal modtageren have nok til at forstå og rette det, men ikke hele rapporten. Send beskrivelsen af det konkrete fund, de berørte systemer og testerens anbefaling. Resten af rapporten handler om andre systemer og andre leverandører og hører ikke hjemme hos dem. → MSP’ens kommunikation om fund
Hvis svagheden ligger i et standardprodukt, kan det være relevant at undersøge, om den allerede er offentligt kendt og har et CVE-nummer. Det hjælper den anden leverandør med at finde producentens rettelse.
Skriv en kort ledsagetekst, når fundet sendes. Den skal sige, hvem der har bestilt testen, at kunden har givet lov til, at fundet deles, og hvem modtageren kan kontakte med spørgsmål. Bed om en bekræftelse på, at fundet er modtaget, og om et skøn over, hvornår der kommer en vurdering. Uden den bekræftelse ved ingen, om fundet faktisk er landet hos en person, der kan handle på det.
Midlertidigt værn i jeres del af miljøet
I kan ikke rette i et system, I ikke drifter. Men I kan måske gøre noget i det, I drifter, mens ejeren arbejder på en rettelse. Det skal altid aftales med kunden.
- Begrænset adgang · færre net eller brugere, der kan nå systemet.
- Ekstra overvågning · opmærksomhed på systemet i jeres overvågning, hvis den dækker det.
- Midlertidig lukning af en indgang · hvis kunden accepterer, at en funktion er utilgængelig en periode.
Tiltagene skal have en ejer og en udløbsdato, så de ikke bliver permanente uden beslutning. → Midlertidige afhjælpninger
Opfølgning: fundet skal have en sag
Et fund, som ingen har i sit opgavesystem, forsvinder. Opret en sag hos jer, selv om rettelsen ligger hos en anden. Sagen skal ikke beskrive jeres arbejde, men jeres opfølgning: hvem fik fundet, hvornår, hvad svarede de, og hvornår spørger I igen. → Fra fund til ticket
Giv kunden status på disse fund sammen med de fund, I selv retter. Kunden skal have ét samlet billede, ikke en liste fra hver leverandør. Hvis en leverandør ikke reagerer, er det kundens beslutning, hvad der så skal ske. Jeres opgave er at gøre kunden opmærksom på det i tide. Hold også øje med, om en rettelse hos den anden leverandør ændrer noget i jeres del af miljøet, fx en ny adresse, en ny port eller et nyt krav til adgang, så I kan tilpasse jeres regler.
Når ansvaret er uklart
Nogle fund passer ikke ind i nogen aftale. Det kan være et system, ingen har nævnt i kontrakterne, eller en opsætning, der er lavet af en leverandør, kunden ikke længere har. I de tilfælde skal kunden beslutte, hvem der skal tage opgaven. Tilbyd gerne at løse den som en ekstra opgave, men lad være med at overtage den stiltiende. Et ansvar, I påtager jer uden aftale, kan være svært at slippe igen.
Brug i stedet anledningen til at foreslå kunden en oversigt over, hvilke leverandører der har ansvaret for hvilke systemer. Den oversigt gør næste test lettere at afgrænse og næste rapport lettere at fordele.
Det skal I lade være med
- At rette i andres systemer uden aftale · I kan bryde deres support og jeres egen aftale.
- At sende hele rapporten til en anden leverandør · send kun det, der vedrører deres system.
- At antage, at den anden leverandør har fået besked · spørg, og skriv svaret ned.
- At overse jeres egen del af et fund · net og regler under systemet kan være jeres.
- At lade midlertidige tiltag stå uden udløb · de skal have ejer og dato.
- At påtage jer ansvar uden aftale · uklare fund skal fordeles af kunden.
Hvad kan og ikke kan konkluderes
Et fund i et system, I ikke drifter, siger noget om det system og om grænsen mellem leverandørerne. Det siger ikke, at jeres drift har fejlet, og heller ikke, at den anden leverandør har. Rapporten placerer svagheden teknisk, men den afgør ikke, hvem der kontraktmæssigt skal rette. Det gør aftalerne og kundens beslutning.
Tjekliste for fund uden for jeres aftale
- ☐ Er det afklaret, om fundet sidder i produktet, opsætningen, grænsefladen eller hos jer?
- ☐ Har kunden bestemt, hvem der sender fundet videre?
- ☐ Har modtageren fået det konkrete fund og ikke hele rapporten?
- ☐ Er midlertidige tiltag i jeres del aftalt, med ejer og udløbsdato?
- ☐ Har fundet en sag hos jer med opfølgningsdatoer?
- ☐ Indgår fundet i kundens samlede status?
- ☐ Er uklare ansvarsforhold lagt frem for kunden?
Kilder
- NCSC (UK), CISA, NSA, FBI m.fl.: Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A): leverandøren forklarer, hvilke ydelser kunden køber og ikke køber; kunden håndterer huller uden for aftalen.
- CVE: fælles numre for offentligt kendte sårbarheder, så producentens beskrivelse og rettelse kan findes.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Drift af andres webapplikationer · Hosting i en ekstern test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
