Vanliga säkerhetsbrister i uppkopplade fastighetssystem

De vanligaste problemen är sällan svåra att beskriva. Fastighetsägaren saknar en aktuell systembild, nätet har otydliga gränser eller fjärråtkomsten lever vidare efter avslutat uppdrag. Äldre utrustning kan dessutom sakna uppdateringsstöd. När loggar och fungerande säkerhetskopior saknas blir även en begränsad händelse dyr att utreda och återställa.

Här går vi igenom sex återkommande brister och visar var ni bör börja.

Fastighetssystem kräver en annan takt än kontors-IT

Byggnadsautomation, passersystem och fysisk miljöövervakning är exempel på operativ teknik, OT. Systemen påverkar den fysiska miljön och behöver ofta fungera dygnet runt.

Det påverkar säkerhetsarbetet. En uppdatering, nätverksändring eller aktiv säkerhetstest kan störa en funktion som hyresgäster och driftpersonal är beroende av. Varje åtgärd behöver därför en konsekvensbedömning, en testad arbetsgång och en väg tillbaka.

Försiktigheten får samtidigt inte bli ett skäl att lämna kända brister orörda. Planera förändringen tillsammans med driftansvarig, systemleverantör och nätansvarig. Då går det att stärka skyddet utan att ta onödiga risker i produktionen.

1. Ingen vet vilka enheter och dataflöden som finns

En tillförlitlig inventering saknas ofta i äldre eller ombyggda fastigheter. Dokumentationen visar kanske huvudsystemen men missar gateways, fristående modem, leverantörsroutrar och äldre styrenheter.

Konsekvensen är konkret. Ni kan inte bedöma sårbarheter, supportstatus eller exponering för utrustning som saknas i förvaltningsbilden. Felsökningen tar också längre tid eftersom beroenden och kommunikationsvägar är okända.

Börja med en passiv inventering där det är möjligt. Dokumentera enhet, funktion, ansvarig, nätanslutning, program- eller firmwareversion, supportstatus och nödvändiga dataflöden. Förvalta sedan informationen som en levande tillgång, inte som en engångslista från projektet.

2. Nätet har otydliga eller öppna gränser

Ett platt nät låter många system nå varandra trots att funktionerna saknar behov av direkt kommunikation. Även ett nät med flera VLAN kan vara öppet om trafiken mellan segmenten inte filtreras.

Segmentering behöver utgå från funktion, risk och ansvar. Fastighetsnätet bör som normalmodell vara skilt från verksamhets- och kontorsnätet. Inom fastighetsnätet skiljer ni tekniska system åt och tillåter bara dokumenterade dataflöden över kontrollerade gränser.

Kontrollera brandväggsregler och undantag löpande. En tillfällig öppning som blir permanent skapar samma problem som en ursprungligen öppen gräns.

Segmentering skyddar inte i sig innehållet i kommunikationen. Kontrollera också hur inloggningsuppgifter, mätvärden och styrkommandon skyddas under överföring. Använd krypterade anslutningar och verifiera motpartens identitet där systemen stöder det. Äldre utrustning kan sakna dessa möjligheter. Begränsa då kommunikationsvägarna, skydda anslutningen till överordnade system och dokumentera kvarvarande risk och planerade åtgärder. Anpassa lösningen till systemets funktion och testa driftpåverkan före ändring.

3. Leverantörer har permanent eller ospårbar fjärråtkomst

Fjärrservice sparar tid och resor. Risken ökar när varje leverantör använder en egen lösning, delar konton eller behåller åtkomst utan slutdatum.

Fastighetsägaren behöver äga åtkomstmodellen. Använd personliga konton, minsta nödvändiga behörighet och en centralt godkänd anslutningsväg. Begränsa åtkomsten i tid och logga vem som ansluter, när anslutningen sker och vilket system som nås. Flerfaktorsautentisering bör skydda fjärråtkomsten där tekniken medger det.

Inventera även inbyggda moln- och fjärrfunktioner. En tjänst kan vara aktiverad från leverans trots att förvaltningen aldrig har beslutat att använda den.

Samma genomgång behövs för lokala användare och systemkonton. Skilj daglig drift från administration och ge varje konto de rättigheter som uppgiften kräver. Ett konto som används av en integration behöver också en ansvarig och ett dokumenterat syfte. Följ upp behörigheter när uppdrag eller roller ändras och avveckla konton som inte längre behövs, efter kontroll av systemberoenden.

4. Uppdateringar och produktlivscykel saknar ägare

Fastighetstekniska system används ofta längre än vanliga IT-system. Under tiden upptäcks nya sårbarheter, medan leverantörens support kan ändras eller upphöra.

En patchlista löser bara en del av frågan. Ni behöver veta vem som bevakar sårbarheter, vem som bedömer driftpåverkan och hur uppdateringen testas. Avtalet bör också ange supporttid, säkerhetsuppdateringar och vad leverantören gör när en produkt når slutet av sin livscykel.

Äldre utrustning går inte alltid att uppdatera direkt. Dokumentera då risken och inför tidsatta kompensationsåtgärder, exempelvis snävare kommunikationsvägar och tätare övervakning. Planera samtidigt för utbyte. En tillfällig lösning behöver ett slutdatum.

5. Loggar finns, men ingen använder dem

Många system loggar inloggningar, larm och konfigurationsändringar lokalt. Det hjälper föga om tiden är fel, lagringsutrymmet tar slut eller loggen raderas innan någon hinner granska den.

Bestäm vilka händelser som behöver sparas och hur de ska samlas in. Prioritera fjärrinloggningar, ändrade behörigheter, konfigurationsändringar, kommunikationsfel och säkerhetsrelaterade larm. Synkronisera tiden och skydda loggarna från obehörig ändring.

Loggning behöver också en mottagare. Ange vem som följer upp avvikelser, vilka larm som kräver åtgärd och hur en händelse lämnas över till incidenthanteringen.

6. Säkerhetskopian har aldrig återställts

En grön symbol i backupverktyget visar att en kopiering har körts. Den visar inte att rätt data finns med eller att ett styrsystem kan återställas inom verksamhetens tidskrav.

Säkerhetskopiera de delar som krävs för att återskapa funktionen: konfigurationer, program, databaser, licensuppgifter och nödvändig systemdokumentation. Skydda minst en kopia så att samma incident inte kan ändra både produktionsmiljö och backup.

Testa återställningen under kontrollerade former. Resultatet ska visa vem som gör arbetet, vilka beroenden som finns och hur lång tid återgången tar. Koppla testet till ändringshantering och kontinuitetsövningar.

Kontrollera grundkonfigurationen innan systemet lämnas över

En produkt kan fungera som avsett och ändå vara osäkert konfigurerad. Standardlösenord, oanvända konton och aktiva tjänster kan finnas kvar efter installationen. Gå igenom grundinställningarna med leverantören, byt standardlösenord och inaktivera konton, tjänster och portar som inte behövs. Kontrollera beroenden innan något stängs av så att åtgärden inte slår ut drift eller service. Hantera lösenord och andra åtkomstuppgifter i en skyddad lösning, inte i öppna överlämningsdokument.

Överlämningen behöver visa mer än att anläggningen går att starta. Kontrollera att överenskomna säkerhetsinställningar är införda och att dokumentationen beskriver den levererade miljön. Underlaget behöver täcka enheter och programversioner, nödvändiga kommunikationsvägar, behörigheter, fjärråtkomst samt ansvar för uppdateringar, loggar och återställning. Säkerställ också en fungerande kontaktväg till leverantören vid säkerhetsproblem.

Dokumentera vad som har verifierats och vilka brister som återstår. Om ett krav inte kan uppfyllas behöver systemägaren kunna ta ställning till risken, eventuella skyddsåtgärder och en tidplan. Ett undantag ska ha en ansvarig och följas upp i förvaltningen; det bör inte försvinna i ett gammalt projektprotokoll.

Otydligt ansvar gör varje teknisk brist större

Fastighetssystem passerar genom projekt, entreprenad, garanti och löpande förvaltning. Ansvar faller lätt mellan beställare, nätorganisation, drift och systemleverantör vid varje övergång.

Utse därför en tillgångsägare eller systemägare för varje system. Rollen behöver hålla ihop risk, behörigheter, livscykel, dokumentation och leverantörskrav. Leverantören ansvarar för sin produkt och avtalade tjänst. Fastighetsägaren behåller ansvaret för den samlade miljön och beslutar vilka anslutningar som tillåts.

IEC 62443-serien beskriver detta som ett delat ansvar genom automationssystemets livscykel. Standarden kan ge struktur även när organisationen inte har ett formellt krav på certifiering.

Prioritera åtgärder efter driftkonsekvens och exponering

Börja inte med en lång lista över tekniska kontroller. Börja med de funktioner som kan orsaka störst konsekvens om de blir otillgängliga eller felstyrda.

En avgränsad nulägesanalys ger ett bättre beslutsunderlag än en bred teknisk skanning utan verksamhetskontext. Den ska visa brist, möjlig konsekvens, rekommenderad åtgärd, ansvar och tidplan.

Börja med en granskningsbar nulägesbild

Ni behöver veta vad som finns, vem som ansvarar och vilka beroenden som påverkar driften. En riktad genomgång av fastighetsnät, system och leverantörsåtkomster ger underlag för en prioriterad åtgärdsplan.

Läs mer om Attivas arbete med IT/OT-säkerhet och fastighetsautomation. Kundcaset Tekniskt spridningsnät visar hur standardisering, dokumentation och segmentering kan stärka kontrollen i ett fastighetsbestånd.