EBITS Arbetsgruppen för Energibranschens Reviderad informationssäkerhet

Transkript

1 Rapportering av Informations- och IT-incidenter Inledning Ett viktigt led i företagens förebyggande säkerhetsarbete är en väl fungerande policy och rutiner för incident- och händelserapportering. Genom att få in uppgifter om incidenter och händelser som hotar informations- och/eller IT-säkerheten kan åtgärder vidtas som försvårar och/eller förhindrar stöld av information och därmed bidrar till företagets fortlevnad. Underlaget och statistiken över inrapporterade incidenter och händelser underlättar planeringen av säkerhetsarbetet och ger underlag för vilka investeringar som kan behöva genomföras. Bra rutiner för rapportering av incidenter och händelser inom ett företag är av samma betydelse som förslagsverksamheten. De rationaliserar insatser och sparar kostnader. På markanden finns ett antal datoriserade rapporteringssystem som har till syfte att förenkla rutinerna för den som rapporterar samt för den som skall följa upp och bearbeta incidentrapporten. Läs gärna mer om incidenter och incidenthantering i ISO Vad är en incident Begreppet IT-incident har inte någon entydig definition enligt de gängse officiella begreppsförklaringarna. Det går inte heller att ange någon exakt definition pga. företagens olikheter vad avser storlek, verksamhet m.m. Det som betraktas som en incident i ett företag kanske man bagatelliserar i ett annat företag. Händelser är lättare att definiera eftersom då har det hänt något. Det är en mer påtaglig situation där inte subjektiva tolkningar ligger till grund för värderingen. Här följer ett försök att ge exempel på två betydelser av begreppet: 1. Händelse som ej lett till allvarlig skada, men om händelsen upprepades skulle den mycket väl kunna leda till allvarlig skada. Exempel: Lokalvårdaren har ställt en skurhink full med vatten i datahallen. 2. Händelse som lett till allvarlig skada. Exempel: Lokalvårdarens hink slås omkull. Datahallen blir strömlös. Bägge typerna av incidenter kan vara föranledda av ont uppsåt eller slarv vilket ger anledning till att se över rutinerna eller de tekniska skydden Informations- och IT-incidenter_v1.3.doc 1 (5)

2 Varför skall incidenter rapporteras? Utvecklingen i såväl Sverige som i vår omvärld medför att förutsättningarna att bedriva verksamhet hela tiden förändras. I vårt informationssamhälle är det just informationen och immateriella värden som är det viktiga och som har betydelse för ett företags fortlevnad. Varje chef måste därför kontinuerligt ta ställning till hot och risker inom sitt ansvarsområde. Därför är en kontinuerlig uppföljning av händelser som inträffat både inom och utanför företaget absolut nödvändig, vilket ökar möjligheten att vidta rätt åtgärd vid rätt tidpunkt. Det är också väsentligt att kunskaper om existerande hot och möjliga skyddsåtgärder sprids inom företaget för att öka riskmedvetenheten bland de anställda. Observera att det är inte enbart är hot mot information som finns i IT-system som omfattas av incident och händelserapporteringen utan detta gäller alla typer av information såsom dokument, ritningar, fotografering, muntlig information m.m. Notera att incidenter som har eller kan ha betydelse för säkerhetsskyddet ska rapporteras till SvK enligt SvKFS 2013:1. Informations- och IT-säkerhet en allt viktigare fråga Dagens företag och industrier liksom hela vårt samhälle blir allt mer beroende av datorer, nätverk, telefonväxlar, kommunikation m.m. Därmed har en hel del nya hot uppstått mot informationen såväl internt i företagen som från externt håll. Genom en fungerande incident- och händelserapportering underlättas bedömningar och/eller beslut om säkerhetshöjande åtgärder för en i företaget. I begreppet ingår även säkerheten för IT-system och kommunikation för produktion och överföring av el och värme. Det finns en tendens, som blir starkare för var dag som går, att de administrativa systemen i ett företag kommer närmare de processnära systemen. Därmed ökar risken att vi får störningar i energiförsörjningen pga. angrepp mot de administrativa systemen. IT-säkerhetshot Hoten mot IT-miljön kan delas upp i tre grupper: fysiska, organisatoriska och logiska hot. Med fysiska hot avses hot där man genom fysisk skada, åverkan m m åstadkommer sådan skada att företaget eller dess organisation inte kan bedriva normal verksamhet. Exempel på fysiska hot: brand, elavbrott, vattenskador, datorhaveri (krascher), inbrott/stöld, skadegörelse och sabotage. Med organisatoriska hot avses hot som uppstår för företaget eller organisationen på grund av bristande organisation, planering, avsaknad av regelverk, kompetensbrist, illojala anställda, slarv, missbruk av befogenheter m.m Informations- och IT-incidenter_v1.3.doc 2 (5)

3 Logiska hot omfattar svagheter i program, operativsystem och applikationer som möjliggör angrepp mot system, databaser och/eller kommunikationen på många olika sätt. Exempel på logiska hot: Hacker (inbrott i datorsystem för nöjes skull eller målinriktat i skadligt syfte), virus (skadlig program-kod som kan sprida sig själv), trojanska hästar (skadlig programvara som kan utföra avancerade uppdrag ), avlyssning av nätverk, kända säkerhetshål, bristande kvalitet på lösenord och RÖS (röjande signaler). Förslag till företagsintern rapporteringsrutin för incidenter Företaget bör ha en policy och en fastställd rutin för intern rapportering av incidenter och händelser i syfte att förebygga alvarliga händelser och/eller skada för företaget eller dess personal. Det får på inga villkor finnas en misstanke att denna typ av rapporter kommer att användas mot personalen som förorsakat incidenten och/eller händelsen eller rapporterat densamma. Detta bygger på ett ömsesidigt förtroende mellan arbetsgivare och arbetstagare. Förtroendet byggs upp successivt och är mycket beroende på vilket sätt en rapporterad incident och/eller händelse hanteras inom företaget eller verksamheten. Att exakt definiera vad som skall rapporteras är inte lätt. En händelse som är uppenbart harmlös kan om den sätts in i ett större sammanhang visa på ett oroande mönster som i förlängningen skulle kunna utveckla sig något allvarligt. Det är med andra ord bättre att rapportera en gång för mycket än att låta bli. Följande bör beaktas vid upprättande av policy och/eller rutiner för incidentoch händelserapportering inom ett energiföretag: Företagsledningens syn på behovet av en fungerande incident- och händelserapportering Policy för företaget om hantering av personal som rapporterar att de gjort fel. Ej bestraffning belöning i stället! Vilket rapporteringssystem eller vilka rapporteringsrutiner gäller Vem/vilka är skyldiga att rapportera incidenter och/eller händelser Hur rapporteringen skall ske dels på framtagen blankett (se bilaga med exempel) eller via e-post, telefon eller muntligt till närmaste chef Roller och ansvar för mottagning, uppföljning, handläggning och återkoppling av rapporter inom olika aktuella områden inom företaget Analys av händelsen och förslag till åtgärder Statistiksammanställning för företaget och vid behov för olika avdelningar och/eller verksamheter inom företaget Rutiner skall finnas för arkivering, bearbetning och uppföljning av incident och händelserapporter Informations- och IT-incidenter_v1.3.doc 3 (5)

4 Process för informations- och IT-incidentrapportering All personal och användare samt personal på IT-avd. Samordnaren för incidentrapportering Chef, IT-chef eller motsv. Rapporten måste kompletteras Händelse upptäcks Händelse rapporteras Incidentrapport granskas Arkivering statistik analys Blankett för rapportering Förslag på blankett framgår av bilaga. Blanketten måste anpassas till de behov respektive företag har. Datastödd rapportering via webbgränssnitt kan vara ett alternativ till den manuella rutinen. Även rapportering på andra typer av media t ex e-post bör accepteras. Det är viktigare att få in rapporten än valet av det sätt som rapportering sker på. Frågor Frågor kan ställas till EBITS via e-post ebits_box@svenskenergi.se Informations- och IT-incidenter_v1.3.doc 4 (5)

5 Förslag på blankett för incidentrapportering Incident/händelse: SEKRETESSKLASS Företagshemlig Företagsintern Uppgiftslämnare NN Namn på den som upptäckt IT-incidenten. Medhjälpare NN Namn (och företag) som varit behjälplig vid analys och åtgärder för att undanröja problemet. Datum för problem c:a ÅÅÅÅ-MM-DD - ÅÅÅÅ-MM-DD Datum för när problemet uppdagades och när det avhjälptes. Beskrivning av problem Kompletterande tekniska uppgifter Analys av problem Orsak till problem Hur problemet avhjälptes Konsekvenser av problemet Kvarstående frågor Rekommendation för framtiden Berört/berörda system Beskriv problemet så kortfattad som möjligt men ändå så utförlig att det går att förstå vilket problem som avses. Teknisk information som beskriver den miljö som händelsen har uppträtt i. Här kan man också beskriva om man har vidtagit någon speciell åtgärd av intresse innan problemet uppstod. Beskriv vad du gjort för att förstå problemet bättre. Den bakomliggande orsaken till att problemet uppstod. Vilka handgrepp eller tekniska förändringar som vidtagits för att avhjälpa problemet. Konsekvenserna finns möjligen på flera nivåer. Här följer några: - Verksamhetskonsekvenser (t ex förlust av information) - Ekonomiska konsekvenser (t ex konsultarvode för att lösa problemet) - Konsekvenser gentemot extern part (t ex förtroende och tillit) Det kan vara så att man inte är säker på att man löst problemet fullt ut. Det kan också vara så att problemet har fått följdverkningar för andra system eller andra verksamheter i företaget, och man har då kanske inte klart för sig omfattningen av detta till fullo. Åtgärder att vidta för att råda bot på uppdagade brister i teknik och/eller rutiner. Andra system som berörts. Ort och datum: Underskrift av rapportör:.. Underskrift Ansvarig chef: Informations- och IT-incidenter_v1.3.doc 5 (5)