End-to-end SOC Workflow, Automation (SOAR), Quality Management och Self-Audit — Artificiell intelligens i cybersäkerhet

Vinster:

Förmåga att designa ett heltäckande SOC-arbetsflöde som består av insamling, upptäckt, triage, undersökning, intervention, förbättring, rapportering och feedback, som specificerar platsen för artificiell intelligens och mänskliga grindar
Möjlighet att separera automatisering efter risknivå (lågrisk/reversibla steg är automatiska, högrisk/irreversibla steg är människokontrollerade) och utforma en återställningsväg för varje automatisk åtgärd.
Möjlighet att upprätta en självövervaknings- och återkopplingsslinga som regelbundet mäter falsk positiv/negativ frekvens, MTTD/MTTR, utmatningsnoggrannhet och modelldrift

Den här sista enheten kombinerar de delar vi lärt oss separat under hela modulen – logganalys, hotjakt, sårbarhetshantering, incidentrespons, nätfiske, kodgranskning, intelligens, rapportering – i ett enda arbetsflöde från början till slut. I ett verkligt säkerhetsoperationscenter (SOC) kopplas inte dessa steg bort; Ett larm utlöser en utredning, som utlöser ett svar, som utlöser en anmälan, som utlöser en sanering. Artificiell intelligens är involverad i varje länk i denna kedja, men det är människan som håller kedjan och fattar beslut vid varje kritisk dörr.

Dessutom täcker den här enheten två viktiga ämnen. Den första är automatisering: När SOAR (Security Orchestration, Automation and Response — plattformen som automatiserar och organiserar säkerhetsprocesser) och AI kombineras ökar både kraft och risk; Det är nödvändigt att skilja mellan vad som kan automatiseras och vad som aldrig kan tas bort från mänskligt godkännande. För det andra, kvalitetsledning och självreglering: En AI-aktiverad säkerhetsoperation ställs inte upp och överges en gång; den övervakas, mäts, återkopplas och korrigeras ständigt. Automatisering ökar hastigheten men tar inte bort ansvar; Ett säkerhetsprogram förblir säkert endast genom regelbunden egenkontroll.

End-to-end SOC-arbetsflöde

Låt oss se var AI spelar in och vem som godkänner det i en typisk incidentlivscykel:

Insamling och övervakning: Loggar flöde till SIEM; AI minskar brus, sammanfattar. (Automatisk, låg risk.)
Detektering och larm: Regel + anomali + AI-mönsterdetektering. (Automatisk produktion; triage är hos människor.)
Triage: Är larmet verkligt eller falskt positivt? AI föreslår motivering och prioritet; bekräftar analytikern. (Mänsklig dörr.)
Utredning: AI samlar in bevis, upprättar tidslinje, listar grundorsaken; analytikern bekräftar med råbevis. (Mänsklig dörr.)
Ingripande: Isolering, låsning, rengöring. AI ger val/inflytande; Beslutet ligger i händerna på den auktoriserade analytikern. (Kritisk mänsklig port.)
Åtgärd: Stängning av sårbarhet, eliminering av grundorsaken. AI-planutkast; godkännande i förändringsledning. (Människa + process.)
Rapportering: AI skriver utkast, anpassar sig efter publik; Experten verifierar och undertecknar bevisen. (Mänsklig dörr.)
Lektionsinlärning och feedback: AI extraherar mönster; Uppdaterar lagdetekteringsregler och spelböcker. (Människa + process.)

Regeln för denna kedja: lågrisk, repetitiva, reversibla steg kan automatiseras; Högrisk, irreversibla, bedömningskrävande steg passerar genom den mänskliga dörren.

Beslutstabell för automation

steg

Kan det automatiseras

skick

mänskligt godkännande

Logginsamling, normalisering

Ja, precis

—

inte nödvändigt

Larmberikning (IOC-sökning)

Källan är tillförlitlig

Den granskas

Falsk positiv eliminering (känd nytta)

delvis

strikt regel

Inspekteras genom provtagning

Sätt nätfiske i karantän

delvis

hög precision

Granskning + återställningsväg

Lås ett konto automatiskt

försiktig

Bara tydliga kriterier

Snabb mänsklig verifiering

Isolera servern

Generellt nej

Förutom kritisk infrastruktur

Påtvingat mänskligt beslut

Patchning (produktion)

nej

—

Testning + förändringsledning

Officiell rapport/anmälan

nej

—

Expert + juridik

Kvalitetsledning och egenrevision

En AI-driven säkerhetsoperation är ett levande system; dess prestanda förändras över tid (nya attacker, förändrad miljö, modelluppdateringar). Regelbunden mätning krävs för att hålla den säker:

Falsk positiv och falsk negativ frekvens: Hur ofta larmar AI förgäves, hur ofta missar den det verkliga hotet? Falska negativ är särskilt tittade eftersom de tyst orsakar skada.
MTTD/MTTR: Förbättras genomsnittliga detekterings- och svarstider?
AI-utmatningsnoggrannhet: Hur mycket av AI:s sammanfattningar/fynd/citat klarar validering genom sampling?
Automatiseringssäkerhet: Fungerar automatiska åtgärder som förväntat, finns det några falska triggers, fungerar återställningen?
Återkopplingsslinga: Blir faktiska händelser som hittats nya detekteringsregler och utlösta larm blir undantagslistor?

Villkor: MTTD (Mean Time To Detect). Återkopplingsslingan är när operationen lär sig av sina egna resultat och uppdaterar sina regler. Modelldrift är när AI blir föråldrad och prestandan minskar när miljön förändras. Självrevision är den regelbundna, kritiska granskningen av teamets egna processer.

tre minifodral

Fall 1 — Korrekt automatisering. En SOC automatiserar steget att "automatiskt berika och prioritera varningar som matchar kända skadliga IOC och är i en lågriskkategori"; men lämnar alltid steget "isolera en server" för mänskligt godkännande. Resultatet: analytiker befrias från 400 rutinlarm om dagen, vilket frigör tid för riktiga undersökningar och överlåter kritiska beslut till människan. Rätt del av kedjan är automatisk, rätt plats är mänsklig.

Fall 2 — Automatisering slår tillbaka. En annan SOC definierar regeln "autolås konto vid misstänkt inloggning" väldigt brett. En dag, på grund av ett konfigurationsfel, låser regeln ute 1 200 legitima användare samtidigt och arbetet stannar; Dessutom är återställningsvägen inte definierad. Lärdom: effektiv automatisering måste ha strikta kriterier, gradvis implementering och en återställningsväg. Automatisering bör vara reversibel och övervakas genom självreglering.

Fall 3 — Glidningen fångad av självkontroll. I en tre månader lång självrevision märker ett team att AI:s nätfiskedetekteringsnoggrannhet minskar: en ny nätfiskevåg missas eftersom den inte passar gamla mönster (mönsterdrift). Teamet samlar in prover, uppdaterar detektionsreglerna och uppdaterar sammanhanget som ges till AI. Utan regelbunden självkontroll hade detta tysta undanflykt kunnat fortsätta i månader. Lärdom: bara för att prestanda är bra en gång, förblir det inte alltid bra; mätning och återkoppling är avgörande.

Svag prompt / Stark prompt

Svag uppmaning:

Helautomatisera vår SOC och låt AI:n hantera allt.

Denna begäran kräver automatisering utan diskriminering av risk, ignorerar mänskliga dörrar och tar inte hänsyn till återställning och kontroll. Om de implementeras kommer högriskbeslut att automatiseras utan övervakning och förvandlas till katastrof vid första misstaget.

Kraftfull uppmaning:

Din roll: Konsult inom SOC processdesign. [Lista] dessa händelselivscykelstegen i tre baserade på risknivå: (A) helt automatiserat (låg risk, reversibel, repetitiv), (B) AI rekommenderar + mänskliga godkänner, (C) alltid mänskliga beslut (hög risk, irreversibel). Föreslå en obligatorisk återställningsväg och ett spårningsmått för varje (A) och (B). Utarbeta också en kvartalsvis självrevisionschecklista: falsk positiv/negativ frekvens, MTTD/MTTR, AI-utdata noggrannhetssampling, tecken på mönsterdrift.

Stark efterfrågan separerar automatisering efter risknivå, kräver återställning och övervakning och etablerar ett ramverk för självreglering.

Kopierbara promptmallar

AUTOMATION RISKSEPARATIONSMALL Dela upp dessa säkerhetsarbetsflödessteg i tre: (A) helt automatiserat lämpligt, (B) Rekommenderar mänskligt godkänner, (C) alltid mänskliga beslut. Skriv motivering, reversibilitet och affärseffekt för varje steg. Rekommendera obligatorisk återställningsbana för steg med hög påverkan. Steg: [lista]

ROLLBACK DESIGN-MALL för automatisk åtgärd [t.ex. kontolåsning] föreslår en säker design: utlösningskriterier (smal), gradvis driftsättning, steg för falsk utlösande av återställning, varning och mänsklig verifieringspunkt. Design för att undvika blindautomatisering. Åtgärd: [skriv]

SJÄLVREVISIONSCHECKLISTAMALL Utarbeta en kvartalsvis självrevisionschecklista för en AI-driven SOC: falsk positiv/negativ frekvens, MTTD/MTTR-bias, AI-utmatningsnoggrannhetssampling, automatiseringsfalska utlösare, tecken på mönsterdrift, återkopplingsslinga, efterlevnad av sekretess/anonymisering. För varje objekt, skriv hur det ska mätas.

FEEDBACK LOOP MALL Rita vad som lärs av den faktiska händelsen/larmet som misslyckas: (1) mönstret som kommer att bli en ny detekteringsregel, (2) den falska positiva som kommer att läggas till i undantagslistan, (3) spelboksteget som kommer att uppdateras, (4) det nya sammanhanget som kommer att ges till AI:n. Sammanfattning av händelse/larm: [klistra in]

Vanliga misstag

Automatisera högrisksteget. Oåterkalleliga steg som serverisolering, produktionspatchning, officiell notifiering tas inte bort från den mänskliga dörren.
Att inte utforma en väg till återhämtning. Det är möjligt att varje automatisk åtgärd utlöses felaktigt; Automatisering utan en punkt för ångra och bekräftelse är farligt.
Ställ in och glöm. AI-prestanda förändras när miljön förändras; Utan regelbunden egenkontroll och mätning ackumuleras tysta undanflykter.
Bara att spåra det falska positiva. Ett falskt negativt (det verkliga hotet som missas) är farligare men svårare att se; Se den privat.
Försummar feedback. Om de upptäckta händelserna inte förvandlas till en ny regel och de misslyckade larmen inte förvandlas till ett undantag, lär operationen sig inte och upprepar samma misstag.

Tips: Den gyllene frågan i automatiseringsbeslut: "Kan den här åtgärden ångras om den utlöses felaktigt och vad är affärseffekten?" Om svaret är "lätt att ångra, låg effekt", automatisera; Om "irreversibel eller hög påverkan" håll dig vid mänsklig dörr.

Varning: Automatisering tar inte bort ansvar, det påskyndar bara det. En ogenomtänkt automatisk handling orsakar skador mycket snabbare och mer omfattande än en människa skulle kunna. Varje automatisering är omgiven av snäva kriterier, återställningsväg och regelbunden inspektion; Det yttersta ansvaret ligger alltid hos människan.

Sammanfattningsvis

Denna enhet kombinerade alla delar av modulen till ett heltäckande SOC-arbetsflöde: insamling, upptäckt, triage, utredning, svar, åtgärdande, rapportering och återkoppling. AI är involverad i varje länk, men det är människan som håller i kedjan och fattar beslut vid varje kritisk dörr. Automation (SOAR + AI) ökar kraften; Regeln är klar: lågrisk, reversibla, repetitiva steg blir automatiserade, högrisk, irreversibla steg passerar genom den mänskliga dörren, och varje automatisering har ett sätt att ångra. Slutligen är ett AI-drivet säkerhetsprogram live: falska positiva/negativa, MTTD/MTTR, utmatningsnoggrannhet och mönsterdrift mäts regelbundet; Det som hittas förvandlas till regler och spelböcker i en återkopplingsslinga. Automatisering accelererar ansvar, inte tar bort det; Självkontroll håller säkerheten vid liv.

Applikationsuppgift

Skriv ut din egen organisations (eller ett exempel på SOC:s) incidentlivscykel. Klassificera varje steg som A/B/C med mallen "Automation Risk Separation" och skapa en säker automatiseringsdesign med mallen "Rollback Design" för minst ett "high impact"-steg. Skapa sedan en kvartalsvis checklista med mallen "Self-Audit Checklist" och bestäm hur du ska mäta varje mätvärde i din miljö.

checklista

[ ] Jag delade in varje steg i incidentens livscykel i A/B/C-riskklass.
[ ] Jag höll irreversibla steg vid den mänskliga dörren.
[ ] Jag utformade smala kriterier och ångra sökvägen för varje automatisk åtgärd.
[ ] Jag har planerat att övervaka frekvensen av falska positiva och speciellt falska negativa.
[ ] Jag planerade att mäta MTTD/MTTR och AI-utmatningsnoggrannhet regelbundet.
[ ] Jag upprättade en kvartalsvis självövervakningschecklista för mönsteravvikelse.
[ ] Jag kopplade de hittade händelserna och skickade larm till återkopplingsslingan.

Modulexamen

1. En SIEM-triage AI flaggade ett larm som "låg prioritet, sannolikt falskt positivt" och sköt det till botten av listan. Vad ska analytikern göra åt detta larm?

A) fortfarande självständigt kontrollerar larmet och verifierar det med råbevis; Analytikern fattar beslutet om nedläggning och registrerar det ✔
B) Artificiell intelligens stänger automatiskt av larmet utan att undersöka det eftersom det säger att det har låg prioritet.
C) Överför larmet till nästa skift som det är.
D) Titta bara på sammanfattningen från artificiell intelligens och skicka rapporten

Förklaring: AI-prioritering är en rekommendation, inte en diagnos; Flaggan 'låg prioritet' kan täcka en riktig attack (falsk negativ). Analytikern måste fortfarande självständigt kontrollera varningen, verifiera den med råbevis och fatta beslutet att stänga den själv. En negativ AI-utgång är ingen garanti för "inget hot".

2. Vilken kombination av risker betecknar AI en riktig attack som "normal" och analytikern litar på detta och slappnar av sin egen analys?

A) Endast falsk positiv och larmtrötthet
B) Falsk negativ och automationsbias (övertilltro till AI) ✔
C) Avsaknad av endast loggkälla
D) Endast SIEM-regelfel

Förklaring: Det är ett falskt negativt om modellen missar det verkliga hotet; Automationsbias är när analytikern överlitar artificiell intelligens och överger oberoende granskning. När de två kombineras försvinner existensberättigandet av mänsklig kontroll och attacken kan förbigås helt. Det är därför också områden som artificiell intelligens kallar "rena" undersöks.

3. AI:n sa "CVE-2024-88888, CVSS 9.8, patch omedelbart" under en triage. Vad ska analytikern göra först?

A) Anser CVE:n som trovärdig och initierar lappningsplanen omedelbart
B) Bara för att CVSS är 9.8, sätter det det först utan att titta på några andra sårbarheter
C) Verifierar CVE-numret och poängen i NVD/leverantörsposten; ✔ Om det inte finns något register, kommer det inte att listas med vetskap om att det kan vara falskt.
D) Utan att verifiera CVE, skriver administratören det i rapporten som "kritiskt hot"

Beskrivning: Språkmodeller kan flytande passa ett obefintligt CVE-nummer och poäng (hallucinera). Analytikern måste verifiera CVE i NVD/leverantörsloggen och bekräfta dess äkthet och poäng innan han förbinder sig till patchschemat. En overifierad CVE ansluter först till resursen; Annars kommer teamet att slösa tid på att jaga en patch som inte finns.

4. För att påskynda en incidentutredning klistrar en expert in den råa brandväggsloggen tillsammans med faktiska interna IP-adresser, användarnamn och VPN-servernamn i ett allmänt tillgängligt AI-verktyg. Vad är huvudproblemet här?

A) AI kan inte läsa loggformatet, så analys är värdelös
B) Om stocken är för lång saktar det ner modellen.
C) Brandväggsloggar är inte lämpliga för analys ändå
D) Verkliga IP-, användar- och servernamn delas utan anonymisering; Detta är både ett brott mot KVKK och läckaget av organisationens nätverkskarta ✔

Beskrivning: Säkerhetsdata är både personuppgifter (användare, IP) och företagsintelligens som avslöjar organisationens attackyta (nätverkstopologi, servernamn). Att ge detta till ett externt verktyg utan att anonymisera det är både ett brott mot KVKK och avslöjar en nätverkskarta som kommer att vara användbar för angriparen. Först maskeras de faktiska värdena med konsekventa platshållare.

5. Vad gör att en hotjakt anses vara väldesignad?

A) Det börjar med en konkret, testbar hypotes och spåret som hittats bekräftas av råbevis ✔
B) Det börjar med att säga till den artificiella intelligensen 'hitta om det finns en angripare i mitt nätverk'
C) Deklarerar automatiskt varje onormal/sällsynt händelse som hittas som en attack
D) Det fungerar bara när ett larm kommer, det är inte proaktivt

Förklaring: En bra hotjakt börjar inte med ett larm, utan med en konkret och testbar hypotes som kan eller kanske inte visar sig vara sann (t.ex. "Ansluter konto X till fler än 50 interna IP-adresser under icke-kontorstid"). En vag fråga som "Finns det något dåligt i mitt nätverk" kan inte testas och lämnar AI:n att gissa. Spåret som hittats anses inte vara ett hot förrän det har verifierats med råbevis.

6. En sårbarhet har ett CVSS-värde på 9,1 på en isolerad testserver på det interna nätverket; I samma lista, CVSS 7.5 på en server öppen för internet, men det finns en annan sårbarhet i KEV-listan (som faktiskt utnyttjas). Vad är korrekt prioritering?

A) Den med högsta CVSS (9.1) patchas alltid först
B) Sårbarheten i 7.5 på Internet och KEV-listan tas vidare; CVSS är inte det enda kriteriet, exponering och faktisk övergrepp är avgörande ✔
C) Båda lappas samtidigt och med samma prioritet, distinktion är onödig
D) Ingen av dem är patchad eftersom det finns en sårbarhet i testservern

Förklaring: CVSS ställer inte enbart prioriteringar; faktisk risk bestäms av EPSS (sannolikhet för exploatering), KEV (faktisk exploatering) och organisatorisk kontext (exponering, kritikalitet, kompenserande kontroll). Internet-exponerad och faktiskt utnyttjad (KEV) sårbarhet förhindrar isolerad och låg sannolik hög-CVSS-sårbarhet.

7. I en incidentrespons säger artificiell intelligens 'Trafik som kommer från IC_HOST_7 är misstänkt, isolera denna server'. IC_HOST_7 är institutionens huvudsakliga autentiseringsserver. Vad ska analytikern göra?

A) Artificiell intelligens isolerar omedelbart servern eftersom den säger så
B) Överlåter isoleringsbeslutet helt och hållet till artificiell intelligens
C) Utvärdera först verksamhetens påverkan och orsaken till trafik; Den isolerar inte kritisk infrastruktur utan att mäta dess påverkan och fattar beslutet som analytiker ✔
D) Isolerar servern och tar sedan bort alla loggar

Beskrivning: Isolering är ett kritiskt beslut som är svårt att vända och kan leda till affärsavbrott; kan inte överföras till artificiell intelligens. Att isolera autentiseringsservern kan stoppa alla anställda från att logga in. Analytikern måste först utvärdera affärseffekten och orsaken till trafiken (kan vara en legitim transaktion), fatta beslutet själv; Förslaget om artificiell intelligens bör inte genomföras som en order.

8. I en incident med ransomware vill teamet bygga om en drabbad maskin för att snabbt rengöra den; men det finns kriminaltekniska bevis (minnesdumpning, angriparverktyg) på maskinen som ännu inte har samlats in. Vad är rätt tillvägagångssätt?

A) Maskinen installeras omedelbart igen; bevis är irrelevant
B) Artificiell intelligens efterfrågas för "snabbaste rengöring" och instruktionen tillämpas blint.
C) Maskinen stängs av och slängs eftersom bevisen redan finns i loggen.
D) Först tas den rättsmedicinska bilden och minnesdumpen och bevisningen bevaras, sedan utförs rengöring/återställning ✔

Förklaring: Återhämtningshastigheten kan inte övertrumfa bevisbevarande. Om du installerar om maskinen utan att samla in bevis förstörs vårdkedjan och lamslår rättsprocessen. Först tas en rättsmedicinsk bild och minnesdump, sedan utförs rengöring/återställning. Kriminaltekniska åtgärder delegeras inte till AI.

9. Vilket är ett av de mest pålitliga lagren av teknisk verifiering när man analyserar ett misstänkt nätfiske-e-postmeddelande och hur ska det bekräftas?

A) SPF/DKIM/DMARC resulterar i e-postrubriker; Bekräftat från den råa titeln, inte från AI:s sammanfattning ✔
B) Färg och typsnitt på e-postmeddelandet; bestäms av visuell design
C) Klicka på den misstänkta länken på livesystemet och titta på sidan som öppnas.
D) Enbart artificiell intelligens säger "nätfiske" är tillräckligt bevis

Förklaring: SPF/DKIM/DMARC-resultat i e-postrubriker är starka indikatorer på huruvida e-postmeddelandet faktiskt kommer från domänen den gör anspråk på; Om alla tre misslyckas och avsändaren förfalskar domänen blir misstanken starkare. Detta bör dock bekräftas från den råa titeln och inte från sammanfattningen av AI. Dessutom klickas aldrig misstänkta länkar på livesystemet.

10. I en kodgranskning föreslog AI en fix för en XSS-sårbarhet och sa "det stänger sårbarheten". Vad ska analytikern/utvecklaren göra?

A) Anser att fixen är tillförlitlig och sätter den direkt i produktion
B) Granska korrigeringen, bekräftar att den faktiskt stänger sårbarheten och inte introducerar nya sårbarheter/buggar, och skriver ett test; Först då hamnar den i lager ✔
C) Eftersom han inte är säker, skriver han om hela filen till den artificiella intelligensen och använder den.
D) Tillämpar fixen men klarar utan att skriva några test

Förklaring: Den fix som föreslås av AI är inte automatiskt säker; Det kanske inte stänger sårbarheten helt, det kan rensa fel lager, eller det kan introducera en ny sårbarhet/funktionsfel. Varje patch granskas, utvärderas om den faktiskt stänger sårbarheten och om den introducerar nya problem, och positiva och negativa testfall skrivs; Först då kommer den in i lagret.

11. När man analyserade en attack sa den artificiella intelligensen "det här är definitivt APT-Dark Eagle-gruppens arbete". Vad är rätt tillvägagångssätt när det gäller hotintelligens?

A) Acceptera referensen som den är och skriv den i rapporten som "definitiv förövare"
B) Han bygger hela sitt försvar utifrån den gruppen utan att någonsin ifrågasätta gruppnamnet.
C) Använder språket "överensstämmande med tekniker" snarare än exakt attribution, verifierar gruppen i kända källor och tar hänsyn till möjligheten till tillverkning ✔
D) Citering är alltid onödigt, det beaktas inte alls

Förklaring: Grupptillskrivning är det svåraste och mest inexakta området för intelligens; AI kan till och med skapa ett bandnamn som inte finns. Istället för en exakt referens används språket "kompatibelt med dessa tekniker" och gruppnamnet bekräftas i kända underrättelsekällor. Dessutom är försvaret inte baserat på kortlivade IOC utan på permanent TTP-detektering.

12. I ett utkast till incidentrapport skrev AI meningen "angriparen var troligen inne i tre veckor och exfiltrerade kunddata"; medan det inte finns några avgörande loggbevis som stödjer dessa påståenden. Vad ska analytikern göra?

A) Lämnar meningen som den är eftersom den är dramatisk och imponerande
B) Lämnar meningen men lägger till 'artificiell intelligens skrev' i slutet
C) Skriver ut hela rapporten till den artificiella intelligensen och undertecknar den utan att verifiera den.
D) Rättar påståenden baserat på bevis; Gör skillnaden mellan "möjligt/bevisat/under utredning" och extraherar det definitiva påståendet utan bevis ✔

Kommentar: I en formell säkerhetsrapport ska varje påstående vara underbyggt och "sannolikt" ska aldrig förväxlas med "bevisat". Ett påstående utan bevis har juridiska, ekonomiska och anseende konsekvenser. Analytikern bör korrigera meningen i enlighet med bevisen (skriv till exempel datumet för första åtkomst upptäckt och säg "inga avgörande bevis hittades, utredning pågår" för dataläckan).

13. En chef vill profilera all aktivitet hos en anställd från säkerhetsloggar med artificiell intelligens för att förstå om han är "lojal" eller inte. Vad ska en säkerhetsspecialist göra?

A) Avvisar begäran och hänvisar den till lämplig kanal (HR/juridisk/definierad utredning); säkerhetsdata är inte ett sätt för personlig övervakning ✔
B) Skapar och levererar profilen eftersom chefen begär det
C) Det extraherar bara några loggar och ger en delprofil
D) Få profilen skapad av artificiell intelligens eftersom ansvaret övergår till artificiell intelligens

Beskrivning: Säkerhetsdata samlas in för säkerhetsändamål; Att spåra/profilera en person är missbruk, övergår i personövervakning och bryter mot KVKK. Experten bör avslå denna begäran och hänvisa den till lämplig kanal (HR, juridisk, en definierad och legitim utredningsram). Goodwill eller chefens önskan motiverar inte denna gräns.

14. En SOC bestämmer vilka steg i säkerhetsarbetsflödet som ska automatiseras. Vilken är den bästa principen för automatisering?

A) De högsta riskbesluten bör automatiseras först så att det inte finns någon mänsklig inblandning
B) Lågrisk/reversibla steg är automatiserade; hög risk/irreversibla steg kvarstår vid den mänskliga dörren och varje automation har ett sätt att ångra ✔
C) Alla SOC bör vara helt automatiserade och självrevision är onödig
D) Automatiserade åtgärder behöver inte ångras eftersom AI inte gör misstag

Förklaring: Lågrisk, repetitiva och reversibla steg (logginsamling, larmberikning) kan automatiseras; Högrisk, irreversibla och bedömningskrävande steg (serverisolering, produktionspatchning, officiell notifiering) passerar genom den mänskliga dörren. Dessutom måste varje automatisk åtgärd ha snäva kriterier och ett sätt att ångra. Automatisering tar inte bort ansvaret, det påskyndar bara det.