Håndtering af hændelser

Transkript

1 ROSKILDE UNIVERSITET Internt notat Finans, IT og Teknik/hje Håndtering af hændelser Formål Hændelser og/eller uhensigtsmæssigheder i forbindelse med anvendelse af udstyr og/eller it-systemer, skal kommunikeres på en sådan måde, at der kan iværksættes de rette korrigerende handlinger og påvirkning af produktionsmiljøet begrænses. Alle ansatte er ansvarlige for at indrapportere hændelser i de it-systemer og/eller det udstyr som de anvender eller har ansvar for. En del af dette ansvar er pligten til at rapportere enhver mistanke eller vished for hændelser. Målgruppe og ansvar Målgruppe Gælder Vedligeholdelse Ansvarlig for It-afdelingerne X Campus-IT X Brugere X Sikkerhedskonsulenten X X Procedure Når en hændelse konstateres skal denne prioriteres og gennemgå RUC s eskaleringsprocedure Bilag A for eskalering af hændelser. Prioritering Prioriteringen er et produkt af konsekvensen (impact), eller hvilken effekt en given hændelse kan have på forretningsførelsen og en vurdering af, hvor meget en given hændelse haster med at få udbedret (urgency), før det vil give forretningsmæssige konsekvenser. Skala for urgency er i udgangspunktet defineret som følger: Uopsættelighed Urgency 1 (Immediately) Urgency 2 (High) Urgency 3 (Normal) Verbal forklaring Har brug for en øjeblikkelig håndtering Har brug for håndtering inden for 4 timer Der er ingen øvre grænse for håndtering (næste servicevindue) Skala for impact er i udgangspunktet defineret som følger: Konsekvens Verbal forklaring Impact 1 En større gruppe af brugere er berørt. Hændelsen rammer hele universitetet og det skønnes at mere end 100 brugere er berør af hæn- (Extreme) delsen. Impact 2 (High) Impact 3 (Medium) En mindre gruppe af brugere er berørt. Hændelsen er regional (f.eks. et enkelt institut) og det skønnes at mindre end 50 brugere er berørt af hændelsen Få personer er berørt. Hændelsen er lokal og det skønnes at 1 2 brugere er berørt af hændelsen RUC_Procedure_Håndtering af hændelser 8

2 Side 2 Campus IT har udarbejdet følgende retningslinjer for prioritering af hændelser. Hændelserne gøres afhængig af impact (konsekvens) og urgency (uopsættelighed). Prioritet er genereret fra urgency og impact i henhold til nedenstående tabel: Impact 1 (Extreme) Impact 2 (High) Impact 3 (Medium) Urgency 1 (immediately) Urgency 2 (High) Urgency 3 (Normal) Prioritet 5 Prioritet 4 Prioritet 3 Prioritet 4 Prioritet 3 Prioritet 2 Prioritet 3 Prioritet 2 Prioritet 1 Prioritet = Hvor hurtigt kunden vurdere, at Campus IT skal reagere på en hændelse: Prioritet Reaktion - Mål for løsning (TTR) HelpDesk Prioritet 5 5 minutter Inden for 2 timer Prioritet 4 30 minutter Inden for 4 timer Prioritet 3 2 timer Inden for 8 timer Prioritet 2 8 timer Inden for 2 arbejdsdage, efter aftale, eller ved næste servicevindue Prioritet 1 16 timer Inden for 5 arbejdsdage eller ved næste servicevindue Eskalering Alle hændelser som indrapporteres, eskaleres mellem forskellige niveauer for teknisk assistance, der alle har til formål, at håndtere indkommende hændelser eller forespørgsler rettidigt. Dette efter følgende nedenstående prioriteringsskala. Prioritet Kategorisering Definition 5 Hardwarefejl IT systemet eller væsentlige dele af det er ude af funktion, således at afviklingen af systemet er generet i en sådan grad, at systemet ikke er brugbart. Dette kan eksempelvis være en fejlbehæftet strømforsyning eller interne komponenter i udstyret som fejler og dermed generer eller forhindrer afvikling af datatrafik (eksemplet er ikke udtømmende). 4 Funktions- og softwarefejl IT systemet eller væsentlige dele af det er ude af funktion, således at individuelle systemkomponenter ikke kan afvikle datatrafik eller afviklingen er generet i en sådan grad, at tjenesten som helhed ikke er brugbar. Dette kan eksempelvis være en log som er løbet fuld og dermed generer eller forhindrer afviklingen af systemet. Det kan også være fejl i softwaren (eksemplerne er ikke udtømmende). 3 Mindre fejl Mindre fejl der ikke hæmmer IT systemets funktionalitet, men som skal rettes af it-afdelingen eller leverandøren inden en forud aftalt frist. 2 Rettelser Der er tale om sikkerhedsmæssige opdateringer (patches) eller opgraderinger af systemet. 1 Ændringer Der er tale om funktionsmæssige ændringer til systemet I bilag A er beskrevet forretningsgangene for eskalering af hændelser på universitetet.

3 Side 3 Kontaktliste Samarbejdspartnere Funktion Navn Tlf.nr. Mobilnr. Internet (forskningsnettet) DeiC STADS Logica (CGI) Navision Moderniseringsstyrelsen F2 cbrain ifolder Novell Exchange, AD, LYNC m.v. Atea Hackere (angreb) CSIS Hackere og virus (hændelsesrapportering) DKCert Hackere og virus (Anmeldelse) Politi Fejl i applikationer Denne procedure beskriver de forholdsregler, som skal træffes af brugere og it-afdelingen i tilfælde af fejl i applikationer. Afhængig af applikationen der er berørt, tildeles der forskellig prioritet i henhold til retningslinjerne for prioritering. Se afsnitte om eskalering for videre instruks. 1. It-afdelingen undersøger de gældende eskaleringsretningslinjer med udgangspunkt i den tildelte prioritet. 2. It-afdelingen eskalerer og fejlsøgningens påbegyndelse i henhold til eskaleringsretningslinjerne. 3. It-afdelingen undersøger de applikationer vi selv drifter, event-loggen for eventuelle fejl. 4. Kan fejlen ikke udbedres ud fra de ovennævnte punkter, kontaktes ekstern assistance i henhold til kontaktlisten. Fejl i systemet 1. It-afdelingen undersøger de gældende eskaleringsretningslinjer. 2. It-afdelingen undersøger først om internetforbindelsen virker korrekt, brug evt. proceduren ved fejl på Internetforbindelsen. 3. It-afdelingen undersøger, hvis fejlen ikke findes i pkt. 2, om der er fejl på selve firewall forbindelsen. 4. It-afdelingen undersøger, hvis fejlen ikke findes i pkt. 3, om der er fejl på Exchangeserveren eller specifikke konti. 5. It-afdelingen undersøger, hvis fejlen ikke findes i pkt. 2 til 4, om der er fejl på SAN eller forbindelsen mellem Exchange Server og SAN eller switche

4 Side 4 6. Kan fejlen ikke udbedres ud fra de ovennævnte punkter 2 til 5, kontaktes ekstern assistance i henhold til kontaktlisten. Fejl på internetforbindelsen 1. Først tjekkes det, om det rent faktisk er internetforbindelse som er forsvundet eller at der er fejl i infrastrukturen (f.eks. DNS fejl), dette tjekkes ved at udføre en ping til en ekstern lokation, f.eks. ping hvis der svares er internetforbindelsen ok og der skal fejlsøges andre steder, ellers skal der fortsættes med pkt Der skal nu findes ud af, hvorvidt det er et brud på Forskningsnettets linjer eller de redundante løsninger, der også er en del af internetforbindelse. 3. For at konstatere om der problemer med forbindelsen til firewall en, skal der foretages et ping på de to firewalls (se ip-adresse på dokumentationen over RUCs internetforbindelser), svares der ikke er fejlen fundet ellers fortsæt til pkt For at konstatere om forbindelsen til den redundante switch, der styre internettet ad den primære eller backup linje, skal der foretages ping på begge disse (Se ipadresse på dokumentationen over RUCs internetforbindelser), svares der ikke er fejlen fundet og Deic kontaktes, ellers fortsæt til pkt Vi har nu fejlsøgt på alle interne fejlmuligheder og fejlen må være på Forskningsnettets forbindelse. Kundeservice hos DeiC kontaktes, der skal oplyses institution og resultatet af undersøgelserne, hvis DeiC kender fejlen, er denne fundet og der spørges, hvor lang tid det tager at rette fejlen. 6. Hvis det skønnes relevant sendes en intern til alle brugere på RUC (der kan ikke sendes til eksterne samarbejdspartnere, disse må kontaktes manuelt), hvor der informeres om fejlens art, tidslængde og informere samtidig om, at det ikke er muligt at sende eller modtage eksterne eller at anvende internettet, så længe fejlen varer. Fejl på VPN-forbindelser 1. It-afdelingen undersøger de gældende eskaleringsretningslinjer 2. It-afdelingen undersøger først om internetforbindelsen virker korrekt, brug evt. proceduren ved fejl på Internetforbindelsen. 3. It-afdelingen undersøger, hvis fejlen ikke findes i pkt. 2, om der er fejl på firewallens VPN modul eller på selve firewall forbindelsen. 4. It-afdelingen undersøger, hvis fejlen ikke findes i pkt. 3, om der er fejl på VPN LDAP serveren eller forbindelsen mellem LDAP serveren og RND. 5. Kan fejlen ikke lokaliseres ud fra de ovennævnte pkt. 2, 3 og 4 kontaktes ekstern assistance i henhold til kontaktlisten. Ved hackerangreb 1. Der skal oprettes en elektronisk log på en arbejdsstation, alt hvad der observeres skal noteres til senere evt. retsforfølgning. Loggen skal indeholde enhedens navn, ipadresse, dato og tid samt evt. handlinger foretaget på enheden der er blevet hacket. (check altid at dato og tid er korrekte). 2. Luk/spær for alt outbound trafik i firewallen.

5 Side 5 3. Observer i firewall loggen, hvor forsøg på udgående trafik kommer fra (internt) og hvilken ip-adresse hackerangrebet kommer fra (eksternt) 4. Når den (eller de) kompromitterede enhed (-er) er lokaliseret, lukkes der kontrolleret ned for firewallen. 5. Kontakt samarbejdspartneren (CSIS) til undersøgelse af skadesomfang og selve hændelsen. Samarbejdspartneren overtager styringen af den videre proces. 6. Dernæst skal der tages et image af hele indholdet på serveren (-erne) og hele imagefilen (-rne) skal sikres med en md5-checksum som bevissikring [bør måske være en del af ovenstående samarbejdspartneres arbejdsopgave]. 7. Herefter underretter it-chefen universitetsdirektøren, mail-relay serviceleverandøren og de lokale myndigheder (politi og DKCert) på. 8. Hvis det skønnes nødvendigt underrettes brugerne via mail, om lukningen af firewall og dermed adgang fra ekstern hold (også til *.ruc.dk og mail) samt årsagen til dette. Det videre arbejde med oprydning, planlægges herefter af samarbejdspartneren i samarbejde med it-sikkerhedsfunktionen og it-afdelingen, og hændelsesrapporteringen forberedes. Ved virusangreb 1. Alt arbejde på den pågældende PC indstilles. 2. Der noteres (på papir) alle umiddelbart tilgængelige oplysninger om identitet, kendetegn og lignende som bliver givet på skærmbilleder 3. Afbryd netværksadgang for Pc en forsøg ikke at afbryde strømmen på Pc en. Hvis du er i tvivl om, hvad der er hvad, så ring til Helpdesk på tlf.: eller helpdesk@ruc.dk. Uden for kontortid til teamlederen Mads Sinkjær Kjærgaard på tlf.: Pc en må IKKE anvendes igen før it-afdelingen giver tilladelse hertil. 5. It-afdelingen undersøger om det er en enkeltstående hændelse, eller om der er tale om et omfattende angreb af et skadevoldende program. 6. Hvis it-afdelingen vurderer, at der er et større angreb af et skadevoldende program i gang på Internettet skal der tages stilling til, hvilke forholdsregler der skal træffes herefter, og hvorvidt Exchange serverne skal lukkes ned. Herefter underretter itsikkerhedskonsulenten universitetsdirektøren. 7. Brugerne underrettes telefonisk, via funktionslederen, om eventuelle handlinger, som bør udføres af brugerne selv. Det videre arbejde med oprydning planlægges herefter af teamlederen i samarbejde med itsikkerhedsfunktionen.

6 Side 6 Stjålet eller mistet udstyr Ved udlån af mobilt udstyr til medarbejdere underskrives blanket, hvoraf fremgår serienummeret på genstanden. Denne blanket arkiveres i supportfunktionen som registrering. Ved tyveri eller bortkomst af enheder meddeles dette til it-afdelingen, ved tyveri foretages endvidere politianmeldelse. Der indkøbes efterfølgende nyt tilsvarende udstyr, idet universitetet som statslig institution er selvforsikrende. Procedure ved mistet udstyr 1. Al bortkomst af it-udstyr skal øjeblikkelig meldes til it-afdelingen 2. It-afdelingen skifter password på brugerens AD konto 3. It-afdelingen sletter evt. brugeren fra poolen af trådløse adgangsprofiler hvis det er en bærbar pc der er mistet 4. It-afdelingen opretter evt. brugeren til trådløs adgang igen, men med en anden brugerkonto 5. It-afdelingen melder enheden stjålet hos HRK (de kontakter relevante myndigheder, husk reference fra anmeldelse til politiet) 6. It-afdelingen holder i en periode øje med, om nogle prøver at forbinde sig med den gamle brugerprofil via netværket, det trådløse netværk eller via VPN. Dokumentation af hændelsen Dokumentationsforholdsregler ved hændelsesrapportering: a. Hvordan og hvorfor skete det? b. Hvordan det er muligt at undgå samme sikkerhedshændelse igen c. Dokumentér skadens omfang og betydning d. Opdater relevante retningslinjer og forholdsregler. e. Indrapportering til myndigheder og DKCert (it-sikkerhedsfunktionen ved Virus og hackere) Undtagelser Ingen Referencer Informationssikkerhedspolitikken for RUC Kontroller I tilfælde af misligholdelse, forelægges sagen straks for It-sikkerhedsudvalget. Vedligeholdelse IT-sikkerhedskonsulenten

7 Side 7 Revision Version Forfatter Kontrolleret af Kontrol Godkendt Ændring 1.0 Henrik HJE Første udgave Jensen 1.1

8 Side 8 Bilag A Eskaleringsprocedure IT afdeling (Daglig drift) Automatisk overvågning Institutter Biblioteket Content Provider (DeIC o.l.) FA brugere Help Desk Brugerservice Help Desk Opret sag SPOC (Single Point Of Contact) Opret hændelsen i systemet Level 1 Målrettede Spørgsmål (dataindsamling) Definition af fejlområde, prioritering og eskalering til 2. level Hændelseshåndtering Information til opdragsgiver/ interessent Vurdering af konsekvens og uopsættelig For prioritet 4 eller 5 Ændringsstyring Afslut og registrer fejlen Rettelse og/ eller ændring påbegyndes Bestil hardware Skal der foretages Hardwareudskiftning Ja Ja Eskaler til level 3 Kan vi selv rette fejlen For prioritet 1, 2 eller 3: Teamlederen informeres Level 2 Målrettet fejlsøgning Problemhåndtering med evt. hardwareudskiftning 3rd level ressource mobiliseres (leverandører, samarbejdspartnere, egne specialister) Level 3 Detailkortlægning af problem Findes der en midlertidig Workaround? Rettelse og/ eller ændring påbegyndes Virker workaround? Den rigtige løsning planlægges og beskrives Information til Interessenter? Problemanalyse Information til Interessenter? Kan fejlen løses inden for 8 timer Skal der foretages Hardwareudskiftning Rettelse og/ eller ændring påbegyndes Afslut og registrer fejlen Detaljeret problemrapport Ja Bestil hardware Information til Interessenter? Katastrofehåndtering Strategisk ledelse informeres; It-ansvarlige Level 4 Er situationen forretningskritisk? Ja Aktivering af katastrofeberedskab* Handlingsplan for håndtering udarbejdes