Hendelsesresponsmønstre
Lær mer om Well-Architected Trust → Sikkerhetshendelsesrespons
Sikkerhetshendelser vil skje til tross for preventive tiltak. Trust arkitektur krever utforming for detekterbarhet, rask respons, forensisk etterforskning og grasiøs gjenoppretting. Denne siden konsoliderer hendelsessvarmønstre fra Trust Hendelsessvar-del, som dekker deteksjonsarkitektur, svarprosedyrer, rettsmedisinske funksjoner og læring etter hendelse.
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Hendelsesovervåking | ✅ Aktiver hendelsesovervåking som fanger opp påloggingsmønstre, massedataeksporter, tillatelsesendringer og API-aktivitet med ruting til SIEM-plattformer for oppbevaring som overskrider innebygde oppbevaringsgrenser |
| Transaksjonssikkerhetspolicyer | ✅ Konfigurer policyer som evaluerer hendelser i sanntid for å blokkere mistenkelige handlinger, kreve gradvis godkjenning eller utløse varsler basert på grunnleggende virkemåter |
| Revisjonsspor for oppsett | ✅ Overvåk administrative konfigurasjonsendringer som aktiverer deteksjon av uautoriserte endringer med 180-dagers oppbevaring |
| Tilpasset programlogging | ✅ Implementer sikkerhetsrelevant hendelseslogging i Apex for å fange opp godkjenningsfeil, autorisasjonsnektinger og mistenkelige inndatamønstre |
| Overvåking av tilstandssjekk | ✅ Konfigurere automatisk deteksjon av konfigurasjonsavvik fra sikkerhetsstandarder som kan indikere uautoriserte endringer |
| SIEM-integrering | ✅ Rut hendelsesovervåkingslogger til SIEM-plattformer for virksomheter for korrelasjon med telemetri for virksomhetssikkerhet og atferdsanalyse |
| Varselregler | ✅ Utform varsleregler som oppdager mistenkelige mønstre (masseadgang utenfor åpningstider, pålogging fra nye geografiske områder, rask eskalering av tillatelser) med grunnleggende virkemåter for å minimere usanne positive |
| Virkemåteanalyse | ✅ Opprett atferdsstandarder som aktiverer avvikdeteksjon for uvanlige datatilgangsvolumer, administrativ aktivitet utenfor arbeidstiden og API-forbruksmønstre |
| Deteksjon med flere kanaler | ✅ Implementer deteksjon via Hendelsesovervåking, Transaksjonssikkerhet, Revisjonsspor for oppsett, tilpasset logging og Tilstandssjekk som gir flere uavhengige deteksjonssignaler |
| Uendelig logglagring | ✅ Rut logger til uforanderlig ekstern lagring som angripere ikke kan endre selv med administrativ Salesforce-tilgang, slik at forensisk bevisintegritet sikres |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Bare innebygd loggoppbevaring | ⚡️ Avhengig bare av innebygde Salesforce-revisjonssporbevaringsvinduer (innebygde grenser for hendelsesovervåking, 180 dagers revisjonsspor for oppsett) uten ekstern arkivering, oppdager logger som er utløpt når undersøkelse krever historisk analyse |
| Ingen grunnleggende virkemåter | ⚡️ Har ingen grunnleggende virkemåter for avvikdeteksjon, genererer overdreven antall falske positive varsler som lærer opp sikkerhetsteam til å ignorere varsler |
| Ingen SIEM-integrering | ⚡️ Manglende SIEM-integrering for virksomheter, manglende korrelasjonsmuligheter med sikkerhetstelemetri fra andre systemer som vil avdekke bredere kompromissmønstre |
| Manuell logggjennomgang | ⚡️ Avhengig av periodisk manuell logggjennomgang i stedet for automatisert varsel, oppdagelse av hendelser uker eller måneder etter at de oppstod når skaden er omfattende |
| Ingen transaksjonssikkerhetspolicyer | ⚡️ Har ingen sanntids transaksjonssikkerhetspolicyer, mangler mulighet til å blokkere mistenkelige handlinger som hindrer skade før den oppstår |
| Ufullstendig dekning | ⚡️ Overvåker bare delsett av sikkerhetsrelevante hendelser (pålogging, men ikke datatilgang, konfigurasjonsendringer, men ikke tillatelsesendringer) som oppretter blindflekker |
| Varseltretthet | ⚡️ Generere for mange falske positive varsler uten justering, lære opp team for å ignorere varsler, inkludert legitime sikkerhetshendelser |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Isolasjonsgrenser | ✅ Utformingsarkitektur slik at kompromitterte komponenter kan isoleres via oppheving av tillatelsessett, endringer i IP-restriksjoner eller øktavslutning uten å forstyrre viktige forretningsfunksjoner |
| Øktbehandling | ✅ Implementer funksjonalitet for rask øktavslutning for kompromitterte kontoer, inkludert tving avlogging og ugyldiggjøring av økter på tvers av alle aktive økter |
| Opphevelse av tillatelse | ✅ Gi rettigheter via tillatelsessett i stedet for standardprofiler, slik at oppheving skjer raskt: fjerning av tillatelsessettildelingen opphever tilgang når ingen profil eller annen tildeling uavhengig gir den samme tillatelsen |
| IP-restriksjoner | ✅ Konfigurer IP-områder for pålogging på profilnivå for privilegerte kontoer slik at pålogginger fra andre adresser avslås direkte, noe som aktiverer rask isolering på nettverksnivå til kjente administrative steder |
| Frysing av brukerkonto | ✅ Implementer prosedyrer for frysing av kontoer som hindrer godkjenning samtidig som data beholdes for undersøkelse uten å slette den kompromitterte kontoen |
| API-tilgangskontroller | ✅ Utform API-godkjenning med tokenopphevingsfunksjonalitet som muliggjør rask isolering av kompromitterte integrasjonskontoer |
| Isolasjon for flere organisasjoner | ✅ For aktiva med høy verdi evaluerer du flerorganisasjonsarkitektur som gir sterkest isolasjon for kritiske komponenter på bekostning av økt driftskompleksitet |
| Prosedyrer for hasteavbruddglass | ✅ Vedlikeholde dokumenterte tilgangsprosedyrer for administrative tilgang i hasteavtaler med revisjon og validering etter bruk |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Ingen isolasjonsgrenser | ⚡️ Manglende arkitektoniske isolasjonsgrenser som krever fullstendig systemavslutting for å inneholde eventuelle kompromisser, som forstyrrer alle forretningsfunksjoner |
| Overdrevent tillatte tilgang | ⚡️ Gi omfattende Endre alle data-tillatelser som hindrer oppheving av detaljerte rettigheter uten å avbryte flere forretningsprosesser |
| Delte tjenestekontoer | ⚡️ Bruk av én delt API-bruker- eller Integrasjonsbruker-konto på tvers av flere systemer for å hindre isolering av bestemte kompromitterte integrasjoner uten å bryte alle integrasjoner |
| Ingen IP-restriksjoner | ⚡️ Har ingen IP-tillatelsesliste for privilegerte kontoer, mangler kapasitet for oppbevaring på nettverksnivå når kontoer kompromitteres |
| Ingen øktbehandling | ⚡️ Mangler øktavslutningsfunksjonalitet som krever tilbakestilling av passord som eneste måte å tvinge avlogging på, og innfører forsinkelser i viktige svarvinduer |
| Ingen hasteprosedyrer | ⚡️ Har ingen dokumenterte bruddglass- eller hasteadgangsprosedyrer, improvisere viktige beslutninger under press under aktive hendelser |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Hendelsesovervåkingslogger | ✅ Registrer detaljerte aktivitetslogger, inkludert brukerhandlinger, API-kall, godkjenningshendelser og datatilgangsmønstre med tilstrekkelige detaljer for kriminalteknisk analyse |
| Feltrevisjonsspor | ✅ Aktiver Feltrevisjonsspor som beholder datahistorikkendringer for Begrensede og Konfidensielle felt med oppbevaringssamsvarende lovpålagte krav (støtter ubestemt oppbevaring, bekrefter den nødvendige perioden i forhold til den aktuelle forskriften) |
| Uendelig lagring | ✅ Rut logger til eksternt uforanderlig lagringsplass som angripere ikke kan endre, slik at forensisk bevisintegritet sikres gjennom hele undersøkelsen |
| Revisjonsspor for oppsett | ✅ Behold administrativ konfigurasjonsendringshistorikk slik at det kan undersøkes uautoriserte systemendringer med 180 dagers oppbevaring |
| Omfangsvurdering | ✅ Utform tillatelsesmodeller og datatilgangskontroller som muliggjør rask vurdering av dataversjonsomfang basert på kompromitterte kontoprivilegier |
| Endrekorrelasjon | ✅ Opprettholde korrelasjon mellom endringer i konfigurasjonen for Revisjonsspor for oppsett og aktivitetsmønstre for hendelsesovervåking som muliggjør undersøkelse av angriperteknikker |
| Datatilgangslogging | ✅ Logg all tilgang til Begrensede og konfidensielle data som muliggjør undersøkelse av hvilke data som ble eksponert i kompromissperioden |
| Integrasjonsrevisjonsspor | ✅ Registrer API-godkjennings-, autorisasjons- og datautvekslingsmønstre for integrerte systemer som muliggjør undersøkelse av kompromiss på tvers av systemer |
| Bevisbevaring | ✅ Rut logger og revisjonsspor kontinuerlig til uforanderlig ekstern lagring slik at rettsmedisinsk bevis bevares og er tilgjengelig når en hendelse undersøkes |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Endringsbar logglagring | ⚡️ Lagring av logger bare i Salesforce der angripere med administrativ tilgang kan slette eller endre rettsmedisinsk bevis |
| Ikke tilstrekkelige loggdetaljer | ⚡️ Registrering af begivenheder på højt niveau uden tilstrækkelige detaljer til undersøgelse (login registreret, men ikke IP-adresse, dataadgang registreret, men ikke specifikke registreringer) |
| Ingen datatilgangslogging | ⚡️ Mangler detaljert logging av tilgang til begrensede og konfidensielle data, kan ikke vurdere dataversjonsomfang under bruddvarsel |
| Feltrevisjonsspor mangler | ⚡️ ikke aktiverer Feltrevisjonsspor for sensitive felt, kan ikke finne ut hvilke dataverdier som ble eksponert under kompromiss |
| Ingen endringskorrelasjon | ⚡️ Har ingen korrelasjonsfunksjonalitet mellom endringer i konfigurasjonen for Revisjonsspor for oppsett og påfølgende aktivitetsmønstre for hendelsesovervåking |
| Slettet revisjonshistorikk | ⚡️ Tillat at revisjonshistorikk utløper før det regulatoriske oppbevaringsminimumet som er angitt av de regulerende forskriftene for distribusjonen, noe som fører til overtredelser av samsvar |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Mål for gjenopprettingstid | ✅ Definer og test Gjenopprettingstidsmål (RTO) og Gjenopprettingspunktmål (RPO) for sikkerhetshendelsesscenarier, ikke bare katastrofegjenopprettingsscenarier |
| Testede gjenopprettingsprosedyrer | ✅ Dokumentgjenopprettingsprosesser for kompromitterte kontoer, massedataekspiltrering, uautoriserte distribusjoner, rettighetseskalering og pakkekompromittering med kvartalsvis testing |
| Sikkerhetskopivalidering | ✅ Valider sikkerhetskopienes integritet regelmessig for å sikre at gjenopprettingsfunksjonaliteten fungerer under sikkerhetshendelser, ikke bare ved driftsfeil |
| Oppsummeringsfunksjoner | ✅ Utform distribusjonslinjer under behandling med testede tilbakeføringsprosedyrer for uautoriserte kodedistribusjoner eller skadelige konfigurasjonsendringer |
| Rotering av legitimasjon | ✅ Implementer hurtige legitimationsoplysningsroteringsprocedurer for kompromitterede integration-konti, API-brugere og navngivne legitimationsoplysninger |
| Tillatelsesgjenoppretting | ✅ Dokumenter prosedyrer for gjenoppretting av riktig tilgang etter for store isoleringshandlinger under hendelsessvar |
| Datagjenoppretting | ✅ Utform datagjenopprettingsfunksjoner som håndterer datakorrumpering eller sletting som følge av sikkerhetshendelser, forskjellig fra katastrofegjenoppretting |
| Service Continuity (Tjenestekontinuitet) | ✅ Arkitekter løsninger slik at prosedyrer for respons på sikkerhetshendelser opprettholder kontinuitet for viktige forretningsfunksjoner under undersøkelse og rettelse |
| Gjenopprettingsvalidering | ✅ Test gjenopprettingsprosedyrer kvartalsvis som validerer om gjenopprettede systemer fungerer riktig og at kompromiss ikke har beholdt seg gjennom gjenoppretting |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Ikke-testede prosedyrer | ⚡️ ha dokumenterte gjenopprettingsprosedyrer som aldri er testet gjennom øvelser, og oppdage under faktiske hendelser at prosedyrer er ufullstendige eller feil |
| Ingen RTO/RPO for sikkerhet | ⚡️ Definere gjenopprettingstidsmål bare for katastrofegjenoppretting uten å vurdere sikkerhetshendelsesscenarier som krever forskjellige gjenopprettingsprosedyrer |
| Ingen tilbagerulingsmulighet | ⚡️ Mangler utrullingsprosedyrer for distribusjon for ikke-godkjente kodedistribusjoner, som krever full omutvikling for å fjerne skadelige endringer |
| Uvaliderte sikkerhetskopier | ⚡️ Test aldri gjenoppretting av sikkerhetskopier, oppdager under hendelser at sikkerhetskopier er ødelagte eller ufullstendige |
| Ingen roteringsprosedyrer for legitimasjon | ⚡️ Har ingen prosedyrer for rask legitimasjonsrotasjon for kompromitterte integrasjonskontoer, og lar kompromitterte legitimasjoner være aktive under undersøkelsen |
| Manuelle gjenopprettingsprosesser | ⚡️ Avhengig helt av manuelle gjenopprettingsprosedyrer under hendelser, introdusere feil og forsinkelser når hastighet er avgjørende |
| Ingen gjenopprettingstesting | ⚡️ Aldrig validere at gjenopprettede systemer fungerer riktig etter gjenoppretting, og potensielt gjeninnføre kompromiss eller datakontroll |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Kompromittert brukerkontosvar | ✅ Dokumentprosedyrer: fryse bruker, tvinge tilbakestilling av legitimasjon, se gjennom Revisjonsspor for oppsett og datatilgangslogger for kompromissperiode, vurdere omfanget av dataeksponering, utføre bruddvarsel hvis Begrenset tilgang til data |
| Massedataekspiltreringssvar | ✅ Dokumentprosedyrer: oppheve økt umiddelbart, begrense tillatelser, identifisere berørte poster og klassifiseringsnivåer, utføre varsel om lovbrudd innenfor tidslinjen som de regulerende forskriftene angir for distribusjonen |
| Respons på uautorisert kodedistribusjon | ✅ Dokumentprosedyrer: rulle tilbake distribusjon umiddelbart, revidere alle endringer fra kompromittert legitimasjon, se gjennom pipelinens sikkerhet for å omgå godkjenning, skanne distribuert kode for faste bakdører |
| Respons for priviligeringseskalering | ✅ Dokumentprosedyrer: oppheve eskalerte rettigheter umiddelbart, revidere aktiviteter utført med økt tilgang, undersøke hvordan eskalering omgått godkjenningskontroller, implementere kompenseringskontroller |
| Svar på kompromiss for AppExchange | ✅ Dokumentprosedyrer: isolere pakketillatelser, vurdere data som pakken har tilgang til, evaluere pakkeutskiftingsalternativer, dokumentere lærdommer fra evalueringskriterier for pakker |
| Deteksjonssignaler | ✅ Konfigurer overvåking for å oppdage hvert scenario: påloggingsavvik for kompromitterte kontoer, eksportvolum for rapporten for eksfiltrering, distribusjonsovervåking for uautorisert kode, overvåking av endring av tillatelser for eskalering |
| Skrivebordsøvelser | ✅ Utfør tabelløvelser for å teste responsprosedyrer for plattformspesifikke scenarier som validerer teamets klargjøring og prosedyrefullstendighet |
| Svarautomatisering | ✅ Sanntids transaksjonssikkerhetspolicyer blokkerer automatisk mistenkelige handlinger, krever gradvis godkjenning eller varsler respondenter om deteksjonssignaler med høy konfidens, noe som gir automatisert inneslutning som reduserer responstiden |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Bare generelle svarplaner | ⚡️ ha bare generelle hendelsessvarprosedyrer uten Salesforce-spesifikk veiledning, improvisere plattformspesifikke handlinger under aktive hendelser |
| Ingen deteksjonskonfigurasjon | ⚡️ Har ingen overvåking konfigurert for å oppdage plattformspesifikke scenarier (masseeksport, rettighetseskalering, uautorisert distribusjon), oppdage hendelser gjennom brukerrapporter eller revisjoner |
| Ingen skrivebordsøvelser | Aldri gjennomføre bordopplæringer som validerer teamets kjennskap til plattformspesifikke responsprosedyrer, oppdager Knowledge gap under faktiske hendelser |
| Ingen automatisering | ⚡️ Fullt manuelt svar for alle hendelser uten sanntids transaksjonssikkerhetspolicyer for automatisert begrensning, som introduserer forsinkelser når umiddelbar blokkering kan redusere skade |
| Svarspillebøker mangler | ⚡️ Mangler dokumenterte svarspillebøker for vanlige scenarier (kompromittert brukerkonto, datautfiltrering, uautorisert kodedistribusjon) |
| Prosedyrer for varsling om ingen brudd | ⚡️ Har ingen prosedyrer for krav til varsling om lovbrudd, sliter med å forstå forpliktelser under faktiske hendelser når tidslinjene er korte |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Kommunikasjon utenfor område | ✅ Opprett kommunikasjonskanaler som ikke er avhengige av potensielt kompromitterte systemer (telefontrær, eksterne meldingsplattformer) for koordinering av svar |
| Eskaleringsprosedyrer | ✅ Dokumenter eskaleringsbaner fra første deteksjon til varsel fra leder med kontaktinformasjon og eskaleringskriterier |
| Varselmaler | ✅ Vedlikehold forhåndsutformede varselmaler for vanlige hendelsestyper som muliggjør rask kommunikasjon til interessenter, kunder og regulatorer |
| Interessentidentifikasjon | ✅ Identifisere interessenter som trenger varsel for forskjellige hendelsestyper, inkludert ledere, juridiske, samsvarsansvarlige, berørte brukere og myndigheter |
| Tidslinjer for lovpålagte varsler | ✅ Dokumenter hver jurisdiksjons krav til lovpålagte varsler, bekreftet mot de lovpålagte forskriftene for distribusjonen, med prosedyrer som sikrer rettidig overholdelse |
| Intern koordinasjon | ✅ Utform hendelseskoordinasjonsprosedyrer som spesifiserer roller og ansvarsområder (hendelsesleder, teknisk leder, kommunikasjonsleder, juridisk kontakt) |
| Ekstern koordinasjon | ✅ Opprett prosedyrer for koordinering med Salesforces kundestøtte, eksterne forensiske etterforskere, juridiske rådgivere og rettshåndhevende etter behov |
| Statuskommunikasjon | ✅ Implementer regelmessig kommunikasjonskadens for status under aktive hendelser for å holde interessenter informert uten overveldende undersøkelsesteam |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Ingen utenforliggende kommunikasjon | ⚡️ Avhengig utelukkende av potensielt kompromitterte e-postmeldinger eller interne meldinger for hendelseskoordinasjon, tap av kommunikasjonskapasitet når primære kanaler kompromitteres |
| Uklare eskaleringsbaner | ⚡️ Har ingen dokumenterte eskaleringsprosedyrer, noe som fører til forsinkelser og forvirring om hvem som skal varsles og når |
| Ingen varselmaler | ⚡️ Improvisere hendelsesvarsler under aktive hendelser under tidstrykk, noe som fører til ufullstendig eller feil kommunikasjon |
| Lister over manglende interessenter | ⚡️ Har ingen forhåndsidentifiserte interessentlister, oppdager under hendelser at viktige parter (juridiske, samsvarsansvarlige, ledere) ikke ble varslet |
| Ingen regulatorisk tidslinjeforståelse | ⚡️ være uvitende om de lovpålagte varslingene som gjelder for distribusjonen din under hendelsessvar, manglende tidsfrister og opprettelse av flere overtredelser |
| Tvetydige roller | ⚡️ Har uklare hendelsessvarroller og ansvarsområder, noe som fører til forvirring om hvem som har myndighet til å ta begrensningsbeslutninger |
| Ingen eksterne koordineringsprosedyrer | ⚡️ Har ingen etablerte relasjoner eller prosedyrer for å engasjere Salesforces kundestøtte, rettsmedisinske etterforskere eller rettshåndheving når det er nødvendig |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Skamløs kultur | ✅ Fokusere etter hendelsesgjennomganger på systemforbedringer i stedet for å klandre enkeltpersoner, slik at organisasjonslæring er mulig uten frykt for konsekvenser |
| Hendelsestidslinjedokumentasjon | ✅ Dokumentere fullstendig hendelsestidslinje, inkludert første kompromiss, deteksjon, svarhandlinger og løsning med presise tidsstempler |
| Kontrollere feilanalyse | ✅ Identifisere hvilke forebyggende og deteksjonskontroller som mislyktes med å hindre eller oppdage hendelsen, og informere om arkitektoniske forbedringer |
| Dokumentasjon for arkitektonisk svakhet | ✅ Dokumentarkitektoniske svakheter avslørt av hendelsen i ADR-er (Architecture Decision Records) som fanger opp sikkerhetsendringer |
| Prioritering av utbedring | ✅ Prioriter tiltak basert på potensielt risikoreduksjon, håndtere rotårsaker i stedet for symptomer |
| Læringsdeling | ✅ Del erfaringer på tvers av team og forretningsenheter for å hindre lignende hendelser i andre deler av organisasjonen |
| Oppdateringer av deteksjonsregler | ✅ Oppdater deteksjonsregler og grunnleggende virkemåter basert på angrepsteknikker observert under undersøkelsen |
| Responsprosedyreforbedring | ✅ Oppdater hendelsessvarprosedyrer basert på hva som fungerte og hva som ikke fungerte under faktisk hendelsessvar |
| Sporing av målinger | ✅ Spor middeltid til deteksjon (MTTD), middeltid til svar (MTTR) og omfang av innvirkning over tid, identifisere trender som krever arkitektoniske investeringer |
| Se gjennom kadens | ✅ Utfør en rettidig post-hendelsesgjennomgang mens detaljene forblir friske og det finnes et momentum for forbedring |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Hoppede vurderinger | ⚡️ Hopp over etter hendelsesgjennomganger, gå direkte til neste hendelse uten å fange opp erfaringer eller arkitektoniske forbedringer |
| Skjul kultur | ⚡️ Fokusere etter hendelsesgjennomganger på individuell skyld i stedet for systemforbedringer, forårsaker hendelsesskjul og hindrer organisasjonslæring |
| Ingen arkitekturdokumentasjon | ⚡️ Mislykket dokumentering av sikkerhetsarkitekturendringer som er drevet av hendelseslæring i ADR-er (Architecture Decision Records) |
| Symptombehandling | ⚡️ Behandler bare hendelsessymptomer (komprimert passord) uten å rette rotårsaker (fravær av MFA), slik at lignende angrep lykkes |
| Deling uten læring | ⚡️ Holde hendelseslæring i svarteam i stedet for deling på tvers av organisasjoner, slik at lignende hendelser kan skje i andre forretningsenheter |
| Ingen deteksjonsoppdateringer | ⚡️ Mislykket oppdatering av deteksjonsregler eller atferdsstandarder basert på observerte angrepeteknikker, og fortsatt sårbar for lignende angrep |
| Ingen sporing av målinger | ⚡️ Ikke spore middeltid til deteksjon (MTTD), middeltid til svar (MTTR) eller omfangstrender, manglende salgsmuligheter for å identifisere systemiske svakheter |
| Forsinkede vurderinger | ⚡️ Utføre etterhendelsesgjennomganger måneder etter hendelsesløsning når detaljer glemmes og forbedringsdynamikk mistes |
| Følg gjennom ingen rettelse | ⚡️ Identifisere forbedringer under etter hendelsesgjennomgang, men mislykkes i å implementere dem, slik at lignende hendelser kan gjentas |