Anbefalinger til krav i en SOC forespørsel

Tematikk:

Suksessfulle hendelser skjer i tillatt trafikk. Man “MÅ” ha en SOC

Det er flere kunder som har etterspurt bistand i forbindelse med kjøp av SOC tjenester, både private og offentlige. Å være produktuavhengig viser seg å være en strategisk fordel. Å ha en SOC tjeneste er meget fornuftig, da suksessfulle hendelser skjer i tillatt trafikk, og da må man følge med på loggene. Men å kjøpe en SOC tjeneste er ikke enkelt. Det er mange tilbydere, med forskjellige kvalifikasjoner og kapasiteter. Det er også mange begreper å forholde seg til. SOC. MDR. IR. Og mange fler. Dette er viktig å ha med seg når man ser etter disse tjenestene for på den måten å sikre seg en så riktig og god tjeneste som mulig.

Noen vil nok starte med en SOC (Security Operations Center) som en startpunkt. Det har med viktigheten av å komme i gang, og det økonomiske. Samtidig bør man ha med MDR (Managed Detection and Response) i forespørselen som en opsjon, da det kan være en fornuftig oppgradering i fase 2, og da kan det være smart å ha med dette før utvelgelsen av leverandør. IR (Incident Response) er en viktig parameter for hendelseshåndtering og gjenoppretting. Dette burde først og fremst være med som en opsjon, og kanskje som et minimum være med som et krav med laveste krav til respons, så har man noe. Mange vil nok være klare for en solid IR fra dag 1. Disse tingene er med i kravspesifikasjonen.

Kravene er skrevet på bakgrunn av innspill fra folk i bransjen, basert på sunn fornuft knyttet opp mot forretning, anbefalinger fra Nasjonal Sikkerhetsmyndighet, KS (Kommunesektorens Organisasjon) og NIST Cybersecurity Framework.

Sikkerhetspartner

Har vinklet ordlyden til å synliggjøre leverandøren som sikkerhetspartner for å forhåpentligvis trigge et partnerskap mer enn bare et leverandør/kunde forhold. Alle kunder trenger hjelp. Ingen kan alt, derfor er partnerskap viktig for å gjøre sikkerheten bedre. Mye av målet med kravene er å bedre identifisere selve leverandørens fokus og holdning.

Kravspesifikasjon

Dette er en forespørsel på logginnsamling, overvåking, analyse, MDR og hendelseshåndtering. Målet er å ha en aktiv sikkerhetspartner som bistår i sikkerhetsarbeidet med anbefalinger, veiledninger, kompetanse, kompetanseheving av kunde og bidragsyter ved en eventuell hendelse.

Vi som kunde etterlever Zero Trust etter beste evne, og antar uvedkommende inne i systemene og dermed skade. Det er derfor viktig med fokus på rask deteksjon og rask gjenoppretting.

MTTD og MTTR

Mean Time To Detect er kritisk i dagens trusselbilde. Statistikk viser at dette ofte ligger på rundt 200 dager fra en hendelse oppstår til den blir oppdaget. Med dagens teknologi, ML og AI, burde dette reduseres til minutter og timer.

✅ Sikkerhetspartneren bes forklare hva som kreves av kunde for å bidra til å detektere en hendelse så raskt som mulig.

✅ Sikkerhetspartneren bes forklare hva de gjør fra et MTTD perspektiv, og vise eksempler på reaksjonstid ved forskjellige hendelser

MTTR kan bety to ting. Mean Time To React og Mean Time To Recover

Mean Time To React.

✅ Sikkerhetspartneren bes forklare hva som kreves av kunde for å reagere så raskt som mulig

✅ Sikkerhetspartneren bes forklare hva som gjøres for å reagere så raskt som mulig fra en maskin og et menneskelig ståsted

✅ Sikkerhetspartneren bes forklare sine tjenestemodeller og priser for de forskjellige nivåene for reaksjonsevne

Mean Time To Recover.

✅ Sikkerhetspartneren bes forklare hva som kreves av kunde for å gjenopprette produksjon så raskt som mulig

✅ Sikkerhetspartneren bes forklare hva som skal til for å raskest mulig gjenopprette stabil, trygg og sikker drift etter KIT prinsippene ved en hendelse. Hva kreves av kunden mtp kompetanse, ressurser, prosedyrer, teknologi og mer?

✅ Sikkerhetspartneren bes vise til erfaringer med hendelseshåndtering av forskjellige slag, omfang, tid brukt, og mer

DAAS

Det er dette det egentlig handler om. Det er disse verdiene som primært må beskyttes.

  • Data
  • Applications
  • Assets
  • Systems

Krav til kunde

✅ Sikkerhetspartneren bes forklare på generelt grunnlag hva som kreves av kunde for på best måte beskytte DAAS mtp MTTD, MTTR og MTTR. Kom med tips relatert til eget datasenter, SaaS, IaaS og andre elementer man som kunde må tenke på relatert til hva sikkerhetspartneren har å tilby relatert til logging, oppdagelse, hendelselshåndtering og mer.

✅ Sikkerhetspartneren bes forklare hva kunde bør gjøre relatert til denne forespørselen for sikring av tjenester levert av tjenesteleverandører.

Krav til sikkerhetspartneren

✅ Sikkerhetspartneren bes forklare hvordan de på generelt grunnlag vil bidra med best mulig MTTD, MTTR og MTTR for datasenter, SaaS og IaaS.

✅ Sikkerhetspartneren bes forklare hva de kan gjøre for å bistå kunden med å kartlegge alle verdier som må beskyttes.

✅ Sikkerhetspartneren bes forklare hva de kan tilby for sikring av tjenester levert av tjenesteleverandører.

✅ Sikkerhetspartneren bes forklare hva de kan gjøre for optimalisering av kundens løsninger for enda bedre MTTD, MTTR og MTTR. Brannmurer. Servere. Skytjenester. SaaS tjenester. Nettverksutstyr. Endepunkter. Applikasjoner. E-post og e-post sikkerhet. Tjenesteleverandører. Og mer.

✅ Sikkerhetspartneren bes vise til relevante referansekunder for:

  • SOC
  • MDR
  • IR

✅ Sikkerhetspartneren bes forklare hva de tilbyr av tjenester (med priser) for:

  • SOC
  • MDR
  • IR
  • Responstid
  • Vakt
  • Andre avtaler

✅ Sikkerhetspartneren bes vise til regelmessig aktivitet som vil bidra til kompetanseheving for kunde. Webinarer. Seminarer. Kurs.

  • Har sikkerhetspartneren regelmessige nyhetsbrev?
  • Har sikkerhetspartneren regelmessige webinarer?
  • Har sikkerhetspartneren regelmessige seminarer?

✅ Sikkerhetspartneren bes vise til rutiner for varsling til kunde ved en hendelse. Klassifisering av hendelser. Og mer.

✅ Sikkerhetspartneren sin kundeportal bør ha API for mulighet til å integrere med kundens saksløsning. Bør kunne lese ut informasjon

✅ Sikkerhetspartneren bes forklare en typisk «Shared Responsibility Model» i forbindelse med SOC, MDR og IR.

✅ Sikkerhetspartneren bes forklare seg rundt ISO 27001 og ISO 9001, om dette innehas, eller hva som eksisterer for tilsvarende.

✅ Sikkerhetspartneren bes forklare hva de vil bidra med for å øke og bedre den proaktive sikkerheten hos kunden for å best mulig sikre seg mot suksessfulle angrep.

✅ Sikkerhetspartneren bes forklare sine topp 10 anbefalinger for å bli så sikker som mulig

✅ Sikkerhetspartneren bes forklare hva de gjør på «sårbarhetsscanning» i innsamlede data

✅ Sikkerhetspartneren bes forklare hva de anbefaler på backup for best forberedelse og best evne til å gjenopprette drift så raskt som mulig eller innbrudd, skadevare og ransomware.

  • API?
  • Hvor ofte bør backup kjøres?
  • Threat Hunting?

✅ Sikkerhetspartneren bes forklare hvordan de jobber med SOAR og playbooks, og hvor mye tid de bruker på dette.

✅ Sikkerhetspartneren bes forklare for ofte de mener man bør ha statusmøte, og hva som bør være på agendaen.

✅ Sikkerhetspartneren bes forklare hvordan de organiserer teamet for SOC, MDR og IR.

✅ Sikkerhetspartneren bes presentere typiske varelinjer med pris en kunde burde ha fra et SOC, MDR og IR ståsted, og hva som er opsjoner. Viktig å ikke få noen overraskelser. Mengde data. Mengde logger. Osv.

✅ Sikkerhetspartneren bes forklare hva de supporterer av teknologi hos kunde, og om det er noen begrensninger. Vis gjerne til sertifiseringer.

✅ Sikkerhetspartneren bes beskrive hvordan den best kan bli en sikkerhetspartner til kunde

✅ Sikkerhetspartneren bes forklare hvor lenge logger bør bevares

  • Tradisjonelt er det sagt rundt 180 dager, men med dagens moderne SOC løsninger er spørsmålet mer om 30 dager er tilstrekkelig

✅ Sikkerhetspartneren bes forklare hvor lenge det er anbefalt å ha XDR analyse bakover i tid. Holder det med 30 dager? Dette er uavhengig av generell logging som kan være 30, 180 eller enda flere dager.

Nasjonal Sikkerhetsmyndighet

https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/grunnleggende-nasjonale-funksjoner-gnf/

https://nsm.no/fagomrader/sikkerhetsstyring/leverandorforhold/kvalitetsordning-for-leverandorer-som-handterer-ikt-hendelser

NSMs Grunnprinsipper for IKT-sikkerhet og SOC

Har plukket ut elementer som har med SOC og gjøre. Skal fylle inn informasjon fortløpende:

Kapittel 3.2. Etabler sikkerhetsovervåkning

“3.2.1 Fastsett virksomhetens strategi og retningslinjer for sikkerhetsovervåkning.
Følgende bør beskrives:
a) Formål med og bruksområdet til innsamlet data.
b) Hvilke data som skal samles inn.
c) Sikker oppbevaring av data (også oppbevaring og behandling av data i forbindelse med rettslig prosesser).
d) Kapasitetsplanlegging for lagring av innsamlet data.
e) Tilgangsstyring til innsamlet data.
f) Sammenstilling av logger fra virksomhetens forskjellige enheter og tjenester.
g) Sletting av data. h) Revisjonsintervall for strategien (minst en gang i året og ved spesielle hendelser, f. eks. etter en større hendelse som dataangrep).”

“3.2.2 Følg lover, reguleringer og virksomhetens retningslinjer for sikkerhetsovervåkning.
a) Undersøk hvilke lover og regler virksomheten må forholde seg til.
b) Ta stilling til hvor lenge innsamlet data skal og kan lagres. c) Informer ansatte om hva som samles inn, hva det skal benyttes til og hvordan data skal behandles.”

“3.2.3 Avgjør hvilke deler av IKT-systemet som skal overvåkes.
Det kan være bl.a. følgende.
a) Deler av systemet som er mest kritisk eller som inneholder den mest konfidensielle informasjonen (både operativsystem, database og applikasjon).
b) Enheters operativsystemer.
c) Interne nøkkelpunkt hvor data flyter gjennom.
d) Nøkkelpunkt mellom interne og eksterne systemer, for eksempel ut mot Internett. e) Sikkerhetsprodukter (AVS, IDS, IPS, FW, mm.) i informasjonssystemene.
f) System for sikkerhetskopiering og gjenoppretting.”

“3.2.4 Beslutt hvilke data som er sikkerhetsrelevant og bør samles inn.
For delene nevnte i 3.2.3 bør man som minimum samle inn
a) data relatert til tilgangskontroll (vellykkede og mislykkede pålogginger) på enheter og tjenester og
b) administrasjons- og sikkerhetslogger fra enheter og tjenester i IKT-systemene. For klienter bør man i tillegg som minimum registrere
c) forsøk på kjøring av ukjent programvare (ref. 2.3.2) og
d) forsøk på å få forhøyede systemrettigheter («privilege escalation»).”

“3.2.5 Verifiser at innsamling fungerer etter hensikt.
a) Kontroller at logginnstillinger fungerer og at det som skal innhentes blir innhentet.
b) Sørg for at alle systemer som jevnlig lagrer sikkerhetsrelevant data har tilstrekkelig lagringsplass slik at nødvendig data ikke går tapt.
c) Benytt et standardisert format slik at data enkelt kan leses av tredjeparts logganalyseverktøy.”

“3.2.6 Påse at innsamlet data ikke kan manipuleres.
a) Arkiver og signer loggene digitalt med jevne mellomrom for å sikre loggintegritet.
b) Sørg for tilstrekkelig tilgangsstyring på logger og implementer funksjonalitet som oppdager forsøk på manipulering eller sletting av logger.
c) Påse at alle komponenter er synkronisert mot en og samme tidskilde.
d) Samle relevante data og konsolider dem til en database slik at de er tilgjengelige for analyse (se prinsipp 3.3 – Analyser data fra sikkerhetsovervåkning).”

“3.2.7 Gjennomgå og konfigurer innhenting av sikkerhetsrelevant data og den sentrale loggdatabasen jevnlig i tråd med strategien slik at det kun innhentes og tas vare på relevante data.
Fjern innsamlede data som ikke lenger har noen operasjonell eller sikkerhetsmessig relevans.”

Kapittel 3.3. Analyser data fra sikkerhetsovervåkning

“3.3.1 Lage en plan for analyse av data fra sikkerhetsovervåkning, herunder:
Avgjøre om virksomheten selv skal bygge opp analysekompetanse, eller om dette skal kjøpes.
a) Prioritet, frekvens og ressursbruk på analysearbeidet.
b) Verktøy, tjenester og mekanismer for søk, prosessering og analyser.
c) Forvaltning og videreutvikling av fagområdet, inkludert:
i) signaturbaserte verktøy,
ii) normaltilstanden i informasjonssystemet,
iii) metodikk og automatisert prosessering av innhentet sikkerhetsrelevant data og
iv) re-konfigurering av innhenting av sikkerhetsrelevant data. e) analyseverktøy, teknologi og algoritmer «anvendt maskinlæring»
d) Rapportering
e) Hendelseshåndtering”

“3.3.2 Etabler og vedlikehold kompetanse om normaltilstanden i virksomhetens informasjonssystemer for å kunne oppdage endringer eller unormaliteter som kan indikere uautoriserte handlinger.
Normaltilstanden må forvaltes over tid og gjenspeiles av omstillinger og omorganiseringer, oppkjøp, sammenslåing, nedbemanning og endring av driftskonsept. Kunnskapen om informasjonssystemene bør være så god at det er mulig å identifisere avvik som representerer trusler. Dette kan være:
a) Dataflyt som er i strid med vedtatt dataflyt i henhold til prinsipp 2.5 – Kontroller dataflyt.
b) Data som flyter på unormale tidspunkter og som ikke anses som normal trafikk.
c) Unormalt store datamengder som flyter i nettverket.”

“3.3.3 Ta i bruk verktøy som muliggjør manuelle og automatiske søk, samt alarmering basert på kriterier, i all innsamlet sikkerhetsrelevant data.
Verktøyet bør automatisk kunne sammenstille data fra forskjellige kilder for å lettere kunne avgjøre om hendelsen er reel (ikke falsk positiv) samt omfang og karakter. Benytt kunnskap om normaltilstanden (se 3.3.2) og trusler (se 3.3.4) til å forbedre søk og kriterier for alarmering i verktøyet – som vil bidra til å kunne oppdage tidligere ukjente trusler.”

“3.3.4 Innhent og bearbeid trusselinformasjon fra relevante kilder slik at denne kan benyttes ved vurdering av potensielle sikkerhetshendelser.
Dette kan være data fra tidligere angrep eller trusselinformasjon fra myndigheter, sektor-CERT-er, sammenliknbare virksomheter eller åpne kilder.”

3.3.5 Vurder fortløpende om innhentet data er tilstrekkelig relevant og detaljert.

3.3.6 Etabler rutine for eskalering av alarmer, hvem det skal rapporteres til, samt hvilke data som skal tilgjengeliggjøres og hvem det skal tilgjengeliggjøres for i forbindelse med hendelseshåndtering.

3.3.7 Benytt analyseverktøy, teknologi og algoritmer (også kalt anvendt maskinlæring) som bidrar til å oppdage og formidle ukjente trusler og unormaliteter i de sikkerhetsrelevante dataene.

Kapittel 4. Håndtere og gjenopprette

Kapittel 4.1 Forbered virksomheten på håndtering av hendelser

“4.1.1 Etabler et planverk for hendelseshåndtering som ivaretar behovet for virksomhetskontinuitet ved beredskap og krise.
Dette bør inkludere
a) en oversikt over krav til gjenopprettelse av IKTfunksjoner, IKT-tjenester og IKT-systemer basert på en analyse av konsekvenser for virksomheten («BIA – Business Impact Analysis»),
b) rolle- og ansvarsbeskrivelser for relevant personell,
c) krav til opplæring for relevant personell,
d) klassifiseringsregime for hendelser og grenseverdier for å aktivere krisestab,
e) krav til testing og øving av planverk og personell.
f) Revider og oppdater planverket jevnlig, minst en gang i året og i etterkant av øvelser og større hendelser eller angrep.”

“4.1.2 Gjennomfør en analyse av virksomhetskritiske effekter.
Denne bør inkludere:
a) prioritering av vitale forretningsfunksjoner og krav til sikkerhetsnivå for disse,
b) identifiserte avhengigheter til IKT-funksjoner, IKT-tjenester, IKT-systemer, mm.,
c) krav til gjenopprettelsestid, tap av data og tjenestenivå.”

“4.1.3 Utarbeid rolle- og ansvarsbeskrivelse for personell som skal involveres i hendelseshåndtering.
Dette inkluderer:
a) Personell med sentrale oppgaver, for eksempel IT-sjef, applikasjonsansvarlig, plattformansvarlig mm.
b) Ledere med beslutningsansvar på ulike nivåer.
c) Beredskapsvakter som er tilgjengelig utenom normal arbeidstid og i ferieperioder.
d) Sørg for tilstrekkelig opplæring og øving av personell i henhold til beskrivelse i planverk.”

“4.1.4 Utarbeid avtaler med relevante tredjeparter slik at disse er klare til å yte støtte dersom det kreves ved en hendelse.
Dette kan være sektorvise responsmiljøer, IT-spesialister innen ulike fagfelt, leverandører av utstyr og programvare mm.”

“4.1.5 Fastsett hvilke kommunikasjonskanaler som skal benyttes i forbindelse med hendelser.
a) Distribuer kontaktinformasjon for relevant personell.
b) Lag en plan for alternative kommunikasjonskanaler.
c) Etabler en plan for intern og ekstern kommunikasjon rundt hendelser.”

“4.1.6 Test og øv på planer jevnlig slik at disse er godt innøvd.
a) Øvelser bør inkludere relevante underleverandører.
b) Øvelser bør inkludere testing av rutiner for deteksjon og beredskap, se 3.4.5.”

Kapittel 4.3 Kontroller og håndter hendelser

“4.3.3 Loggfør alle aktiviteter, resultater og relevante avgjørelser for senere analyse.
a) Etabler en tidslinje for egne og trusselaktørens aktiviteter.
b) Oppdater hendelsesdata og situasjonsbilde underveis for best håndtering av hendelsen.
c) Sikre elektroniske bevis for skadevareanalyse og eventuelle rettslige prosesser, se også prinsipp 3.2 – Etabler sikkerhetsovervåkning”

KS sine anbefalinger

Her er link til KS sine anbefalinger:

Har plukket ut noen av anbefalingene som ikke allerede er nevnt over:

✅ Tjenesten skal kunne samle inn data fra mange logg kilder. Som et minimum skal følgende kilder, kunne logges:

  • Microsoft Windows servere
  • Endepunkter, servere og klienter
  • Brannmurlogger
  • Switsjer
  • Applikasjonslogger
  • Saas løsnnger
  • Skyløsninger

✅ Dataene skal kunne sendes til en skybasert datainnsjø. Dataene skal eies av oppdragsgiver.

✅ Loggdataene som samles inn, skal analyseres automatisk ved hjelp av kunstig intelligens. AI. Dette betyr bl.a

  • Høy integrasjon og korrelasjon av data som er samlet inn
  • Høy visibilitet
  • Høy automasjon

✅ Det skal være mulig for kundens operatører å sjekke denne analysedelen via ett management system. Dette skal kunne gjøres via en portal eller ett GUI.

✅ Analyserte data skal kunne bearbeides og sjekkes av ett hendelses respons team (IR-team) hos leverandør. 24/7/365

✅ Ved mistanke om noe sikkerhetsbrudd hos kunde skal varsling iverksettes så snart som mulig.

✅ Det skal vises forskjellig nivå på hendelser og trusler. F.eks Lav, middels, høy og kritisk.

✅ Kritiske hendelser skal handteres umiddelbart.

✅ Det skal være mulig for IR teamet hos leverandør og foreta handlinger som stopper videre spredning av sikkerhetsbrudd om det blir oppdaget. Dette gjøres etter nærmere avtale.

✅ Leverandør skal kunne dokumentere kompetanse på etterspurt tjeneste

✅ Det skal være ett supportapparat rundt tjenesten

✅ Det skal gis en rapportstatus ukentlig fra leverandør. Månedlige statusmøter skal utføres.

NIST Cybersecurity Framework

Det finner dere her.

 

Gøran Tømte

Gøran Tømte

Gøran har jobbet i bransjen siden 1996 og trives best med ukjente utfordringer. Er utdannet høgskole ingeniør innen telematikk, og kontinuerlig selvlært innen sikkerhet basert på gode kollegaer, bransjen og generell nysgjerrighet og interesse

KONTAKT

Andre artikler

Stay Connected

More Updates

Krav ved kjøp av NGFW

Det er mange gode brannmur produsenter og produkter, og flere er oppe til høyre i Gartners Magic Quadrant. Å velge brannmur er ikke enkelt. Men

Leverandørkontroller

Viktigheten av kontroller ved tjenesteutsetting/kjøp av tjenester “Alle” tjenesteutsetter/kjøper tjenester. Men hvordan verifiseres og risikovurderes dette? Som kunde har man alltid 100% ansvar for sikkerheten,

Anbefalinger til krav i en SOC forespørsel

Facebook
Twitter
LinkedIn

More to explorer

Krav ved kjøp av NGFW

Det er mange gode brannmur produsenter og produkter, og flere er oppe til høyre i Gartners Magic Quadrant. Å velge brannmur er