När en svensk organisation ska beskriva sin externa attackyta räcker det sällan att fråga IT vilka servrar som finns i drift. Verksamheten kan ha en huvudwebb, kundportal, gamla kampanjsidor, API-hostar, inloggningsdomäner, testmiljöer och tjänster som startats av en byrå. Vissa resurser syns i DNS eller certifikat långt efter att projektet avslutats. Andra är privata eller avsiktligt dolda. Ett användbart NIS2-underlag behöver därför kombinera upptäckt med verifiering, ägarskap och prioritering.
NIS2 är inte en checklista för att skanna fler adresser. Kraven måste förstås i organisationens rättsliga och verksamhetsmässiga kontext, med PTS och andra behöriga myndigheter som relevanta källor för svensk tillämpning. En teknisk domänrapport ersätter inte riskanalys, incidentprocess, styrning eller juridisk bedömning. Den kan däremot ge ledningen en mer konkret bild av vilka publika tillgångar som behöver förklaras och skyddas.
Definiera vad inventeringen ska svara på
Börja med beslutet som inventeringen ska stödja. Behöver ni hitta okända subdomäner före en revision, prioritera TLS-åtgärder, bekräfta ägare inför en leverantörsgranskning eller förstå vilka tjänster som kan påverka en kritisk process? Ett brett mål som upptäck allt blir snabbt dyrt och svårtolkat. Skriv i stället ner scope, datum, tillåtna metoder, ansvarig beställare och vad ett fynd ska leda till.
- Vilka registrerade domäner och varumärkesrelaterade namn omfattas?
- Vilka subdomäner är relevanta för kritiska tjänster och e-post?
- Vilka bevis räcker för att en host ska bli verifierad tillgång?
- Hur skiljer ni aktiv tjänst, parkering, omdirigering och okänd exponering?
- Vem äger teknisk verifiering, riskbeslut och åtgärd?
- När ska observationerna uppdateras och gallras?
Samla domäner från flera verksamhetskällor
Utgå från domänportföljen, men lita inte på en enda lista. Jämför registraruppgifter, DNS-delegation, webbplatser, certifikatobservationer, dokumentation, inköpssystem och kontakt med produktägare. Marknadsavdelningen kan känna till en kampanjdomän som aldrig hamnade i CMDB. Drift kan känna till en API-host som juridik inte kopplat till varumärket. Skillnaderna är värdefulla fynd, men de måste verifieras innan de blir en incident eller en prioritet.
Sätt ett bevisdatum och en källa på varje resultat. En synlig subdomän från ett gammalt certifikat visar att namnet förekommit, inte att en aktiv server fortfarande finns där. En DNS-post visar aktuell delegation vid observationen, men inte vem som har rätt att ändra den. Lägg därför till status som upptäckt, verifierad, okänd, avvecklad eller falskt positiv. Denna vokabulär gör rapporten möjlig att följa upp.
Skilj mellan identifiering och test
En extern inventering ska börja passivt och försiktigt. Samla publika DNS-, certifikat-, HTTP- och registreringssignaler med rimlig hastighet och begränsning. När en host verkar viktig kontrollerar en behörig ägare den i sin dokumentation eller genom en planerad teknisk test. Skicka inte aggressiva förfrågningar till okända system och anta inte att en oväntad inloggningssida ger tillstånd att försöka logga in.
Sårbarhetsskanning är ett annat steg än domänupptäckt. Den kräver godkännande, mål, tid och kontaktväg. Om inventeringen visar en gammal admin-host ska fyndet gå till en ansvarig för verifiering, inte direkt till en djup skanning från en okänd miljö. Dokumentera vad som faktiskt gjordes så att en revisionsrapport inte överdriver täckning eller säkerhet.
Knyt hosten till en verksamhetstjänst
För varje verifierad subdomän skriver du vilket affärsflöde den stöder, vilken data den hanterar och vilken återställningstid som gäller. En host för ett publikt pressarkiv är inte samma risk som en host för kundinloggning. Fråga vem som godkänner ändringar, vem som kontaktas vid incident och vilken leverantör eller intern grupp som sköter tjänsten. Om ingen kan svara är det ett styrningsfynd även om den tekniska konfigurationen ser rimlig ut.
- Namn och observerad DNS- eller certifikatkälla.
- Aktivitet och slutlig URL med observationstid.
- Tjänsteägare, teknisk ägare och leverantörskontakt.
- Kritikalitet, dataflöde och beroende till andra domäner.
- TLS-status, omdirigering och relevanta DNS-poster.
- Godkänd status, risknivå, åtgärd och nästa kontroll.
Prioritera enligt påverkan och osäkerhet
En enkel prioriteringsmatris kombinerar verksamhetspåverkan med hur väl resultatet är verifierat. En verifierad host för återställning av lösenord får hög prioritet även om den har få besökare. En okänd subdomän med en inloggningsportal behöver snabb ägarbekräftelse. En gammal informationssida utan aktiva formulär kan få lägre teknisk prioritet men ändå kräva varumärkes- eller avvecklingsbeslut. Skriv varför varje nivå valdes, så att prioriteringen kan ändras när ny information kommer.
Undvik att kalla allt som inte är känt för sårbart. Okänd betyder att bevis eller ägare saknas. Den kan vara avvecklad, felaktigt observerad eller aktiv. Lika viktigt är att frånvaro inte bevisar att en tillgång inte finns. En domän kan ha en privat host, en kortlivad tjänst eller en DNS-post som inte syns i den valda observationen. Behandla både närvaro och frånvaro med rätt evidensnivå.
Kontrollera grundläggande säkerhetssignaler
När ägaren är bekräftad kan ni följa DNS, TLS, omdirigering, e-postautentisering och synliga tekniksignaler. Kontrollera att certifikatet täcker avsedd host, att gamla protokoll eller felaktiga omdirigeringar inte lämnar en alternativ väg och att viktiga MX- och TXT-poster är avsiktliga. Technikidentifiering kan hjälpa ett team att hitta en gammal plattform, men den är en signal och inte en fullständig versions- eller sårbarhetsanalys.
Ta också hänsyn till förändringstakt. En tjänst som byter namnservrar och certifikat flera gånger under en migrering kan skapa larm utan att risknivån ökar. En stabil host som plötsligt får ny teknik, ny omdirigering och ny ägare kan däremot kräva snabbare kontroll. Koppla larm till godkända ändringsfönster och visa tidigare värden så att teamet kan skilja planerad förändring från överraskning.
Skapa en NIS2-anpassad åtgärdscykel
Gör inventeringen till en återkommande process med fyra lägen: upptäckt, verifiering, åtgärd och uppföljning. Upptäckt kan ske veckovis eller efter större förändring. Verifiering ska ha en tidsgräns och ansvarig. Åtgärd kan vara att säkra, dokumentera, ta bort eller acceptera risken. Uppföljning ska kontrollera att DNS, TLS och ägarskap verkligen ändrats. Ett kalkylblad som aldrig får en andra kontroll är inte ett aktivt riskunderlag.
Integrera resultaten med incidenthantering, förändringshantering och leverantörsstyrning. Ett okänt certifikat kan bli ett säkerhetsärende, en ny subdomän kan bli ett förändringsärende och en saknad ägare kan bli ett ledningsbeslut. Ge teamen en tydlig eskaleringsväg, men undvik att skicka råa tekniska observationer till hela organisationen. Sammanfatta bevis, påverkan och nästa steg för varje mottagare.
Gör rapporten användbar vid granskning
Spara scope, metod, observationsperiod, undantag, datakällor och begränsningar. Visa antal upptäckta och verifierade tillgångar, andel med ägare, öppna högriskfynd och medelålder på bevis. Lägg gärna en sida med förändringar sedan föregående period. En revisor eller ledning behöver kunna förstå vad ni tittade på, vad som inte ingick och vilka beslut som följde, utan att läsa en rå lista på hostnames.
Var noga med åtkomst och personuppgifter. Domän- och DNS-data kan kopplas till personer, kunder eller interna namn. Begränsa rapporten till den information som behövs för beslutet och definiera lagring och gallring. Skicka inte detaljer om okända system i öppna kanaler. En bra attackytarapport minskar risk även genom att hantera sitt eget innehåll varsamt.
Börja med ett begränsat pilotområde, till exempel huvuddomän och kundportal, och följ hela cykeln till stängd åtgärd. Justera statusvärden, ägarroller och larm innan ni skalar till hela portföljen. Då får ni ett arbetssätt som verksamheten kan använda och inte bara en stor engångslista. När ny information kommer ska det vara enkelt att säga vad som ändrats, vem som godkänt det och vilket bevis som finns.
Det viktigaste utfallet är inte ett högre antal upptäckta subdomäner. Det är att organisationen kan svara på vilka publika tjänster som stödjer viktiga processer, vem som ansvarar för dem, vilka risker som är öppna och när de följs upp. Med den kopplingen blir domäninventering ett konkret underlag i NIS2-arbetet och i den dagliga säkerhetsstyrningen.
Gör ägarskap till ett beviskrav
En host ska inte bli grön bara för att någon säger att den är gammal. Be tjänsteägaren bekräfta funktion, data, leverantör, supportväg och planerad avveckling. Om ägaren inte kan hittas ska statusen förbli okänd och få en tidsgräns. Detta kan kännas strängt, men en gammal tillgång utan ägare har ingen som säkert kan patcha, stänga, förnya certifikat eller svara vid incident.
Använd ett tvåstegsbeslut för att undvika att säkerhetsteamet ensamt tar verksamhetsbeslut. Teknik verifierar observation och exponering, medan verksamhetsägare avgör kritikalitet och accepterad åtgärdstid. Juridik eller dataskydd kan behöva delta om data eller leverantörsavtal berörs. Spara beslutet tillsammans med bevisdatum och nästa kontroll så att en ny medarbetare förstår varför ett fynd hanterades på ett visst sätt.
Följ förändringar över tid
En engångsinventering visar bara ett ögonblick. Jämför därför nya observationer med godkända baslinjer och markera när en subdomän tillkommer, DNS flyttas, certifikat byts eller tekniksignaler förändras. Lägg in planerade releasefönster så att larm kan förklaras. Om en förändring sker utanför fönstret ska ägaren bekräfta den, även när resultatet inte ser direkt sårbart ut.
Mät hur snabbt okända fynd får ägare, hur många risker som stängs före deadline och hur stor del av kritiska tjänster som har färska bevis. Presentera både förbättringar och kvarvarande luckor. En rapport som bara visar färdiga kontroller ger ledningen sämre beslut än en ärlig rapport med osäkerhet och en plan för nästa steg.
Använd exempel som verksamheten känner igen
En försäkrings- eller industriverksamhet kan ha en portal för kunder, en separat leverantörsportal och ett gammalt supportnamn. Ett kommunikationsföretag kan ha API, statuswebb och flera regionala domäner. Beskriv risker genom dessa flöden, inte bara genom tekniska etiketter. När verksamheten ser sin egen kundresa i rapporten blir det lättare att hitta ägare och bestämma om en host ska säkras, avvecklas eller accepteras med kontroll.
Lägg en tydlig gräns mellan intern och extern attackyta. Publika DNS- och certifikatsignaler visar inte privata system, och en frånvarande signal bevisar inte att något är skyddat. Komplettera därför domäninventeringen med interna register och behörig verifiering. Rapporten ska säga vad den täcker och vad som kräver en annan kontroll. Den tydligheten är viktig när underlaget används i ledning eller revision.
Efter varje större åtgärd ska fyndet testas igen. Om en okänd subdomän tas bort, kontrollera DNS, certifikat, omdirigering och eventuella länkar efter normal cachetid. Om en tjänst flyttas, uppdatera ägare och kritikalitet samt bekräfta att den gamla exponeringen inte finns kvar. Stäng inte ett ärende på grund av en ändringsbilaga ensam. Stäng när observationen och verksamhetens beslut stämmer överens.