Nisses skola - Cyber security - Inte bara en IT-fråga
Cybersäkerhet är en fråga som de flesta som jobbar med automation inte vill beröra, det har ofta att göra med att IT (Informations Teknologi) och OT (Operational Technology=Automation) har olika behov. Vi som jobbar inom automation har en förmåga att lämpa över denna frågeställning till IT-avdelningarna, gärna med lite klagomål samtidigt för att utförligt berätta att IT-avdelningen förpestar vår tillvaro och gör livet svårt. Resultatet gör att vi ofta hamnar i interna konflikter, då meningarna går isär, ofta på grund av att IT och OT har helt olika syften.
Poängen är att syftena är olika och de måste vara olika. Olika är bra.
Skillnaden mellan OT och IT
Exempel: Skillnad mellan IT och OT
Ett praktiskt exempel är att det är acceptabelt inom IT-värden att installera en Windows uppdatering ca. 1 gång i veckan med en påtvingad omstart utan att någon reagerar på något sätt. Men skulle automationsavdelningen jobba på samma sätt och uppdatera firmwaren på styrsystemen skulle detta resultera i helt andra saker. Ta t.ex. ett styrsystem som sitter installerat i t.ex. ett pappersbruk eller i en maskin som tillverkar juiceförpackningar. Ställ dig frågan: Vad skulle hända om vi måste göra en omstart?
Förmodligen skulle detta resultera i att företaget förlorar inkomster, då maskinen inte kan producera, bieffekten kan även vara att vi måste tömma hela processystemet på ev. gamla ingredienser som ingår i produkten vi skall tillverka, som blivit dålig eller felaktig p.g.a. stoppet vi just genomförde.
Man skulle kunna säga att OT/automationen generellt, av uppenbara anledningar har inställningen ”If it ain´t broke, don´t fix it”.
Kraven på tillgänglighet/driftsäkerhet är uppenbarligen helt annorlunda mellan IT avdelningen och automationsavdelningen. Automationen får helt enkelt inte tiden att som IT -sitta och ”tweaka” nätverket allt eftersom man har automatiskt uppdaterat någon enhet. Helt enkelt för att påverkan av detta blir allt för stort, efter idrifttagningen/FAT skall applikationen helt enkelt rulla säkert, helst 25 timmar/dygn 375 dagar/år utan avbrott, därför måste enheterna/systemet vara oerhört stabilt.
Det faktiska nätverket är ofta inom IT-avdelningarna ett stort fokus. Detta till skillnad från synsättet på nätverk inom automation/OT. Där nätverket ofta är mer som ett ”verktyg” eller ett bärande media och absolut inte en huvuduppgift.
Nätverkets funktion inom automation är helt enkelt för att kunna realisera distribuerade in och utgångar (från t.ex. Profinet) samt anslutningar från olika enheter som ligger utspridda i maskinen eller anläggningen, nätverket som sådant har egentligen ingen egennytta i sig själv utan är bara en förlängning av bakplanet på en dator för att slippa dra massor av parallellkablar från givare, ställdon etc. Detta då tillverkningsprocessen, INTE infrastrukturen är det stora fokuset för automationsfolket. Helst skall de individuella delarna klara sig själva, även om anslutningen/kommunikationen till det överordnade nätverket förloras. (Inte som i IT-fallet där man ofta har stora centrala väl kylda serverhallar och 28-portars switchar som sitter rad efter rad i 19”-rack med resultatet automation hade för 20 år sedan med parallelldragning istället för fältbuss)
Automation är komplext, finns det resurser?
Automation köper ofta in extremt komplexa tillverkningsmaskiner som har en optimerad uppgift, det är mer eller mindre omöjligt att vara expert och ha kunskap om varje egenskap i dessa komplexa maskiner om man inte har en egen maskinbyggaravdelning på fabriken. Samtidigt är det ur företagssynvinkel väldigt viktigt att dessa maskiner (produktionen) alltid kan tillverka, då det är just dessa maskiner som genererar företagets inkomster.
Därför finns det ofta behov av att användaren av den specifika maskinen skall få snabb och effektiv support av sin leverantör (som förhoppningsvis har 100% kontroll på sin maskin). Detta realiseras ofta med någon slags remote/fjärranslutning eller ett serviceavtal där maskinleverantören hjälper användaren att hålla maskinen igång.
Brandväggen från IT-avdelningen skyddar automationen?
Den normala inställningen idag är att maskinerna i ”fabriksnätverket” är skyddade då all Internettrafik kopplas ihop genom IT-avdelningens brandvägg där anslutningen till Internet sker. Men är detta verkligen sant?
Problemet med den ovannämnda servicegrad som krävs, är att denna remoteanslutning eller anslutning av ”främmande” datorer från maskinleverantören gör ett hål på IT-avdelningarnas brandvägg. Då modemet/servicedatorn som följer med maskinen skapar en bakdörr från Internet till fabriks-nätverket. Självklart kan detta även ske kontrollerat med en krypterad VPN-tunnel och ”best practice” brukar vara att sätta maskinen som VPN-klient, men detta är en helt annan historia.
Resultatet av integrering av komplexa produktionsmaskiner i företagsnätverket. Säkerheten förloras då bakdörrar är öppna exempel är ”varningstrianglarna!”
Som kan ses i ovanstående bild är IT´s brandvägg inte ett skydd för automationen. I verkligheten sitter det 4G modem i maskiner, datorer med laptops med mjukvaror installerat som t.ex Teamviewer för fjärrsupport etc. Detta kommer att resultera i access till allt bakom IT-brandväggen.
Förslag på lösning: Dela upp produktionen/nätverket i celler.
I en perfekt värld skulle vi plugga igen alla USB-portar, låsa alla hårddiskar, ta bort alla möjligheter till oönskad kommunikation men detta är inte realistiskt i verkligheten. Då resultatet av detta är att maskinparken förmodligen skulle bli väldigt säker, men i praktiken oanvändbar.
Med automationen (OT) d.v.s. företagets huvudinkomstkälla som utgångspunkt måste det vara enkelt att konfigurera upp ev. skydd för oönskad trafik.
Så vi måste tänka kreativt.
Genom att isolera produktionsenheterna i enskilda produktionsceller, dels genom separata subnätverk och separata brandväggar. Detta tankesätt tar inte bort risken, men begränsar skadorna som kan uppkomma och om något skulle uppkomma är skadan isolerad. Dessutom passar tankebanan bra med den sedan länge vedertagna tanken med distribuerade styrsystem och I/O´n.
Brandvägg: Vad är det?
En brandvägg är egentligen inget annat än ett ”filter”. Detta filter kan ställas så vi kan tala om vilken enhet (källans IP-adress, t.ex. en PLC, ett IO, frekvensomformare etc.) som får skicka en viss typ av telegram (TCP, UDP etc.) till vilken enhet (målets IP-adress t.ex. en ny PLC, SCADA en filserver etc.) samt vilka portar som programmet ifråga använder (t.ex. Modbus telegram brukar ligga på port 502, vanlig TCP/IP brukar ligga på port 80 etc.). Dessa parametrar är något som vi måste ställa in i vår brandvägg. Teoretiskt ganska enkelt, men handen på hjärtat.
-Vet du vilka enheter i ditt nätverk som pratar med vilka enheter och vad dom pratar om?
Svaret på denna fråga bör vara ja, men förmodligen är det inte så.
Praktiskt kan man spegla alla portar och t.ex. spela in trafiken med wireshark (en mjukvara som sniffar trafik) och sedan analysera loggen man spelade in, eller köpa in ett specifikt program för detta ändamål. Sedan försöka trigga alla möjliga scenarion i maskinen. Det är dock i praktiken ganska sällsynt att detta genomförs i den verkliga värden utanför mötesprotokollet.
Skapa brandvägsregler automatiskt
För att lösa detta har Phoenix Contact frågat mängder av automationskunder runt om i världen, tagit fram en lösning för att på enklast möjliga sätt skapa dessa brandväggsregler med alla parametrar som behövs.
Resultatet av all erfarenhet och kunddialoger är en säkerhetsprodukt som vi kallar mGuard.
Denna nya generation av mGuard kan automatiskt generera de brandväggsregler (vilka enheter skall kommunicera med vilka protokoll och vilka portar) som applikationen kräver. Installationen är redan från skrivbordet optimerat för ”Icke IT-personal”, förfarandet är så förenklat det bara kan bli.
1/ Anslut mGuarden mellan produktionsnätverket och den produktionscell man vill isolera (förslagsvis utan att koppla in Internetanslutningen)
2/ Starta den automatiska brandväggsinlärningen i mGuarden, genom ett klick i webgränsnittet.
3/ Kör maskinen i ca 2 veckor eller tills all funktionalitet är genomprovad.
4/ Aktivera brandväggen.
All trafik som kördes under dessa 2-veckor kommer fortsätta att fungera, men…trafiken som inte registrerades under dessa 2-veckor av test kommer effektivt att blockeras och filtreras bort. Enkelt och logiskt!
Men vi expanderar vår maskinpark
Optimering, ökning av produktionskapacitet, förändring av processer. Detta är vardagsfrågor för automationen. Innebörden av detta är förmodligen en förändring av nätverket, produktionsstrukturen.
Resultatet av detta blir återigen förändringar i vägarna som nätverkstrafiken går, kanske något nytt protokoll. Vilket i sin tur innebär förändringar i brandväggsreglerna.
Vi är med andra ord tillbaka på ruta ett.
För att lösa denna uppgift har Phoenix Contact i mGuarden lagt in ett ”teach mode”. Vilket innebär att vi under drift behåller de regler vi tidigare satte upp (2-veckorsdriften), men fångar upp och loggar nytillkommen nätverkstrafik.
När ett obekant telegram registreras, kan mGuarden automatiskt skicka ett meddelande i form av en SNMP-trap eller ett mail till en fördefinierad e-postadress. Detta så att man manuellt kan godkänna de ev. nya reglerna som krävs för att kommunikationen i produktionen skall fungera. Detta ”teach mode” kan även självklart användas för att detektera förändringar i nätverket för ev. åtgärder innan något allvarligt inträffat.
Summering:
Tyvärr är det nog omöjligt att skapa ett 100% säkert industrinätverk, men du kan begränsa skadorna och vidta åtgärder så det blir extremt mycket svårare och säkrare utan att tumma för mycket på användarvänligheten. De nya brandväggarna i mGuard serien från Phoenix Contact är optimerade för automation, ger säkerhet som IT-kräver, utvecklade för folk som jobbar inom automation.
Olika men ändå lika, olika är bra.