ITIL og DS484/ISO27001

Transkript

1 ITIL og DS484/ISO27001 Sikkerhed for sikkerhedens skyld? Allan Bjerre Afdelingsleder, Service Delivery Management Siemens IT Solutions & Services Siemens IT Solutions & Services 2008 Slide 1 af 289

2 Agenda Siemens Koncernen ISO27001 & DS484 rammen om informationssikkerhed Hvordan mødes Service Desk & ISO27001/DS484 Praktiske Eksempler Konklusion 2

3 Siemens Koncernen 3

4 3 sektorer Industry Energy Healthcare Cross-Sector activities Automation and Drives Industrial Solutions and Services Siemens Building Technologies Transportation Systems OSRAM Power Generation Power Transmission and Distribution Medical Solutions IT Solutions and Services Siemens Financial Services Ca medarbejdere 4

5 Siemens IT Solutions & Services en Global spiller 5

6 Siemens IT Solutions & Services Det globale Siemens IT Solutions & Services Globale Produktions Centre (GPC) Industrialiseret Produktion Højt specialiserede services Ca ansatte Service Desk Desktop & Server Network Application Operation Det lokale Siemens IT Solutions & Services Application Management Professional Services Lokalt produktions center (CPC) Forretningsorienterede IT- og kommunikationsløsninger målrettet private og offentlige virksomheder Kerneforretningen er IT-outsourcing. Løsningerne omfatter hele værdikæden fra design og implementering til drift og vedligehol-delse. Certificeret partner for blandt andre Citrix, SAP og Microsoft. Ca. 300 ansatte i Danmark 6

7 Og så til emnet... ISO27001 & DS484 rammen om informationssikkerhed Hvordan mødes ITIL s Service Desk relaterede discipliner med ISO27001/DS484 s rammer Er der tale om win win eller er det sikkerhed for sikkerhedens skyld? 7

8 ISO27001/2 & DS484:2005 To standarder for Informationssikkerhed De indeholder i al væsentlighed de samme kontrol områder Efterlevelse af DS484:2005 er p.t. obligatorisk i statslige virksomheder DS484 er en Dansk Standard IS er en international anerkendt standard De er begge tiltænkt at være ledelsens værktøj til at få indblik i hvilke risici virksomheden har inden for informationssikkerhed Den væsentligste forskel: DS484: Logning og overvågning ISO Monitoring Informationsbehandlingssystemer skal overvåges og Systems should be monitored and information security sikkerhedsrelaterede hændelser skal registreres. Der skal events should be recorded. Operator logs and fault være en logning, som sikrer, at uønskede forhold logging should be used to ensure information system konstateres problems are identied Hvis der er en forskel? Begge værktøjer bygger rent faktisk på statement of applicability og risikovurdering. Organisering Styring af IS aktiver Medarbejder sikkerhed Fysisk sikkerhed Styring af netværk og drift Anskaffelse, udvikling og vedligehold af systemer Styring af sikkerheds hændelser Beredskabs styring Lov og kontraktkrav Risikovurdering og håndtering 8

9 Informationssikkerhed en definition Jf. DS484:2005 defineres Informationssikkerhed som den samlede mængde af beskyttelsesforanstaltninger, der skal sikre virksomhedens daglige drift, minimere skader, samt beskytte virksomhedens investeringer og sikre grundlaget for nye forretningsmuligheder Jf. DS484:2005 opnås Informationssikkerhed ved at implementere, overvåge, revurdere og løbende ajourføre et passende sæt af beskyttelsesforanstaltninger bestående af politikker, praksis, procedurer, organisatoriske tiltag og system- eller maskintekniske funktioner Man vælger sine beskyttelsesforanstaltninger ved at tage udgangspunkt i en risikovurdering, der afdækker virksomhedens aktiver, trusler, sårbarheder og konsekvenser ved brud på fortrolighed, integritet og/eller tilgængelighed 9

10 Informationssikkerhed Trussel, Sårbarhed & Konsekvens Trussel: Udefrakommende begivenhed, der kan true en forretnings fortrolighed, integritet og tilgængelig. Eks.: Jordskælv Hackere strømafbrydelse svig Brugerfejl Sårbarhed: De svagheder en forretning har i forhold til fortrolighed, integritet og tilgængelighed Eks.: Manglende redundans Manglende patch Manglende uddannelse Manglende retningslinier Konsekvens Hvor galt går det hvis en trussel effektures eller en sårbarhed udnyttes Eks.: Taber vi data? Går forretningen i stå? Giver det image problemer? Er det ligegyldigt? 10

11 Informationssikkerhed Fortrolighed, Integritet og Tilgængelighed Fortrolighed: Fortrolighed er at sikre sine informationer på en sådan måde at de ikke kommer uvedkommende til kendskab Integritet: At sikre sin information på en sådan måde at den kan bevares i den form den var tiltænkt Tilgængelighed: At sikre sin information på en sådan måde at den er tilgængelig når den skal anvendes 11

12 Informationssikkerhed Et eksempel To glade sælgere er på vej hjem fra et kunde møde De tager naturligvis Siemens toget De diskuterer de vilkår som kunden er gået med på Ordren er stort set i hus Overfor sidder der en sød pige og smiler Fortroligheden er potentielt brudt! Det gør vi naturligvis slet ikke! - Rammerne for informationssikkerhed rækker blot udover rammerne for ITIL 12

13 Informationssikkerhed Et andet eksempel TOP SECRET F I T Trussel Sårbarheder? Konsekvens? Service Desken Incident Management Service Level Management Problem Men Management hvor kommer kravene Availability Management til Change Management Capacity Management Release processerne Management fra IT? Service Continuity Managment Configuration Management Financial Management 13

14 Informationssikkerhed Hvor kommer kravene fra? Afkast - Sikkerhed Konkurrence - Etik Lovgivning - Ansvarlighed Fortrolighed Integritet Tilgængelighed Hvordan får vi det til at virke i praksis? 14

15 Informationssikkerhed Hvordan operationaliseres den? Sikkerhedspolitik Sikkerhedspolitikken er det strategiske dokument, der afspejler virksomhedens holdning til informationssikkerhed med udgangspunkt i forretningen Sikkerhedshåndbog Sikkerhedshåndbogen er det dokument hvor man beskriver hvilke kontroller man har implementeret og hvordan de er tiltænkt at virke Operationel dokumentation Den operationelle dokumentation anviser hvordan man konkret løser l opgaven eks. I form af procedurer eller instrukser Eks.: Eks.: Eks.: Formål: Hvorfor gør vi det? Omfang: Hvor meget tager vi ansvar for? Sikkerhedsniveau: Lovgivning, risiko, valg af kontroller (eks. DS484 basale) Sikkerhedsbevidsthed: Awareness Sanktioner: Hvad sker der når den brydes? 11.2 Administration af brugeradgang Sikre mod uautoriseret adgang Der skal være en formaliseret arbejdsgang for tildeling af rettigheder Tildeling af priviligerede brugere kræver øget fokus på godkendelse Procedure for brugeradministration Oprette, ændre, nedlægge Hvem må anmode og oprette Krav til dokumentation Instruks for oprettelse i AD Åbn user manager etc. 15

16 Hvordan mødes ITIL s Service Desk relaterede discipliner med informationssikkerheden Afkast - Sikkerhed Konkurrence - Etik Lovgivning - Ansvarlighed Sikkerhedspolitik Support af forretningen Fortrolighed Integritet Tilgængelighed Service Level Agreement Service Desk Service Level Management Operational Level Agreement 16

17 Hvem kontrollerer at rammerne er udfyldt? Support af forretningen Afkast - Sikkerhed Konkurrence - Etik Ledelsen Intern Revision Lovgivning - Ansvarlighed Ekstern Revision Fortrolighed Integritet Tilgængelighed Pressen Service Desk Sikkerhedspolitik Service Level Management Myndighederne Service Level Agreement Operational Level Agreement 17

18 Hvordan tilfører ITIL s Service Desk værdi til informationssikkerheden ITIL består af de byggeklodser, der får IT Fabrikken til at understøtte forretningens behov for fortrolighed, integritet og i særdeleshed tilgængelighed. Service Desken er jo en væsentlig del af ITIL og benytter og understøtter stort set alle processer. Ergo tilfører Service Desken værdi til informationssikkerheden 18

19 Hvordan tilfører ITIL s Service Desk værdi til informationssikkerheden Incident Respons o Håndtering af alarmer og brugerhenvendelser o Kommunikation o Eskalering Levere services fra Service Kataloget o Brugeradministration o Passwordskift o Tildeling af diskplads o Fil restore Dokumentation af egenkontroller o Sikre at vi dokumenterer at en proces / aktivitet er udført o Vedhæfte modtagne dokumenter (eks. Godkendelser) o Foretage opdatering i cmdb Statistik Hvordan kommer vi dertil? o Tryghed og vished o Faktuel og konkret 19

20 Proces ejere skal tage medansvar Proces ejere tager naturligt ansvar for o Effectiveness & Efficiency o Kvalitet o Cost to produce o Proces optimering o De services vi tilbyder (service katalog) o O.m.a. Hvorfor egentlig ikke sikkerhed? o Har vi kompetencerne? o Er vores modenhed i organisationen høj nok? o Er der modstand mod strukturen? o Synes vi egentlig selv det er vigtigere end alle de andre ting, der også er vigtige? Hvad er det så for et medansvar? 20

21 Sikkerhed i incident processen Incident Proces Detect & Record Classifcation & initial support Service request Investigate & Diagnose Resolution & Recovery Incident Closure Service Request Procedure Ownership, monitoring, tracking, escalation, communication Hvilke oplysninger ønsker vi registreret når et incident oprettes? Har vi forsynet Service Desken med de nødvendige forhåndsordrer? Er service kataloget kendt? Er der definerede fremgangsmåder for service requests? Kvalitetssikrer vi de løsninger vi har i vores systemer og er de tilgængelige? Stiller vi gode nok krav til dokumentation af løsning og følger vi op? Hvem tager vi i ed når en sag lukkes? Det betyder alt sammen noget for sikkerheden 21

22 Praktiske eksempler Incident response En bruger ringer ind til Service Desken. Han har modtaget en underlig mail og er vist nok kommet til at klikke på en fil og det er lidt irriterende for der kommer hele tiden popups nede i hjørnet og om 10 minutter skal han altså til et vigtigt møde. Fortrolighed Integritet Tilgængelighed Muligvis truet Muligvis truet Der er p.t. er bruger, der ikke kan arbejde (påvirker muligvis flere) Action: -Eksekver forhåndsordre - isoler arbejdsstation - check virus server (er det en ond eller harmløs virus) - Eskaler evt. til antivirus team - Dokumenter undervejs 22

23 Praktiske eksempler Problem Management En bruger ringer ind til Service Desken. Han er igang med at udskrive fakturaer, og nu har han fået den der fejl du ved nok, som han plejer at få. Den der bytter rundt på antal og pris. Fortrolighed Integritet Tilgængelighed Ikke relevant Formentlig truet, risiko for at forkerte data ender hos vores kunder Faktureringen er helt konkret standset Action: -Det er en kendt fejl - Hvad gjorde vi sidst findes der en løsning - Identificer evt. circumvention - Registrer anvendelse (måske skal der rejses en rfc) - Dokumenter undervejs 23

24 Praktiske eksempler Change Management En projektleder ringer ind til Service Desken. Hun vil gerne have oprettet en ny vpn tunnel til firmaet leverandør portal. Hun oplyser at man lige har indgået en ny samarbejdsaftale og at det er vigtigt det bliver lige nu! Fortrolighed Integritet Tilgængelighed Er vi ved at give en vi ikke kender adgang til vores miljøer Har vi helt styr over rettighederne hvad skal leverandøren kunne Forretningen er afhængig af denne ændring? Action: -Eksekver standard RFC - Bed om at få en kopi af leverandør godkendelsen / upload til sag - Læg en sag til vpn teamet (eskaler evt. via telefon) - Informer evt. om standard tid for sådan en RFC - Kontroller med projektlederen at hendes problem nu er løst 24

25 Praktiske eksempler IT Service Continuity Management Virksomhedens fremmeste Serverspecialist har i forbindelse med en server opgradering oprettet en Service Request med bestilling af et SAN kort. Der er tilknyttet en standard RFC for udskiftning af SAN kortet. Fortrolighed Integritet Tilgængelighed Ingen påvirkning Ingen påvirkning Dokumentationen skal være retvisende hvis beredskabet skal virke Action: -Opdater dokumentation - Serveren konfiguration skal tilpasses i cmdb - Sikkerhedsgruppen skal orienteres om at der er sket en opdatering i beredskabsdokumentation - Det nye driftsdokument som serverspecialisten fremsender knyttes til rette CI 25

26 Praktiske eksempler Kapacitetsplanlægning Virksomhedens overvågningssystem alarmerer om manglende diskplads på det drev, der hoster firmaets ERP databaser helt specifikt drevet, der indeholder transaktionslogge. Fortrolighed Integritet Tilgængelighed Ingen påvirkning Hvis vi løber tør for plads kan vi muligvis miste transaktioner Og databasen går selvsagt ned Action: -Ryd op og informer - Foretag et ekstraordinært commit på databasen - Informer capacity teamet om at de måske bør kigge på deres vækst analyser 26

27 Praktiske eksempler Availability Som en del af Service Deskens månedlige rapportering om tingenes tilstand er der dukket en interessant sag op. Der har været en række nedbrud på et ikke kritisk system og det har forårsaget mange incidents ift. det forventede. Fortrolighed Integritet Tilgængelighed Ingen påvirkning Ingen påvirkning Tilsyneladende større påvirkning end antaget Action: -Orienter availability teamet - Har servicen den rette reliability? - Er den resilient nok? 27

28 Praktiske eksempler Serviceydelse Brugeradministration Direktion Indkøb Lager Salg Produktion Levering Faktura ERP - SYSTEM Oprettelse af en bruger Ændring af rettigheder Nedlæggelse Periodisk kontrol 28

29 Konklusion DS484 eller ISO27001 er på ingen måde garanti for at opnå god informationssikkerhed, men det vil være fjollet ikke at anvende disse omfangsrige standarder som inspiration, når man designer sine processer. Det er ikke tale om sikkerhed for sikkerhedens skyld snarere sikkerhed for forretningens skyld - dermed endnu et godt argument for at en velfungerende Service Desk er vital for en virksomhed. Hvis man altså vælger at tage ansvar for de egenkontroller og processer, der naturligt ligger i Service Desken. Givet man sørger for at Service Desken har de rette betingelser for at kunne fungere agilt så tilføres høj værdi til informationssikkerheden og der er tale om win win når ITIL s Service Desk møder rammerne for DS484 / ISO

30 Tak for opmærksomheden! Spørgsmål? 30