Workshop om logning, loghåndtering og overvågning

Transkript

1 Workshop om logning, loghåndtering og overvågning IT- og Telestyrelsen, 7.december 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

2 Velkomst og dagens program 2 Hvorfor er vi her Dagens formål og succeskriterier Disponeringen af programmet Deltagerpræsentation (kort)

3 Temaer 3 Workshoppen er målrettet imod tre områder indenfor kontrol området : 1. Logning og loghåndtering/-analyse: Hvad bør/skal logges? Hvordan logges? Regelmæssige gennemgange og hvordan? Managed service 2. Overvågning : Hvad bør/skal overvåges? Realtime overvågning/alarmering Hvordan? Serviceovervågning, ressourceforbrug og tilgængelighed Hvordan? Overvågning af netværkstrafik Hvordan? 3. Reaktion på sikkerhedsrelaterede hændelser : Forberedelse og verificering af hændelser Reaktion (incident response) Håndtering Kravene til logning/overvågning gennemgås samlet ud fra DS484

4 Praktiske forhold 4 Pauser Frokost Løbende forplejning Toiletter Rygning Spørgsmål undervejs er altid velkomne Evalueringsskemaer

5 DS484 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

6 DS 484: Hvad er informationssikkerhed? Informationssikkerhed opnås 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.

7 DS 484: Logning og overvågning Formål At afsløre uautoriserede handlinger. Informationsbehandlingssystemer skal overvåges og sikkerhedsrelaterede hændelser skal registreres. Der skal være en logning, som sikrer, at uønskede forhold konstateres. Overvågning skal verificere, at sikringsforanstaltningerne fungerer efter hensigten.

8 DS 484: Opfølgningslogning Sikringsforanstaltning Alle brugeraktiviteter, afvigelser og sikkerhedshændelser skal logges og opbevares i en fastlagt periode af hensyn til opfølgning på adgangskontroller og eventuel efterforskning af fejl og misbrug.

9 DS 484: Opfølgningslogning Implementeringsretningslinjer Opfølgningsloggen skal, så vidt det er muligt, indeholde: a) brugeridentifikation b) dato og klokkeslæt for væsentlige aktiviteter som eksempelvis log-on og log-off c) arbejdsstationens identitet d) registrering af systemadgange og forsøg herpå e) registrering af dataadgange og forsøg herpå f) ændringer i systemkonfigurationen g) brug af særlige rettigheder h) brug af hjælpeværktøjer i) benyttede datafiler j) benyttede netværk og protokoller k) alarmer fra adgangskontrolsystemet l) aktivering og deaktivering af beskyttelsessystemer, fx antivirus og indbrudsalarmer.

10 DS 484: Opfølgningslogning Bemærkninger Opfølgningsloggen vil ikke altid være tilstrækkelig til at opfylde kravene til kontrol- og transaktionsspor i Bogføringsloven. Systemer, der skal efterleve disse krav, må derfor have supplerende logning. Hvis det er muligt, skal systemadministratorer og andre med særlige rettigheder ikke have mulighed for at slette logningen af deres egne aktiviteter, jf En opfølgningslog vil ofte indeholde personhenførbare data og skal derfor beskyttes i overensstemmelse med Persondataloven.

11 DS 484: Overvågning af systemanvendelse Sikringsforanstaltning Brugen af virksomhedens informationsbehandlingssystemer skal overvåges og løbende følges op. Implementeringsretningslinjer Niveauet for overvågning skal fastlægges ud fra en risikovurdering og lovgivningens krav. Følgende områder skal indgå i vurderingen: a) autoriseret adgang: 1. brugeridentifikation 2. dato og klokkeslæt 3. hændelsestype 4. benyttede datafiler 5. benyttede programmer

12 DS 484: Overvågning af systemanvendelse Implementeringsretningslinjer (fortsat) b) anvendelse af særlige rettigheder: 1. anvendte rettigheder, fx systemadministrator 2. start og stop af systemer 3. til- og frakobling af udstyr c) uautoriserede adgangsforsøg: 1. fejlslagne og afviste brugerhandlinger 2. fejlslagne og afviste dataadgangsforsøg 3. advarsler fra logiske netværksbeskyttelsesfiltre 4. alarmer fra logiske indbrudsalarmsystemer d) systemtekniske alarmer: 1. alarmer og meddelelser fra det overordnede styresystem 2. undtagelsesrapporteringer 3. alarmer og meddelelser fra netværkets styresystem 4. alarmer fra adgangskontrolsystemet e) ændringer og forsøg på ændringer af sikkerhedsopsætninger og sikringsforanstaltninger.

13 DS 484: Overvågning af systemanvendelse Implementeringsretningslinjer (fortsat) Frekvensen af overvågningsaktiviteterne afgøres af en risikovurdering, hvor følgende risikofaktorer skal indgå i vurderingen: informationsbehandlingssystemets forretningsmæssige betydning de behandlede informationers forretningsmæssige betydning og følsomhed virksomhedens erfaringer med misbrug, trusler og sårbarheder informationssystemets anvendelse af eksterne forbindelser, specielt offentlige netværk pålideligheden af logningsfaciliteterne.

14 DS 484: Overvågning af systemanvendelse Bemærkninger Overvågning er nødvendig for at sikre, at brugerne kun har mulighed for at gøre det, de eksplicit er autoriseret til. Log-gennemgang kræver en god forståelse for de trusler, et informationssystem er udsat for, og hvorledes disse ytrer sig. I findes eksempler på hændelser, som kan kræve yderligere undersøgelser.

15 DS 484: Beskyttelse af log-oplysninger Sikringsforanstaltning Både log-faciliteter og log-oplysninger, skal beskyttes mod manipulation og tekniske fejl. Implementeringsretningslinjer En log skal beskyttes mod: a) enhver form for ændringer af indholdet b) sletninger og ændringer af logfiler c) tekniske fejl, eksempelvis overskrivninger, fordi der ikke er afsat tilstrækkelig plads på lagringsmediet.

16 DS 484: Beskyttelse af log-oplysninger Bemærkninger Som udgangspunkt skal en log aldrig ændres. Man kan derfor ikke tale om autoriserede ændringer. Hvis der er fejl i en log, må eventuelle korrektioner fremgå af efterfølgende logninger. En generel systemlog vil ofte indeholde store mængder af information, som ikke har sikkerhedsmæssig interesse. Dette problem kan afhjælpes ved enten automatisk at overføre sikkerhedsrelevante informationer til en egentlig opfølgningslog eller ved at benytte særlige udtræksværktøjer til at fremfinde sikkerhedsrelevante informationer.

17 DS 484: Administrator- og operatørlog Sikringsforanstaltning Aktiviteter udført af systemadministratorer og -operatører samt andre med særlige rettigheder skal logges. Implementeringsretningslinjer Loggen skal omfatte: a) tidspunktet for en given handling b) oplysninger om handlingen, fx filhåndtering. Ved fejlhåndtering skal de korrigerende og eventuelle kompenserende foranstaltninger fremgå c) den udførende persons identitet d) de benyttede procedurer, værktøjer og systemer e) * loggen skal løbende gennemgås af en uvildig person, jf Bemærkninger Et særligt indbrudsalarmsystem, som ikke er underlagt systemadministratorens kontrol, kan benyttes til at overvåge brugen af særlige rettigheder og systemværktøjer.

18 DS 484: Fejllog Sikringsforanstaltning Fejl skal logges og analyseres, og nødvendige udbedringer og modforholdsregler gennemføres. Implementeringsretningslinjer Både brugerrapporterede og systemregistrerede fejl skal fremgå af fejlloggen. Der skal være klare retningslinjer for fejlhåndtering: a) Regelmæssig gennemgang af fejlloggen, for at sikre at alle fejl er rettet tilfredsstillende. b) Regelmæssig gennemgang af de korrigerende og kompenserende foranstaltninger, for at sikre at virksomhedens sikkerhed ikke er blevet kompromitteret, og at de gennemførte foranstaltninger er autoriseret. Bemærkninger Hvis informationsbehandlingssystemet har en automatisk fejlregistreringsfunktion, skal denne være aktiv, såfremt en risikovurdering viser, at dette er forretningsmæssigt velbegrundet.

19 DS 484: Tidssynkronisering Sikringsforanstaltning Alle ure i virksomhedens informationsbehandlingsanlæg skal være synkroniseret med en præcis tidsangivelseskilde. Implementeringsretningslinjer Der skal være en procedure for en løbende kontrol med og eventuel korrektion af tidsangivelsen i virksomhedens informationsbehandlingsanlæg. Bemærkninger En præcis tidsangivelse kan være kritisk i forbindelse med indgåelse af bindende aftaler, realtidstransaktioner eller efterforskning ved hjælp af logningsinformationer.

20 DS 484: Periodisk opfølgning Bemærkninger Den periodiske opfølgning supplerer, men kan ikke erstatte, den løbende overvågning og kontrol.

21 DS 484: Samarbejdsaftaler m) beskrivelse af de aftalte servicemål, deres overvågning og afrapportering n) retten til at overvåge og afbryde den aftalte serviceydelse

22 DS 484: Mærkning og håndtering af informationer og data For hvert klassifikationsniveau skal der være retningslinjer for behandling, lagring, transmission og destruktion samt den hertil relaterede logning.

23 DS 484: Ledelsens ansvar Sikringsforanstaltning Ledelsen skal sikre sig, at alle medarbejdere implementerer og fastholder informationssikkerhed i overensstemmelse med virksomhedens sikkerhedspolitik, retningslinjer og procedurer. Implementeringsretningslinjer Ledelsens ansvar omfatter følgende for alle medarbejdere: e) At de holder sig inden for de retningslinjer og bestemmelser, der er for ansættelsen, inkl. virksomhedens informationssikkerhedspolitik og korrekte arbejdsmetoder.

24 DS 484: Fysisk adgangskontrol Sikringsforanstaltning Sikre områder skal beskyttes af adgangskontrol, så kun autoriserede personer kan få adgang. Implementeringsretningslinjer Følgende punkter skal implementeres: a) * Gæster i sikre områder skal være overvåget eller sikkerhedsgodkendt og dato og tidspunkt for deres ankomst og afgang skal registreres. De skal kun have adgang med et godkendt formål og skal være instrueret om områdets sikkerheds- og nødprocedurer. b) * Adgang til områder, hvor følsomme informationer behandles, skal være beskyttet med et adgangskontrolsystem, hvor enhver adgang logges.

25 DS 484: Arbejdsmæssige forhold i sikre områder Sikringsforanstaltning Ud over de fysiske sikringsforanstaltninger skal der etableres forretningsgange og procedurer til beskyttelse af kritiske/ følsomme informationsaktiver i sikre områder. Implementeringsretningslinjer Følgende foranstaltninger skal etableres: b) * Arbejde i sikre områder skal så vidt muligt være overvåget. c) * Ubenyttede lokaler i sikre områder skal være aflåst og inspiceres jævnligt.

26 DS 484: Områder til af- og pålæsning med offentlig adgang Sikringsforanstaltning Af- og pålæsningsområder samt andre områder, hvor offentligheden kan få adgang, skal være overvåget. Implementeringsretningslinjer Følgende punkter skal implementeres: a) Adgang til af- og pålæsningsområder udefra skal så vidt muligt begrænses til identificerede og autoriserede personer. Bemærkninger Overvågning af områder med offentlig adgang skal følge lovgivningens krav.

27 DS 484: Placering af udstyr Sikringsforanstaltning Udstyr skal placeres eller beskyttes, så risikoen for skader og uautoriseret adgang minimeres. Implementeringsretningslinjer Følgende punkter skal implementeres: f) * Trusler fra omgivelserne, som eksempelvis temperatur og fugtighed, skal overvåges.

28 DS 484: Forsyningssikkerhed Sikringsforanstaltning Udstyr skal sikres mod forsyningssvigt i overensstemmelse med udstyrets betydning for kritiske forretningssystemer. Implementeringsretningslinjer Følgende forhold skal indgå i sikringen: a) Alle forsyninger som elektricitet, vand, kloak, varme og ventilation skal have den fornødne kapacitet og løbende inspiceres for at forebygge uheld. f) * Vandforsyningen skal være stabil og tilstrækkelig til eventuelle køle-, befugtnings- og brandbekæmpelsesanlæg, og der skal være alarm ved svigtende vandforsyning.

29 DS 484: Sikring af kabler Sikringsforanstaltning Kabler til elektricitetsforsyning og datakommunikation skal være sikret mod skader og uautoriserede indgreb. Implementeringsretningslinjer Følgende punkter skal indgå i sikringen: f) For kritiske eller følsomme forretningssystemer skal det overvejes: 5. * at kontrollere netværket regelmæssigt for uautoriseret udstyr

30 DS 484: Udstyrs og anlægs vedligeholdelse Sikringsforanstaltning Udstyr skal vedligeholdes efter forskrifterne for at sikre dets tilgængelighed og pålidelighed. Implementeringsretningslinjer Følgende punkter skal efterleves: c) * Der skal føres log over alle fejl og mangler samt reparationer og forebyggende vedligeholdelse.

31 DS 484: Fjernelse af virksomhedens informationsaktiver Sikringsforanstaltning Virksomhedens informationsaktiver må ikke fjernes fra virksomheden uden fornøden autorisation. Implementeringsretningslinjer Følgende punkter skal efterleves: d) Hvis aktivets klassifikation eller forretningsmæssige værdi tilsiger det, skal det registreres, når aktivet fjernes, og når det returneres. e) Hvis en risikovurdering tilsiger det, skal der indføres stikprøvevis kontrol med uautoriseret fjernelse. f) Hvis der er etableret stikprøvekontrol, skal dette være kendt i virksomheden.

32 DS 484: Driftsafviklingsprocedurer Sikringsforanstaltning Driftsafviklingsprocedurer for forretningskritiske systemer skal være dokumenterede, ajourførte og tilgængelige for driftsafviklingspersonalet og andre med et arbejdsbetinget behov. Implementeringsretningslinjer Driftsafviklingsprocedurer er en del af virksomhedens informationsaktiver og skal derfor indgå i en formaliseret ændringsstyring, herunder en ledelsesmæssig godkendelse. Procedurerne skal omfatte samtlige informationsbehandlingsopgaver, herunder: h) styringen af kontrolspor og øvrige systemtekniske logninger, jf

33 DS 484: Ændringsstyring Sikringsforanstaltning Ændringer til forretningskritisk informationsbehandlingsudstyr, -systemer og -procedurer skal styres gennem en formaliseret procedure. Implementeringsretningslinjer Proceduren skal indeholde følgende: g) logningsprocedure, jf

34 DS 484: Funktionsadskillelse Implementeringsretningslinjer Det skal sikres, at samme person ikke har adgang til at tilgå, ændre og anvende informationsaktiver, uden at dette er godkendt eller vil blive opdaget. Hvis funktionsadskillelse ikke kan gennemføres i eksempelvis mindre virksomheder, skal der iværksættes kompenserende kontrolforanstaltninger, fx overvågning, logning eller lignende.

35 DS 484: Ekstern serviceleverandør Formål Virksomheden skal verificere implementeringen af det aftalte sikkerhedsniveau og løbende overvåge, at niveauet fastholdes, og at eksempelvis ændringer i serviceleverandørens driftsmiljø ikke forringer sikkerhedsniveauet.

36 DS 484: Serviceleverancen Sikringsforanstaltning Virksomheden skal sikre sig, at der er indgået en aftale, og at de aftalte sikrings- og kontrolforanstaltninger, serviceydelser og servicemål bliver etableret, leveret og opretholdt, jf. 6.2.

37 DS 484: Overvågning og revision af serviceleverandøren Sikringsforanstaltning Virksomheden skal regelmæssigt overvåge serviceleverandøren, gennemgå de aftalte rapporter og logninger samt udføre egentlige revisioner, for at sikre at aftalen overholdes, og at sikkerhedshændelser og -problemer håndteres betryggende. Implementeringsretningslinjer Følgende aktiviteter skal gennemføres løbende: a) overvågning af det aftalte serviceniveau b) * regelmæssige møder med gennemgang af driftsrapport, herunder sikkerhedshændelser c) gennemgang af og opfølgning på sikkerhedshændelser, driftsproblemer, fejl og nedbrud d) gennemgang af sikkerheds- og driftsrelaterede logninger e) indgåelse af aftale, planlægning og opfølgning på løsningen af udestående problemer.

38 DS 484: Kapacitetsstyring Sikringsforanstaltning Ressourceforbruget skal overvåges og tilpasses, og der skal foretages fremskrivninger af det forventede kapacitetsbehov. Implementeringsretningslinjer Kapacitetsstyring skal omfatte: a) løbende overvågning og justering for at sikre optimal anvendelse af kapaciteten b) * varslingssystemer som i tide advarer om eventuelle kapacitetsproblemer.

39 DS 484: Skadevoldende programmer og mobil kode Formål Der skal træffes foranstaltninger til at forhindre og konstatere angreb af skadevoldende programmer.

40 DS 484: Beskyttelse mod skadevoldende programmer Sikringsforanstaltning Der skal etableres både forebyggende, opklarende og udbedrende sikringsog kontrolforanstaltninger, herunder den nødvendige uddannelses- og oplysningsindsats for virksomhedens brugere af informationssystemer. Implementeringsretningslinjer Følgende foranstaltninger skal etableres: c) * Regelmæssig gennemgang af system- og datafiler til kritiske forretningssystemer, hvor uautoriserede filer og systemændringer undersøges omhyggeligt.

41 DS 484: Beskyttelse mod skadevoldende programmer (fortsat) Implementeringsretningslinjer Følgende foranstaltninger skal etableres: d) Installering og løbende opdatering af systemværktøjer til: 1. at undersøge alle filoverførsler fra åbne netværk eller fra en ukendt eller uautoriseret kilde 2. at undersøge al elektronisk post for vedhæftede filer eller anden tilknyttet programkode. Denne undersøgelse bør gennemføres flere steder, fx i virksomhedens logiske netværksfilter, i udstyret til behandling af elektronisk post eller i udstyret på den enkelte arbejdsplads 3. * at beskytte imod skadevoldende programmer fra internethjemmesider.

42 DS 484: Netværket Sikringsforanstaltning Netværk skal beskyttes mod trusler for at sikre netværksbaserede systemer og de transmitterede data. Implementeringsretningslinjer Den netværksansvarlige skal sikre, at der er implementeret den fornødne beskyttelse mod uautoriseret adgang, herunder: d) de fornødne lognings- og overvågningsprocedurer skal være etableret, jf

43 DS 484: Netværkstjenester Sikringsforanstaltning Aftalen vedrørende netværkstjenester skal beskrive de aftalte sikringsforanstaltninger og servicemål, uanset om tjenesten leveres af en intern eller en ekstern leverandør. Implementeringsretningslinjer Netværksleverandørens evne til at efterleve de aftalte betingelser skal vurderes og løbende overvåges. Muligheden for en uvildig revision skal være aftalt. Netværksleverandøren skal kunne levere: a) de nødvendige teknologiske muligheder for autentifikation, kryptering og overvågning

44 DS 484: Bærbare datamedier Sikringsforanstaltning Der skal foreligge procedurer for modtagelse, registrering, behandling, opbevaring, forsendelse og sletning af bærbare datamedier som eksempelvis papir, magnetbånd, disketter, flytbare diske, mobile lagringsenheder, CDrom er m.m. Implementeringsretningslinjer Procedurerne skal være i overensstemmelse med de lagrede datas klassifikation og skal omfatte: b) autorisation til og logning af flytning af bærbare datamedier, hvis de lagrede datas klassifikation og/eller krav om kontrolspor tilsiger det

45 DS 484: Destruktion af datamedier Implementeringsretningslinjer Proceduren for destruktion af datamedier skal være i overensstemmelse med de lagrede datas klassifikation med særligt hensyn til beskyttelsen af følsomme oplysninger: c) Hvis man benytter en ekstern leverandør til destruktion af virksomhedens datamedier, skal man sikre sig, at han efterlever de aftalte sikkerhedskrav, jf og d) Destruktion af følsomme, fortrolige eller kritiske data skal logges af hensyn til kontrolsporet.

46 DS 484: Beskyttelse af datamediers indhold Implementeringsretningslinjer Der skal foreligge forretningsgange, som i overensstemmelse med klassifikationen sikrer beskyttelse af følsomme og fortrolige data såvel på bærbare arbejdsstationer, mobiltelefoner og andre håndholdte enheder som på dokumenter, disketter, magnetbånd, udskrifter, rapporter, CD-rom er, mobile lagringsenheder, værdiblanketter m.m.: c) log over tildelte autorisationer i) regelmæssig gennemgang af distributions- og autorisationslister.

47 DS 484: Udvidede adgangsrettigheder Sikringsforanstaltning Tildeling og anvendelse af udvidede adgangsrettigheder skal begrænses og overvåges.

48 DS 484: Periodisk gennemgang af brugernes adgangsrettigheder Sikringsforanstaltning Brugernes adgangsrettigheder skal gennemgås regelmæssigt efter en formaliseret forretningsgang. Implementeringsretningslinjer Gennemgangen skal omfatte følgende: a) Brugernes adgangsrettigheder skal gennemgås regelmæssigt, fx hver 6. måned, og i forbindelse med ændringer i brugeres arbejdsmæssige forhold, jf b) En brugers adgangsrettigheder skal revurderes ved organisatoriske ændringer. c) Autorisationer til udvidede adgangsrettigheder, jf , skal gennemgås hyppigere, fx hver 3. måned. d) Udvidede adgangsrettigheder skal gennemgås regelmæssigt for at sikre, at ingen har fået uautoriserede rettigheder. e) Ændringer i autorisationer til udvidede adgangsrettigheder skal logges og gennemgås regelmæssigt.

49 DS 484: Retningslinjer for brug af netværkstjenester Sikringsforanstaltning Brugere skal kun have adgang til de tjenester, de er autoriseret til at benytte. Implementeringsretningslinjer Retningslinjerne for brug af netværkstjenester skal omfatte: c) forretningsgange for overvågning og styring af adgangen til netværk og tjenester

50 DS 484: Styring af systemadgang Formål At forhindre uautoriseret adgang til informationsbehandlingssystemer. Adgangsstyringen skal omfatte: brugerautentifikation logning af gennemførte og afviste autentifikationer logning af anvendelsen af særlige rettigheder alarmering ved brud på sikkerhedsretningslinjerne tilfredsstillende autentifikationsværktøjer mulighed for tidsbegrænset adgang.

51 DS 484: Sikker log-on Sikringsforanstaltning Systemadgang skal beskyttes af en sikker log-on-procedure. Implementeringsretningslinjer Log-on-proceduren skal minimere mulighederne for uautoriseret adgang ved at afsløre så lidt som muligt om systemet. Proceduren skal: e) begrænse antallet af fejlslagne log-on-forsøg til eksempelvis tre forsøg, og: 1. * logge fejlslagne og gennemførte forsøg 4. * alarmere en eventuel overvågningsfunktion ved fejlslagne log-on-forsøg

52 DS 484: Identifikation og autentifikation af brugere Sikringsforanstaltning Alle brugere skal have en unik identitet til personlig brug, og der skal vælges en passende autentifikationsteknik til verifikation af brugernes identitet. Implementeringsretningslinjer Følgende sikringsforanstaltninger skal omfatte alle former for brugere, inkl. teknisk støttepersonale, driftspersonale, netværksadministratorer, systemteknikere og databaseadministratorer: a) Brugeridentiteten skal kunne bruges til at spore den person, som er ansvarlig for en given aktivitet. d) Hvis adgangsrettighederne kun giver mulighed for at udføre funktioner og handlinger, som ikke kræver sporbarhed, eller hvis der er implementeret kompenserende sikringsforanstaltninger, eksempelvis streng fysisk adgangskontrol og logning af adgange, er det ikke påkrævet at anvende unikke, personlige identiteter.

53 DS 484: Brug af systemværktøjer Sikringsforanstaltning Brugen af systemværktøjer, som kan omgå virksomhedens sikringsforanstaltninger, skal begrænses og styres effektivt. Implementeringsretningslinjer Følgende retningslinjer skal være implementeret: f) Al brug af systemværktøjer skal logges.

54 DS 484: Fjernarbejdspladser Sikringsforanstaltning Virksomheden skal have retningslinjer for anvendelsen og opsætningen af fjernarbejdspladser. Implementeringsretningslinjer Følgende punkter skal indgå i ledelsens overvejelser: g) virksomhedens ret til adgang til privat udstyr anvendt som fjernarbejdsplads i forbindelse med den løbende sikkerhedsopfølgning eller en undersøgelse De konkrete retningslinjer skal omfatte: 9. revisionsadgang og sikkerhedsovervågning

55 DS 484: Validering af inddata Sikringsforanstaltning Data, der sendes ind i systemerne, skal valideres for korrekthed. Implementeringsretningslinjer Det skal vurderes, hvilke af følgende kontroller der er nødvendige: g) generering af log over de aktiviteter, der involverer data, der sendes ind i systemerne, jf

56 DS 484: Kontrol af den interne databehandling Sikringsforanstaltning Kontrol af datas korrekthed skal indarbejdes i virksomhedens systemer med det formål at afsløre, om data er blevet modificeret, enten på grund af systemfejl eller bevidste handlinger. Implementeringsretningslinjer For at kontrollere korrektheden skal der være udarbejdet en tjekliste med tilhørende dokumentation. Følgende punkter skal vurderes som mulige punkter i tjeklisten: generering af log over de aktiviteter, der er involveret i processen, jf

57 DS 484: Validering af uddata Sikringsforanstaltning Data fra systemer skal valideres med det formål at sikre, at de, under de givne omstændigheder, er korrekte. Implementeringsretningslinjer Validering af data fra systemer skal indeholde følgende: f) Generering af en log over aktiviteterne i forbindelse med uddatavalideringen.

58 DS 484: Nøglehåndtering Sikringsforanstaltning Der skal være etableret et nøglehåndteringssystem, som understøtter virksomhedens anvendelse af kryptografi. Implementeringsretningslinjer Et system til nøglehåndtering skal være baseret på et aftalt sæt af standarder, forretningsgange og sikre metoder for: k) logning og overvågning af aktiviteter i forbindelse med nøglehåndteringen.

59 DS 484: Sikkerhed ved systemtekniske filer Sikringsforanstaltning Der skal være forretningsgange for installation af systemer i driftsmiljøer. Implementeringsretningslinjer For at sikre driftsmiljøet skal følgende retningslinjer for ændringer være implementeret: f) Der skal være en log med beskrivelse af alle opdateringer af driftsmiljøet. Leverandører må kun få fysisk eller netværksbaseret adgang, når det er nødvendigt, og det må kun finde sted med ledelsens accept. Leverandørers aktiviteter skal overvåges. Systemer kan være afhængige af eksternt leverede systemer. Disse skal ligeledes overvåges og kontrolleres, således at uautoriserede ændringer og adgange, som kan introducere yderligere risici, forhindres.

60 DS 484: Sikring af testdata Sikringsforanstaltning Data, der anvendes til test, skal udvælges omhyggeligt, kontrolleres nøje og beskyttes i henhold til dets klassifikation. Implementeringsretningslinjer Driftsdatabaser med personfølsomme eller andre kritiske informationer må ikke anvendes til test. Hvis der er behov for at anvende personfølsomme informationer, skal disse informationer ændres i en sådan grad, at de ikke længere kan genkendes og henføres til personer, før de anvendes til test. Alternativt skal følsomme driftsdata, der anvendes til test, beskyttes efter følgende retningslinjer: d) Kopiering og brug af data fra driftsmiljøet skal logges for at sikre kontrolsporet.

61 DS 484: Styring af adgang til kildekode Sikringsforanstaltning Adgang til kildekode skal begrænses. Implementeringsretningslinjer Adgang til kildekode og den tilhørende dokumentation, fx designspecifikationer, diagrammer og testplaner, skal kontrolleres strengt for at forhindre uautoriseret funktionalitet og utilsigtede ændringer. For kildekode til programmer kan dette opnås ved at lagre kildekoden under streng kontrol, helst i særlige kildebiblioteker. De følgende retningslinjer skal gennemføres jf. pkt. 11 for at kontrollere adgangen til disse biblioteker, således at risikoen for kompromittering af programmer minimeres: f) * Alle adgange til kildebibliotekerne skal logges.

62 DS 484: Ændringsstyring Sikringsforanstaltning Implementeringen af ændringer skal være styret af en formel forretningsgang. Implementeringsretningslinjer Forretningsgangen for ændringsstyring skal opfylde følgende krav: i) Vedligeholdelse af et kontrolspor for alle ændringer.

63 DS 484: Lækage af informationer Sikringsforanstaltning Der skal implementeres beskyttelsesforanstaltninger, der begrænser risikoen for lækage af informationer gennem fx skjulte kanaler. Implementeringsretningslinjer For at begrænse risikoen for lækager skal følgende overvejes: a) * scanning efter skjulte informationer i al udgående trafik både fysiske medier og elektronisk kommunikation d) * jævnlig overvågning af medarbejdere og systemer, hvor lovgivningen tillader det e) * overvågning af ressourceforbruget i udstyr og systemer.

64 DS 484: Sårbarhedsstyring Formål At forhindre skader fra angreb, som udnytter kendte sårbarheder. Beskyttelse mod tekniske sårbarheder skal implementeres effektivt og systematisk med løbende målinger, der sikrer effektiviteten. Disse overvejelser skal omfatte driftsmiljøer og samtlige brugersystemer.

65 DS 484: Sårbarhedssikring Sikringsforanstaltning Virksomheden skal løbende indhente informationer om eventuelle sårbarheder i de anvendte systemer. Sårbarhederne skal evalueres, og passende foranstaltninger skal implementeres for at modvirke de nye risici. Implementeringsretningslinjer g) Opdateringer skal testes og evalueres, før de installeres, således at virksomheden sikrer sig, at de er effektive og ikke resulterer i utilsigtede og uacceptable bivirkninger. Hvis der ikke er opdateringer til rådighed, skal der indføres kompenserende sikringsforanstaltninger som fx at: 1. stoppe tjenesten eller systemanvendelsen relateret til svagheden 2. tilpasse eller tilføje adgangskontroller, fx i de logiske filtre ved indgangene til netværket, jf udvide overvågningen for at opdage og forhindre udnyttelse af svagheden 4. øge opmærksomheden på svagheden. h) * Der skal udarbejdes en log over alle de handlinger, der finder sted.

66 DS 484: Håndtering af sikkerhedsbrud og forbedringer Ansvar og forretningsgange Sikringsforanstaltning Ledelsens ansvar og de nødvendige forretningsgange skal være fastlagt for at sikre en hurtig, effektiv og metodisk håndtering af sikkerhedsbrud. Implementeringsretningslinjer Ud over rapportering af sikkerhedshændelser og svagheder, jf. 13.1, skal overvågningen af systemer, alarmer og sårbarheder bruges til at konstatere sikkerhedshændelser. Følgende retningslinjer skal være etableret: a) Procedurer til håndtering af forskellige typer af sikkerhedsbrud, herunder: 1. fejl i systemer og tab af tilgængelighed. 2. skadevoldende kode 3. blokering af tjenester ( denial of service ) 4. fejl forårsaget af ufuldstændige og unøjagtige forretningsdata 5. brud på fortrolighed og integritet 6. misbrug af systemer.

67 DS 484: Håndtering af sikkerhedsbrud og forbedringer Ansvar og forretningsgange Implementeringsretningslinjer (fortsat) c) Opfølgningslog og lignende beviser skal indsamles, jf , og sikres til brug for: 1. intern analyse af problemet 2. dokumentation af tekniske beviser i relation til potentielle kontraktbrud eller lovgivningsmæssige krav i tilfælde af en civil eller kriminel retssag under gældende lovgivning om misbrug af data 3. forhandling om kompensation fra leverandører af systemer eller tjenester.

68 DS 484: Håndtering af sikkerhedsbrud og forbedringer At lære af sikkerhedsbrud Sikringsforanstaltning Der skal være implementeret et system, der kan kvantificere og overvåge typerne og omfanget af samt omkostningerne ved håndteringen af sikkerhedsbrud. Implementeringsretningslinjer Informationer, der er indsamlet i forbindelse med sikkerhedsbrud, skal anvendes til identifikation af gentagne brud og brud med store konsekvenser.

69 Hvilke andre standarder og best practices kan være aktuelle at hente oplysninger fra? 69 IT- og Telestyrelsens vejledninger NIST vejledningerne Producenter, Microsoft m.v. CobiT4 Give et tilstrækkeligt revisionsspor til root-cause analyse Brug logging og overvågning til at detektere usædvanlige eller unormale aktiviteter Regelmæssigt gennemgang af adgang, privilegier og ændringer ITIL CMDB Incident records Problem management Capacity management Service desk Overvåg performance Verificer backup færdiggørelse

70 Hvilke andre standarder og best practices kan være aktuelle at hente oplysninger fra? 70 IT- og Telestyrelsens vejledninger NIST vejledningerne Producenter, Microsoft m.v. NIST Indsamle revisions RECORDS Regelmæssig gennemgang af log for usædvanlig aktivitet og brud Automatisk behandling af logs Beskyt loginformation imod uautoriseret sletning NIST Log management infrastruktur Planlægning af logning Konfiguration Analyse Håndtering af data Behold/bevar logfiler

71 Fasemodellen som flowdiagram 71

72 Pause C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

73 Hvordan opdages sikkerhedshændelser? 73 Log og loganalyse IDS Antivirus Strukturerede observationer, overvågning mm. Uorganiseret! Eksterne parter, kunder, brugere, administratorer

74 Hvad er situationen? 74 Administrator fokus på drift, ikke sikkerhed logfiler/loganalyse får lav prioritet Fejlfinding (fokus på drift) Logfiler er kedelige Outputfiler kan være svære at tolke Støj i logfilerne Gennemgang på enkeltstående systemer Reaktiv >< proaktiv (også i forhold til drift)

75 Logning hvor meget skal man logge 75 Nok! Dvs. alt det man kan: - Kan spore hændelser tilbage til kilden - Aktiviteter i forhold til kritiske objekter - Sporbarhed Det kan tage tid at opdage sikkerhedshændelser - Opbevar logfiler mindst en måned, 3 måneder er bedre - Persondatalovgivningen: 6 måneder, hvorefter den skal slettes. Op til 5 år med særligt behov. Harddiske er billige Særlige krav, f.eks. Persondata lovgivningen (refereret ovenfor) men anden lovgivning kan have tilsvarende krav.

76 Plads i sikkerhedslandskabet 76 Prevent Detect Respond Recover Sikkerhedspolitikker Forebyggende sikkerhedsforanstaltninger logindsamling IDS Antivirus Overvågning Incident team Eskalations procedurer

77 Hvorfor foretage overvågning? 77 Opdage - sekundært forebygge, forudsætning for afhjælpe Foretage overvågning af tjenester Overvågning af kritiske services for tilgængelighed og ressourceforbrug Etablere IDS/IPS (Dumme) hackere, virus, orme, P2P, malware osv. Statistik og grafer Opsamling på logs fra Firewalls, proxyer, hosts osv. Interne brugere Decentraliseret IDS

78 Hvorfor foretage overvågning? (fortsat) 78 Identificere mistænkelig eller uautoriseret netværkstrafik Udadgående IRC (Internet Relay Chat) (f.eks. port mv.) Udadgående mail (port 25) fra ikk server Monitorering ved mistanke om sikkerhedsproblemer Få overblik over forbrug af båndbredde Top 5 modtager/afsender Top 10 protokoller Top 10 sessions

79 Hvorfor logge? 79 Formål At afsløre uautoriserede handlinger. Informationsbehandlingssystemer skal overvåges og sikkerhedsrelaterede hændelser skal registreres. Der skal være en logning, som sikrer, at uønskede forhold konstateres. Overvågning skal verificere, at sikringsforanstaltningerne fungerer efter hensigten Planlægning, fejlfinding, kapacitetsovervågning (oppetid, ressourceforbrug, services, fejl m.v.), information om drifts- og applikationsproblemer. - Fejlog (DS ) Opdagelse af hændelser, beskyttelse imod trusler - Incident response, forensics - kan være eneste spor og bevismateriale

80 Hvorfor logge? (fortsat) 80 Opdage, forebygge, afhjælpe Lovkrav, sikkerhedspolitikker, revisionskrav Hvad der sker på system/netværk nogen gange også hvorfor - Første tegn på uønskede ting sker på system eller netværk - Logfiler giver ikke altid fuld information om hændelse, man kan give nok information til at advare om, at yderligere undersøgelser skal sættes i gang (kap13). Kan give info om trusler hvor man muligvis har fejlestimeret sandsynligheden og/eller effekten af de etablerede sikkerhedsforanstaltninger Revisionskrav -> drift opdager nytteværdi (men har ikke ressourcer) Hvad er interessant? - Fejl login, specielt til admin konti - også succes?

81 Logning muligheder 81

82 Logformater 82 Dokumentation for en hændelse på et tidspunkt Format Forholde sig til nødt til at gå på tværs Fælles nøgle sammenholde data på tværs

83 Hvad er en log? 83

84 Hvad er en log? Event/hændelse 84

85 Hvad er en log? (NB: Ikke samme hændelse) 85

86 Hvad er en log? 86

87 Hvad er en log? 87 Logs kan også være manuelle -> skemaudfyldning! Hvordan sikres - Tilgængelighed - Integritet - Evt. fortrolighed Indgår i diskussionen på følgende slide -> Udfordringer

88 Udfordringer 88 Sikre, at der logges Sikre, at logfiler gennemgåes Logfiler kan være meget store og det kan være svært at finde den relevante information i mængden af data. Sammenholdelse af information fra logfiler på tværs af servertyper og forskellige typer enheder (servere, IDS, firewalls, routere m.m.) Logkonsolidering Logfiler i forskellige formater. Sammenholdelse af tider på tværs af tidszoner og systemer. Opbevaring af data Træning i sortering og filtrering af log data. Behandling af logfiler Beskyttelse imod ændringer/sletning Mangler samlet overblik

89 Aktiver og aktiviteter/hændelser C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

90 Aktiver 90 Ikke kun overvågning af firewall logs og ignorere de interne systemer

91 Aktiver identifikation af funktionelle komponenter 91 Netværkstegning - oversigt Hjemmearbejdspladser Internet Samarbejdspartnere Afdelinger Kortlæser Brugere Telefonsystem Firewall Wireless Router Kortlæser Krydsfelt 1 Server rum Switch Laptops Opbevaring af backup

92 Hvad kan man logge 92 Logiske sikkerhed Fysisk sikkerhed Administrativ sikkerhed Automatisk vs. manuel logning

93 Hvad kan man logge logisk sikkerhed 93 Netværksenheder Router og switche DHCP server Webserver Webcache Mail server VPN Netværkstrafik Autentificering Operativsystemer Servere, workstations, databaser Applikationer Egenudviklede applikationer Forretningsapplikationer Bruger applikationer Sikkerhedsudstyr Firewalls Anti-virus IDS/IPS Enheder><tjenester

94 Hvad kan man logge logisk sikkerhed 94 OSI modellen 1. Fysiske lag - Dokumentation - bruges til undersøgelser, hvor kan angriber komme hen, osv 2. Data link lag - MAC-adresser - Statistik fra netværksovervågning der giver baseline om aktivitet på netværket 3. Netværk lag - VPN - RAS - NetBIOS/Host names og IP-adresser, DHCP scopes, WINS, Operativsystemer 4. Transport lag - TCP og UDP portnumre 5. Session lag - Telnet, SSH, SNMP, SSL.SNMP 6. Presentation - Kryptering 7. Application lag - Logfiler fra applikationer

95 Hvad kan man logge segmentering logisk sikkerhed 95 DMZ >< intern Segmentering, VLAN Hovedkontor >< afdelinger

96 Placering af centrale logenheder logisk sikkerhed 96 DMZ >< intern Segmentering, VLAN Hovedkontor >< afdelinger

97 Risikovurderingen 97 Omfang og frekvens skal afspejle den gennemførte risikovurdering og være formuleret i kravspecifikationer og SLA s Identifikation af aktiver og registrering af de kritiske/væsentlige er et basalt krav (forudsætter konsekvensvurdering) udpegning af ejere/ansvarlige ligeså. Afledt kritikalitet Trusselsbeskrivelser og initiale sandsynligheder opbyg trusselsbilledet Effektiviteten af etablerede sikkerhedsforanstaltninger (identificer de potentielle) opbyg risikobilledet Handlingsplaner effekten af at implementere de potentielle sikkerhedsforanstaltninger (forebygge, opdage, afhjælpe) udtrykt i nye risikobilleder

98 Frokost C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

99 Logning og overvågning C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

100 Konsolideret logning 100 Gennemgang på hver enkelt system eller konsolidering?

101 Log gennemgang 101 Administratorer og systemansvarlige har selv ansvaret for at checke og følge op på logfiler fra egne systemer. Ingen central kontrol eller styring.

102 Log gennemgang 102 Central loghost Monitor Mulighed for central styring af log gennemgang. Arkivering Lettere sammenholdelse af data Data bevares hvis enkelt enhed angribes

103 Log gennemgang 103 Central loghost Monitor

104 Log gennemgang 104 Central loghost Systemansvarlige modtager rapporter for egne systemer. Mulighed for central kontrol eller styring.

105 Logning hvordan indsamles data til loghost 105 Agenter >< Agentløs, Push >< Pull Push: Agent på maskine pusher (konvertibelt) data til central loghost Applikation pusher selv (konvertibelt) data til central loghost Minus: server er nede = ingen data, overvågning Pull: Log host henter selv (konvertibelt) data fra central loghost Minus: hacking kan medføre datatab Skal konfigureres pr. maskine Kræver typisk administrator rettigheder

106 Logning hvordan indsamles data til loghost 106 Windows Vista Syslog fleksibel, understøttes af mange systemer og applikationer

107 Hvordan logges - syslog UDP Simpel Fleksibel, udbredt understøttelse - UDP Ingen autentificering/adgangskontrol Ingen kryptering Ingen analyse eller alarmering Sikring af logfiler Andre typer logfiler

108 Hvordan logges - syslog 108 SyslogNG m.fl. Routere m.v.

109 Logning hvordan indsamles data til loghost 109 Overvej hvad der skal logges før et system købes eller en løsning designes Hvad vil vi bruge logfilerne til? Lovkrav Sikkerhed Funktionalitet Understøtter løsningen det?! Skalere løsning? Relevante spørgsmål: - Hvor tit skal logdata udveksles - real time, en gang i timen, osv.? - Hvad sker der, hvis log host ikke er tilgængelig (net/server)? Opdager klient at data ikke modtages? Frekvens: Real time 5min. 2 timer 24 timer 48 timer

110 Log sikring 110 Sikkerheden på loghosts er meget vigtig. Single point of failure Central loghost Sikker overførsel Sikker opbevaring også midlertidige filer Sikker analyse, rapportering Sikkerhed, change management, access control DoS, Virus, pen test Backup, arkivering

111 Sikring af loggen 111

112 Sikring af loggen - fortsat 112 Redundant central loghost? - Spejlede diske Sender klienterne logdata igen? Risikovurdering!

113 Frokost C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

114 Logning hvad skal man logge 114 Baseline, f.eks. DS484 Lovkrav Aftaler Risiko vurdering Best practice (Microsoft guidelines, standarder, ) Hvad skal jeg bruge loggen til (idag) >< hvad kan jeg komme til at bruge loggen til

115 Eksempler på opsætning af logparametre 115

116 Roller og rettigheder 116 Systemansvarlige - Krav til logning - Gennemgang af logs - Systemekspertise ved spørgsmål til logs Administratorer - Opsætning og konfiguration af logning - Gennemgang af logs - Rapportering til sikkerhedsansvarlige/systemansvarlige Sikkerhedsansvarlige - Gennemgang af logs(*) - Rapportering udtræk af tendenser, ændringer i risikobillede/fejlestimering - Statistik - Rådgivning vedr. konfiguration og log gennemgang

117 Retningslinier 117 Basale krav samt skærpede krav baseret på lovkrav, aftalekrav og risiko vurdering Disponeres efter DS484 disposition med bilag. Bør bl.a. inkludere - Hvilke enheder skal logge/data opsamles fra - Hvad skal som minimum logges relateret til konkrete enheder mm. - Hvordan skal logfiler opbevares (sikkert) - Hvordan skal logfiler beskyttes - Hvor længe skal logfiler opbevares - Hvordan behandles logfiler der ikke længere skal opbevares - Hvem skal kunne tilgå logfilerne - Skal logs behandles centralt evt. distribueret - Hvor tit skal logs gennemgås, forskellige typer? - Hvad gør man når der opdages mistænkelige events/hændelser i logfilerne - Hvordan håndteres fortrolige/personfølsomme data i logfilerne Udmøntes i procedurer, instrukser og tekniske foranstaltninger Support

118 Politikker formidling til medarbejderne 118 Logning Af hensyn til lovgivningen vedrørende behandling af fortrolige og følsomme data, samt drift- og it-sikkerheden i organisationens systemer, vil der forekomme logning af aktivitet på enheder og netværk. Loggen vil blive anvendt ved mistanke om ulovlige handlinger eller brud på organisationens it-sikkerhed.

119 Logning ejerskab af logs 119 Skal det være systemejer, dataejer eller administrator? Man må/bør ikke checke sig selv - checker administratoren sine egne adminlogs? Hvordan deles/opdeles log gennemgangen - Lejlighedsvis reviews af logfiler af andre(*) - Funktionsadskillelse DS opfølgningslog

120 Ikke kun administratoren 120

121 Hvorfor skal logfiler beskyttes? 121 Sikringsforanstaltning Både log-faciliteter og log-oplysninger skal beskyttes mod manipulation og tekniske fejl Hvorfor: Kan man stole på logfilen? - ændringer, sletninger, falske beskeder Potentielt bevismateriale Hvem kan/må tilgå logfilerne? - Definer, dokumenter Logfiler fra systemer der er blevet hacket Arkivering read-only, f.eks. DVD, off-line, separat system

122 Logning beskyttelse af logfiler 122 Som udgangspunkt skal en log aldrig ændres. Man kan derfor ikke tale om autoriserede ændringer. Hvis der er en fejl i en log, må eventuelle korrektioner fremgå af efterfølgende logninger Ændringer ved fejl og med vilje. - Overskrivning pga. afsat for lidt plads på harddisk - Beskyttet imod administrator ændringer? Fortroligt/personfølsomt materiale i logs? (se ) Backup af logs Fortrolighed og integritet + tilgængelighed

123 DS484 afs Hvis det er muligt, skal system administratorer og andre med særlige rettigheder ikke have mulighed for at slette logningen af deres egne aktiviteter

124 Tidssynkronisering 124 Der skal være procedurer for løbende kontrol med og eventuel korrektion med tidsangivelsen i virksomhedens informationsbehandlingsanlæg Svært at sammenholde tider på tværs af tidszoner og systemer med ure der alle går forskelligt. Synkronisering med en præcis tidsangivelse. I hvilket omfang kan dette automatiseres?

125 Behandling af indsamlet materiale C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

126 Alarmering 126 Hvordan håndteres alarmer eller mistanke om sikkerhedsproblemer efter loggennemgang? Alarmering - På skærm - SMS, Hvem skal alarmeres - Administrator - Systemansvarlige - Vagten - Sikkerhedsansvalige - Flere personer, forskellige systemer forskellige personer

127 Alarmering 127 Hvordan håndteres alarmer eller mistanke om sikkerhedsproblemer efter loggennemgang? Hvad gør man når der opdages mistænkelige events i logfilerne - Rolleindehavere - Sagsstyring, flere behandler data sammen ITIL / change mangement DS484 kap.13

128 Analyse C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

129 Loganalyse 129 The common item to look for when reviewing log files is anything that appears out of the ordinary. CERT Coordination Center, Intrusion Detection Checklist Hvad er underligt, usædvanligt, ukendt Alt der ikke er uinteressant er interessant

130 Loganalyse 130 Log-gennemgang kræver en god forståelse af de trusler, et informationssystem er udsat for, og hvorledes disse ytre sig. I findes eksempler på hændelser, som kan kræve yderligere undersøgelser Eksempler på sikkerhedshændelser og -brud er: Tab af tilgængelighed, udstyr eller faciliteter Systemfejl eller overbelastning Menneskelige fejl Hvis forretningsgange eller vejledninger ikke følges Brud på den fysiske sikkerhed Ukontrollerede ændringer i systemer Fejl i operativsystemer eller udstyr Brud på adgangskontrollerne

131 Loganalyse - baseline 131 Typisk udgør sikkerhedshændelser mindre end 1% af den totale logdata Baseline, thresholding, hvad er interessant Falske positiver Trends, forskellige typer data - historisk info Known bad Ukendte Se på baseline: Hvad er underligt Hvor mange gange sker en hændelse på en given periode (thresholding) Besked hvis besked ikke kommer frem Det, der er normalt et sted kan være meget unormalt et andet

132 Loganalyse - baseline 132 Overvågning: Start med top ti mest almindelige på DIT net/din server - Protokoller/DNS osv - Logdata pr. dag/time standard - Ændringer i trafikmængder kan være tegn på ormeudbrud IDS begrænset mange alarmer - Tweek, tweek, tune, tune Risikovurdering

133 Loganalyse - filtrering 133 Signatur matching Se efter kendte mønstre (som IDS) Fjern kendte data Se på tværs af netværk, operativsystemer og applikationer Hvad er systemejernes tekniske niveau? - Udarbejd og tilpas filtre

134 Loganalyse 134 Almindelig daglig gennemgang af logs >< alarmer Ved alarmer Fokuseres på udvalgte kritiske områder. Alarmering bør oftest være begrænset til få, kritiske områder. - Kan evt. være anden type alarm ved "røde, niveau 1 events", men kun få alarmeringer. Daglig gennemgang Ved almindelig daglig gennemgang ved man ikke hvad man kikker efter, derfor kan grafer, statistik mv. være meget nyttigt. - Pas på med snigende stigninger i transaktioner, den kogte frø Spørg sig selv/systemejere: Hvad er kritisk for dette system

135 Loganalyse undersøgelse 135 Hvordan startes en undersøgelse? Som standard benyttes der en række regelbaserede alarmer/alerts Derudover regelmæssige gennemgange af indsamlede og konsoliderede logs "Kan du sige mig" - Specifikke undersøgelser af hændelser på tidspunkt bruger IP Osv - baseret på de indsamlede og opbevarede logdata Igen, alt der ser unormalt ud

136 Loganalyse undersøgelse 136 Underlige hændelser og afvigende mønstre kan pege en undersøgelse i den rigtige retning Logfiler kan indsnævre tidspunktet for hvornår en hændelse kan have fundet sted. Kan give information om f.eks. potentielt interessante filer, personer og IPadresser, der kan benyttes i efterfølgende undersøgelser. Gennemgang af data, gerne fra en række forskellige kilder: - Hvem har været logget ind på systemet indenfor en vis periode - og hvorfra". - Er der tegn på problemer fra kendte tidligere sikkerhedshændelser", - Hvad er de mest almindelige hændelser i loggen", - Hvad er kun logget en eller to gange", - Hvad har aldrig været logget tidligere, - Er der spor efter IP-adresser, der er kendte 'angrebsadresser'". - Er der huller eller mellemrum i logningen, særligt lige efter udsædvanlige logbeskeder

137 Loganalyse hvad betyder det, der står i loggen? 137 Indbygget i nogle loganalyse værktøjer, knowledgebasen Links på computerforensics.dk Managed service Træning Konsulenter

138 Introduktion til værktøj og programmer C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

139 Managed service (og andre løsninger) 139 Hvornår gennemgås loggen (realtime, 2 timer, 12 timer, hver morgen kl. 10, i alm. forretningstid)? Dækker prisen pr. MB, per server, Hvordan hentes/pushes logdata Konsolideres på host eller hos partner Hvordan håndteres potentielt fortroligt data i loggen Administrator rettigheder på log host 3.part administrator rettigheder på log host Hvad sker der med vores logdata efter undersøgelsen? Kan vi få adgang til rapporter og rå logdata Verificere hvad de har gjort, dokumentation Sikkerhed hos outsourcing partner Kan der opstå flaskehals på netværket, når data sendes til partner Stil rutine spørgsmål som check Funktionel opdeling: administrativ sikkerhed, fysisk sikkerhed, logisk sikkerhed

140 Outsourcing 140 Ingen ekstra udstyr på netværket Minimal belastning af personale Minimal behov for træning/uddannelse SLA Manglende kontrol Opbevaring af logs Behandling af logs Opfyldes krav fra DS484: ? Viden hos leverandøren?

141 Priser, eksempler på spørgsmål til leverandøren 141 Er prisen inklusive - Hardware - Software licenser - Tilpasning af filtre - Installation - Løbende opdateringer Fast pris på tilpasning? - Understøttelse af vores logformater

142 Programmer/værktøjer 142 Gratis programmer - Logbehandling Microsoft Logparser Syslog Snare (Lasso) Cyber-Defense DAD ManageEngine (også kommerciel) - Netværksovervågning Snort Sguil Kommercielle (SIM, SEM, SIEM) programmer - Logbehandling Immune Cisco Mars CA Secure Vantage esec, PwC, CSIS, Outpost24, FortConsult - Netværksovervågning HP OpenView IBM Tivoli

143 Gratis programmer - overblik 143 Logbehandling - Snare indsamler Windows log til syslog server - Microsoft Logparser søger på tværs af filer Netværksovervågning Sguil kombinerer Snort med flere andre programmer Alarmering, visualisering, log rotation, arkivering

144 Gratis programmer - vurdering 144 Kræver typisk en række specialiserede programmer - Mindre/ingen support - Skalerbarhed - Samlede overblik - Personafhængighed - Udvikling og træning (tid) Kan tilpasses til egne behov Pris Specialiserede opgaver Syslog-ng, ssh, MySQL, SEC, OSSIM, Swatch

145 Microsoft Logparser 145

146 Visual Logparser 146

147 Syslog 147

148 Snare 148

149 DAD 149

150 ManageEngine EventLog Analyzer Freeware og kommercielt produkt

151 Netværk: Snort 151

152 Netværk: Sguil 152

153 Kommercielle programmer 153 Typisk en samlet løsning Support Pris Som udgangspunkt ikke tilpasset til egne behov Kræver nogen form for uddannelse/træning

154 Cisco Mars 154

155 CA 155

156 Secure Vantage 156

157 Immune 157

158 HP OpenView 158

159 IBM Tivoli 159

160 Immune 160 Live demo

161 ComputerForensics.dk 161

162 Pause C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

163 Håndtering af sikkerhedsrelaterede hændelser C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

164 Standarder m.m. 164 DS484: Styring af sikkerhedsbrud ISO/IEC 17799: Information security incident management ISO/IEC TR Information security incident management NIST SP Computer Security Incident Handling Guide SANS, FIRST, RFC-2350, Microsoft osv.

165 Plads i sikkerhedslandskabet 165 Beredskabsstyring = Business Continuity Management (BCM) a) Sårbarhedsvurdering og risiko analyse b) Risiko styring inkl. Forebyggelse c) Incident Response (Incident Anticipation) Reaktionsprocedurer ved sikkerhedsmæssige hændelser Disaster Recovery og Business Continuity Planning

166 DS484 - kap DS484: Styring af sikkerhedsbrud Forberedelse, ledelse og lære af sikkerhedsrelaterede hændelser. Hvordan man bedst muligt undersøger/efterforsker og håndterer hændelser. Forbedre processer ved at lære af tidligere hændelser.

167 Computer forensics >< incident response 167 To helt forskellige ting! Computer Forensics og Incident Response

168 Computer forensics Search and seizure beslaglæggelse af elektronisk bevismateriale 2. Chain of custody 3. Detaljeret gennemgang af data

169 169

170 Sikring af bevismateriale 170 Elektroniske data er flygtige og sårbare Al efterforskning må kun udføres på kopier af det egentlige bevismateriale for at beskytte dettes integritet