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
Velkomst og dagens program 2 Hvorfor er vi her Dagens formål og succeskriterier Disponeringen af programmet Deltagerpræsentation (kort)
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
Praktiske forhold 4 Pauser Frokost Løbende forplejning Toiletter Rygning Spørgsmål undervejs er altid velkomne Evalueringsskemaer
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
DS 484:2005 6 0.1 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.
DS 484:2005 7 10.10 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.
DS 484:2005 8 10.10.1 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.
DS 484:2005 9 10.10.1 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.
DS 484:2005 10 10.10.1 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. 10.10.3. En opfølgningslog vil ofte indeholde personhenførbare data og skal derfor beskyttes i overensstemmelse med Persondataloven.
DS 484:2005 11 10.10.2 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
DS 484:2005 12 10.10.2 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.
DS 484:2005 13 10.10.2 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.
DS 484:2005 14 10.10.2 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 13.1.1 findes eksempler på hændelser, som kan kræve yderligere undersøgelser.
DS 484:2005 15 10.10.3 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.
DS 484:2005 16 10.10.3 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.
DS 484:2005 17 10.10.4 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. 10.1.3. 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.
DS 484:2005 18 10.10.5 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.
DS 484:2005 19 10.10.6 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.
DS 484:2005 20 6.1.8 Periodisk opfølgning Bemærkninger Den periodiske opfølgning supplerer, men kan ikke erstatte, den løbende overvågning og kontrol.
DS 484:2005 21 6.2.3 Samarbejdsaftaler m) beskrivelse af de aftalte servicemål, deres overvågning og afrapportering n) retten til at overvåge og afbryde den aftalte serviceydelse
DS 484:2005 22 7.2.2 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.
DS 484:2005 23 8.2.1 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.
DS 484:2005 24 9.1.2 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.
DS 484:2005 25 9.1.5 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.
DS 484:2005 26 9.1.6 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.
DS 484:2005 27 9.2.1 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.
DS 484:2005 28 9.2.2 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.
DS 484:2005 29 9.2.3 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
DS 484:2005 30 9.2.4 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.
DS 484:2005 31 9.2.7 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.
DS 484:2005 32 10.1.1 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. 10.10.
DS 484:2005 33 10.1.2 Ændringsstyring Sikringsforanstaltning Ændringer til forretningskritisk informationsbehandlingsudstyr, -systemer og -procedurer skal styres gennem en formaliseret procedure. Implementeringsretningslinjer Proceduren skal indeholde følgende: g) logningsprocedure, jf. 10.10.
DS 484:2005 34 10.1.3 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.
DS 484:2005 35 10.2 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.
DS 484:2005 36 10.2.1 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.
DS 484:2005 37 10.2.2 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.
DS 484:2005 38 10.3.1 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.
DS 484:2005 39 10.4 Skadevoldende programmer og mobil kode Formål Der skal træffes foranstaltninger til at forhindre og konstatere angreb af skadevoldende programmer.
DS 484:2005 40 10.4.1 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.
DS 484:2005 41 10.4.1 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.
DS 484:2005 42 10.6.1 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. 10.10
DS 484:2005 43 10.6.2 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
DS 484:2005 44 10.7.1 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
DS 484:2005 45 10.7.2 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. 6.2.1 og 6.2.3. d) Destruktion af følsomme, fortrolige eller kritiske data skal logges af hensyn til kontrolsporet.
DS 484:2005 46 10.7.3 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.
DS 484:2005 47 11.2.2 Udvidede adgangsrettigheder Sikringsforanstaltning Tildeling og anvendelse af udvidede adgangsrettigheder skal begrænses og overvåges.
DS 484:2005 48 11.2.4 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. 11.2.1. b) En brugers adgangsrettigheder skal revurderes ved organisatoriske ændringer. c) Autorisationer til udvidede adgangsrettigheder, jf. 11.2.2, 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.
DS 484:2005 49 11.4.1 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
DS 484:2005 50 11.5 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.
DS 484:2005 51 11.5.1 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
DS 484:2005 52 11.5.2 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.
DS 484:2005 53 11.5.4 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.
DS 484:2005 54 11.7.2 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
DS 484:2005 55 12.2.1 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. 10.10.1.
DS 484:2005 56 12.2.2 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. 10.10.1.
DS 484:2005 57 12.2.4 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.
DS 484:2005 58 12.3.2 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.
DS 484:2005 59 12.4.1 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.
DS 484:2005 60 12.4.2 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.
DS 484:2005 61 12.4.3 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.
DS 484:2005 62 12.5.1 Æ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.
DS 484:2005 63 12.5.4 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.
DS 484:2005 64 12.6 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.
DS 484:2005 65 12.6.1 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. 11.4.5 3. 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.
DS 484:2005 66 13.2 Håndtering af sikkerhedsbrud og forbedringer 13.2.1 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.
DS 484:2005 67 13.2 Håndtering af sikkerhedsbrud og forbedringer 13.2.1 Ansvar og forretningsgange Implementeringsretningslinjer (fortsat) c) Opfølgningslog og lignende beviser skal indsamles, jf. 13.2.3, 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.
DS 484:2005 68 13.2 Håndtering af sikkerhedsbrud og forbedringer 13.2.2 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.
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
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 800-53 Indsamle revisions RECORDS Regelmæssig gennemgang af log for usædvanlig aktivitet og brud Automatisk behandling af logs Beskyt loginformation imod uautoriseret sletning NIST 800-92 Log management infrastruktur Planlægning af logning Konfiguration Analyse Håndtering af data Behold/bevar logfiler
Fasemodellen som flowdiagram 71
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
Hvordan opdages sikkerhedshændelser? 73 Log og loganalyse IDS Antivirus Strukturerede observationer, overvågning mm. Uorganiseret! Eksterne parter, kunder, brugere, administratorer
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)
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.
Plads i sikkerhedslandskabet 76 Prevent Detect Respond Recover Sikkerhedspolitikker Forebyggende sikkerhedsforanstaltninger logindsamling IDS Antivirus Overvågning Incident team Eskalations procedurer
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
Hvorfor foretage overvågning? (fortsat) 78 Identificere mistænkelig eller uautoriseret netværkstrafik Udadgående IRC (Internet Relay Chat) (f.eks. port 6660-6669 mv.) Udadgående mail (port 25) fra ikke-mailserver Monitorering ved mistanke om sikkerhedsproblemer Få overblik over forbrug af båndbredde Top 5 modtager/afsender Top 10 protokoller Top 10 sessions
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. 10.10 Planlægning, fejlfinding, kapacitetsovervågning (oppetid, ressourceforbrug, services, fejl m.v.), information om drifts- og applikationsproblemer. - Fejlog (DS484 10.10.5) Opdagelse af hændelser, beskyttelse imod trusler - Incident response, forensics - kan være eneste spor og bevismateriale
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?
Logning muligheder 81
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
Hvad er en log? 83
Hvad er en log? Event/hændelse 84
Hvad er en log? (NB: Ikke samme hændelse) 85
Hvad er en log? 86
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
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
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
Aktiver 90 Ikke kun overvågning af firewall logs og ignorere de interne systemer
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
Hvad kan man logge 92 Logiske sikkerhed Fysisk sikkerhed Administrativ sikkerhed Automatisk vs. manuel logning
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
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
Hvad kan man logge segmentering logisk sikkerhed 95 DMZ >< intern Segmentering, VLAN Hovedkontor >< afdelinger
Placering af centrale logenheder logisk sikkerhed 96 DMZ >< intern Segmentering, VLAN Hovedkontor >< afdelinger
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
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
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
Konsolideret logning 100 Gennemgang på hver enkelt system eller konsolidering?
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.
Log gennemgang 102 Central loghost Monitor Mulighed for central styring af log gennemgang. Arkivering Lettere sammenholdelse af data Data bevares hvis enkelt enhed angribes
Log gennemgang 103 Central loghost Monitor
Log gennemgang 104 Central loghost Systemansvarlige modtager rapporter for egne systemer. Mulighed for central kontrol eller styring.
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
Logning hvordan indsamles data til loghost 106 Windows Vista Syslog fleksibel, understøttes af mange systemer og applikationer
Hvordan logges - syslog 107 + UDP Simpel Fleksibel, udbredt understøttelse - UDP Ingen autentificering/adgangskontrol Ingen kryptering Ingen analyse eller alarmering Sikring af logfiler Andre typer logfiler
Hvordan logges - syslog 108 SyslogNG m.fl. Routere m.v.
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
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
Sikring af loggen 111
Sikring af loggen - fortsat 112 Redundant central loghost? - Spejlede diske Sender klienterne logdata igen? Risikovurdering!
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
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
Eksempler på opsætning af logparametre 115
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
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
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.
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 DS484 10.10.1 - opfølgningslog
Ikke kun administratoren 120
Hvorfor skal logfiler beskyttes? 121 Sikringsforanstaltning Både log-faciliteter og log-oplysninger skal beskyttes mod manipulation og tekniske fejl. 10.10.3 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
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 10.10.3 Æ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 10.10.1) Backup af logs Fortrolighed og integritet + tilgængelighed
DS484 afs. 10.10 123 Hvis det er muligt, skal system administratorer og andre med særlige rettigheder ikke have mulighed for at slette logningen af deres egne aktiviteter 10.10.1
Tidssynkronisering 124 Der skal være procedurer for løbende kontrol med og eventuel korrektion med tidsangivelsen i virksomhedens informationsbehandlingsanlæg. 10.10.6 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?
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
Alarmering 126 Hvordan håndteres alarmer eller mistanke om sikkerhedsproblemer efter loggennemgang? Alarmering - På skærm - SMS, e-mail Hvem skal alarmeres - Administrator - Systemansvarlige - Vagten - Sikkerhedsansvalige - Flere personer, forskellige systemer forskellige personer
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
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
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
Loganalyse 130 Log-gennemgang kræver en god forståelse af de trusler, et informationssystem er udsat for, og hvorledes disse ytre sig. I 13.1.1 findes eksempler på hændelser, som kan kræve yderligere undersøgelser. 10.10.2 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 13.1.1
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
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
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
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
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
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
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
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
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
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:2005 6.2? Viden hos leverandøren?
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
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
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
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
Microsoft Logparser 145 http://www.logparser.com/
Visual Logparser 146 http://en.serialcoder.net/logiciels/visual-logparser.aspx
Syslog 147 http://www.syslog.org/
Snare 148 http://www.intersectalliance.com/projects/snarewindows/index.html
DAD 149 http://www.cyber-defense.org/dad.html
ManageEngine EventLog Analyzer 150 http://manageengine.adventnet.com/products/eventlog/ http://demo.eventloganalyzer.com/event/index2.do Freeware og kommercielt produkt
Netværk: Snort 151 http://www.snort.org/
Netværk: Sguil 152 http://sguil.sourceforge.net/
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
Cisco Mars 154 http://www.cisco.com/en/us/products/ps6241/index.html
CA 155 http://www3.ca.com/solutions/product.aspx?id=157
Secure Vantage 156 http://www.securevantage.com/
Immune 157 http://www.immune.dk/
HP OpenView 158 http://h20229.www2.hp.com/
IBM Tivoli 159 http://www-306.ibm.com/software/tivoli/
Immune 160 Live demo
ComputerForensics.dk 161
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
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
Standarder m.m. 164 DS484:2005 13. Styring af sikkerhedsbrud ISO/IEC 17799:2005 13 Information security incident management ISO/IEC TR 18044 Information security incident management NIST SP 800-61 Computer Security Incident Handling Guide SANS, FIRST, RFC-2350, Microsoft osv.
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
DS484 - kap.13 166 DS484:2005 13. 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.
Computer forensics >< incident response 167 To helt forskellige ting! Computer Forensics og Incident Response
Computer forensics 168 1. Search and seizure beslaglæggelse af elektronisk bevismateriale 2. Chain of custody 3. Detaljeret gennemgang af data
169
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. 13.2.3