Kort sagt: En tabletop-övning inom IT spelar igenom en säkerhetsincident vid bordet: En moderator ger steg för steg ny lägesinformation, deltagarna beslutar som i ett skarpt läge och till slut finns en lista över konkreta förbättringar. För webbservrar lämpar sig ett scenario efter mönster av PHP2Shell, eftersom det berör teknik, beslut under osäkerhet, dataskydd och kommunikation på samma gång.
Varför en plan först verkar genom övning
Många företag har numera en krisplan. Om den fungerar visar sig dock först när någon använder den under tidspress. Står rätt telefonnummer i den? Vet ledningen att den måste besluta om en avstängning? Känner leverantören till åtkomsterna? Sådana frågor klarlägger en övning vid bordet på några timmar.
Oktoberveckan 2026 visade hur snabbt ett läge kan eskalera: förhandsmeddelande från php.net den 20.10., patchar den 21.10. kl. 16 tysk tid, BSI:s (tyska förbundskontoret för informationssäkerhet) varningsnivå orange, avstängningar av offentliga webbplatser enligt medierapporter. Den som hade övat den här följden en gång i förväg behövde improvisera mindre. Förloppet i detalj beskriver Kronologin för PHP2Shell. Hur ni bygger upp själva planen står under Ta fram en IT-krisplan för webbservrar; här handlar det om att öva.
Tabletop-övning inom IT: roller och förberedelse
En bra övning behöver lite material men tydliga roller. Moderatorn leder genom manuset, spelar in information och håller tiden. Hen diskuterar inte med utan ställer frågor. En protokollförare noterar beslut, öppna frågor och varje ställe där någon säger ”det skulle jag inte veta nu”. Som tillval iakttar ytterligare en person hur kommunikationen fungerar.
Deltagarna är de människor som faktiskt agerar i ett skarpt läge: ledning, intern IT eller extern leverantör, dataskyddsombud, kommunikation och vid behov inköp eller juridisk avdelning. Viktigt är att ersättare är med, för incidenter håller sig inte till semesterplaner.
Till förberedelserna hör: den aktuella krisplanen på papper, kontaktlistan, en översikt över webbplatser och servrar och ett rum utan avbrott. Bestäm i förväg att det handlar om att lära, inte om betyg. Den som är rädd för att blamera sig säger inte vad hen inte vet.
Ett färdigt manus: kritisk PHP-lucka på fredag eftermiddag
Följande scenario är fiktivt men följer mönstret av ett verkligt läge. Anpassa system och namn till er miljö. Varje inspel får tio till tjugo minuters diskussion.
| Steg | Moderatorns inspel | Ledande fråga till gruppen |
|---|---|---|
| 1 | Fackpressen rapporterar en kritisk lucka i PHP, patchar är aviserade men finns inte än. | Vem får veta det först, och vem måste informeras? |
| 2 | Patcharna kommer på eftermiddagen. BSI rekommenderar omedelbar uppdatering, annars tillfällig avstängning. | Vilka av våra system berörs, och hur vet vi det? |
| 3 | Hostingleverantören hör inte av sig. En egen server kör en PHP-version utan officiell uppdatering. | Patcha, stänga av eller avvakta, och vem beslutar det? |
| 4 | Webbshoppen ska köra en kampanj i helgen. Försäljningen trycker på att inget ska stängas av. | Hur väger vi omsättning mot risk, och hur dokumenterar vi beslutet? |
| 5 | En administratör hittar på måndagen en okänd PHP-fil i uppladdningsmappen. | Vad gör vi först, vad låter vi medvetet bli? Vem säkrar bevis? |
| 6 | Det är oklart om kunduppgifter har läckt ut. | Vem bedömer en möjlig anmälningsplikt, och när löper fristen? |
| 7 | En journalist frågar varför webbplatsen är offline. | Vem talar utåt, och vad säger vi så länge vi vet lite? |
Steg 6 berör GDPR. I övningen räcker det att klargöra förloppet: vem som involverar dataskyddsombuden och när. Den juridiska bedömningen ligger kvar hos fackfolk; grunddragen om fristen står i art. 33 GDPR.
Typiska insikter och hur ni dokumenterar dem
Vissa luckor dyker upp vid nästan varje första övning. Det saknas en fullständig lista över vilka webbplatser som körs på vilka servrar med vilken PHP-version. Hostingleverantörens kontaktuppgifter är föråldrade eller lagrade bara i en brevlåda som inte går att nå i ett skarpt läge. Ingen vet säkert om ledningen själv får beordra en avstängning eller om någon måste godkänna.
Dokumentera varje insikt i tre delar: vad vi konstaterade, vad vi ändrar och vem som gör det senast när. En insikt utan ansvarig blir erfarenhetsmässigt liggande. Ordna punkterna efter effekt: Ett saknat nödnummer är snabbt åtgärdat och hjälper direkt, en ny övervakningslösning kräver planering.
För den strukturerade utvärderingen efter övningen lämpar sig samma tillvägagångssätt som efter en verklig incident. Det beskrivs i inlägget Lessons learned: bli bättre efter incidenten. Kontaktlistan, som i övningen oftast visar svagheter, behandlar Nödkontakter: vem måste informeras och när?.
Upprepa övningen efter sex till tolv månader med ett annat scenario, till exempel en hackad webbplats med omdirigering till främmande sidor. Så prövar ni om åtgärderna från den första omgången verkligen genomfördes.
Hur hjälper PHP SOS konkret?
- Vi anpassar manuset till era verkliga webbplatser, servrar och leverantörer och förbereder inspelen.
- Vi modererar övningen på distans eller via videokonferens och håller tillbaka med bedömningar tills gruppen har beslutat.
- Vi levererar därefter ett protokoll med insikter, åtgärder, ansvariga och datum.
- På begäran övar vi därefter den tekniska delen, alltså inventering, patch och spårsökning, så som vår Incident Response avverkar den i ett skarpt läge.
Slutsats
En krisövning vid bordet är det billigaste sättet att hitta svagheterna i en krisplan innan en verklig incident gör det. En eftermiddag, ett realistiskt manus och en ärlig utvärdering räcker till en början. Avgörande är att varje insikt blir en uppgift med namn och datum.
Vanliga frågor
Vad är en tabletop-övning?
En övning där de inblandade tillsammans talar igenom en incident vid bordet, utan att arbeta på verkliga system. En moderator spelar steg för steg in ny information, gruppen beslutar och motiverar. Så blir luckor i plan, ansvar och kontaktlistor synliga.
Vem bör delta i en krisövning?
Alla som i ett skarpt läge beslutar eller agerar: ledning, IT eller leverantör, dataskydd, kommunikation och, om sådan finns, den som ansvarar för försäkringsfrågor. Fler än åtta till tio personer gör rundan trög.
Hur lång tid tar en tabletop-övning?
För en första genomgång räcker två till tre timmar inklusive utvärdering. Viktigare än längden är att resultaten dokumenteras och att åtgärder fördelas med datum.
Måste scenariot vara realistiskt?
Det bör passa er miljö, men behöver inte stämma in i detalj. Ett scenario efter mönster av ett verkligt läge som PHP2Shell verkar trovärdigt och riktar diskussionen mot beslut i stället för tekniska detaljer.