Enhed 11 / 11

End-to-End SOC Workflow, Automation (SOAR), Quality Management og Self-Audit

Gevinster:

  • Evne til at designe et end-to-end SOC-workflow bestående af indsamling, detektion, triage, undersøgelse, intervention, forbedring, rapportering og feedback, specificering af placeringen af kunstig intelligens og menneskelige porte
  • Evne til at adskille automatisering efter risikoniveau (lavrisiko/reversible trin er automatiske, højrisiko/irreversible trin er menneskekontrollerede) og designe en rollback-sti for hver automatisk handling.
  • Evne til at etablere en selvovervågnings- og feedbackloop, der regelmæssigt måler falsk positiv/negativ rate, MTTD/MTTR, outputnøjagtighed og modeldrift

Denne sidste enhed kombinerer de stykker, vi har lært separat gennem modulet – loganalyse, trusselsjagt, sårbarhedshåndtering, hændelsesrespons, phishing, kodegennemgang, efterretninger, rapportering – i en enkelt end-to-end workflow. I et ægte sikkerhedsoperationscenter (SOC) afbrydes disse trin ikke. En alarm udløser en undersøgelse, som udløser et svar, som udløser en anmeldelse, som udløser en afhjælpning. Kunstig intelligens er involveret i hvert led i denne kæde, men det er mennesket, der holder kæden og træffer beslutninger ved enhver kritisk dør.

Derudover dækker denne enhed to kritiske emner. Den første er automatisering: Når SOAR (Security Orchestration, Automation and Response — platformen, der automatiserer og organiserer sikkerhedsprocesser) og AI kombineres, øges både kraft og risiko; Det er nødvendigt at skelne mellem, hvad der kan automatiseres, og hvad der aldrig kan fjernes fra menneskelig godkendelse. For det andet kvalitetsstyring og selvregulering: En AI-aktiveret sikkerhedsoperation er ikke konfigureret og opgivet én gang; den bliver konstant overvåget, målt, tilbageført og korrigeret. Automatisering øger hastigheden, men fjerner ikke ansvar; Et sikkerhedsprogram forbliver kun sikkert gennem regelmæssig egenkontrol.

End-to-end SOC-arbejdsgang

Lad os se, hvor AI kommer i spil, og hvem der godkender det i en typisk hændelseslivscyklus:

  1. Indsamling og overvågning: Logs flow til SIEM; AI reducerer støj, opsummerer. (Automatisk, lav risiko.)
  2. Detektion og alarm: Regel + anomali + AI-mønsterdetektion. (Automatisk produktion; triage er hos mennesker.)
  3. Triage: Er alarmen reel eller falsk positiv? AI foreslår begrundelse og prioritet; bekræfter analytiker. (Menneskelig dør.)
  4. Undersøgelse: AI indsamler beviser, etablerer tidslinje, lister hovedårsagen; analytikeren bekræfter med rå beviser. (Menneskelig dør.)
  5. Indgreb: Isolering, aflåsning, rengøring. AI giver valg/indflydelse; Beslutningen er i hænderne på den autoriserede analytiker. (Kritisk menneskelig port.)
  6. Afhjælpning: Sårbarhedslukning, fjernelse af årsagen. AI plan udkast; godkendelse i forandringsledelse. (Menneske + proces.)
  7. Rapportering: AI skriver udkast, tilpasser sig publikum; Eksperten verificerer og underskriver beviserne. (Menneskelig dør.)
  8. Lektionsindlæring og feedback: AI udtrækker mønstre; Opdaterer teamdetektionsregler og spillebøger. (Menneske + proces.)

Reglen for denne kæde: lavrisiko, gentagne, reversible trin kan automatiseres; Højrisiko, irreversible, dømmekraftskrævende trin passerer gennem den menneskelige dør.

Automatiseringsbeslutningstabel

trin

Kan det automatiseres

tilstand

menneskelig godkendelse

Log indsamling, normalisering

Ja, præcis

ikke nødvendigt

Alarmberigelse (IOC-søgning)

Ja

Kilden er pålidelig

Den bliver gennemgået

Falsk positiv eliminering (kendt god)

delvist

streng regel

Inspiceret ved prøveudtagning

Sæt phishing-e-mail i karantæne

delvist

høj præcision

Gennemgang + tilbagerulningssti

Lås automatisk en konto

forsigtig

Kun klare kriterier

Hurtig menneskelig verifikation

Isoler serveren

Generelt nej

Bortset fra kritisk infrastruktur

Tvunget menneskelig beslutning

Patching (produktion)

nej

Test + forandringsledelse

Officiel rapport/meddelelse

nej

Ekspert + jura

Kvalitetsstyring og selvrevision

En AI-drevet sikkerhedsoperation er et levende system; dens ydeevne ændrer sig over tid (nye angreb, skiftende miljø, modelopdateringer). Regelmæssig måling er påkrævet for at holde det sikkert:

  • Falsk positiv og falsk negativ rate: Hvor ofte alarmerer AI forgæves, hvor ofte går den glip af den reelle trussel? Falske negativer ses især, fordi de stille forårsager skade.
  • MTTD/MTTR: ​​Bliver de gennemsnitlige detektions- og responstider forbedret?
  • AI-outputnøjagtighed: Ved stikprøver, hvor meget af AI's resuméer/resultater/citater består validering?
  • Automatiseringssikkerhed: Fungerer automatiske handlinger som forventet, er der nogle falske triggere, fungerer tilbageførslerne?
  • Feedback-sløjfe: Bliver faktiske fundne hændelser nye registreringsregler, og hævede alarmer bliver undtagelseslister?

Vilkår: MTTD (Mean Time To Detect). Feedback-sløjfen er, når operationen lærer af sine egne resultater og opdaterer sine regler. Modeldrift er, når AI bliver forældet, og ydeevnen falder, efterhånden som miljøet ændrer sig. Selvrevision er den regelmæssige, kritiske gennemgang af teamets egne processer.

tre minisager

Case 1 — Korrekt automatisering. En SOC automatiserer trinnet med "automatisk berigelse og prioritering af advarsler, der matcher kendte ondsindede IOC'er og er i en lavrisikokategori"; men forlader altid trinnet "isolering af en server" til menneskelig godkendelse. Resultatet: analytikere bliver befriet fra 400 rutinealarmer om dagen, hvilket frigør tid til reelle undersøgelser, og overlader kritiske beslutninger op til mennesket. Den rigtige del af kæden er automatisk, det rigtige sted er menneskeligt.

Case 2 — Automatisering giver bagslag. En anden SOC definerer reglen "autolås konto ved mistænkeligt login" meget bredt. En dag, på grund af en konfigurationsfejl, låser reglen 1.200 legitime brugere ude på én gang, og arbejdet stopper; Desuden er gendannelsesstien ikke defineret. Lektion: Effektiv automatisering skal have strenge kriterier, gradvis implementering og en rollback-sti. Automatisering bør være reversibel og overvåges gennem selvregulering.

Tilfælde 3 — Skridningen fanget af selvkontrol. I en tre-måneders selv-audit bemærker et hold, at AI'ens phishing-detektionsnøjagtighed er faldende: en ny phishing-bølge savnes, fordi den ikke passer til gamle mønstre (mønsterdrift). Holdet indsamler prøver, opdaterer detektionsreglerne og opdaterer konteksten givet til AI. Uden regelmæssig selvkontrol kunne denne tavse unddragelse have fortsat i flere måneder. Lektion: bare fordi præstationen er god én gang, forbliver den ikke altid god; måling og feedback er afgørende.

Svag prompt / Stærk prompt

Svag prompt:

Fuldstændig automatiser vores SOC og lad AI'en håndtere alt.

Denne anmodning kræver automatisering uden diskrimination af risiko, ignorerer menneskelige døre og tager ikke højde for tilbagerulning og kontrol. Hvis de implementeres, vil højrisikobeslutninger blive automatiseret uden overvågning og blive til katastrofe ved den første fejl.

Kraftig prompt:

Din rolle: Konsulent i SOC procesdesign. [Liste] disse hændelseslivscyklustrin i tre baseret på risikoniveau: (A) fuldautomatisk (lav risiko, reversibel, repetitiv), (B) AI anbefaler + menneskelig godkendelse, (C) altid menneskelig beslutning (høj risiko, irreversibel). Foreslå en obligatorisk rollback-sti og en sporingsmetrik for hver (A) og (B). Udarbejd også en kvartalsvis selvrevisionstjekliste: falsk positiv/negativ rate, MTTD/MTTR, AI-output nøjagtighedsprøvetagning, tegn på mønsterdrift.

Stærk efterspørgsel adskiller automatisering efter risikoniveau, kræver rollback og overvågning og etablerer en selvreguleringsramme.

Kopierbare promptskabeloner

AUTOMATION RISIKO SEPARATION Skabelon Adskil disse sikkerhedsworkflow-trin i tre: (A) fuldt automatiseret passende, (B) Anbefaler menneskelig godkendelse, (C) altid menneskelig beslutning. Skriv begrundelse, reversibilitet og forretningspåvirkning for hvert trin. Anbefal obligatorisk tilbagerulningssti for trin med høj påvirkning. Trin: [liste]

TILBAGE DESIGN SKABELON til automatisk handling [f.eks. konto lockout] foreslår et sikkert design: triggerkriterier (snævre), gradvis implementering, falsk trigger rollback-trin, advarsel og menneskelig verifikationspunkt. Design for at undgå blindautomatisering. Handling: [skriv]

Skabelon for SELV-AUDIT CHECKLISTE Udarbejd en kvartalsvis selvrevisionstjekliste for en AI-drevet SOC: falsk positiv/negativ frekvens, MTTD/MTTR-bias, AI-udgangsnøjagtighedssampling, automatiserings falske triggere, tegn på mønsterdrift, feedback-sløjfedrift, overholdelse af privatliv/anonymisering. Skriv for hver vare, hvordan den vil blive målt.

FEEDBACK LOOP Skabelon Tegn, hvad der er lært af den faktiske hændelse/alarm, der fejler: (1) mønsteret, der bliver en ny registreringsregel, (2) den falske positiv, der vil blive tilføjet til undtagelseslisten, (3) playbook-trinnet, der vil blive opdateret, (4) den nye kontekst, der vil blive givet til AI. Hændelses-/alarmoversigt: [indsæt]

Almindelige fejl

  • Automatisering af højrisikotrinnet. Irreversible trin såsom serverisolering, produktionspatching, officiel notifikation fjernes ikke fra den menneskelige dør.
  • Udtænker ikke en vej til genfinding. Det er muligt for enhver automatisk handling at udløse forkert; Automatisering uden et punkt for fortrydelse og bekræftelse er farligt.
  • Sæt og glem. AI-ydeevnen skifter, efterhånden som miljøet ændrer sig; Uden regelmæssig egenkontrol og måling akkumuleres tavse undvigelser.
  • Bare sporer den falske positive. En falsk negativ (den virkelige trussel, der er savnet) er farligere, men sværere at se; Se den privat.
  • Forsømmer feedback. Hvis de opdagede hændelser ikke bliver til en ny regel, og de mislykkede alarmer ikke bliver til en undtagelse, lærer handlingen ikke og gentager den samme fejl.
Tip: Det gyldne spørgsmål i automatiseringsbeslutningen: "Kan denne handling fortrydes, hvis den udløses forkert, og hvad er forretningsvirkningen?" Hvis svaret er "let at fortryde, lav effekt," automatiser; Hvis "irreversibel eller høj påvirkning" holdes ved menneskelig dør.
Forsigtig: Automatisering fjerner ikke ansvar, det fremskynder kun det. En dårligt gennemtænkt automatisk handling forårsager skade meget hurtigere og bredere end et menneske kunne. Enhver automatisering er omgivet af snævre kriterier, rollback-vej og regelmæssig inspektion; Det ultimative ansvar ligger altid hos mennesket.

Sammenfattende

Denne enhed kombinerede alle dele af modulet i et end-to-end SOC-workflow: indsamling, detektion, triage, undersøgelse, respons, afhjælpning, rapportering og feedback. AI er involveret i hvert led, men det er mennesket, der holder kæden og træffer beslutninger ved enhver kritisk dør. Automatisering (SOAR + AI) øger kraften; Reglen er klar: lavrisiko, reversible, gentagne trin bliver automatiserede, højrisiko, irreversible trin passerer gennem den menneskelige dør, og enhver automatisering har en måde at fortryde. Endelig er et AI-drevet sikkerhedsprogram live: falske positive/negative, MTTD/MTTR, outputnøjagtighed og mønsterdrift måles regelmæssigt; Det, der findes, bliver til regler og spillebøger i en feedback-loop. Automatisering fremskynder ansvar, ikke fjerner det; Selvkontrol holder sikkerheden i live.

Ansøgningsopgave

Skriv din egen organisations (eller et eksempel på SOC's) hændelseslivscyklus. Klassificer hvert trin som A/B/C med skabelonen "Automation Risk Separation" og udled et sikkert automatiseringsdesign med "Rollback Design"-skabelonen for mindst ét ​​"high impact"-trin. Opret derefter en kvartalsvis tjekliste med skabelonen "Selvrevisionstjekliste" og bestem, hvordan du vil måle hver enkelt metrik i dit miljø.

tjekliste

  • [ ] Jeg opdelte hvert trin i hændelsens livscyklus i A/B/C-risikoklasse.
  • [ ] Jeg holdt højrisiko, irreversible skridt ved den menneskelige dør.
  • [ ] Jeg designede smalle kriterier og fortryd-sti for hver automatisk handling.
  • [ ] Jeg har planlagt at overvåge antallet af falske positive og især falske negative.
  • [ ] Jeg planlagde at måle MTTD/MTTR og AI output nøjagtighed regelmæssigt.
  • [ ] Jeg etablerede en kvartalsvis selvovervågningstjekliste for mønsterdrift.
  • [ ] Jeg tilsluttede de fundne hændelser og sendte alarmer til feedback-sløjfen.

Modul eksamen

1. En SIEM triage AI markerede en alarm som 'lav prioritet, sandsynligvis falsk positiv' og skubbede den til bunden af listen. Hvad skal analytikeren gøre ved denne alarm?

  • A) Stadig uafhængigt kontrollerer alarmen og verificerer den med rå bevis; Analytikeren træffer beslutningen om lukning og registrerer den ✔
  • B) Kunstig intelligens slukker automatisk alarmen uden at undersøge den, fordi den siger, at den har lav prioritet.
  • C) Overfører alarmen til næste skift, som den er.
  • D) Bare se på resuméet givet af kunstig intelligens og send rapporten

Forklaring: AI-prioritering er en anbefaling, ikke en diagnose; Flaget 'lav prioritet' kan dække et reelt angreb (falsk negativ). Analytikeren skal stadig uafhængigt kontrollere advarslen, verificere den med rå bevis og træffe beslutningen om at lukke den selv. Et negativt AI-output er ingen garanti for 'ingen trussel'.

2. Hvilken kombination af risici betegner AI et rigtigt angreb som "normalt", og analytikeren stoler på dette og slapper af sin egen analyse?

  • A) Kun falsk positiv og alarmtræthed
  • B) Falsk negativ og automatiseringsbias (overdreven afhængighed af AI) ✔
  • C) Kun mangel på logkilde
  • D) Kun SIEM-regelfejl

Forklaring: Det er en falsk negativ, hvis modellen går glip af den reelle trussel; Automatiseringsbias er, når analytikeren har overdreven tillid til kunstig intelligens og opgiver uafhængig gennemgang. Når de to kombineres, forsvinder eksistensen af ​​menneskelig kontrol, og angrebet kan omgås helt. Derfor undersøges også områder, som kunstig intelligens kalder 'rene'.

3. AI sagde "CVE-2024-88888, CVSS 9.8, patch straks" under en triage. Hvad skal analytikeren gøre først?

  • A) Betragter CVE'en som troværdig og igangsætter patching-planen med det samme
  • B) Bare fordi CVSS er 9.8, sætter den den først uden at se på andre sårbarheder
  • C) Verificerer CVE-nummeret og scoren i NVD/leverandørens post; ✔ Hvis der ikke er nogen registrering, vil den ikke blive opført vel vidende, at den kan være falsk.
  • D) Uden at verificere CVE, skriver administratoren det i rapporten som 'kritisk trussel'

Beskrivelse: Sprogmodeller kan flydende passe til et ikke-eksisterende CVE-nummer og score (hallucinerer). Analytikeren skal verificere CVE'en i NVD/leverandørloggen og bekræfte dens ægthed og score, før han forpligter sig til programrettelsen. En uverificeret CVE forbinder først til ressourcen; Ellers vil holdet spilde tid på at jagte en patch, der ikke eksisterer.

4. For at fremskynde en hændelsesundersøgelse indsætter en ekspert den rå firewalllog sammen med faktiske interne IP'er, brugernavne og VPN-servernavne i et offentligt tilgængeligt AI-værktøj. Hvad er hovedproblemet her?

  • A) AI kan ikke læse logformatet, så analyse er ubrugelig
  • B) Hvis loggen er for lang, bremser det modellen.
  • C) Firewall-logfiler er alligevel ikke egnede til analyse
  • D) Ægte IP-, bruger- og servernavne deles uden anonymisering; Dette er både en overtrædelse af KVKK og lækagen af ​​organisationens netværkskort ✔

Beskrivelse: Sikkerhedsdata er både personlige data (bruger, IP) og virksomhedsintelligens, der afslører organisationens angrebsoverflade (netværkstopologi, servernavne). At give dette til et eksternt værktøj uden at anonymisere det er både en krænkelse af KVKK og afslører et netværkskort, der vil være nyttigt for angriberen. For det første er de faktiske værdier maskeret med konsistente pladsholdere.

5. Hvad gør, at en trusselsjagt anses for at være veldesignet?

  • A) Det starter med en konkret, testbar hypotese, og det fundne spor bekræftes af råbevis ✔
  • B) Det starter med at fortælle den kunstige intelligens 'find om der er en angriber i mit netværk'
  • C) Erklærer automatisk enhver unormal/sjælden hændelse fundet som et angreb
  • D) Det virker kun når der kommer en alarm, det er ikke proaktivt

Forklaring: En god trusselsjagt starter ikke med en alarm, men med en konkret og testbar hypotese, der måske eller måske ikke viser sig at være sand (f.eks. 'Forbandt konto X sig til mere end 50 interne IP'er i ikke-arbejdstid'). Et vagt spørgsmål som 'Er der noget dårligt på mit netværk' kan ikke testes og lader AI'en gætte. Det fundne spor betragtes ikke som en trussel, før det er verificeret med rå beviser.

6. En sårbarhed har en CVSS-score på 9,1 på en isoleret testserver på det interne netværk; I samme liste, CVSS 7.5 på en server åben til internettet, men der er en anden sårbarhed i KEV listen (som faktisk udnyttes). Hvad er korrekt prioritering?

  • A) Den med den højeste CVSS (9.1) lappes altid først
  • B) Sårbarheden af 7.5 på Internettet og KEV-listen tages videre; CVSS er ikke det eneste kriterium, eksponering og faktisk misbrug er afgørende ✔
  • C) Begge er lappet på samme tid og med samme prioritet, skelnen er unødvendig
  • D) Ingen af dem er rettet, fordi der er en sårbarhed i testserveren

Forklaring: CVSS opstiller ikke prioriteter alene; faktisk risiko bestemmes af EPSS (sandsynlighed for udnyttelse), KEV (faktisk udnyttelse) og organisatorisk kontekst (eksponering, kritikalitet, kompenserende kontrol). Internet-eksponeret og faktisk udnyttet (KEV) sårbarhed forhindrer isoleret og lav sandsynlighed høj-CVSS sårbarhed.

7. I et hændelsesvar siger kunstig intelligens 'Trafik, der stammer fra IC_HOST_7 er mistænkelig, isoler denne server'. IC_HOST_7 er institutionens hovedgodkendelsesserver. Hvad skal analytikeren gøre?

  • A) Kunstig intelligens isolerer straks serveren, fordi den siger det
  • B) Overlader isolationsbeslutningen udelukkende til kunstig intelligens
  • C) Evaluer først forretningspåvirkningen og årsagen til trafik; Den isolerer ikke kritisk infrastruktur uden at måle dens effekt og træffer beslutningen som analytiker ✔
  • D) Isolerer serveren og sletter derefter alle logfiler

Beskrivelse: Isolation er en kritisk beslutning, som er svær at omgøre og kan føre til forretningsafbrydelser; kan ikke overføres til kunstig intelligens. Isolering af godkendelsesserveren kan forhindre alle medarbejdere i at logge ind. Analytikeren skal først evaluere forretningspåvirkningen og årsagen til trafikken (kan være en legitim transaktion), selv træffe beslutningen; Forslaget om kunstig intelligens bør ikke implementeres som en ordre.

8. I en ransomware-hændelse ønsker teamet at genopbygge en berørt maskine for hurtigt at rense den; men der er retsmedicinske beviser (hukommelsesdump, angriberværktøjer) på maskinen, som endnu ikke er blevet indsamlet. Hvad er den rigtige tilgang?

  • A) Maskinen geninstalleres straks; bevis er irrelevant
  • B) Kunstig intelligens bedes om 'hurtigste rengøring' og instruktionen anvendes blindt.
  • C) Maskinen er slukket og smidt væk, fordi beviserne allerede er i loggen.
  • D) Først tages det retsmedicinske billede og hukommelsesdump, og beviserne bevares, derefter udføres rengøring/genopretning ✔

Forklaring: Gendannelseshastigheden kan ikke overtrumfe bevisbevaring. Geninstallation af maskinen uden at indsamle beviser ødelægger varetægtskæden og lammer den retlige proces. Først tages et retsmedicinsk billede og hukommelsesdump, derefter udføres rengøring/genopretning. Retsmedicinske trin delegeres ikke til AI.

9. Hvad er et af de mest pålidelige lag af teknisk verifikation, når man analyserer en formodet phishing-e-mail, og hvordan skal den bekræftes?

  • A) SPF/DKIM/DMARC resulterer i e-mail-headere; Bekræftet fra den rå titel, ikke fra AI'ens oversigt ✔
  • B) Farve og skrifttype på e-mailen; bestemt af visuelt design
  • C) Klik på det mistænkelige link på live-systemet og se på siden, der åbner.
  • D) Kunstig intelligens siger "phishing" alene er tilstrækkeligt bevis

Forklaring: SPF/DKIM/DMARC-resultater i e-mail-headers er stærke indikatorer for, om e-mailen faktisk kommer fra det domæne, den hævder at være; Hvis alle tre fejler, og afsenderen forfalsker domænet, bliver mistanken stærkere. Dette bør dog bekræftes fra den rå titel og ikke fra resuméet af AI. Derudover bliver mistænkelige links aldrig klikket på live-systemet.

10. I en kodegennemgang foreslog AI en rettelse til en XSS-sårbarhed og sagde "det lukker sårbarheden". Hvad skal analytikeren/udvikleren gøre?

  • A) Betragter rettelsen som pålidelig og sætter den direkte i produktion
  • B) Gennemgår rettelsen, bekræfter, at den faktisk lukker sårbarheden og ikke introducerer nye sårbarheder/bugs, og skriver en test; Først derefter kommer den på lager ✔
  • C) Da han ikke er sikker, omskriver han hele filen til den kunstige intelligens og bruger den.
  • D) Anvender rettelsen, men består uden at skrive nogen test

Forklaring: Rettelsen foreslået af AI er ikke automatisk sikker; Det kan muligvis ikke lukke sårbarheden fuldstændigt, det kan rense det forkerte lag, eller det kan introducere en ny sårbarhed/funktionsfejl. Hver patch bliver gennemgået, vurderet om den faktisk lukker sårbarheden, og om den introducerer nye problemer, og positive og negative testcases skrives; Først derefter kommer den ind på lageret.

11. Da den kunstige intelligens analyserede et angreb, sagde "det her er bestemt arbejdet for APT-Dark Eagle-gruppen". Hvad er den rigtige tilgang med hensyn til trusselsintelligens?

  • A) Accepter referencen, som den er, og skriv den i rapporten som den 'klare gerningsmand'
  • B) Han bygger hele sit forsvar baseret på den gruppe uden nogensinde at stille spørgsmålstegn ved gruppens navn.
  • C) Bruger sproget 'konsistent med teknikker' frem for præcis tilskrivning, verificerer gruppen i kendte kilder og tager højde for muligheden for fremstilling ✔
  • D) Citering er altid unødvendigt, det tages slet ikke i betragtning

Forklaring: Gruppetilskrivning er det sværeste og mest unøjagtige område af intelligens; AI kan endda lave et bandnavn, der ikke eksisterer. I stedet for en nøjagtig reference bruges sproget 'kompatibelt med disse teknikker', og gruppenavnet bekræftes i kendte efterretningskilder. Derudover er forsvaret ikke baseret på kortvarige IOC'er, men på permanent TTP-detektion.

12. I et udkast til hændelsesrapport skrev AI sætningen "angriberen var højst sandsynligt inde i tre uger og eksfiltrerede kundedata"; der henviser til, at der ikke er noget afgørende logbevis til støtte for disse påstande. Hvad skal analytikeren gøre?

  • A) Lader sætningen være som den er, fordi den er dramatisk og imponerende
  • B) Forlader sætningen, men tilføjer 'kunstig intelligens skrev' til sidst
  • C) Genprinter hele rapporten til den kunstige intelligens og underskriver den uden at verificere den.
  • D) retter påstande baseret på beviser; Foretager skelnen mellem 'mulig/bevist/under undersøgelse' og uddrager den endelige erklæring uden beviser ✔

Kommentar: I en formel sikkerhedsrapport skal enhver påstand være underbygget, og 'sandsynlig' må aldrig forveksles med 'bevist'. Et krav uden bevis har juridiske, økonomiske og omdømmemæssige konsekvenser. Analytikeren bør rette sætningen i henhold til beviserne (skriv f.eks. datoen for første opdagelse af adgang og sig "ingen afgørende bevis fundet, undersøgelse er i gang" for datalækket).

13. En leder ønsker at profilere al en medarbejders aktivitet fra sikkerhedslogfiler med kunstig intelligens for at forstå, om han er 'loyal' eller ej. Hvad skal en sikkerhedsprofessionel gøre?

  • A) Afviser anmodningen og henviser den til den relevante kanal (HR/juridisk/defineret undersøgelse); sikkerhedsdata er ikke et middel til personlig overvågning ✔
  • B) Opretter og leverer profilen, fordi lederen anmoder om det
  • C) Den udtrækker kun nogle logfiler og giver en delvis profil
  • D) Få oprettet profilen af kunstig intelligens, fordi ansvaret overgår til kunstig intelligens

Beskrivelse: Sikkerhedsdata indsamles til sikkerhedsformål; Sporing/profilering af en person er misbrug, bliver til personovervågning og krænker KVKK. Eksperten bør afvise denne anmodning og henvise den til den relevante kanal (HR, juridisk, en defineret og legitim efterforskningsramme). Goodwill eller lederens ønske retfærdiggør ikke denne grænse.

14. En SOC beslutter, hvilke trin i sikkerhedsworkflowet, der skal automatiseres. Hvad er det bedste princip for automatisering?

  • A) De højeste risikobeslutninger bør automatiseres først, så der ikke er nogen menneskelig involvering
  • B) Lavrisiko/reversible trin er automatiseret; høj risiko/irreversible trin forbliver ved menneskets dør, og enhver automatisering har en måde at fortryde ✔
  • C) Alle SOC bør være fuldautomatiske, og selvrevision er unødvendig
  • D) Automatiserede handlinger behøver ikke at fortrydes, fordi AI ikke laver fejl

Forklaring: Lavrisiko, gentagne og reversible trin (logopsamling, alarmberigelse) kan automatiseres; Højrisiko-, irreversible og domskrævende trin (serverisolering, produktionspatching, officiel notifikation) går gennem den menneskelige dør. Derudover skal enhver automatisk handling have snævre kriterier og en måde at fortryde. Automatisering fjerner ikke ansvar, det fremskynder det bare.