Enhet 11 / 11

End-to-end SOC arbeidsflyt, automatisering (SOAR), kvalitetsstyring og egenrevisjon

Gevinster:

  • Evne til å designe en ende-til-ende SOC-arbeidsflyt bestående av innsamling, deteksjon, triage, etterforskning, intervensjon, forbedring, rapportering og tilbakemelding, spesifisere plasseringen av kunstig intelligens og menneskelige porter
  • Evne til å skille automatisering etter risikonivå (lavrisiko/reversible trinn er automatiske, høyrisiko/irreversible trinn er menneskekontrollerte) og designe en tilbakerullingsvei for hver automatiske handling.
  • Evne til å etablere en selvovervåking og tilbakemeldingssløyfe som regelmessig måler falsk positiv/negativ rate, MTTD/MTTR, utgangsnøyaktighet og modelldrift

Denne siste enheten kombinerer bitene vi lærte separat gjennom modulen – logganalyse, trusseljakt, sårbarhetshåndtering, hendelsesrespons, phishing, kodegjennomgang, etterretning, rapportering – i en enkelt ende-til-ende arbeidsflyt. I et ekte sikkerhetsoperasjonssenter (SOC) kobles ikke disse trinnene fra; En alarm utløser en undersøkelse, som utløser et svar, som utløser en melding, som utløser en utbedring. Kunstig intelligens er involvert i hvert ledd i denne kjeden, men det er mennesket som holder kjeden og tar avgjørelser ved enhver kritisk dør.

I tillegg dekker denne enheten to kritiske emner. Den første er automatisering: Når SOAR (Security Orchestration, Automation and Response — plattformen som automatiserer og organiserer sikkerhetsprosesser) og AI kombineres, øker både kraft og risiko; Det er nødvendig å skille mellom det som kan automatiseres og det som aldri kan fjernes fra menneskelig godkjenning. For det andre, kvalitetsstyring og selvregulering: En AI-aktivert sikkerhetsoperasjon er ikke satt opp og forlatt en gang; det overvåkes, måles, tilbakekobles og korrigeres hele tiden. Automatisering øker hastigheten, men eliminerer ikke ansvar; Et sikkerhetsprogram forblir trygt bare gjennom regelmessig egenkontroll.

End-to-end SOC arbeidsflyt

La oss se hvor AI spiller inn og hvem som godkjenner det i en typisk hendelseslivssyklus:

  1. Innsamling og overvåking: Logger flyter til SIEM; AI reduserer støy, oppsummerer. (Automatisk, lav risiko.)
  2. Deteksjon og alarm: Regel + anomali + AI-mønsterdeteksjon. (Automatisk produksjon; triage er hos mennesker.)
  3. Triage: Er alarmen ekte eller falsk positiv? AI foreslår begrunnelse og prioritering; analytiker bekrefter. (Menneskedør.)
  4. Undersøkelse: AI samler bevis, etablerer tidslinje, lister opp grunnårsaken; analytikeren bekrefter med rå bevis. (Menneskedør.)
  5. Intervensjon: Isolering, låsing, rengjøring. AI gir valg/påvirkning; Avgjørelsen er i hendene på den autoriserte analytikeren. (Kritisk menneskelig port.)
  6. Utbedring: Sårbarhetslukking, eliminering av rotårsak. AI plan utkast; godkjenning i endringsledelse. (Menneske + prosess.)
  7. Rapportering: AI skriver utkast, tilpasser seg publikum; Eksperten verifiserer og signerer bevisene. (Menneskedør.)
  8. Leksjonslæring og tilbakemelding: AI trekker ut mønstre; Oppdaterer lagdeteksjonsregler og spillebøker. (Menneske + prosess.)

Regelen for denne kjeden: lavrisiko, repeterende, reversible trinn kan automatiseres; Høyrisiko, irreversible, dømmekraftkrevende trinn går gjennom menneskedøren.

Automatiseringsbeslutningstabell

trinn

Kan det automatiseres

tilstand

menneskelig godkjenning

Logginnsamling, normalisering

Ja, akkurat

ikke nødvendig

Alarmberikelse (IOC-søk)

Ja

Kilden er pålitelig

Den er anmeldt

Falsk positiv eliminering (kjent god)

delvis

streng regel

Inspisert ved prøvetaking

phishing-e-post i karantene

delvis

høy presisjon

Gjennomgang + tilbakerullingsbane

Lås en konto automatisk

forsiktig

Kun klare kriterier

Rask menneskelig verifisering

Isoler serveren

Generelt nei

Bortsett fra kritisk infrastruktur

Tvunget menneskelig beslutning

Patching (produksjon)

nei

Testing + endringsledelse

Offisiell rapport/melding

nei

Ekspert + jus

Kvalitetsstyring og egenrevisjon

En AI-drevet sikkerhetsoperasjon er et levende system; ytelsen endres over tid (nye angrep, skiftende miljø, modelloppdateringer). Regelmessig måling er nødvendig for å holde det trygt:

  • Falsk positiv og falsk negativ rate: Hvor ofte alarmerer AI forgjeves, hvor ofte går den glipp av den virkelige trusselen? Falske negativer blir spesielt sett fordi de i det stille forårsaker skade.
  • MTTD/MTTR: ​​Blir gjennomsnittlig deteksjon og responstid bedre?
  • AI-utdatanøyaktighet: Ved prøvetaking, hvor mye av AIs oppsummeringer/funn/siteringer består validering?
  • Automatiseringssikkerhet: Fungerer automatiske handlinger som forventet, er det noen falske triggere, fungerer tilbakeføringene?
  • Tilbakemeldingssløyfe: Blir faktiske hendelser funnet nye deteksjonsregler, og utløste alarmer blir unntakslister?

Vilkår: MTTD (Mean Time To Detect). Tilbakemeldingssløyfen er når operasjonen lærer av sine egne resultater og oppdaterer reglene. Modelldrift er når AI blir foreldet og ytelsen reduseres etter hvert som miljøet endres. Egenrevisjon er den regelmessige, kritiske gjennomgangen av teamets egne prosesser.

tre minisaker

Tilfelle 1 – Riktig automatisering. En SOC automatiserer trinnet med å "automatisk berike og prioritere varsler som samsvarer med kjente ondsinnede IOC-er og er i en lavrisikokategori"; men forlater alltid trinnet "isolere en server" for menneskelig godkjenning. Resultatet: analytikere frigjøres fra 400 rutinealarmer om dagen, noe som frigjør tid til reelle undersøkelser, og overlater kritiske beslutninger til mennesket. Høyre del av kjeden er automatisk, rett sted er menneskelig.

Tilfelle 2 — Automatisering slår tilbake. En annen SOC definerer regelen "autolås konto ved mistenkelig pålogging" veldig bredt. En dag, på grunn av en konfigurasjonsfeil, låser regelen ute 1200 legitime brukere samtidig og arbeidet stopper; Videre er gjenopprettingsbanen ikke definert. Leksjon: Effektiv automatisering må ha strenge kriterier, gradvis distribusjon og en tilbakeføringsvei. Automatisering bør være reversibel og overvåkes gjennom selvregulering.

Tilfelle 3 — Glidningen fanget av selvkontroll. I en tre måneders selvrevisjon legger et team merke til at AIs phishing-deteksjonsnøyaktighet synker: en ny phishing-bølge blir savnet fordi den ikke passer til gamle mønstre (mønsterdrift). Teamet samler inn prøver, oppdaterer deteksjonsreglene og oppdaterer konteksten gitt til AI. Uten regelmessig selvkontroll kunne denne tause unndragelsen ha fortsatt i flere måneder. Leksjon: bare fordi ytelsen er god en gang, forblir den ikke alltid bra; måling og tilbakemelding er viktig.

Svak forespørsel / Sterk forespørsel

Svak melding:

Fullautomatiser vår SOC og la AI håndtere alt.

Denne forespørselen krever automatisering uten diskriminering av risiko, ignorerer menneskelige dører og tar ikke hensyn til tilbakerulling og kontroll. Hvis de implementeres, vil høyrisikobeslutninger bli automatiserte uten tilsyn og bli til katastrofe ved første feil.

Kraftig ledetekst:

Din rolle: Konsulent i SOC prosessdesign. [Liste] disse hendelseslivssyklustrinnene i tre basert på risikonivå: (A) helautomatisert (lav risiko, reversibel, repeterende), (B) AI anbefaler + menneskelig godkjenner, (C) alltid menneskelig beslutning (høy risiko, irreversibel). Foreslå en obligatorisk tilbakerullingsbane og en sporingsberegning for hver (A) og (B). Lag også et utkast til en kvartalsvis selvrevisjonssjekkliste: falsk positiv/negativ rate, MTTD/MTTR, AI-utgangsnøyaktighetsprøve, tegn på mønsterdrift.

Sterk etterspørsel skiller automatisering etter risikonivå, krever tilbakerulling og overvåking, og etablerer et selvreguleringsrammeverk.

Kopierbare spørsmålsmaler

AUTOMATISERING RISIKOSEPLARASJON Del disse sikkerhetsarbeidsflyttrinnene i tre: (A) helautomatisk passende, (B) Anbefaler menneskelig godkjennelse, (C) alltid menneskelig beslutning. Skriv begrunnelse, reversibilitet og forretningseffekt for hvert trinn. Anbefaler obligatorisk tilbakerullingsbane for trinn med høy påvirkning. Trinn: [liste]

ROLLBACK DESIGN MAL for automatisk handling [f.eks. kontosperring] foreslår en sikker utforming: utløserkriterier (smal), gradvis distribusjon, trinn for falsk utløserrulling, advarsel og menneskelig verifiseringspunkt. Design for å unngå blindautomatisering. Handling: [skriv]

SELVREVISJONSJEKKLISTE MAL Lag en kvartalsvis selvrevisjonssjekkliste for en AI-drevet SOC: falsk positiv/negativ frekvens, MTTD/MTTR-bias, AI-utgangsnøyaktighetssampling, automasjonsfalske utløsere, tegn på mønsterdrift, tilbakemeldingssløyfedrift, samsvar med personvern/anonymisering. For hvert element, skriv hvordan det skal måles.

TILBAKESLØYKEMAL Tegn det som er lært fra den faktiske hendelsen/alarmen som mislykkes: (1) mønsteret som vil bli en ny deteksjonsregel, (2) den falske positive som vil bli lagt til unntakslisten, (3) playbook-trinnet som vil bli oppdatert, (4) den nye konteksten som vil bli gitt til AI. Oppsummering av hendelse/alarm: [lim inn]

Vanlige feil

  • Automatisering av høyrisiko-trinnet. Irreversible trinn som serverisolering, produksjonsoppdatering, offisiell varsling fjernes ikke fra den menneskelige døren.
  • Ikke utforme en vei til gjenfinning. Det er mulig for enhver automatisk handling å utløse feil; Automatisering uten et angrepunkt og bekreftelse er farlig.
  • Sett og glem. AI-ytelsen skifter etter hvert som miljøet endres; Uten regelmessig egenkontroll og måling akkumuleres tause unnvikelser.
  • Bare sporer den falske positive. En falsk negativ (den virkelige trusselen som er savnet) er farligere, men vanskeligere å se; Se den privat.
  • Forsømmer tilbakemeldinger. Hvis de oppdagede hendelsene ikke blir til en ny regel og de mislykkede alarmene ikke blir til et unntak, lærer ikke operasjonen og gjentar den samme feilen.
Hint: Det gyldne spørsmålet i automatiseringsbeslutningen: "Kan denne handlingen angres hvis den utløses feil, og hva er forretningseffekten?" Hvis svaret er "lett angret, lav effekt," automatiser; Hvis "irreversibel eller høy påvirkning" holdes ved menneskelig dør.
Forsiktig: Automatisering fjerner ikke ansvar, det øker bare hastigheten. En dårlig gjennomtenkt automatisk handling forårsaker skade mye raskere og mer omfattende enn et menneske kunne. Hver automatisering er omgitt av snevre kriterier, tilbakerullingsvei og regelmessig inspeksjon; Det endelige ansvaret ligger alltid hos mennesket.

Oppsummert

Denne enheten kombinerte alle delene av modulen til en ende-til-ende SOC-arbeidsflyt: innsamling, deteksjon, triage, etterforskning, respons, utbedring, rapportering og tilbakemelding. AI er involvert i hvert ledd, men det er mennesket som holder kjeden og tar beslutninger ved hver kritisk dør. Automatisering (SOAR + AI) øker kraften; Regelen er klar: lavrisiko, reversible, repeterende trinn blir automatiserte, høyrisiko, irreversible trinn passerer gjennom menneskedøren, og hver automatisering har en måte å angre på. Endelig er et AI-drevet sikkerhetsprogram live: falske positive/negative, MTTD/MTTR, utgangsnøyaktighet og mønsterdrift måles regelmessig; Det som blir funnet blir til regler og spillebøker i en tilbakemeldingssløyfe. Automatisering akselererer ansvar, ikke fjerner det; Selvkontroll holder sikkerheten i live.

Søknadsoppgave

Skriv ut din egen organisasjons (eller et eksempel på SOCs) hendelseslivssyklus. Klassifiser hvert trinn som A/B/C med "Automation Risk Separation"-malen og utled en sikker automatiseringsdesign med "Rollback Design"-malen for minst ett "high impact"-trinn. Lag deretter en kvartalsvis sjekkliste med malen "Selvrevisjonssjekkliste" og finn ut hvordan du vil måle hver beregning i miljøet ditt.

sjekkliste

  • [ ] Jeg delte hvert trinn i hendelsens livssyklus inn i A/B/C risikoklasse.
  • [ ] Jeg holdt høyrisiko, irreversible skritt ved menneskedøren.
  • [ ] Jeg utformet smale kriterier og angre bane for hver automatiske handling.
  • [ ] Jeg har planlagt å overvåke frekvensen av falske positive og spesielt falske negative.
  • [ ] Jeg planla å måle MTTD/MTTR og AI utgangsnøyaktighet regelmessig.
  • [ ] Jeg etablerte en kvartalsvis egenkontrollsjekkliste for mønsterdrift.
  • [ ] Jeg koblet de funnet hendelsene og sendte alarmer til tilbakemeldingssløyfen.

Moduleksamen

1. En SIEM-triage AI flagget en alarm som 'lav prioritet, sannsynligvis falsk positiv' og presset den til bunnen av listen. Hva bør analytikeren gjøre med denne alarmen?

  • A) Fortsatt uavhengig sjekker alarmen og verifiserer den med råbevis; Analytikeren tar beslutningen om nedleggelse og registrerer den ✔
  • B) Kunstig intelligens slår automatisk av alarmen uten å undersøke den fordi den sier at den har lav prioritet.
  • C) Overfører alarmen til neste skift som den er.
  • D) Bare se på sammendraget gitt av kunstig intelligens og send rapporten

Forklaring: AI-prioritering er en anbefaling, ikke en diagnose; Flagget 'lav prioritet' kan dekke et reelt angrep (falsk negativ). Analytikeren må fortsatt kontrollere varselet uavhengig, verifisere det med råbevis og ta beslutningen om å lukke det selv. En negativ AI-utgang er ingen garanti for "ingen trussel".

2. Hvilken kombinasjon av risikoer merker AI et reelt angrep som "normalt", og analytikeren stoler på dette og slapper av i sin egen analyse?

  • A) Kun falsk positiv og alarmtretthet
  • B) Falsk negativ og automatiseringsskjevhet (overavhengighet av AI) ✔
  • C) Kun mangel på loggkilde
  • D) Bare SIEM-regelfeil

Forklaring: Det er en falsk negativ hvis modellen savner den reelle trusselen; Automatiseringsbias er når analytikeren stoler for mye på kunstig intelligens og forlater uavhengig vurdering. Når de to kombineres, forsvinner eksistensen av menneskelig kontroll og angrepet kan omgås helt. Derfor undersøkes også områder som kunstig intelligens kaller 'rene'.

3. AI’en sa «CVE-2024-88888, CVSS 9.8, oppdatering umiddelbart» under en triage. Hva bør analytikeren gjøre først?

  • A) Vurderer CVE som pålitelig og setter i gang oppdateringsplanen umiddelbart
  • B) Bare fordi CVSS er 9.8, setter det det først uten å se på noen andre sårbarheter
  • C) Verifiserer CVE-nummeret og poengsummen i NVD/leverandørposten; ✔ Hvis det ikke er noen post, vil den ikke bli oppført vel vitende om at den kan være falsk.
  • D) Uten å verifisere CVE, skriver administratoren den i rapporten som "kritisk trussel"

Beskrivelse: Språkmodeller kan flytende passe til et ikke-eksisterende CVE-nummer og poengsum (hallusinerer). Analytikeren må verifisere CVE i NVD/leverandørloggen og bekrefte dens autentisitet og poengsum før han forplikter seg til oppdateringsplanen. En ubekreftet CVE kobles først til ressursen; Ellers vil teamet kaste bort tid på å jakte på en oppdatering som ikke eksisterer.

4. For å fremskynde en hendelsesundersøkelse limer en ekspert inn den rå brannmurloggen sammen med faktiske interne IP-er, brukernavn og VPN-servernavn i et offentlig tilgjengelig AI-verktøy. Hva er hovedproblemet her?

  • A) AI kan ikke lese loggformatet, så analyse er ubrukelig
  • B) Hvis stokken er for lang, bremser det modellen.
  • C) Brannmurlogger er uansett ikke egnet for analyse
  • D) Ekte IP-, bruker- og servernavn deles uten anonymisering; Dette er både brudd på KVKK og lekkasje av organisasjonens nettverkskart ✔

Beskrivelse: Sikkerhetsdata er både personlige data (bruker, IP) og bedriftsintelligens som avslører angrepsoverflaten til organisasjonen (nettverkstopologi, servernavn). Å gi dette til et eksternt verktøy uten å anonymisere det er både et brudd på KVKK og avslører et nettverkskart som vil være nyttig for angriperen. For det første er de faktiske verdiene maskert med konsistente plassholdere.

5. Hva gjør at en trusseljakt anses som godt designet?

  • A) Det starter med en konkret, testbar hypotese og sporet som ble funnet bekreftes av råbevis ✔
  • B) Det starter med å fortelle den kunstige intelligensen "finn om det er en angriper i nettverket mitt"
  • C) Erklærer automatisk hver unormal/sjelden hendelse funnet som et angrep
  • D) Det fungerer kun når det kommer en alarm, det er ikke proaktivt

Forklaring: En god trusseljakt starter ikke med en alarm, men med en konkret og testbar hypotese som kanskje eller kanskje ikke viser seg å være sann (f.eks. «Knyttet konto X til mer enn 50 interne IP-er i ikke-arbeidstiden»). Et vagt spørsmål som "Er det noe dårlig på nettverket mitt" kan ikke testes og lar AI gjette. Sporet som ble funnet anses ikke som en trussel før det er verifisert med råbevis.

6. En sårbarhet har en CVSS-score på 9,1 på en isolert testserver på det interne nettverket; I samme liste, CVSS 7.5 på en server åpen for internett, men det er en annen sårbarhet i KEV-listen (som faktisk utnyttes). Hva er riktig prioritering?

  • A) Den med høyest CVSS (9.1) lappes alltid først
  • B) Sårbarheten til 7.5 på Internett og KEV-listen tas videre; CVSS er ikke det eneste kriteriet, eksponering og faktisk misbruk er avgjørende ✔
  • C) Begge er lappet på samme tid og med samme prioritet, skille er unødvendig
  • D) Ingen av dem er lappet fordi det er en sårbarhet i testserveren

Forklaring: CVSS setter ikke prioriteringer alene; faktisk risiko bestemmes av EPSS (sannsynlighet for utnyttelse), KEV (faktisk utnyttelse) og organisatorisk kontekst (eksponering, kritikalitet, kompenserende kontroll). Internett-eksponert og faktisk utnyttet (KEV)-sårbarhet forhindrer isolert og lavsannsynlig høy-CVSS-sårbarhet.

7. I en hendelsesrespons sier kunstig intelligens 'Trafikk som stammer fra IC_HOST_7 er mistenkelig, isoler denne serveren'. IC_HOST_7 er institusjonens hovedautentiseringsserver. Hva bør analytikeren gjøre?

  • A) Kunstig intelligens isolerer umiddelbart serveren fordi den sier det
  • B) Overlater isolasjonsavgjørelsen helt til kunstig intelligens
  • C) Evaluer først virksomhetens innvirkning og årsak til trafikk; Den isolerer ikke kritisk infrastruktur uten å måle effekten og tar beslutningen som analytiker ✔
  • D) Isolerer serveren og sletter deretter alle logger

Beskrivelse: Isolasjon er en kritisk beslutning som er vanskelig å reversere og kan føre til forretningsavbrudd; kan ikke overføres til kunstig intelligens. Isolering av autentiseringsserveren kan stoppe alle ansatte fra å logge på. Analytikeren må først vurdere forretningseffekten og årsaken til trafikken (kan være en legitim transaksjon), ta avgjørelsen selv; Forslaget om kunstig intelligens bør ikke implementeres som en ordre.

8. I en løsepengevarehendelse ønsker teamet å gjenoppbygge en berørt maskin for raskt å rense den; men det er rettsmedisinske bevis (minnedump, angriperverktøy) på maskinen som ennå ikke er samlet inn. Hva er riktig tilnærming?

  • A) Maskinen installeres umiddelbart på nytt; bevis er irrelevant
  • B) Kunstig intelligens blir bedt om 'raskeste rengjøring' og instruksjonen brukes blindt.
  • C) Maskinen slås av og kastes fordi bevisene allerede ligger i loggen.
  • D) Først blir det rettsmedisinske bildet og minnedumpen tatt og bevisene bevart, deretter utføres rengjøring/gjenoppretting ✔

Forklaring: Utvinningshastigheten kan ikke trumfe bevisbevaring. Å installere maskinen på nytt uten å samle bevis ødelegger varetektskjeden og ødelegger rettsprosessen. Først tas et rettsmedisinsk bilde og minnedump, deretter utføres rengjøring/gjenoppretting. Rettsmedisinske skritt er ikke delegert til AI.

9. Hva er et av de mest pålitelige lagene med teknisk verifisering når man analyserer en mistenkt phishing-e-post, og hvordan bør den bekreftes?

  • A) SPF/DKIM/DMARC resulterer i e-posthoder; Bekreftet fra den rå tittelen, ikke fra AIs sammendrag ✔
  • B) Farge og font på e-posten; bestemt av visuell design
  • C) Klikk på den mistenkelige lenken på live-systemet og se på siden som åpnes.
  • D) Kunstig intelligens som sier "phishing" alene er tilstrekkelig bevis

Forklaring: SPF/DKIM/DMARC-resultater i e-posthoder er sterke indikatorer på om e-posten faktisk kommer fra domenet den hevder å være; Hvis alle tre mislykkes og avsenderen forfalsker domenet, blir mistanken sterkere. Dette bør imidlertid bekreftes fra den rå tittelen og ikke fra sammendraget av AI. I tillegg blir mistenkelige lenker aldri klikket på live-systemet.

10. I en kodegjennomgang foreslo AI en løsning for en XSS-sårbarhet og sa "det lukker sårbarheten". Hva bør analytikeren/utvikleren gjøre?

  • A) Betrakter reparasjonen som pålitelig og setter den direkte i produksjon
  • B) Gjennomgår rettelsen, bekrefter at den faktisk lukker sårbarheten og ikke introduserer nye sårbarheter/bugs, og skriver en test; Først da kommer den på lager ✔
  • C) Siden han ikke er sikker, skriver han om hele filen til den kunstige intelligensen og bruker den.
  • D) Bruker rettelsen, men består uten å skrive noen tester

Forklaring: Reparasjonen foreslått av AI er ikke automatisk sikker; Det kan hende den ikke lukker sårbarheten helt, den kan rense feil lag, eller den kan introdusere en ny sårbarhet/funksjonsfeil. Hver patch blir gjennomgått, evaluert om den faktisk lukker sårbarheten og om den introduserer nye problemer, og positive og negative testtilfeller skrives; Først da kommer den inn på lageret.

11. Da den kunstige intelligensen analyserte et angrep, sa "dette er definitivt arbeidet til APT-Dark Eagle-gruppen". Hva er den riktige tilnærmingen når det gjelder trusseletterretning?

  • A) Godta referansen slik den er, og skriv den i rapporten som den 'klare gjerningsmannen'
  • B) Han bygger hele forsvaret sitt basert på den gruppen uten noen gang å stille spørsmål ved gruppenavnet.
  • C) Bruker "konsistent med teknikker"-språk i stedet for presis attribusjon, verifiserer gruppen i kjente kilder og tar hensyn til muligheten for fabrikasjon ✔
  • D) Sitering er alltid unødvendig, det tas ikke hensyn til i det hele tatt

Forklaring: Gruppeattribusjon er det vanskeligste og mest unøyaktige området for intelligens; AI kan til og med lage et bandnavn som ikke eksisterer. I stedet for en nøyaktig referanse, brukes språket "kompatibelt med disse teknikkene", og gruppenavnet bekreftes i kjente etterretningskilder. I tillegg er forsvaret ikke basert på kortvarige IOC-er, men på permanent TTP-deteksjon.

12. I et utkast til hendelsesrapport skrev AI setningen "angriperen var mest sannsynlig inne i tre uker og eksfiltrerte kundedata"; mens det ikke er noen avgjørende loggbevis som støtter disse påstandene. Hva bør analytikeren gjøre?

  • A) La setningen være som den er fordi den er dramatisk og imponerende
  • B) Forlater setningen, men legger til 'kunstig intelligens skrev' på slutten
  • C) Skriver ut hele rapporten på nytt til den kunstige intelligensen og signerer den uten å verifisere den.
  • D) retter påstander basert på bevis; Gjør forskjellen mellom "mulig/bevist/under etterforskning" og trekker ut den definitive uttalelsen uten bevis ✔

Kommentar: I en formell sikkerhetsrapport skal hvert krav være underbygget og "sannsynlig" skal aldri forveksles med "bevist". Et krav uten bevis har juridiske, økonomiske og omdømmemessige konsekvenser. Analytikeren bør korrigere setningen i henhold til bevisene (for eksempel skrive datoen for første tilgang oppdaget og si "ingen avgjørende bevis funnet, etterforskning pågår" for datalekkasjen).

13. En leder ønsker å profilere all aktiviteten til en ansatt fra sikkerhetslogger med kunstig intelligens for å forstå om han er 'lojal' eller ikke. Hva bør en sikkerhetsekspert gjøre?

  • A) avviser forespørselen og henviser den til riktig kanal (HR/juridisk/definert etterforskning); sikkerhetsdata er ikke et middel for personlig overvåking ✔
  • B) Oppretter og leverer profilen fordi lederen ber om det
  • C) Den trekker bare ut noen logger og gir en delvis profil
  • D) Få profilen opprettet av kunstig intelligens fordi ansvaret går over til kunstig intelligens

Beskrivelse: Sikkerhetsdata samles inn for sikkerhetsformål; Å spore/profilere en person er misbruk, går over i personovervåking og bryter med KVKK. Eksperten bør avvise denne forespørselen og henvise den til riktig kanal (HR, juridisk, et definert og legitimt etterforskningsrammeverk). Goodwill eller lederens ønske rettferdiggjør ikke denne grensen.

14. En SOC bestemmer hvilke trinn i sikkerhetsarbeidsflyten som skal automatiseres. Hva er det beste prinsippet for automatisering?

  • A) De høyeste risikobeslutningene bør automatiseres først, slik at det ikke er menneskelig involvering
  • B) Lavrisiko/reversible trinn er automatisert; høy risiko/irreversible trinn forblir ved menneskedøren og hver automatisering har en måte å angre på ✔
  • C) Alle SOC skal være helautomatiserte og egenrevisjon er unødvendig
  • D) Automatiserte handlinger trenger ikke å angres fordi AI ikke gjør feil

Forklaring: Lavrisiko, repeterende og reversible trinn (logginnsamling, alarmberikelse) kan automatiseres; Høyrisiko, irreversible og dømmekraftkrevende trinn (serverisolering, produksjonsoppdatering, offisiell varsling) går gjennom den menneskelige døren. I tillegg må hver automatisk handling ha snevre kriterier og en måte å angre på. Automatisering fjerner ikke ansvar, det øker bare hastigheten.