Praktisk bruk og oppfølgning av logger

Praktisk bruk og
oppfølgning av logger
Oddbjørn Steffensen
Sjefskonsulent Sikkerhet
EDB Business Partner

Historisk perspektiv
 Unix: find /var/log -mtime +7d -type f –exec rm {} ;

 Windows:

“Logfiles: The Data Center’s Equivalent of Compost. Let’em Rot.” – Marcus J. Ranum
EDB Anvendt Logghåndtering
2

Motivasjon
• Oppdage uautoriserte • Datagrunnlag ifb.
handlinger og policybrudd hendelseshåndtering
• Trendanalyse & baselining • Fastslå årsakssammenhenger
• Gi oss ”situational • Bevissikring / forensics
awareness”

Deteksjon Reaksjon

Revisjon og
Refleksjon
compliance
• Hva skjer i systemene våre?
• Logger vi det vi burde logge?
• Hva er normalt og abnormalt? • Etterlevelse av interne og
• Loggene som telemetri mot eksterne krav (for eksempel
infrastrukturen vår 27001, PCI DSS, SOx mfl.)
• Fungerer sikringsmekanismene
som forventet?
3

Fra logg til forståelse
Mar 21 00:42:40 epia sshd[20318]: Invalid user a from 83.19.222.221
Mar
Mar
Mar
21
21
21
00:44:00
00:45:00
00:42:13
Who
epia /usr/sbin/cron[20342]: (operator) CMD (/usr/libexec/save-entropy)
epia /usr/sbin/cron[20362]: (root) CMD (/usr/libexec/atrun)
node2.lan ntp: Clock synchronized to network time server time.apple.com
Hvem gjorde
Mar 21 00:42:53 Airport-Express.lan Airport-Express 80211: Rotated CCMP group key.
Mar
Mar
Mar
Mar
21
21
21
21
00:50:00
00:53:33
01:00:00
01:00:00
What,
epia /usr/sbin/cron[24691]: (root) CMD (/usr/libexec/atrun)
did
MBP.lan mbp /usr/sbin/ocspd[28388]: starting
epia /usr/sbin/cron[36977]: (root) CMD (newsyslog)
epia /usr/sbin/cron[36978]: (operator) CMD (/usr/libexec/save-entropy)
Hva,
Mar 21 01:00:00 epia /usr/sbin/cron[36979]: (root) CMD (/usr/libexec/atrun)
Mar
Mar
Mar
21
21
21
01:01:52
01:01:56
09:56:54
When,
epia sudo: userA : TTY=ttyp0 ; PWD=/usr/local/www/data/wordpress
epia sudo: userA : TTY=ttyp0 ; PWD=/usr/local/www/data/wordpress
epia sshd[45971]: Did not receive identification string from 93.103.12.217
Hvor,
Mar 21 11:55:21 epia sshd[46447]: Did not receive identification string from 12.155.124.130
Mar 21 11:55:36 epia sshd[46450]: Invalid user fluffy from 202.155.124.130
Mar
Mar
Mar
21
21
21
11:55:40
11:55:44
11:55:46
Where
epia sshd[46452]: Invalid user admin from 202.155.124.130
epia sshd[46454]: Invalid user test from 202.155.124.130
epia sshd[46456]: Invalid user guest from 202.155.124.130
Hvortid,
Mar 21 11:55:49 epia sshd[46458]: Invalid user webmaster from 202.155.124.130
Mar
Mar
Mar
Mar
21
21
21
21
11:55:56
11:55:59
11:56:01
11:56:04
How
epia sshd[46463]: Invalid user oracle from 202.155.124.130
and
epia sshd[46465]: Invalid user library from 202.155.124.130
epia sshd[46467]: Invalid user info from 202.155.124.130
epia sshd[46469]: Invalid user shell from 202.155.124.130
Hvordan
Mar 21 11:56:08 epia sshd[46471]: Invalid user linux from 202.155.124.130
og ikke minst
Mar
Mar
Mar
21
21
21
11:56:11
11:56:14
11:56:23
and Why?
epia sshd[46473]: Invalid user unix from 202.155.124.130
epia sshd[46475]: Invalid user webadmin from 202.155.124.130
epia sshd[46478]: Invalid user ftp from 202.155.124.130
Hvorfor?

4

Fra data til handling …
Mar 21 11:55:44 minserver sshd[46454]: Invalid user test from 202.155.124.130

Tegn

Data

Informasjon

Kunnskap

Handling
“Information is data endowed with relevance and purpose.” – Peter Drucker
5

… som i praksis blir:

1. Tegn Mar 21 11:55:44 minserver sshd[46454]: Invalid user test from 202.155.124.130

2. Data token token token token token token token token token token

3. Informasjon måned dag tid node opphav ssh-hendelse med hva/hvem/hvorfra

Den 21. mars 11:55:44 forsøkte noen fra IP-adressen 202.155.124.130
4. Kunnskap
å logge på minserver med brukernavn test
1. Hvem er 202.155.124.130?
2. Har noen bak den adressen legitimt behov for å logge på minserver?
5. Handling 3. Er test en lovlig bruker på minserver?
4. Prøver noen å bryte seg inn på minserver?
5. Hvorfor får 202.155.124.130 i det hele tatt snakke med minserver?

6

Hva trenger vi?
Tema i NISTs Guide to Computer
Security Log Management (800-92):

7

Hovedingredienser
• Hva er forretningsmessig drivkraft?
• Hvem er ansvarlig for regimet?
• Hvilke faginstanser må involveres?
• Hvem er interessentene?
• Hvem er konsumentene?

• Deployment
• Forvaltning og operasjon
• Analyse (løpende/ad hoc)
• Hendelseshåndtering
• Loggkilder • Eskaleringsveier
• Logghåndteringsløsning • Bevissikring
• Lagring- og arkivering
• Systemintegrasjon
8

Faser i logghåndteringen
• Identifisere kilder • Innsamling • Rapportering • Forvaltning og drift
• Konfigurere kilder • Transportere • Berikelse • Kompetanse
• Vaske • Prioritering • Kobling mot prosess
• Tidssynkronisering • Normalisere • Korrellering • Hendelseshåndtering
• Sporbarhet • Konsolidere • Gruppering • Tilpasninger og integrasjon
• Lagre • Visualsering • Workflow & ticketing
• Sikre • Alarmering • Varsling

Loggkilder Prosessere Analysere Operasjon

Vanskelighetsgrad

9

Loggkategorier
• Brannvegger, proxyer, routere og switcher

Nettverk •
•
•
IDS og Netflows
DNS og DHCP
VPN-løsninger

• Systemnære logger

Plattform • Unix syslog, Windows Eventlog, z/OS SMF
• Auditlogger
• Sikkerhetssystemer (AAA)

• Appliksjonsspesifikke logger

Applikasjon • Mellomvare
• Databaser

Forretning • Transaksjonslogger

Relativt enkle isolert sett, men hva om noen spør:
1. Hva har bruker XYZ gjort? (top-down)
2. Hva har skjedd i forbindelse med verdikjede ABC? (top-down)
3. Hva har angriper fra IP-adresse a.b.c.d gjort? (bottom-up)
10

Identifisering av loggkilder
• Windows Eventlog

Windows
Brukers PC domenekontroller

• Unix syslog
• Webserverlogg • Audit-trail
• Applikasjonslogg
• Auditlogg
Unix-
• Brannvegg (trafikk + audit) Oracle
server
• Windows Eventlog • Web- og e-mailgatewayer
• Browserhistorikk • DHCP- og DNS-logg
• VPN-logg • Netflows
• VPN-autentiseringslogg

• Logg fra ACF/2 eller RACF
15+ distinkte kilder for • Hendelser fra SMF
selv et forenklet scenario • Transaksjonslogg (forretning)

Mainframe

11

Forslag til prioritering

Sikkerhets- Internett- Infrastruktur
systemer eksponert • DHCP & DNS
• Sec Evtlog fra DCer • Webservere • Brannvegg
• LDAP • Plattformer (trafikk & audit)
Annet
• RACF & ACF/2 • Applikasjoner • Malware
• RSA & Cisco ACS • Netflows • Netflows
• RDBMSer • (Fysisk adgang)

12

Hva bør logges?
2700x

Standard of Good Practice

BSI Guidelines for logging procedures

PCI DSS
•userIDs •start/stop times for key • System generation and •User identification
•dates, times and details of systems and processes modification of system •Type of event
key events, eg. logon and •successful sign-on by parameters •Date and time
logoff authorized users and failed •Configuration of users •Success or failure indication
•terminal identity or location if sign-on attempts •Preparing rights profiles •Origination of event
possible •error and exception •Implementation of data •Identify or name of affected
•records of successful and conditions backup measures data, system component or
rejected system access •access or changes to files or •Use of administration tools resource
attempts programs •Attempts at unauthorized
•records of successful and •access to privileged login and transgressions of
rejected data and other capabilities rights
resource access attempts •Input of data
•changes to system •Data transfer
configuration
•Use of automatic retrieval
•use of privileges procedures
•use of system utilities and •Deletion of data
applications
•Invocation of programs
•files accessed and the kind of
access
•network addresses and
protocols
•alarms raised by the access
contriol system
•activation and deactivation of
protection systems, such as
antivirus systems and
intrusion detection systems
Standard sikkerhetslogger fra de vanligste
plattformene gir oss bare dette i begrenset grad, og vi
må enten tilpasse loggingen, supplere eller resignere.
13

Konfigurering
1. Kartlegg hva de ulike loggkildene er i stand til å levere (default og
med aktiv konfigurering)
2. Definer en policy for den enkelte type loggkilde/-plattform
3. Gjør en vurdering av belastning og volum policyen vil medføre

14

Vasking av loggdata
Microsoft Security Monitoring and Attack Detection Planning Guide

 Logger kan inneholde mye ”støy”
– Spesielt utunet
 Kan redusere loggvolum med 95%+

“Artificial Ignorance.”
– Marcus J. Ranum

 Kan filtreres på flere steder:
– Avleverende node (tweaking eller filter)
– Ved sentralt mottak
– Før last til database eller lignende
– Vasking internt i database
 Kan være nødvendig å oppbevare
komplette logger ift. bevisføring

15

Resthendelser
Apr 15 02:39:15 statd[2468]:
attempt to create
"/var/statmon/sm/; echo "ingreslock
Kjent
stream tcp nowait root /bin/sh sh -
Kjente ”støy” i" >>/tmp/bob; /usr/sbin/inetd -s
hendelser /tmp/bob &"

Kjente • Hendelse for ca. ti år siden
hendelser
• Sårbarhet i Sun Solaris rpc.statd
• Lyttende root-shell på port 1524/tcp
• Fullstendig kompromittert maskin
• Logginnslaget ville sannsynligvis ikke
blitt fanget opp av loggrapportering
Resthendelser • (ikke driftet av EDB på dette tidspunktet)
16

Unknown Unknowns
As we know, there are known knowns.
There are things we know we know.
We also know there are known unknowns.
That is to say we know there are
some things we do not know.
But there are also unknown unknowns,
The ones we don't know we don't know.
— Donald Rumsfeld (2002)

17

Sikre sporbarhet
 Hvert ledd i verdikjeden skal minst
kunne spore sine hendelser ett ledd
fram og ett ledd tilbake Database Admin

 For å kunne sammenstille logger trenger
vi en eller flere av følgende:
– Korrekt tidsstempling SysB
SysA
– Identifikatorer:
– IP-adresse
Internett
– brukernavn
– kundenummer
– transaksjonsidentifikator
– eller lignende SysC
Telenett
 Selv om «korrekt tid» er implementert,
bør det kunne dokumenteres at dette Forsøk på svindel
faktisk virker i tilfelle rettssak • Rettet angrep mot verdikjede via flere vektorer
 Definér use case-scenarioer og verifiser
at disse er dekket av logghåndterings- • Ingen gode identifikatorer på tvers av verdikjedene
regimet. • Systemer mer eller mindre ute av tidssync
• Varierende grad av logging på plass
 Sett krav til avleverende systemer • Mye manuell jobbing for å få fatt i relevante logger

18

Sikring av loggdata
 Rask evakuering av logg  Sikring av loggplattformen
– Batch versus nær sanntid
– Klassifiser logghåndterings-løsningen
– Kan ikke stole på logg fra
kompromitterte maskiner på nivå med høyest klassifiserte
avleverende system
 Sikker transport – Om kunnskap er makt, hva er flere
– Signering terabyte med loggdata?
– Kryptering
– Sikkerhetspatching
– UDP versus TCP
– Buffering – Herding
– Tilgangskontroll
 Generering av hasher av
loggmateriale med sikker
lagring
Hva kan så tvil om loggenes integritet?
 Retensjon av logger
– Avhengig av behov (helst 3mnd+) Tenk som om du var motpartens
ekspertvitne i en eventuell rettssak!
19

Analyse av logger

Not everything that can be counted counts,
and not everything that counts can be counted.
– Albert Einstein

Everything counts (in large amounts).
– Depeche Mode

20

Data overflow
Ok, dette er en oppsummering…

Hvilken
boks var
nå dette
igjen?

EDB Anvendt Logghåndtering Whoa!
21

Paralysis by analysis

Deteksjon Reaksjon

Refleksjon Revisjon

22 Med unnskyldning til eventuelle CISAer i salen..

TM & © 2008 Entertainment Rights Distribution Limited. All rights reserved.

Where’s Waldo

23

Manglende kontekst

• Hva betyr EventIDene?
• Er dette vellykkede eller mislykkede forsøk?
• Er volumene normale?
• Hvordan er trendutviklingen?

24

Rapporteringsformer
• Hvem har logget på minserver i dag?
Enkle • Hvor har brukerA logget på i dag?
• Hvilke mislykkede forsøk på sudo-bruk har vi i dag?

• Hvor mange malwarehendelser hadde vi siste måned?
Aggregerte • Hvor mange pålogginger forekommer om natten?
• Hvilke noder initierer kontakt med mer enn 10 noder?

Trender • Har det vært en økning i mislykkede pålogginger siste døgn?
• Har vi flere eller færre malwarehendelser nå ift. tidligere?

Anomalier • Har vi forekomster av samtidig bruk av en brukerident fra
flere maskiner?

25

Hvordan finne nålen?
 Hvordan oppdager vi det ekstraordinære blant det ordinære?
– Filtrering (vasking) og gruppering hjelper oss til en viss grad
– Prefabrikerte rapporter og signaturer hjelper til en viss grad, men:

 Vanskelig å uttømmende spesifiserende hva som er signifikant

 Vi kan i tillegg benytte følgende for å gi oss bedre overblikk:
1. Informasjonsfusjon – berikelse av logghendelser med støtteinformasjon
2. Visualisering – øke båndbredden ut mot analytiker

26

Informasjonsfusjon
Logghendelse
 Tradisjonell korrellering mappet
innbyrdes mellom logghendelser vha. IP-
1 stk adresser, brukernavn og lignende
 Nyttig, men hva skjer om vi mapper mot

>2 teknisk støtteinformasjon fra eksterne
kilder?
– Brannveggregelsett, DHCP, malware-hendelser,
assetinformasjon, geomapping, brukere, MAC-
1 stk prefix, HR-system, routingtabell, sårbarhetsinfo

Støtteinformasjon
 Målet er å gi kontekst til hendelsene

“Information fusion is an Information Process dealing with the:
[association, correlation, and combination of data and information] from
[single and multiple sensors or sources] to achieve
[refined estimates of parameters, characteristics, events, and behaviors] for
observed entities in an observed field of view."
27

Et praktisk eksempel
SNMP Trap: 2009-09-01 14:23:16 Virus W32.Virut.CF found on host 10.99.1.14

Kilde Supplerende informasjon
DHCP-logg 10.99.1.14 ble på tidspunktet (sannsynligvis) benyttet av klient63
DHCP scopedefinisjon 10.99.1.14 er del av 10.99.1.0/24 som er filialen i Mandal
Assetregister klient63 er en laptop som disponeres av brukerA (Ole Olsen, Mandal)
HR-system eller AD Ole Olsen disponerer telefon med nummer 5551 2345
Security Eventlog fra Viser pålogginger av brukerA i forkant av hendelsen fra 10.99.1.14
domenekontrollerne
SNMP Trap-log Viser ingen andre W32.Virut.CF-hendelser i nettet
SNMP Trap-log Viser ingen andre malwarehendelser i Mandal
Virusleverandører Direkte link til informasjonsside om W32.Virut.CF for vurdering av
kritikalitet, informasjon om modus operandi mv.

28

OODA-loopen
Hva skjer?

Utføre tiltak
Hva betyr det?

Må vi iverksette tiltak?

29 Kilde: John Boyd, USAF

Bruk av DHCP-logger
30,04/04/08 07:12:27 DNS Update Request 1.1.168.192,abc.xyz.lan,,
10,04/04/08 07:12:27 Assign 192.168.1.1,abc.xyz.lan,000D8894E4B3,
32,04/04/08 07:13:51 DNS Update Successful 192.168.1.1,abc.xyz.lan,,

00-0D-88 (hex) D-Link Corporation
http://standards.ieee.org/regauth/oui/oui.txt 000D88 (base 16) Hsinchu 30077 TAIWAN, REPUBLIC OF CHINA

”Jeg testet denne muligheten 4. april,
og benyttet den for oppgradering i går
8. april. Samme D-LINK AP2000+ ble
benyttet begge ganger, og AP’et var i
begge tilfeller konfigurert med WPA-
PSK. Var nok operativt totalt ca 1 time
ved begge anledninger.”

Obs! Husk at en angriper enkelt kan
overstyre/klone MAC-adressen Enkel identifisering
av VMware-instanser
30

Refleksjon

Argyris & Schön: Organizational learning: A theory of action perspective (1978)
Årsak Hendelse Konsekvens

"Single-loop" læring

"Double-loop" læring

 I logghåndtering er det lett å bare fokusere hendelse→konsekvens og ikke årsak
 Vi kan få ut mye mer verdi ved å også se på årsaksforholdene

31 Detect the expected ― Discover the unexpected

Brukeradministrasjon
2007-01-02 12:11:49 | Security | 624 | t | Account Management | EDB/E9999| EDBYYYADC001 ”Rå” hendelse
1 | User Account Created | {{"New Account Name",XX1597},{"New Domain",EDB},{"New Account
ID","{S-1-5-21-1617895038-2399380067-405634583-43577}"},{"Caller User Name",E9999},{"Caller fra Windows
Domain",EDB},{"Caller Logon ID","(0x0,0x28EF5D45)"},{"Privileges - Security Eventlog
",""},{Attributes:,""},{"Sam Account Name",XX1597},{"Display Name",“Ole Hansen"},{"User
Principal Name",XX1597@edb.local},{"Home Directory",//EDB-Users-Data-Server/EDB-
Users005$/XX1597},{"Home Drive",H:},{"Script Path",et},{"Profile Path",-},{"User
Workstations",-},{"Password Last Set",<never>},{"Account Expires",<never>},{"Primary Group
ID",513},{AllowedToDelegateTo,-},{"Old UAC Value",0x0},{"New UAC Value",0x15},{"User Account
Control",""},{"Account Disabled",""},{"Password Not Required - Enabled",""},{"Normal Account
- Enabled",""},{"User Parameters",-},{"Sid History",-},{"Logon Hours","<value changed, but
not displayed>"}}

time | account | creator | department Mappet mot avdeling
2 --------------------+---------------------+--------------------+-----------------
2007-01-04 11:21:40 | XX1597 (Ole Hansen) | E9999 (Kjell Olsen)| Operativ sikkerhet til utførende konto

3 Generering av rapport som viser brukeradministrative hendelser per avdeling.
Kan fullautomatiseres ved hjelp av uttrekk fra HR-system.

1. At en bruker blir opprettet er normalt
2. At brukeren som oppretter kommer fra en avdeling som har dette som oppgave er normalt
3. At en bruker utenfor disse avdelingene oppretter en bruker er et potensielt policybrudd

32

Visualisering

33 A picture is worth a thousand packets. – Greg Conti

A periodic table of
visualization methods

Used by permission
34

Påloggingsforsøk

Hver celle gir drill-down-muligheter

35

Serverbelastning

• Visualisering lar oss dramatisk øke båndbredden ut mot analytiker.
• Heatmapet viser ~365 datapunkter, og sparklines over 8500 datapunkter
• Ved et øyekast kan vi gjøre oss opp en kvalifisert mening om belastningen på
aktuell server, og også fange opp naturlige variasjoner (helger osv).

36

Dataflyt mellom noder

“The simple fact that Alice telephones a known terrorist every
week is more important than the details of their conversation.”
EDB Anvendt Logghåndtering – Bruce Schneier, Secrets & Lies
37

Implementering
 Veldig lett å ta utgangspunkt i:  Hvorfor skal vi logge?
– Windows Security Eventlog
– Unix syslog  Hva bør vi logge?
– Brannvegglogger
 Hva kan vi logge?
 Når har vi bruk for loggene?
 Ta heller et steg tilbake
 Hvem skal vi logge?
 Hva har vi lov til å logge?
 Implementering i tre steg:
1. Forberedende  Hvor skal vi logge?
2. Valg og utforming av løsning
 Hvordan skal vi logge?
3. Implementering og operasjonalisering

38

Implementering: Steg 1

Løpende

Clipart fra Todd Zazelenchuk & Elizabeth Boling
Hendelser
Etterforskning

39


40


41

Føringer

Pragmatisme Effekt
• Identifiser interessenter • Ta høyde for endret målbilde
• Sikre eierskap • Korte iterasjoner
(forretningsmessig, løsning, • Paretos 80/20-regel • Logghåndtering er ikke
avleverende miljø, brukere)
• Hyppige releaser
• Ikke gap over alt på én gang • Ikke mal inn i et hjørne målet
• Involver disse underveis
• Det finnes ikke dårlige produkter, • Få opp rapporter som gir
• Logghåndtering må integreres bare dårlige anskaffelsesprosesser effekt
• Tenk koordinerte/fødererte • Scenariebasert planlegging
løsninger fremfor one-size-fits all
Forankring Smidighet

“A good plan violently executed today is better than a perfect plan next week.” - General George Patton
42

Antipatterns
• Hoppe over initiell behovsanalyse og tydelig forretningsbehov
• Ikke utpeke tjenesteansvarlig
Forankring • Ikke ha oversikt over kostnadsbildet
• Å la compliance være den primære driveren for løsningen

• Vi har et Problem™, la oss kjøpe et Produkt™!
Produkt • Forventninger om en ”maskin som sier ping!” ved hendelser
• Urealistiske forventninger til hva en logghåndteringsløsning alene kan gi

• Ikke gjennomføre reell pilot
Innfasing • Ikke gjennomføre tilstrekkelig testing av nødvendig systemintegrasjon
• Ikke allokere tilstrekkelig ressurser til implementering og løpende drift

• Ikke identifisere tilgjengelige loggkilder
• Ikke definere use cases for logganvendelse
Anvendelse • Bli for fokusert på hendelse → konsekvens, og dropper årsak
• Slavisk rapportering; ingen trening på bruk av logginformasjonen

43

Hyllevare ↔ hjemmesnekret

Support Modenhet Utvidbarhet Kostnad

Referanser Kompetanse Fleksibilitet Mye gaffatape..

Rettede
Funksjonalitet Kostnad Kompetanse
rapporter
Person-
Skalerbarhet Generiske Smidighet
avhengig

Hyllevare Hjemmesnekret
44

Et praktisk eksempel
Jun 5 12:55:44.359: %SEC-6-IPACCESSLOGP: list logacl permitted tcp 192.168.16.1(38402) -> 192.168.16.2(23), 1 packet

• Ormehendelse for flere år siden
• Hvordan identifisere infiserte noder?
• Etablerte ACLer på routere
• Logging via syslog mot Unix-node
Liste • Script aggregerte hendelsene i
~sanntid
• Vasking av legitime noder
over • Varsling via SMS

• Netflow kunne også blitt benyttet
hostnavn
og Under 50
linjer Perl

IP-adresser
(grønt tall =
node sjekket ut)
45

The Gartner Magic Quadrant for Security
Information and Event Management (SIEM): 2006-2009
Leverandører:
• CA
• Cisco
• IBM
• Novell
• RSA / EMC
• Symantec

• ArcSight
• Consul (kjøpt av IBM 2006-12)
• eIQnetworks (etablert 2001)
• ExaProtect (kjøpt av LogLogic 2009)
• High Tower (nedlagt 2008)
• Intellitactics
• LogLogic (etablert 2002)
• LogRhytm (etablert 2003)
• netForensics (etablert 1999)
• Network Intelligence (kjøpt av EMC 2006)
• NetIQ (etablert ~1995)
• NitroSecurity (etablert 1999)
• OpenService (etablert ~2002)
• Prism Microsystems (etablert 1999)
• Q1 Labs (etablert 2001)
• Quest Software (etablert 1987)
• SenSage (etablert 2000)
• Tenable Network Security (etablert 2002)
• TriGeo (etablert 2001)

46
Used by kind permission of

Oppsummering
• Det er en utfordring å få nyttiggjort sikkerhetsdata,
men har vi råd til å la være?

• Ved å studere våre systemer nærmere i fredstid
står vi bedre rustet til å håndtere hendelser

• Loggene kan få mye større verdi med berikelse

• Visualisering er kult! Og iblant også nyttig…

• Det finnes ingen fasit!
47

Spørsmål?
 En del brutale generaliseringer og
grove overforenklinger er begått
 Momenter som bevisst er utelatt:
– Juridiske aspekter ved overvåkning
– Log↔LMI↔ SEM↔SIM↔SIEM
– Plattformspesifikke forhold
– Spesifikke kommersielle løsninger

“Some problems are so complex that you have to
be highly intelligent and well informed just to be
undecided about them. – Laurence Peter

oddbjorn.steffensen@edb.com
oddbjorn@tricknology.org
48

Noen relevante ressurser
 Bøker og publikasjoner  Websteder
– Audit and Trace Log Management, Phillip Maier – http://www.loganalysis.org/
– Security Log Management, Jacob Babbin – http://www.rumint.org/gregconti/
– ISF: Security/Event Working Group Final Report – http://www.raffy.ch/
– NIST 800-92: Guide to Computer Security Log – http://secviz.org/
Management – http://www.securityforum.org/
 Konferanser – http://www.securitymetrics.org/

– Usenix Workshop on the Analysis of System Logs – http://www.isif.org/

– SANS WhatWorks Log Management & Analysis – http://manyeyes.alphaworks.ibm.com/

– CERT FloCon – http://www.graphviz.org/
– http://www.visual-literacy.org/
– http://www.edwardtufte.com/
– http://www.cert.org/flocon/
– http://tools.netsa.cert.org/
– http://www.caida.org/
– http://cee.mitre.org/

50

Praktisk bruk og oppfølgning av logger

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Praktisk bruk og oppfølgning av logger