Programvaresårbarheter: typer, risikoer og hvordan man håndterer dem

Informatec Digital » Ressurser » Programvaresårbarheter: typer, risikoer og hvordan håndtere dem

Programvaresårbarheter er det svake leddet i de fleste moderne digitale systemer: en liten feil i koden, en feilkonfigurasjon eller en uoppdatert oppdatering kan åpne døren for datainnbrudd, ransomware eller alvorlige tjenesteforstyrrelser. Selv om mange organisasjoner allerede har antivirusprogramvare, brannmurer og andre forsvarslag, kan all den innsatsen bli kompromittert i løpet av minutter hvis programvaren er sårbar.

Alt som er designet av mennesker er utsatt for feil , og programvare er intet unntak. Fra webapplikasjoner og API-er til operativsystemer, fastvare og kjernedrivere, kan alle disse komponentene inneholde utnyttbare sårbarheter. Å forstå hva sårbarheter er, de forskjellige typene som finnes, hvordan man oppdager dem, og fremfor alt hvordan man fikser og håndterer dem raskt, er nøkkelen til å unngå store problemer som kan føre til tap på millioner av dollar, straffer eller omdømmeskade.

Hva er en programvaresårbarhet, og hvorfor er det så viktig?

Innen informatikk er en sårbarhet en svakhet i et system, en applikasjon, en enhet eller en prosess som en angriper kan utnytte til å skade, endre eller få tilgang til informasjon eller tjenester uten autorisasjon. Denne svakheten kan ligge i koden (programmeringsfeil), maskinvaren, konfigurasjonen, interne prosedyrer eller til og med menneskelig atferd.

En sårbarhet i seg selv er ikke et angrep ; det er en latent risiko. Problemet oppstår når noen klarer å utnytte den, enten det er med vilje (en nettkriminell som utnytter den) eller ved et uhell (en bruker som forårsaker et krasj ved å legge inn uventede data). En enkel, dårlig administrert bufferoverløp kan utløse alt fra et tjenestenektangrep til utførelse av vilkårlig kode.

Konsekvensene av en utnyttet sårbarhet kan være enorme : tyveri eller eksponering av personlige og økonomiske data, distribusjon av skadelig programvare, datakryptering via ransomware, forstyrrelse av kritiske tjenester eller til og med kompromittering av infrastruktur på høyt nivå. Når det gjelder webapplikasjoner, kan for eksempel en SQL-injeksjon eller et XSS-angrep bli inngangsporten til resten av bedriftsnettverket.

Å oppdage og fikse sårbarheter tidlig er mye billigere enn å reagere etter en hendelse. Å integrere sikkerhet i programvareutviklingslivssyklusen (SDLC) og ta i bruk DevSecOps-lignende tilnærminger lar deg "flytte sikkerheten til venstre": å finne feil i tidlige design- og kodefaser, når det å fikse dem er billigere enn å oppdatere systemer som allerede er implementert i produksjon.

En sårbarhet kan manifestere seg på mange forskjellige måter . Det kan være en tjeneste som lytter på en unødvendig port, et åpent Wi-Fi-nettverk, en eksponert brannmurport, en ikke-eksisterende passordpolicy eller fasiliteter uten fysisk tilgangskontroll. Alle disse situasjonene, selv om de ikke tilsynelatende er rent "programvarerelaterte", er en del av settet med sårbarheter som en angriper kan utnytte for å oppnå sitt mål.

Hovedtyper av programvaresårbarheter

Programvaresårbarheter omfatter flere kategorier , fra klassiske minnefeil til logiske feil i autentisering eller mangler i arkitekturdesign. Nedenfor er noen av de vanligste og mest relevante typene i dag, hvorav mange gjenspeiles direkte i lister som OWASP Topp 10.

Nulldagssårbarheter

En nulldagssårbarhet er en feil som er ukjent for produsenten, og som allerede utnyttes av angripere før en oppdatering er tilgjengelig. Tilfeller som Log4j-sårbarheten viste hvor farlige disse situasjonene kan være: millioner av systemer ble eksponert mens leverandører kjempet for å forberede rettelser.

I en nulldagssårbarhet har angripere en midlertidig fordel fordi de har en fungerende utnyttelse, mens forsvarerne forblir uforberedte. I dette scenariet er atferdsbasert deteksjon, trafikkfiltrering, nettverkssegmentering og retningslinjer for minste rettigheter avgjørende for å redusere virkningen inntil offisielle oppdateringer slippes.

Ekstern kodekjøring (RCE)

En sårbarhet for ekstern kjøring av kode lar en angriper utføre ondsinnede instruksjoner på et målsystem uten fysisk tilgang. Det er en av de mest kritiske kategoriene fordi den, når den utnyttes, kan brukes til å installere skadelig programvare, få tilgang til sensitive data, lage bakdører eller pivotere til andre interne systemer.

RCE-er er vanligvis avhengige av andre underliggende sårbarheter , som minneoverløp, injeksjoner eller problemer med datadeserialisering. Vellykket utnyttelse resulterer vanligvis i en fullstendig kompromittering av det berørte systemet, spesielt hvis det sårbare programmet kjører med utvidede rettigheter.

Problemer med datavalidering og sanering

Et stort antall angrep stammer fra dårlig validerte inndata . Hvis et program ikke sjekker eller renser dataene det mottar (skjemaer, URL-parametere, overskrifter, JSON osv.), kan en angriper snike inn skadelig innhold som tolkes som uventet kode eller instruksjoner.

Denne kategorien inkluderer flere kjente sårbarheter , som SQL-injeksjon, Cross-Site Scripting (XSS), strengformateringsfeil og visse bufferoverløp. Validering av typer, områder, formater og lengder på alle felt, samt bruk av hvitelister og sikker utarbeidelse av spørringer, er grunnleggende for å minimere disse risikoene og er en del av god sikker utviklingspraksis.

SQL-injeksjon og andre typer injeksjon

SQL-injeksjon (SQLi) er et av de vanligste angrepene mot webapplikasjoner som samhandler med databaser. Det innebærer å sette inn manipulerte SQL-setninger i ubeskyttede inndatafelt (påloggingsskjemaer, søk, filtre osv.) for å tvinge applikasjonen til å utføre spørringer som ikke var ment av utvikleren.

Denne typen sårbarhet lar angripere lese hele tabeller (inkludert passord og kredittkortinformasjon), endre eller slette poster, endre legitimasjon eller gjøre hele databaser ubrukelige. Siden SQL-skjemaer og -spørringer er allestedsnærværende, kan nesten alle SQL-motorer (MySQL, PostgreSQL, SQL Server, Oracle og til og med noen MongoDB-lignende implementeringer som støtter lignende spørringer) bli påvirket hvis koden ikke er ordentlig sikret.

SQL-injeksjoner er ikke begrenset til SQL-injeksjoner . Det finnes også kommandoinjeksjoner i operativsystemer, LDAP-injeksjoner, malinjeksjoner, headerinjeksjoner og usikker deserialisering. De har alle et felles problem: programvaren tolker data som instruksjoner fordi riktige kontroller og separasjon ikke er implementert.

Cross-Site Scripting (XSS) og Cross-Site Request Forgery (CSRF)

Cross-Site Scripting (CSSS) lar en angriper injisere skript i legitime nettsider som andre brukere vanligvis besøker. Hvis applikasjonen ikke filtrerer det viste innholdet på riktig måte, kan det skadelige skriptet stjele økter, fange legitimasjon eller endre nettstedets oppførsel fra offerets nettleser.

Cross-site request forgery (CSRF), derimot, lurer en autentisert brukers nettleser til å utføre uønskede handlinger på et klarert program (for eksempel å endre et passord eller gjøre en overføring) ved å utnytte det faktum at nettleseren automatisk sender øktinformasjonskapsler. Beskyttelsen er avhengig av anti-CSRF-tokens, passende overskrifter og ytterligere verifiseringstiltak.

Bufferoverløp og formateringsfeil

Bufferoverløp er et klassisk sikkerhetsproblem i C og C++ . Det oppstår når et program skriver mer data enn det får plass i et reservert minneområde (buffer), og overskriver tilstøtende områder og potensielt endrer variabler, returadresser eller interne systemstrukturer.

Denne ukontrollerte oppførselen kan føre til krasj, frysing eller i verste fall kjøring av vilkårlig kode. På samme måte kan formateringsfeil i strenger (for eksempel feil bruk av utskriftsfunksjoner med brukerkontrollerte parametere) tillate minnemanipulasjon eller lekkasje av sensitiv informasjon hvis den ikke er nøye programmert.

Feilaktig adgangskontroll og usikker design

Feilaktig tilgangskontroll oppstår når applikasjonen ikke klarer å bekrefte hva hver bruker er autorisert til å gjøre, noe som tillater handlinger eller tilgang som burde begrenses. Dette inkluderer alt fra administrative funksjoner som er synlige for alle autentiserte brukere til API-er som ikke håndhever rollebaserte kontroller.

Usikker design gjenspeiler derimot dypereliggende arkitektoniske feil, ikke bare kodefeil. Dette er problematiske strukturelle beslutninger, som å ikke vurdere lagdeling, ikke inkludere loggings- og sporbarhetsmekanismer, eller ikke planlegge for beskyttelse av sensitive data fra starten av. Å rette opp disse problemene krever vanligvis betydelige endringer i systemets fundament.

Kryptografiske feil og mangel på kryptering

Kryptografiske feil spenner fra bruk av utdaterte algoritmer (som ødelagte chiffer eller usikre hashfunksjoner) til dårlig implementering av protokoller eller feil gjenbruk av nøkler. Alt dette fører til at den teoretiske beskyttelsen som kryptografi tilbyr, forsvinner i praksis.

Fraværet av kryptering er også en sårbarhet i seg selv . Lagring av data i ren tekst i databaser, filer eller sikkerhetskopier, eller manglende kryptering av kommunikasjon mellom klient og server, forenkler arbeidet til en angriper som får tilgang til miljøet eller avlytter nettverkstrafikk.

Svake og dårlig konfigurerte API-er

API-er har blitt en topprioritet innen risikostyring for cybersikkerhet fordi de er den stille inngangsporten til kritiske data og funksjoner. Mange organisasjoner sikrer sine synlige webgrensesnitt, men lar interne, mobile eller tredjeparts API-er være mindre beskyttet.

Typiske API-sårbarheter inkluderer svak autentisering, dårlig autorisasjon, overdreven dataeksponering, altfor detaljerte feilmeldinger og fravær av begrensning av forespørselsfrekvens. Alt dette gjør API-er til en perfekt vektor for å automatisere storskala angrep.

Sårbarheter på grunn av utdatert og uoppdatert programvare

Uoppdatert programvare er sannsynligvis den vanligste akilleshælen i enhver organisasjon. Hver gang en leverandør slipper en sikkerhetsoppdatering og den ikke blir installert, etterlater det en dør åpen med en lås hvis funksjoner allerede er offentlig kjent, ofte dokumentert i databaser som CVE-listen (Common Vulnerabilities and Exposures). Derfor er proaktivt programvarevedlikehold viktig.

Disse uoppdaterte sårbarhetene påvirker alle typer komponenter : operativsystemer, forretningsapplikasjoner, nettlesere, programtillegg, fastvare for nettverksenheter, maskinvaredrivere osv. Jo lenger oppdateringen er uoppdatert, desto større er sannsynligheten for at fungerende utnyttelser vil dukke opp og begynne å bli brukt i stor grad.

Nettkriminelle oppsøker aktivt utdaterte systemer fordi de er mål som krever lite innsats: det er nok å bare skanne IP-områder eller publiserte tjenester for å finne versjoner som er kjent for å være sårbare og iverksette automatiserte angrep, uten behov for kompleks ingeniørkunst.

Hvorfor mange sårbarheter ikke blir oppdatert

Til tross for den åpenbare fordelen med å «alltid oppdatere », møter organisasjoner flere praktiske hindringer: antall oppdateringer, avhengigheter mellom systemer, mangel på tid eller personell og stadig mer distribuerte miljøer.

Blant de vanligste faktorene er logistiske problemer (tusenvis av forskjellige applikasjoner å oppdatere), ressursbegrensninger (overbelastede IT-team, mangel på budsjett), kompleksiteten i sterkt sammenkoblede systemer (en patch kan ødelegge kompatibiliteten), og, mer nylig, vanskeligheten med å administrere patcher på eksterne enheter eller utenfor bedriftsnettverket.

Eldre systemer representerer en spesielt sårbar sak . Mange eldre systemer slutter å motta produsentstøtte, noe som betyr at offisielle oppdateringer ikke lenger er tilgjengelige. De er imidlertid fortsatt viktige for kritiske prosesser, noe som gjør det vanskelig å avvikle dem. I disse tilfellene må tiltak som å isolere dem fra nettverket eller implementere kontrollert virtualisering vurderes.

Risikoer ved uoppdatert programvare

Konsekvensene av å ikke installere sikkerhetsoppdateringer er vidtrekkende . For det første øker de eksponeringen for cyberangrep eksponentielt, for det andre kan de føre til manglende overholdelse av regelverk, og til slutt har de økonomiske og omdømmemessige konsekvenser som kan vare i årevis.

Fra et cybersikkerhetsperspektiv utnyttes uoppdatert programvare til å starte datainnbrudd, ulike skadevareinfeksjoner og store ransomware-kampanjer. Høyprofilerte saker som WannaCry-angrepet utnyttet kjente sårbarheter i uoppdaterte Windows-systemer, noe som påvirket hundretusenvis av datamaskiner over hele verden.

I regulerte sektorer (finans, helsevesen, betalingstjenester) kan vedlikehold av utdaterte systemer være i strid med forskrifter som GDPR, HIPAA eller PCI DSS, som krever implementering av rimelige tiltak for å beskytte data. Straffer kan nå en betydelig prosentandel av den årlige inntekten, i tillegg til omdømmekostnadene forbundet med et offentlig sikkerhetsbrudd.

Den direkte økonomiske skaden fra en uoppdatert sårbarhetshendelse inkluderer hendelsesrespons, rettsmedisinsk analyse, gjenoppretting av sikkerhetskopier, juridisk rådgivning, kundevarsler og potensiell kompensasjon. Dette forverres av tap på grunn av nedetid, kundefrafall og kostnadene ved senere styrking av sikkerhetstiltak.

Andre sårbarhetsområder: maskinvare og menneskelig faktor

Sikkerhet stopper ikke med applikasjonsprogramvare . Maskinvaren som disse applikasjonene kjører på og menneskene som bruker dem er viktige deler av angrepsflaten. En seriøs cybersikkerhetsplan kan ikke ignorere disse elementene.

Maskinvaresårbarheter

Innen maskinvaresektoren stammer mange svakheter fra fabrikkfeil eller dårlig etterfølgende håndtering. Enheter som leveres med standardpassord, utdaterte rutere eller kameraer, forfalsket utstyr eller fastvare med kjente sårbarheter er vanlige eksempler.

Noen vanlige maskinvarerisikoer inkluderer standardpassord som aldri endres, mangel på tiltak mot uautorisert fysisk tilgang, utdatert fastvare, enheter uten offisiell støtte, feilinjeksjonsangrep eller bruk av forfalsket maskinvare med potensielt skadelige modifikasjoner.

Dessuten har mange infrastrukturkomponenter lang levetid og blir foreldet, samtidig som nye trusler dukker opp. Uten fornyelse, segmentering og herdingsplaner blir de svake ledd som er svært vanskelige å beskytte.

Personellrelaterte sårbarheter

Den menneskelige faktoren er fortsatt en av de største risikovektorene . Ansatte som bruker svake eller gjenbrukte passord, faller for phishing-e-poster, kobler til uautoriserte enheter, deler legitimasjon eller ignorerer sikkerhetsprosedyrer – ofte uten ondsinnet hensikt – kan undergrave selv det beste tekniske forsvaret.

Blant de vanligste sårbarhetene knyttet til personell er tilgang til usikrede nettverk, manglende bevissthet om phishing, bruk av forutsigbare passord, installasjon av programvare uten autorisasjon, manglende overholdelse av bedriftens retningslinjer eller interne trusler fra misfornøyde ansatte.

Å redusere disse risikoene krever mye mer enn en skriftlig policy . Det krever kontinuerlig opplæring og bevisstgjøring, simuleringer (som kontrollerte interne phishing-kampanjer), overvåking av samsvar og å fremme en kultur der rapportering av hendelser eller mistenkelig atferd er en selvfølge.

CVE-er og avanserte sårbarheter: et eksempel på et tilfelle i Linux-kjernen

Noen sårbarheter påvirker svært lave lag i systemet , som operativsystemkjernen eller virtualiseringsmoduler. Et illustrerende eksempel er en feil dokumentert som CVE-2026-23005, relatert til FPU-tilstandsstyring og XSAVE/XRSTOR-instruksjonene i x86-miljøer med KVM-virtualisering.

I dette spesifikke tilfellet oppstår problemet med håndteringen av XFD-registeret og XSTATE_BV-feltet i XSAVE-tilstanden til de virtuelle gjestemaskinene. Hvis visse FPU-funksjoner (som avanserte utvidelser som AMX) er deaktivert via XFD, men forblir merket som "i bruk" i XSTATE_BV, kan kjernen forsøke å gjenopprette en inkonsekvent tilstand og utløse et #NM-unntak, noe som potensielt til og med kan forårsake systempanikk.

Utløseren kan for eksempel være en skriving til MSR IA32_XFD fra gjestemaskinen, kombinert med et avbrudd eller en kontekstbryter i det nøyaktige øyeblikket når den virtuelle maskinens FPU-tilstand ennå ikke er riktig synkronisert. Det kan også oppstå hvis brukerområdet introduserer inkonsistente XSAVE-tilstander gjennom grensesnitt som KVM_SET_XSAVE.

Kjerneløsningen innebærer å fjerne XSTATE_BV for funksjoner som er deaktivert av XFD når gjestemaskinens XSAVE-tilstand oppdateres. Dette sikrer at XRSTOR ikke prøver å gjenopprette informasjon for komponenter som XFD anser som inaktive. Denne løsningen opprettholder konsistens med Intel-spesifikasjoner og forhindrer unntak for utilgjengelige enheter.

Dette eksemplet viser at sårbarheter ikke alltid er åpenbare for de som bare ser applikasjonslaget. De ligger ofte i samspillet mellom maskinvare, kjerne og virtualisering, og krever høy grad av ekspertise for å identifisere og fikse. Derfor er det viktig å overvåke sikkerhetsråd for operativsystemet nøye og nøye implementere lavnivåoppdateringer.

Metoder og verktøy for å oppdage sårbarheter

Systematisk oppdagelse av sårbarheter innebærer å kombinere både manuelle og automatiserte metoder. Én enkelt tilnærming er ikke tilstrekkelig: kodegjennomgang, penetrasjonstesting, systemskanning og testing med simulerte ondsinnede brukere er alle komplementære komponenter.

Gjennomgang av kildekode

Kodegjennomgang er et av de mest effektive forsvarsmekanismene for å oppdage sårbarheter før programvare når produksjon. Det kan gjøres manuelt, gjennom fagfellevurdering blant utviklere, eller assistert av statiske analyseverktøy som automatisk ser etter risikomønstre.

I manuelle gjennomganger må de ansvarlige være grundig kjent med terminologien som brukes, beste sikkerhetspraksis (feilkontroll, inputvalidering, minnehåndtering, autentisering, kryptering) og ha tydelige sjekklister. Det er ikke nok å bare gjennomgå den «lykkelige veien»; kanttilfeller og kappløpsforhold må også identifiseres.

Statiske analyseverktøy og SAST kompletterer denne prosessen ved å skanne store kodebaser for kjente mønstre knyttet til typiske sårbarheter: injeksjoner, XSS, bufferoverløp, bruk av farlige funksjoner osv. Selv om de genererer falske positiver, bidrar de til å unngå å overse visse tilbakevendende problemer.

Penetrasjonstesting og sårbarhetsskanninger

Penetrasjonstesting simulerer virkelige angrep mot applikasjoner, infrastruktur og API-er for å identifisere inntrengingsvektorer ved å kjede sammen sårbarheter, akkurat som en angriper ville gjort. Disse testene kan være svartboks (uten forutgående informasjon), gråboks (med litt kontekst) eller hvitboks (med tilgang til koden og arkitekturen).

Parallelt skanner sårbarhetsskannere porter , tjenester og applikasjoner på jakt etter kjente sårbare versjoner eller problematiske konfigurasjoner. De er ideelle verktøy for å opprettholde et oppdatert kart over risikoene som finnes i organisasjonen og prioritere utbedring.

Spesialverktøy: OWASP ZAP, Nikto og Acunetix

OWASP ZAP er et mye brukt åpen kildekode-verktøy for å analysere webapplikasjoner. Det lar deg avskjære trafikk, automatisere oppdagelsesangrep, kjøre SQL-injeksjonstester, XSS-angrep, autentiseringskontroller og mer, og genererer rapporter som beskriver de oppdagede sårbarhetene og deres innvirkning.

Nikto fokuserer på å analysere webservere , sjekke for svake konfigurasjoner, utdaterte versjoner, sensitive kataloger og filer, og feilkonfigurerte overskrifter. Det er spesielt nyttig som en rask skanner for å identifisere grunnleggende, men farlige problemer i webmiljøer.

Acunetix er en mer omfattende kommersiell løsning som kombinerer dype automatiserte skanninger av web- og mobilapplikasjoner med målrettet testing for kodeinjeksjon, autentiserings- og autorisasjonsfeil, XSS, CSRF og mange andre kategorier. Rapportene inneholder vanligvis spesifikke anbefalinger for å håndtere hvert funn.

Brukertesting med fokus på sikkerhet

I tillegg til teknisk testing er det avgjørende å innlemme sikkerhetsorientert brukertesting. Dette handler ikke bare om å bekrefte at applikasjonen «fungerer», men om å sjekke hvordan den oppfører seg når den møter ondsinnede brukere, feil input eller uforutsette arbeidsflyter.

Datainjeksjonstesting fokuserer for eksempel på å introdusere spesiallagde data (spesialtegn, lange strenger, mistenkelige strukturer) for å teste hvordan applikasjonen behandler dem. Hvis det viser seg at programvaren filtrerer utilstrekkelig, åpner det døren for SQL-injeksjon, XSS og andre angrep.

Autentiseringstester verifiserer robustheten til innloggingsprosessen , øktadministrasjon, mekanismer for passordgjenoppretting og rollebasert tilgangskontroll. Det gjøres forsøk på å omgå innloggingsprosessen, eskalere rettigheter, gjenbruke økter eller manipulere tokener for å evaluere styrken til hele autentiseringssystemet.

Beste praksis for å forebygge og håndtere sårbarheter

En effektiv sårbarhetsstrategi kombinerer forebygging , tidlig oppdagelse og rask respons. Det er umulig å forhindre 100 % av sårbarheter, men det er mulig å redusere antallet, alvorlighetsgraden og tiden de kan utnyttes.

Vedlikehold og administrasjon av oppdateringer

Å holde systemer og applikasjoner oppdatert er grunnleggende og en del av programvarevedlikehold . Dette innebærer å installere sikkerhetsoppdateringer så snart som rimelig mulig, etablere regelmessige vedlikeholdsvinduer, teste oppdateringer i preproduksjonsmiljøer og automatisere utrulling så mye som mulig.

Automatiserte løsninger for oppdateringshåndtering bidrar i stor grad til å orkestrere oppdateringer av operativsystemer og tredjepartsprogramvare, prioritere dem basert på kritiskhet og redusere manuell inngripen. Integrering av disse verktøyene med endepunktsikkerhet (antivirus, EDR, brannmur) gir en enhetlig oversikt over beskyttelsesstatus.

Risikobasert prioritering er nøkkelen : ikke alle oppdateringer er like viktige. Bruk av målinger som CVSS, kombinasjon av trusselinformasjon (å vite hvilke sårbarheter som aktivt utnyttes) og vurdering av hvert systems rolle i virksomheten bidrar til å bestemme hva som skal fikses først.

Opplæring av ansatte og sikkerhetskultur

Ingen teknologi kan kompensere for manglende bevissthet . Regelmessig opplæring av alle ansatte i phishing, passordbruk, enhetsbeskyttelse, håndtering av sensitiv informasjon og hendelsesrapportering reduserer angrepsflaten merkbart.

Videre er det viktig å fremme en kultur der sikkerhet er alles ansvar, ikke bare IT-avdelingens. Dette inkluderer utviklere, drift, personalavdelinger, økonomiavdelinger og toppledelse. Sikkerhet bør integreres i daglige prosesser og beslutninger, ikke bare en ettertanke.

Retningslinjer, revisjoner og hendelsesrespons

Å definere tydelige sikkerhetspolicyer bidrar til å sette grenser for hva som er og ikke er tillatt: programvarebruk, fjerntilgang, passordhåndtering, datalagring, personlige enheter (BYOD) osv. Men disse policyene må gjennomgås og revideres regelmessig for å sikre samsvar.

Regelmessige sikkerhetsrevisjoner gjør det mulig å oppdage avvik , identifisere utdaterte systemer, dårlig implementerte prosesser og tidligere ubemerkede sårbarheter. Basert på disse revisjonene utvikles korrigerende handlingsplaner og prioriteringer revurderes.

Det er viktig å ha en veldefinert plan for hendelsesrespons for å minimere konsekvensene når noe uunngåelig går galt. Denne planen bør inneholde prosedyrer for deteksjon, inneslutning, utryddelse, gjenoppretting og kommunikasjon, samt tydelige ansvarsområder for hvert involverte team.

I et miljø der trusler stadig utvikler seg , er den eneste realistiske måten å holde seg trygg på å anta at sårbarheter alltid vil eksistere, men samtidig jobbe for å redusere antallet, oppdage dem tidligere og minimere utnyttelsestiden deres. Dette kombinerer god design, sikker utvikling, disiplinert patchhåndtering, spesialiserte verktøy, beskyttet maskinvare og fremfor alt trente personer som er klar over sin rolle i organisasjonens sikkerhet.