Alle systemer fungerer jo, så da er vel alt ok. Vel, er det det? Har dere faktisk sjekket? For det er mye man kan sjekke i det dere allerede har.
Indicator of Compromise (IoC)
Eller på norsk, en indikator på kompromittering, innbrudd eller hendelse.
- Dere eksisterer.
- Dere er digitale.
- Dere vet at truslene eksisterer.
- Dere vet at man alltid har sårbarheter.
Til sammen danner dette risiko. For å adressere denne risikoen finner man tiltak, på alt fra mennesker, prosesser til teknologi. Kanskje tjenesteutsetter man. Kanskje kjøper man tjenester i skyen. Ting er komplekst og sikkerheten er derfor meget sentral og viktig.
Men hva om noe uønsket skjer? Hva om en trusselaktør finner en sårbarhet hos dere, bevisst eller ubevisst. Hva om denne aktiviteten identifiseres av sikkerhetsteknologien og IoC-signaturer? Hva gjør man med disse indikatorene på kompromittering eller innbrudd?
Logger vs alarmer
Logging brukes som et begrep om det å lagre informasjon om ting som skjer. Loggene brukes svært sjelden og først typisk etter en hendelse. Men deler av loggene er alarmer, og alarmer, tilsvarende innbruddsalarmen i huset eller bilen din, eller i et kjernekraftverk, bør/må få oppmerksomhet.
Følger dere med på alarmene/IoC’ene i datasystemene som er indikatorene på at dere kan ha uønskede hendelser på gang? Disse kan komme fra serverne deres, fra PC’ene, fra nettverket med brannmurene eller fra skytjenestene. Hva med alarmer fra deres tjenesteleverandør? Har tjenesteleverandøren alarmering på plass? Får dere informasjon om alarmer som skjer hos tjenesteleverandøren?
Suksessfulle hendelser skjer i tillatt trafikk
Normal aktivitet skjer og den skjer i tillatt trafikk. Den skjer i løsninger vi mennesker har satt opp og gitt tillatelser i. Det er i denne trafikken suksessfulle hendelser skjer. Det er derfor viktig å ikke tillate for mye.
Man har sikkerhet og man tenker at denne stopper skadelige hendelser. Den gjør og skal gjøre det. At ting stoppes, gjør angrepet/innbruddet/tyveriet/skadegjøringen mislykket. Men hva om de kriminelle ikke gir seg? Hva om de bare fortsetter? Hva om de rett og slett bare logger inn med noens brukernavn og passord? Hva om de misbruker en ukjent sårbarhet? Hva om de gjør aktivitet der det mangler sikkerhet og alarmering? Da går typisk ingen alarmer. Da kan skade begynne å skje, og da utløser nesten alltid en eller flere alarmer i forsøkene.
En alarm/IoC kan være en viktig indikator på at noe er i ferd med å skje. Er det en phishing-alarm eller en skadevare-alarm? Er det en alarm om at noen prøver å misbruke en sårbarhet? Er det en innbruddsalarm som indikerer at noen prøver å logge inn, men har feil brukernavn og passord? Det kan være mange forskjellige alarmer, men de er der for en grunn. Følg derfor med på dem. Få hjelp til å følge med på dem om dere ikke kan gjøre det selv. Skjer det noe mistenkelig i den tillatte trafikken? Det er mulig å sikre alarmering på avvik fra normal adferd i tillatt trafikk også.
Les også: Et automatisert Security Operations Center (SOC) er nøkkelen til god IT-sikkerhet
Det er forskjell på alarmer og logger. I alarmene ligger de mislykkede angrepene. I loggene ligger de suksessfulle.
Nasjonal Sikkerhetsmyndighet sier følgende om viktigheten av logging
«Norske virksomheter må forholde seg til et vidt spekter av trusler i det digitale rom. Skade kan påføres IKT-systemene både som følge av utilsiktede handlinger som feil og uhell, men også av tilsiktede handlinger som spionasje og sabotasje. For å beskytte mot trusler av alle typer er det kritisk at virksomhetene kan oppdage og håndtere en hendelse. Etablering og analyse av logger er en forutsetning for effektiv håndtering av hendelser.»
Konklusjon
Man må forholde seg til verdier, trusler, sårbarheter, risikoer, risikovurdering, tiltak, sikkerhet, logger og alarmer.
- Sikre tilstrekkelig logging, for så mye som mulig, så lenge som det er fornuftig for deg og dere. Det kan være 3, 6 eller 12 måneder. Her er Nasjonal Sikkerhetsmyndighets
- Følg med på alarmene. Sikre at noe eller noen tar til seg alarmene. Reager på alarmer. De kan avgjøre om dette blir støy eller katastrofe.
- Sikre at teknologien på servere, på klienter, i skyen, hos leverandøren og brannmuren er satt opp i tråd med anbefalinger fra produsent eller uavhengige, som f.eks Center for Internet Security. Da skal man få full logging, inkludert alarmer. Prøv å samle disse loggene og alarmene et sted. Gjennomfør analyse og integrasjoner på denne informasjonen og sikre at avvik rapporteres til mennesker og systemer som kan ta dette videre til undersøkelse og håndtering.
Ta truslene, sårbarhetene og risikoene på alvor. Ta loggingen og alarmene på alvor. De aller fleste må ha hjelp til dette. Spør om bistand og hjelp.
Vi i Data Equipment har etablert sikkerhetsplattformen Intellisec og tjenesten Managed Detection & Response, for å kunne bistå deg på nevnte punkter i denne artikkelen. Vi kan hjelpe deg med loggene, evalueringen av dem og håndteringen ved behov for videre tiltak. Dette er viktig for det store sikkerhetsbildet, og kan avgjøre utfallet av en hendelse.
Les også Suksessfulle hendelser skjer i tillatt trafikk. Sikre kvaliteten på din RFP.
