Skift af hosting- eller driftsleverandør: hvad skal testes før og efter?

Når driften flytter til en ny leverandør, flytter ansvaret for mange sikkerhedsindstillinger med, også dem ingen har skrevet ned. En test omkring skiftet bygger derfor på to målepunkter: et udgangspunkt under den hidtidige drift og en kontrol af den opsætning, den nye leverandør faktisk har leveret.

Test før skiftet, hvis I har brug for at vide, hvad I tager med jer. Test efter, når den nye drift er i gang og stabil. Er der kun plads til én test, bør den som udgangspunkt ligge efter skiftet, fordi det er den løsning, kunder og medarbejdere skal leve med fremover.

Et skifte ændrer mere end fakturaen

Et leverandørskifte er et projekt med mange hænder. Servere bygges op på ny eller flyttes, regler i firewallen skrives om, adgange til fjernadministration oprettes, og domæner og certifikater skifter hjem. Arbejdet sker ofte under tidspres, med en opsigelsesdato for den gamle aftale hængende over projektet.

I et tænkt eksempel flytter webshoppen og kundeportalen fra ét hostingfirma til et andet, mens kontornettet fortsat passes af den nuværende driftsleverandør. Projektplanen handler om oppetid og om, at alt virker på flyttedagen. Om de tidligere adgangsbegrænsninger er genskabt hos den nye leverandør, står sjældent på planen, medmindre nogen sætter det der.

Gamle forhold kan også følge med uden at blive opdaget. En testserver flyttes sammen med resten, eller en administrativ adgang, som var lukket, åbnes igen for at lette flytningen og bliver aldrig lukket. → Glemte testmiljøer på internettet

Testen før skiftet giver et udgangspunkt

En test før skiftet skal ikke redde den gamle løsning. Den skal give et dokumenteret billede af de systemer, der flytter, sådan som de fungerede under den hidtidige drift. Billedet kan bruges på tre måder.

Krav til den nye leverandør · kendte svagheder kan skrives ind i flytteplanen, så de ikke bygges op igen.
Sammenligning bagefter · en senere test kan holdes op mod et kendt udgangspunkt.
Afklaring af ansvar · fund fra før skiftet hører til den gamle opsætning og ikke til den nye leverandørs arbejde.

Testen før kræver tilladelse fra den nuværende leverandør, hvis systemerne står på dennes udstyr. Under en opsigelse kan samarbejdet være anstrengt, så afklar tilladelse og kontaktperson tidligt. → Er en penetrationstest lovlig?

Er tiden knap, kan testen før afgrænses til de systemer, der skal bygges op på ny. Systemer, der flyttes uændret, kan vente til kontrollen bagefter.

Testen efter skiftet kontrollerer det leverede

Efter skiftet er spørgsmålet et andet: svarer den nye drift til det, der er aftalt? Testen bør ligge, når flytningen er afsluttet, og de midlertidige løsninger fra flytteperioden er fjernet eller i det mindste registreret. En test midt i flytningen beskriver en mellemtilstand, som snart er væk.

Scope skal navngive de systemer og adresser, der nu ligger hos den nye leverandør, og de adgange, leverandøren selv bruger til drift. Fjernadgangen til administration er et eksempel på noget, der er nyt og derfor hører med. → Leverandørers fjernadgang til jeres systemer

Kontrollér også, at den gamle platform faktisk er lukket ned. Adresser, domæner og konti, der stadig peger på den tidligere leverandør, er en del af det, virksomheden viser frem efter skiftet, selv om ingen længere passer på dem.

Tag også stilling til, om testen efter skal have samme udgangspunkt som testen før. Var den første test en ekstern test af webshoppen og kundeportalen, giver det mening at gentage det perspektiv, så resultaterne kan holdes op mod hinanden. Nye elementer hos leverandøren, som en anden måde at administrere serverne på, kan lægges oveni som en særskilt del.

To leverandører, to sæt regler

Begge leverandører kan have regler om test på deres platforme. Den nye leverandørs kontrakt kan kræve varsel, faste testvinduer eller en navngiven kontakt. Den gamle leverandørs regler gælder, så længe systemerne står der.

Rollerne under en test er beskrevet nærmere i → Driftsleverandøren og testen. Det særlige ved et skifte er, at to parter kan have adgang på samme tid, og at ingen af dem nødvendigvis føler sig ansvarlig for overgangen. Skriv i bestillingen, hvem der modtager kritiske fund i hver fase, og hvem der må stoppe testen.

Sæt testen ind i kontrakten fra starten

Det er lettere at aftale test, før kontrakten med den nye leverandør er underskrevet. Spørg, om virksomheden må lade en uafhængig tester undersøge den leverede opsætning, hvordan fund skal håndteres, og hvem der bærer omkostningen ved rettelser af forhold, som strider mod aftalen.

Aftal samtidig, hvordan fund fra testen efter skiftet behandles. Har leverandøren lovet en bestemt opsætning, og viser testen noget andet, skal det være klart, om rettelsen hører til leverancen eller er en ny opgave. Uden en aftale kan fundene ende i en diskussion om ansvar frem for i en rettelse.

ISO/IEC 27001 indeholder i bilag A kontroller om informationssikkerhed i leverandørforhold, blandt andet om krav i aftaler og opfølgning på leverandørers ydelser. Det kan bruges som baggrund for drøftelsen, men standarden kræver ikke i sig selv en penetrationstest ved hvert skifte. En leverandørs egne test kan være nyttige, men de erstatter ikke en vurdering, som virksomheden selv har bestilt. → Hostingfirmaet tester for os

Det skal I lade være med

At teste midt i flytningen · resultatet beskriver en tilstand, som ingen skal drive.
At tro, at gamle rettelser følger med · en opsætning bygget op på ny kan miste ændringer fra en tidligere test.
At glemme den gamle platform · konti og adresser, der stadig kører, er fortsat jeres eksponering.
At lade den nye leverandør afgrænse testen alene · scope fastlægges af virksomheden ud fra det spørgsmål, der skal besvares.
At bruge testen før som dom over den gamle leverandør · den er et udgangspunkt, ikke et opgør.
At vente for længe med kontrollen · når driften har kørt længe, siger testen mindre om selve skiftet.

Hvad kan og ikke kan konkluderes

En test efter skiftet kan vise, om de aftalte systemer hos den nye leverandør havde de undersøgte svagheder på testtidspunktet. Den kan ikke vise, at leverandørens øvrige drift, egne systemer eller andre kunders miljøer er i orden.

En sammenligning mellem før og efter kræver, at de to test har nogenlunde samme scope og udgangspunkt. Ellers kan forskellen skyldes opgaven og ikke leverandøren. Testen før kan heller ikke bruges som bevis for, at den gamle leverandør har levet op til sin aftale. Den viser tilstanden på testtidspunktet, ikke hvordan driften blev passet i hele aftaleperioden. → Fremskridt fra test til test