Omvärldsbevakning utan extraljus är kejsarens nya kläder

Extraljusen är ingen lyx. De är skillnaden mellan att se vägen och att se älgen som står i kurvan. Stig Blomqvist hade fyra extraljus på sin Lancia Stratos och var kung på vägen.

Ulf Dellborg

Kontakt

Men att se älgen hjälper bara om du rör ratt och broms, och säkert gasen för Stig Blomqvist. Omvärldsbevakning för cybersäkerhet ska fungera precis som för Stig Blomqvist: Insamling, bedömning och agerande.

Ett säkerhetsarbete som grundas på en riskanalys gjord en gång och en incidenthantering som rapporterar olyckor skulle du inte acceptera som flygpassagerare.

Som pilot gjorde jag en omvärldsanalys inför varje uppdrag, jag skulle aldrig ge mig ut på ett uppdrag baserat på gårdagens väder.

Omvärldsbevakning minskar överraskningar

Omvärldsbevakning är inte att prenumerera på nyhetsbrev. Det är en funktion med definierat behov, valda källor, en analys som ställer det inkomna mot er egen arkitektur, och en dirigering av utfallet dit det gör nytta. För er innebär den:

Ni bestämmer vad ni behöver veta, utifrån er kontext och er hotbild
Ni väljer och granskar källorna, och gallrar dem som inte ger något
Ni bedömer relevansen mot er arkitektur, inte mot en generell allvarlighetsgrad
Ni dirigerar utfallet på tre nivåer — operativt till triagen, taktiskt till hotbilden, strategiskt till ledningen
Ni kan visa att hotbilden är aktuell, vilket är vad regelverken faktiskt efterfrågar

En vanlig vecka

En vanlig vecka komer till er fyrtio sårbarhetsnotiser, leverantörsbulletiner och myndighetsvarningar. Trettiofem gav ingenstans, men ni noterade varför. Dessa anteckningarna gör att er omvärldsbevakning håller vid en granskning.

Fem berörde er, och de ska till tre olika håll.

Driften får en leverantörsbulletin om en komponent som sitter i två av era produkter. Sårbarheten utnyttjas inte, rättningen finns, och den läggs i nästa underhållsfönster.
Arkitekterna får två. Den ena är en angreppsteknik som används mot er sektor. Den andra är en komponent som ingen har uppdaterat på fjorton månader, vilket kan betyda att leverantören har slutat underhålla den.
Ledningen får ett samråd om en genomförandeakt på väg. Den skulle ändra vad produkter av er klass måste kunna visa för att få säljas.

Den femte ser minst ut och är värd mest. En av era leverantörer har lämnat er tre kritiska sårbarheter på arton månader. Den ska till alla tre hållen, och den betyder olika saker på varje:

Driften ser en rättning bland andra.
Arkitekterna ser en fråga om att byta komponent.
Ledningen ser en fråga om leveranskedjan, och om ett tioårigt supportåtagande håller.

Ingen av de tre frågorna är brådskande, och de har tre olika tidshorisonter. Det är vad dirigering innebär.

Går fynden bara till ett av hållen blir felet olika beroende på vilket håll det är. Når de bara driften patchar ni i evighet och byter aldrig ut någon komponent, och den kostnaden står inte i en budget utan tas ut i arbetade nätter. Når de bara arkitekterna får ni en bra diskussion om komponentval medan rättningen ligger kvar oinstallerad. Når de bara ledningen resonerar ni om leverantörsstrategi medan komponenten sitter kvar.

Ibland utnyttjas en sårbarhet aktivt. Då startar en klocka, och ärendet går över till incidenthanteringen. Men de veckor då ingen klocka startar är inte veckor då bevakningen var onödig. De är hur den ser ut när den fungerar.

Vad är omvärldsbevakning?

Omvärldsbevakning, att bevaka förändring, dra slutsatsen och agera

Omvärldsbevakning är att systematiskt samla in information om det som förändras utanför verksamheten, bedöma vad av det som faktiskt berör er, och se till att slutsatsen når fram till någon som kan handla på den. Tre steg: insamling, bedömning, åtgärd.

Alla har strålkastare. Få har extraljus

Halvljus lyser upp vägen precis framför dig. En älg syns inte i tid med halvljuset. Bevakning är extraljusen. De lyser längre och bredare. De ger er tid, och ni ser älgen i kurvan.

Extraljuset ger precis den omvärldsbevakning rallyföraren, som min gamla idol Stig Blomqvist, behöver. Och, förlåt SAAB, Lancia Stratos är den absolut coolaste rallybilen.

Ett säkerhetssystem utan omvärldsbevakning fungerar på precis det sättet. Bilen går, föraren gör allt rätt, instrumenten visar grönt, ingenting av det säger något om vad som ligger runt nästa kurva.

Säkerhet byggs kring kontinuerlig förbättring, PDCA-cykeln. I uppföljningssteget finns i två olika granskningar. Bygg båda:

Internrevision. Gör vi det vi sa att vi skulle göra? Inåtblickande granskning som är en del av förbättring.
Omvärldsbevakningen. Är det vi sa vi skulle göra fortfarande rätt? En utåtblickande granskning som beskrivs här.

Tre skäl att inte sluta när systemet är i drift

Nya hot och sårbarheter uppstår dagligen. När ni gjorde riskanalysen var det hotbilden just då. Den håller inte nu.
Nya regler. Inom kort tid kom cybersäkerhetslag, cyberresiliensförordning och AI-förordning.
Intressenterna förändras. Deras behov, avtal och krav förändras. Ni kan fortfarande välja vilka affärer ni tackar ja till.

Omvärldsbevakning i 6 steg

Metoden som implementerar regelverken genom policyer

Metoden styrs av säkerhetspolicyn, och policyn implementerar regelverken. Policyn säger vad som gäller, rutinerna hur det görs. Och policyn ändras av bevakningen, när bevakningen hittar brister i den.

Metoden består av sex steg:

Styr och planera En bevakningsplan: behov, källor, frekvens, mottagare
Inhämta och bearbeta. Varje post får en källa och tidsstämpel. Posterna bearbetas till ett gemensamt format
Bedöm relevans En prioriterad kö: ej relevant, relevant, brådskande
Analysera En bedömning per post, med föreslagen åtgärd
Besluta och omsätt Ett beslut i beslutsloggen och ett ärende hos mottagaren
Kommunicera och dela Lägesbilder, information till berörda, delad hotinformation

Stegen följer underrättelsecykeln och ISO/IEC 27002:s ordning för hotunderrättelser, och de täcker föreskriftens fem bevakningsområden: hot, sårbarheter, teknisk utveckling, rättsliga krav och tillgängligt stöd.

Underrättelsecykelns åttonde steg, att mäta effekten och förbättra arbetssättet, ligger inte här utan i förbättring, operativ säkerhets tredje ben. Bevakningen äger sin plan och sina källor; ska arbetssättet ändras är det en annan funktions beslut.

Resultat

Två register, och de är funktionens bevis.

Bevakningsloggen är inflödesregistret. Varje post får källa, tidpunkt, sekretessklass, bedömning och status.
Beslutsloggen håller besluten med namngiven beslutsfattare.

Tillsammans ska de visa kedjan källa → bedömning → beslut → åtgärd. Kedjan gör att ni kan svara på varför ni gjorde eller inte gjorde något. Denna kedja är det tillsynsmyndigheten vill ha.

Att tänka på:

Bibliotekens versioner ger spårbarhet.
Loggen tidpunkt är viktig. Rapporteringsfristerna räknas från när ni fick kännedom. Bevakningsloggen och incidentärendet ska ha samma tidsstämpel.
Används AI i något steg sparas också prompten som användes.

1. Planera

Indata: säkerhetspolicyns bevakningskrav. Behoven med ägare, frekvensen per mottagare, vad som bryter in utanför rytmen, och vad källförteckningen minst ska innehålla. Utdata: en bevakningsplan med fyra kolumner: behov, källa, läsrytm, mottagare. Ledningen fastställer den.

Styrningen ligger i policyn, inte här. Behoven härleds ur kontextanalysen och den preliminära riskanalysen, fastställs i policyarbetet, och står kvar hos den tillgång, det hot eller det beroende de kommer ur. Rytmen och utlösarna är regler, och de är samma varje varv. Står en regel bara i planen ändras den utan att någon beslutar om det.

Steget gör det som skiljer sig mellan varven. Vilken konkret källa som svarar på vilket behov. Hur ofta just den källan läses, inom den frekvens policyn satt för mottagaren. Vem som gör arbetet den här perioden. Och täckningskontrollen: har varje behov minst en källa, och tjänar varje källa minst ett behov? Den andra frågan är gallringen.

Bevakning utan behov blir en prenumeration, och planen är det som gör behovet till arbete.

Steget ställer två krav på sitt indata. Ett behov ska vara en fråga, inte ett ämne. "Cybersäkerhet i tillverkningsindustrin" är ett ämne, och till ett ämne går ingen källa att välja. "Vilka angreppstekniker används mot fjärråtkomst i industriella styrsystem av vår typ" är en fråga. Och behoven ska komma från två håll: systemriskanalysen ger de operativa och taktiska, kontextanalysen och affärsmodellen de strategiska. Saknas det andra hållet producerar bevakningen bara sårbarhetslistor, och posten till ledningen i veckoexemplet blir aldrig skriven.

Omkörningen planeras här

Att en omkörning ska ske även när ingenting har hänt är en policyregel. Skälet är att ett inflöde bara kan berätta om det någon annan redan har skrivit ned. En komponent som slutat underhållas får ingen sårbarhetsnotis, eftersom ingenting är trasigt, och en källa som tystnat ser ut som att det är tyst. Ingen upptäcker en frånvaro.

Vad steget gör är att lägga in den. Omkörningen är systemriskanalysen körd om med dagens arkitektur och dagens bibliotek, och skillnaden mot förra körningen är svaret: biblioteket har ändrats, arkitekturen har ändrats, eller förra bedömningen var fel. Tre orsaker med tre olika åtgärder.

Takten är en kostnadsfråga, och den avgörs här. Blir omkörningen billig kan den styras av ändringar i stället för av kalendern.

Källorna väljs här, och gallras här

Källorna delar sig i interna och externa, och ISO 27002:s kontroll 5.7 kräver båda.

De interna har ni redan, och de heter något annat hos er. Granskningar av egna incidenter, avvikelserapporter, debriefingar, penetrationstester, sårbarhetsskanningar och fynd från leverantörer är precis det erfarenhetsminingen samlar in. Bygg inte om det. Lägg i stället till en läsning: samma utfall ska också läsas som hotinformation, inte bara som förbättringsunderlag. En genomgång av era egna incidenter säger mer om er hotbild än någon extern rapport.

Blomqvist satt lågt i sin Audi Quattro därför att han hade vält så många Saabar att han ville hålla sig undan taket. Det är ett säkerhetskrav härlett ur egen incidenthistorik, formulerat av den som råkat ut för incidenterna. Det är precis den sortens källa ni redan sitter på.

Externa är myndighetsvarningar och CSIRT-utskick, leverantörsbulletiner, sårbarhetsdatabaser, sektorsvisa delningsforum, och för den strategiska nivån nyhets- och forskningskanaler som berör er affär. Den sista gruppen glöms nästan alltid, eftersom den inte ser ut som säkerhet.

Två av källtyperna är inte valfria: information från era leverantörer av hårdvara och programvara, och från den nationella CSIRT-funktionen. Den svenska föreskriften pekar ut båda.

Två regler gör skillnad. Få källor som används slår många som inte läses. Och källförteckningen ska ses över med planerade intervall, vilket NIS2:s genomförandeförordning kräver uttryckligen. Intervallet sätter ni i policyn. En källa som inte lett till någon åtgärd på ett år ska antingen bytas ut eller bort.

Översynen gäller inte bara gallring av döda källor. Frågan är om det fortfarande är rätt kanaler, och den går bara att besvara mot behoven. En källa kan leverera flitigt och ändå svara på fel fråga.

Steget har med avsikt ingen prompt. Att välja och gallra källor är ett mänskligt beslut, och konsekvensen av det är vad ni kommer att missa.

2. Inhämta och bearbeta

Indata: källförteckningen ur planen. Utdata: ett inflöde där varje post har källa och tidsstämpel.

Tre slags källor ska in:

Publika (myndigheter, databaser, forskning),
Avtalade (era leverantörers information om incidenter och sårbarheter)
Egna (incidenter, tillbud, kundservice, och sårbarhetsrapporter som kommer in via er publika kontaktväg).

Den sista gruppen är lätt att glömma. Har ni en produkt på marknaden ska det finnas en bevakad adress där vem som helst kan anmäla en sårbarhet. Nu har ni många källor i många format. De ska bli ett.

Normalisera. Samma fält för varje post: produkt, version, angreppsteknik, berört krav, källa, datum.
Slå ihop dubbletter. Samma sårbarhet kommer från sex källor och ska vara en post, inte sex. Det här är den enskilt största tidsvinsten i hela kedjan, och den är helt mekanisk.
Källvärdera. Två omdömen per post, och de är olika: hur tillförlitlig är källan, och hur trovärdig är uppgiften. En pålitlig källa kan återge ett obekräftat rykte.
Sekretessmärk. En del av det ni får in får inte spridas vidare, och den begränsningen följer med posten. Utan märkning vid ankomsten blir den en gissning senare.

3. Bedöm relevans

Indata: bevakningsloggens poster, arkitekturen, tillgångsförteckningen. Utdata: en prioriterad kö i tre fack: ej relevant, relevant, brådskande.

Det här steget gör omvärldsbevakning till säkerhet. En allvarlighetsgrad i en extern databas säger något om världen. Den säger ingenting om er förrän den ställts mot er arkitektur.

Och det är här bristvaran sitter. Flöden är nästan gratis och nästan likvärdiga. Det ingen kan köpa är förmågan att besvara "berör det här oss" utan att någon gissar. Det svaret kräver en beskriven arkitektur, och har ni den blir relevansbedömningen en fråga mot en modell i stället för en läsning av ett nyhetsbrev.

Steget sorterar, det bedömer inte allvar. Det brådskande facket går direkt till steg 5 och analyseras parallellt.

Vad diagrammet måste innehålla

Indata är era arkitekturdiagram, och det är med avsikt. Det är dem ni redan har, och en funktion som kräver en exportkedja före första körningen blir aldrig körd. Topologin finns dessutom bara i diagrammet: vad som kopplas till vad, vad som ligger i vilken zon, vad som korsar en gräns. Exponering är en topologisk egenskap.

Men då blir diagrammet bärande, och fyra saker måste finnas i det:

Komponentnamn som motsvarar det som faktiskt är driftsatt.
Zonerna utritade, inte underförstådda. Gränsen avgör om en kritisk sårbarhet är akut eller ointressant.
Flödenas riktning, eftersom en angreppsväg är riktad.
Dataobjektens klassificering, nycklad mot klassificeringslistan. Utan den går konsekvens inte att rangordna.

Vilket bibliotek som biter beror på lagret, och det är ingen smaksak. Sårbarhetsnotiser kräver en produkt och en version, och de biter bara tekniskt. Angreppstekniker och konstruktionssvagheter är egenskaper hos något som gör X och nås via Y, och de biter logiskt. Regelverk, marknad och intressentförväntningar biter på verksamhetsnivå och har ingenting att göra på de tekniska lagren.

Därav två slags indata med olika facit. Hot och sårbarheter matchas mot arkitekturen och ger en ändrad hotbild. Regelverk och förväntningar matchas mot kravbilden och affärsmodellen och ger ändrade krav.

Frågan ställs i fyra lager

Lager	Frågan	Vad den fångar
Affärsarkitektur	Påverkar det en förmåga eller ett värdeerbjudande vi är beroende av?	Regelverksskiften, marknadsförändringar, forskningsresultat. Det enda lager som kan producera en möjlighet och inte bara ett hot
Funktionell	Påverkar det en funktion vi måste kunna leverera?	Beroenden som inte syns i komponentlistan
Logisk	Påverkar det ett gränssnitt eller ett dataflöde, och är det exponerat?	Exponeringen, alltså den faktor som oftast avgör
Teknisk	Finns komponenten hos oss, i vilken version, bakom vad?	Den konkreta matchningen mot komponentinventariet

Det fjärde lagret bygger alla först och är lättast att automatisera. Det första är värt mest och nästan ingen har det, och det är det lagret som avgör om ledningen får något att besluta om.

Matchningen på det tekniska lagret står och faller med identifieraren. Ett komponentnamn i en ritning går inte att jämföra med en sårbarhetsnotis. En maskinläsbar identifierare gör det, och utan programvaruförteckning syns dessutom inte de indirekta beroendena, där de flesta sårbarheterna brukar sitta. Andelen komponenter som har en matchningsbar identifierare är därför det mest talande mätetalet ni kan sätta på den här funktionen.

Den som bedömer bör inte vara den som samlade in. Den som letat fram en post har redan investerat i att den är viktig, och den som byggt en komponent har svårt att se den som exponerad. Separationen kostar nästan ingenting och fångar den vanligaste felbedömningen. Den är rollskiftet i taktisk planering tillämpat på en inkommen post, och den gäller både människor och modeller.

Prompt: bedöm relevansen mot arkitekturen

Vem du är: agera som säkerhetsarkitekt med erfarenhet av hotmodellering och sårbarhetshantering.

Bifogat material: arkitekturdiagrammen för de fyra lagren, klassificeringen av dataobjekten, förteckningen över versioner i drift, och periodens poster ur bevakningsloggen.

Din uppgift: bedöm för varje post om den berör oss, och i vilket lager. En post i taget.

Ställ frågan i fyra lager och svara på vart och ett separat: påverkar posten en förmåga eller ett värdeerbjudande vi är beroende av, en funktion vi måste kunna leverera, ett gränssnitt eller dataflöde och är det i så fall exponerat, eller en komponent vi har i en version vi har ute?

Ange för varje bedömning vad i arkitekturen som gör den tillämplig: komponent, flöde eller zongräns, med namn som det står i diagrammet. Inte ditt allmänna intryck.

Bedöm inte åtgärd, allvarlighetsgrad eller rapporteringsplikt. Det är mänskliga beslut i steg 5.

Lämna slutsatsen tom där du saknar underlag, och säg vad du saknar.

Svarsformat:

PER POST
Post, källa, datum:
Vad den säger:

BERÖR OSS
Lager | Komponent eller förmåga | Grund i arkitekturen

BERÖR OSS INTE
Lager | Varför inte, med hänvisning till diagrammet

KAN INTE BEDÖMAS
Vad jag saknar, och var det borde ha stått

Den sista listan är den som är värd mest. En post som inte går att bedöma mot arkitekturen pekar antingen på ett hål i modellen eller på en källa som inte är användbar för er. Båda är fynd, och båda har åtgärd.

Och den är viktigare när indata är ett diagram än när det är en databas. Ett diagram som en modell inte kan bedöma är ett diagram en ny arkitekt inte kan bedöma heller. Prompten blir därmed ett prov på diagramkvaliteten, och det är en bieffekt värd att ha.

Notera att fältet är grund, inte trovärdighet. En modell som ombeds betygsätta sin egen säkerhet låter säker oavsett. En modell som ombeds peka ut komponenten i diagrammet går att kontrollera på tio sekunder.

Prompt: argumentera mot bedömningen

Körs som nästa prompt i samma konversation, enligt rollskiftet i taktisk planering. Att be samma roll både bedöma och invända i ett svar fungerar inte, eftersom modellen försvarar det den just skrivit.

Vem du är: agera som angripare, och som den systemägare som inte vill byta komponent.

Din uppgift: angrip bedömningen ovan från två håll. Vilka poster som avfärdades kan ändå nås, via en väg som inte syns i ett enskilt lager? Och vilka poster som bedömdes beröra oss gör det i själva verket inte, därför att ett skydd eller en zongräns som finns i diagrammet inte vägdes in?

Peka i båda fallen på vad i arkitekturen du bygger invändningen på.

Svarsformat: post | invändning | vad i arkitekturen den bygger på | vad som skulle avgöra frågan

Den tredje rollen i rollskiftet, den som utmanar helheten, är människans. Den utövas i steg 5.

4. Analysera betydelsen

Indata: den relevanta kön. Utdata: en bedömning per post, med angiven säkerhetsgrad och föreslagen åtgärd.

Steg 3 svarade på om posten rör er. Det här steget svarar på vad den betyder, och frågan är olika för de tre mottagarna.

Operativt: är den nåbar och utnyttjbar? Är den sårbara funktionen i bruk? Ligger den bakom en zongräns? Finns belägg för att någon utnyttjar den i verkligheten, eller bara ett bevis på att det går?

Taktiskt: hur ändras angreppsvägarna? Posten prövas mot de logiska gränssnitten och blir ett scenario. Räcker våra säkerhetskrav, eller ska komponenten bytas?

Strategiskt: vad betyder mönstret? Trender, nya krav, och den enda frågan som också kan ge ett tillfälle i stället för ett hot.

Tre frågor till per post

Aktualitet. Är detta nytt, eller något vi redan hanterat? Tillförlitlighet. Säger flera oberoende källor samma sak? Konsekvens. Vad är rimligt värsta utfall om vi inte gör något?

En kritisk sårbarhet i en komponent ni inte exponerar kan vara ointressant. En medelallvarlig i något som sitter i ert mest exponerade gränssnitt kan vara akut. Det är arkitekturen som avgör, inte poängsättningen. En allvarlighetspoäng mäter hur illa något är i allmänhet, inte vad det är värt hos er.

Skriv ned svaret, särskilt när det är nej

Utfallet av tillämplighetsprövningen ska dokumenteras i fyra möjliga lägen: berörd, ej berörd med motivering, åtgärdad, eller under utredning. För en produkt har den dokumentationen ett etablerat maskinläsbart format, och den blir då också underlag ni kan ge era kunder.

Det låter administrativt, och det är det inte. "Ej berörd med motivering" är exakt det regelverken kräver att ni kan visa, och det är den enda av de fyra raderna som försvinner om ingen skriver ned den. De tre andra syns av sig själva.

Ett avfärdande är ett ställningstagande och behöver därför fyra uppgifter: vem, när, på vilken grund, och när det upphör att gälla. Utan upphörandevillkor överlever det den förutsättning det vilade på, och nästa körning rör det inte.

Ingår komponenten i en säkerhetsfunktion räcker det inte att patcha. En ändring i ett system med SIL-krav är en modifiering som kräver konsekvensanalys före ändringen, och då är en kompenserande åtgärd ofta rätt första steg.

5. Besluta och omsätt

Indata: bedömningen från steg 4, och det brådskande facket direkt från steg 3. Utdata: ett beslut i beslutsloggen, och ett ärende hos den mottagande processen.

Bevakningen äger inte åtgärden. Den äger att utfallet hamnar rätt.

Här ligger också den viktigaste omläsningen av kontroll 5.7. Standardens tre nivåer brukar läsas som en indelning av information. De är i själva verket en dirigeringstabell, där varje nivå har en egen mottagare, en egen takt och en egen beslutsfattare.

Standarden stödjer den läsningen själv. Den anger uttryckligen att underrättelserna ska matas in i riskbedömningen, leverantörssäkerheten, sårbarhetshanteringen, övervakningen och incidenthanteringen. Fem namngivna mottagare. En standard som räknar upp mottagare beskriver en dirigering, inte en informationsindelning.

Nivå	Vad det är	Mottagare och beslut
Operativ timmar	Konkreta angrepp och tekniska indikatorer. Tecken på att något utnyttjas nu	Triagen i incidenthanteringen. Där görs klassificeringen mot regelverkens trösklar och där startar fristerna. Beslut: patcha, isolera, rapportera
Taktisk releasetakt	Angriparnas metoder, verktyg och teknik. Hur man numera tar sig in i system som era	Hotbilden i systemriskanalysen, och vidare till funktionella säkerhetskrav. Beslut: byta komponent, skärpa krav, ändra arkitektur
Strategisk år	Hur hotlandskapet förändras. Regelverksskiften, teknikskiften, forskningsresultat. Den enda nivån som också bär möjligheter	Kontextanalysen och den strategiska planeringen. Beslut: leverantörsstrategi, supportåtaganden, affärsmodell. Beslutsfattaren är ledningen, inte säkerhetsfunktionen

Utöver de tre finns en mottagare som inte är en nivå utan ett arbetssätt: förbättringsbackloggen, dit det hör som visar att ett arbetssätt behöver ändras snarare än en åtgärd införas.

Beslutet har fyra möjliga utfall, och alla fyra ska skrivas: åtgärda inom fastställd tid, kompensera, acceptera, eller lämna över till incidenthanteringen. Riskägaren beslutar, bevakningsägaren följer upp.

Och åtgärdsbeslutet har en egen klocka som inte är en rapporteringsfrist. Säkerhetsuppdateringar ska genomföras skyndsamt, och det allmänna rådet till den svenska föreskriften anger att installationen bör påbörjas inom 72 timmar från att en rättning finns tillgänglig. Programvara som inte längre får säkerhetsuppdateringar från leverantören ska bytas eller uppgraderas utan onödigt dröjsmål.

Vilken klocka som startar

En sårbarhet i sig utlöser ingen rapporteringsskyldighet. Antagandet om motsatsen ger både onödiga anmälningar och felriktad brådska. Hittar ni en tidigare okänd sårbarhet själva bör den rapporteras till den nationella CSIRT-funktionen, vilket är ett råd och inte en plikt.

Två andra utfall startar däremot en klocka, och de är olika utlösare som råkar dela takt. Det är den vanligaste förväxlingen på området.

En aktivt utnyttjad sårbarhet i en produkt ni själva levererar. Cyberresiliensförordningen: tidig varning inom tjugofyra timmar. Den utlöses utan att något har hänt hos er, eftersom det räcker att sårbarheten utnyttjas hos någon som använder er produkt.

En betydande incident i er egen verksamhet. Cybersäkerhetslagen, också inom tjugofyra timmar. Här är utlösaren incidenten, inte sårbarheten.

I båda fallen lämnar posten bevakningen. Bevakningens uppgift är att överlämningen sker tidigt och med underlag, inte att hantera den.

Prompt: dirigera utfallet

Bifogat material: bedömningen från steg 4, och dirigeringsreglerna ur säkerhetspolicyn.

Din uppgift: föreslå för varje post vilken mottagare den ska till och vilket metodsteg som berörs. Föreslå inte åtgärd.

Ange när en post ska till mer än en mottagare, och varför.

Svarsformat: post | mottagare | berört metodsteg | vad som ska beslutas där | motivering

En namngiven person kvitterar dirigeringen innan posten skickas. Ett förslag ingen kvitterat är ingen dirigering.

6. Kommunicera och dela

ndata: besluten ur beslutsloggen. Utdata: lägesbilder per nivå, information till berörda, och delad hotinformation.

Ett beslut som ingen får veta om är inget beslut. Steget har tre mottagargrupper, och de är olika i art.

Internt: en lägesbild per nivå. Driften behöver indikatorer och detektionsregler. Arkitekterna behöver en uppdaterad hotbild. Ledningen behöver en strategisk lägesbild, och den ska in i ledningens genomgång minst en gång om året.

Utåt till era kunder. Cybersäkerhetslagen kräver att ni informerar tjänstemottagare som kan påverkas av ett betydande cyberhot om de skydds- och motåtgärder de själva kan vidta. Det är en plikt som utlöses av bevakning, inte av incident, och den enda plikten på den här sidan som kan träffa er utan att någonting har hänt hos er.

Utåt till kollektivet. Hotinformation får delas med den nationella CSIRT-funktionen och i sektorsvisa informationsutbyten. Delningen är frivillig, men den är uttryckligen uppmuntrad i NIS2, och den är det enda i hela funktionen som gör att er bevakning också förbättrar någon annans.

Det sista är värt en tanke för den som tycker att delning bara är kostnad: ni läser andras delningar varje dag. Källförteckningen i steg 1 består till stor del av det.

Prompt: underlag till den strategiska lägesbilden

Bifogat material: periodens poster på strategisk nivå, kontextanalysen och affärsmodellen.

Din uppgift: sammanställ periodens observationer och ange var i arkitekturen eller affärsmodellen var och en tar. Dra inga slutsatser och föreslå inga beslut.

Svarsformat: observation | källa | var den tar i modellen | vad som skulle behöva vara sant för att den ska betyda något

Den sista kolumnen är gruppens arbete, inte modellens.

Lägesbilden har dessutom en utdataform som de andra saknar: utfallet kan ritas. Periodens fynd markerade på arkitekturen visar var trycket ligger, och det är ett bättre underlag för en ledningsgrupp än en lista.

Vad AI gör, och vad en människa gör

Bevakning är det område i säkerhetsarbetet där AI gör mest nytta. Matchning av flöden mot komponentinventariet, klustring och avdubblering av samma sårbarhet från sex källor, och utkast till relevansbedömningen i de fyra arkitekturlagren. Det är arbete som är stort, repetitivt och beroende av en beskriven modell, alltså precis vad en maskin är bra på och en människa tröttnar på vid post trettio.

Men en språkmodell är en mönsterfullbordare. Den är System 1: snabb, intuitiv, utan förståelse för sammanhang. Utdatan har däremot System 2:s form: strukturerad, sekventiell, med reservationer. Och flyt i sig skapar sanningskänsla hos läsaren. Det är kombinationen som gör att ett utkast läses som ett besked.

Där kliver ni in som System 2. Inte som en spärr i vägen för maskinen, utan som den enda part som kan väga sammanhang. Det är därför arbetsfördelningen ser ut som den gör.

Graden av slutsats ska avta uppåt

Det är motsatsen till instinkten, som vill att AI ska vara mest polerad där frågan är viktigast.

Operativt drar AI så långt det går: matchning, exponering, kandidatbedömning. Och en människa kvitterar. Miljön är regelbunden och återkopplingen snabb, så mönsterigenkänning är pålitlig här, och 24-timmarsfristen gör långsamt tänkande otillgängligt. Samma skäl som gör att flyget har checklistor i stället för resonemang i cockpit.

Taktiskt föreslår AI bedömningen, och en namngiven ägare antar eller avslår den.

Strategiskt redovisar AI observationerna och var i modellen de tar, och lämnar bedömningen tom med avsikt. Där är miljön oregelbunden och återkopplingen tar år, så mönsterigenkänning är opålitlig oavsett hur erfaren bedömaren är. Kommer underlaget med en färdig slutsats blir gruppens uppgift tyst att validera den i stället för att tänka.

Tre beslut som är era

Rapporteringsplikten är er. AI förbereder det kompletta men ofärdiga underlaget på sekunder: vilka versioner, vilken exponering, vilka belägg. Men bedömningen om fristen har börjat löpa är rättslig, och den har en namngiven ägare. Er erfarenhet är filtret som skyddar bolaget både från missade frister och från falsklarm.

Avfärdandet är ert. Falska positiv kostar tid och upptäcks. Falska negativ är tysta och upptäcks aldrig. Därför är beslutet att inte göra något det enda beslut i hela kedjan som aldrig kan delegeras till en maskin. Det syns inte i någon logg om det blir fel.

Motiveringen är er. CRA artikel 13.4 kräver att varje väsentligt krav som inte är tillämpligt motiveras i dokumentationen, och 13.7 att bedömningen uppdateras systematiskt. "Modellen bedömde den som icke-tillämplig" håller inte hos ett anmält organ. Ni är den enda part som kan säga varför, och det är den meningen som bär er efterlevnad.

Bevakningen behöver ingen egen styrning för det här. Prompterna körs i de loopar ni redan har. Omkörningen och den strategiska lägesbilden är arbetssessioner och drivs av taktisk planering, medan relevansbedömningen och dirigeringen per batch är löpande arbete och drivs av operativ planering.

Därmed gäller planeringens egna regler, och två av dem är avgörande här. Deltagarna skriver sin egen bild innan de läser AI:ns utdata, annars ankrar modellen gruppen. Och AI-utdata är en hypotes för whiteboarden, aldrig direkt indata till modellen.

Sammanfattat: AI utkastar, en namngiven person avgör, beslutet skrivs ned. Och nedskrivningen är inte byråkrati. Den är det regelverken faktiskt efterfrågar.

Tillbaka till bilen. AI är kartläsaren, inte föraren. Kartläsaren har noterna, läser dem i förväg och ropar ut kurvan innan den syns, men han rör inte ratten. Och noterna är värdelösa om ingen rekognoscerat sträckan, vilket är er arkitektur. Ett rally körs inte på förra årets rekognoscering.

FAQ: Allt du behöver veta om omvärldsbevakning

1. Räcker det inte med sårbarhetsskanning?

Svar: Skanning är en källa bland flera, och den hittar bara det som redan är känt och som finns i det ni skannar. Den säger ingenting om angreppstekniker, om leverantörer som slutar underhålla komponenter, eller om hot mot er sektor.

2. Hur många källor behöver vi?

Svar: Färre än ni tror. ISO 27002 vill att ni väljer, granskar och gallrar. En källa som inte lett till någon åtgärd under ett år är en kostnad, inte en tillgång.

3. Vem ska äga funktionen?

Svar: Någon som har mandat att eskalera. Bevakningens värde ligger i dirigeringen, och den kräver att den som sitter på den kan väcka triagen utanför kontorstid.

4. Vad skiljer bevakningen när objektet är produkt?

Svar: Matchningen mot programvaruförteckningen. Är objektet er verksamhet bevakar ni hot mot er sektor och era system. Är objektet en produkt bevakar ni sårbarheter i de komponenter som sitter i varje version ni har ute.

5. Hur ofta ska hotbilden uppdateras?

Svar: När den förändras, inte enligt kalender. Den planerade översynen är ett golv, inte ett schema. Genomförandeförordningen till NIS2 talar om årlig översyn av riskhanteringen; det är miniminivån, inte ambitionen.