Sök

Nyhetsbrev OT-Säkerhet #25 - Giganter och Konsekvenser

Ett sprängfyllt nyhetsbrev som den här gången förbereder en kamp mellan två giganter, ger ett boktips om konsekvensdrivet säkerhetsarbete, tycker lite synd om Rockwell Automation, diskuterar konceptet "Insecure by design", ger en lång rad spännande lästips och en massa annat!

Nyhetsbrev nummer 25! Något av ett jubileum alltså... Det första nyhetsbrevet skickade jag till fyra läsare. Tydligen fanns det ett och annat intressant bland mina tankar för nu är det flera hundra gånger fler som läser varje utgåva. Det är fantastiskt roligt med ett så positivt gensvar och jag vill verkligen skicka ett stort tack till dig som läser mina spretiga funderingar kring det här spännande ämnet!


Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Med IT använder man teknik för att hantera information. Inom OT använder man liknande teknik men för "Operations", alltså att få fysiska saker under kontroll. Det kan exempelvis vara att styra maskiner i en fabrik, elproduktionen i ett kraftverk eller kemiska processer i ett raffinaderi. Inom IT är fokus ofta på att skydda hemligheter men inom OT blir det oftast viktigast att hålla en funktion tillgänglig och korrekt. Det innebär att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är anledningen till mina texter.


Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att dra ett mejl till mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!


Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i en egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se. Framöver kommer också en kopia publiceras på Ateas officiella blogg.


Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på den här artikeln och genom att dela den vidare. Tack för hjälpen!

Så olika men ändå så lika!

Något jag slås av varje gång jag träffar nya verksamheter för att prata säkerhet är hur olika de ser ut på ytan, men hur mycket som går igen när man tittar innanför skalet! Ett sågverk kan väl inte ha mycket gemensamt med tillverkning av biogas? Hur kan en industrihamn vara besläktad med eldistribution? Man kan tycka att skyddet av medicintekniska system i sjukvården inte borde ha jättemycket att göra med en högteknologisk tillverkande industri men de har de! De har olika namn på saker och de har lite olika prioriteringsmetoder men de är alla ute efter att skydda fysiska funktioner från störningar och ganska ofta också att människor skyddas från att skadas fysiskt på grund av manipulerade eller störda OT-system. Miljöpåverkan är också ofta en risk som har stort fokus.


En annan likhet mellan just sjukvård och hitech-tillverkning är att de både måste skydda väldigt känslig information i sina OT-system och se till att systemen i sig fungerar exakt som det är tänkt. I riskanalyserna hamnar man ofta på väldigt låga sannolikheter och extrema konsekvenser vilket ju kan kräva ett lite speciellt synsätt. Just detta är temat för mitt boktips lite längre ner där en väldigt intressant metod beskrivs.

I förra nyhetsbrevet frågade jag om intresset för någon form av nätverkande eller onlineforum kring OT-säkerhet. Av svaren att döma verkar det glädjande nog som att intresset är stort. Jag tror just att mötet mellan människor från olika branscher som alla har ett intresse av OT-säkerhet kan bli riktigt spännande och roligt tack vare de oväntade likheterna mellan deras utmaningar!


Det visade sig att mina tankar på någon form av diskussionsforum kring OT-säkerhet sammanföll med Karl Emil Nikkas tankar om något motsvarande fokuserat på IT- och informationssäkerhet. Du är kanske med i gruppen Säkerhetsbubblan på Facebook som han ligger bakom tillsammans med Jonas Lejon? Vi insåg direkt att det är bäst för alla om vi skapar ett gemensamt ställe att diskutera alla former av säkerhetsfrågor. Herr Nikka hade redan kommit en bra bit på väg i sina planer så då väljer jag att skrota mina egna planer och lägger min energi på att stötta honom i arbetet för en gemensam plats. Vi återkommer framöver med mer information...

Intresset för att träffas och diskutera OT-säkerhet var också stort. Fysiska träffar avvaktar jag förstås lite för att se hur det går med pandemin. Någon form av digital träff skulle det däremot kunna bli framöver. Clubhouse hade ju kanske varit ett kul upplägg. Jag tar gärna emot förslag och tankar på former, teman och metoder! Om någon har en Clubhouse-inbjudan att skicka till mig så tar jag den gärna, måste bara skaffa en äpple-telefon också...


För någon vecka sedan skapade jag en omröstning på LinkedIn om vilka delar av nyhetsbrevet som mina läsare vill se mer av. (Det är inte försent, tyck gärna till fortfarande!) Det verkar så här långt vara många som gillar dagens upplägg men med önskemål om att "Mats Filosoferar" ska ta lite större utrymme och även mina tankar kring aktuella händelser. Jag kommer förstås ta till mig önskemålen framöver!

Giganternas kamp!


Det är verkligen ingen hemlighet att jag tycker det är roligt att jag stöter på så mycket spännande teknik i mitt arbete. Nu måste jag säga att det är två ovanligt coola prylar som står i labbet och väntar på sin tur. Jag kan riktigt höra hur de frustar och stampar i marken som de båda fullblod de är.

I den ena ringhörnan står en maskin som jag har nämnt i tidigare nyhetsbrev. Det är Pro-versionen av IPSen från TxOne, kallad "EdgeIPS Pro". De har tagit deras lilla ruggade OT-IPS som du kan läsa mer om i nyhetsbrev #23 och gjort en datacenter-version som innehåller 24 stycken separata IPS-segment! Dessutom har de kryddat anrättningen med en del extra funktionalitet. Det här är 16 kg brutal OT-IPS som i princip ska klara att maxa alla 24 Gigabit segmenten samtidigt! Det finns faktiskt en dubbelt så stor maskin också, men den har jag inte lyckats få fingrarna på ännu... Ett typiskt use-case för Pro-versionen är när man inte vill bygga in de små EdgeIPS-enhetern från TxOne i respektive maskin som ska skyddas utan hellre samlar skyddet i ett nätverksrum eller datacenter. Ett extra tack till TxOne som skickade den första Pro-burken i Norden direkt till mig! Det här ska bli riktigt roligt!

I den andra ringhörnan står en riktig doldis för de flesta. Det är en "ixia PerfectStorm One" från Keysight. Keysight har jag nämnt tidigare, exempelvis deras fina lilla tap "IxTap" i nyhetsbrev 17. Den ser ärligt talat inte så mycket ut för världen, men specen säger någonting helt annat! Tanken med den här besten är att skapa verklighetstrogen testtrafik för att provskjuta mot olika typer av nätverkssäkerhetsutrustning. I den här kör man en programvara kallad "BreakingPoint" vilket är ett mycket passande namn... Genom de 8 portarna med SFP+ kan du skapa och pressa igenom 80 Gb/s av testtrafik. Det är dessutom inte vilken testtrafik som helst utan du kan krydda med mängder av attacker och skadlig kod. I det enorma biblioteket med elakheter finns en rejäl dos OT-specifika attacker att välja från. Det typiska use-caset är att simulera trafik för exempelvis en brandvägg genom att helt enkelt stadigt öka på med trafik tills brandväggen inte klarar mer och kastar in handduken!


De här två tänkte jag matcha mot varandra framöver. Det kommer bli en intressant match mellan två riktiga tungviktare! Vi får hoppas att propparna och luftkonditioneringen håller för det kommer bokstavligen gå hett till! Vadslagning på vinnaren, någon?

"Ooops!" eller "Insecure by design"

Nyligen fick amerikanska automations-giganten Rockwell Automation (mest kända för varumärket Allen-Bradley) ett delikat problem kring en sårbarhet i en låååång radda av deras Logix-controllers. Sårbarheten fick dessutom CVSS-poäng 10, dvs den absolut värsta graderingen en sårbarhet kan få. Med tanke på att det var en bugg som gjorde det enkelt att helt ignorera alla former av inloggningskrav i produkterna var betyget kanske inte så förvånande. Det blev inte bättre när Rockwell några dagar senare tvingades annonsera att problemet inte skulle gå att lösa med en patch!

Det är inte klart för mig ännu varför sårbarheten inte går att adressera med en patch, spontant är den enda förklaringen att sårbarheten på något vis är kopplad till hårdvaran - vilket låter osannolikt. Vi får se hur den här historien utvecklar sig...


Jag hade egentligen tänkt att skriva en liten text om begreppet "Insecure by design" vilket INTE ALLS avser det som Rockwell råkade ut för, alltså produkter som designats lite tokigt och därmed är osäkra. Det här är ett begrepp som blivit populärt under senaste halvåret i diskussioner kring hur vi bygger våra automationssystem. Jag har hört lite olika varianter men min egen tolkning är att "insecure by design" avser faktumet att många komponenter och protokoll inte behöver "hackas" för att manipuleras - de är helt enkelt utformade för att göra som de blir åtsagda, oavsett vem det är som skickar ordern.


Det låter som ett lite löjligt resonemang men det är förvånansvärt ofta man springer på situationer när någon är upprörd över att de hittat ett opatchat system och hävdar att det är ett hot mot verksamheten. Om det råkar vara ett system som är "Insecure by design" pekar man då på faktumet att, även om systemet var helt uppdaterat, så kör det en mjukvara som inte behöver hackas för att en angripare ska manipulera den fysiska processen. Allt man behöver finns till och med beskrivet i manualen!


Nu var det som sagt inte det här som Rockwell drabbades av även om effekten i slutändan blev den samma. Sista ordet är inte sagt kring vare sig deras sårbarhet eller hur man ska värdera sårbarheter i OT-system...

Konsekvensdrivet säkerhetsarbete - Ett boktips!

Som jag teasade om i förra nyhetsbrevet så kommer här en berättelse om vad jag lärt mig av boken "Security PHA Review for Consequence-Based Cybersecurity" och något slags recension av boken.


Boken gör en grundlig genomgång av SPR-metoden på cirka 140 sidor och gör det på ett sätt som känns lättillgängligt för de flesta läsare. SPR, som ska uttalas som det engelska ordet "Spur", syftar till att flytta fokus inom OT-säkerhetsarbetet bort från att skydda varje komponent och istället fokusera på att göra den fysiska processen "ohackbar" och därmed säker. (SPR är en förkortning av "Security PHA Review".)


Det är viktigt att ha med sig att det man vill uppnå med SPR är framför allt att säkerställa att vi inte har ihjäl folk, skadar miljön eller orsakar stora fysiska skador som är svåra och dyra att åtgärda. Därför är det en metod som framför allt passar i processindustrier och då speciellt i verksamheter som har farliga moment i sin produktion.

Eftersom man utgår från processen i den inledande riskanalysen, istället för att göra det som ISA/IEC 62443 kallar "en riskanalys på hög nivå", så identifierar man mycket lättare de ställen där skydd av OT-systemen kan göra verklig nytta för skyddet av processen. På samma sätt påpekar de att det som 62443 kallar "detaljerad riskanalys" inte alls är en riskanalys utan snarare en granskning av den design som tagits fram. Det här angreppssättet tar hand om ett av de områden som alltid stört mig i 62443-standarden och gör det på ett riktigt elegant sätt. Jag hoppas att få omsätta det här arbetssättet i ett verkligt projekt snart, det ska bli intressant! Man inser att man är en riktig nörd när man går igång på sådana här insikter...


Författarna sågar ett antal andra metoder, som till namnet verkar vara ungefär samma sak, vid fotknölarna. Metoder som "Cyber PHA", "Cyber HAZOP" och "CHAZOP" siktar i praktiken på något helt annat och liknar egentligen mer feleffektsanalys (FMEA, "Failure Mode and Effects Analysis"). De har alla sin plats men med andra syften.

Det som jag kanske gillar allra mest med SPR är att man tar ett rejält kliv bort från skogen och då plötsligt kan se träden. Andra verktyg tenderar ofta att bli väldigt detaljfokuserade, tekniska och omständliga men missar ironiskt nog det egentliga målet att skapa en översiktlighet av risker och hot. Man försöker göra något åt vartenda träd i hela skogen i förhoppningen att skogen borde bli bättre. I SPR börjar vi med att titta på skogen för att sedan välja vilka träd som är viktigast att göra någonting åt.


Tidigt i boken gör de upp med några av de (som jag tycker) mest störande bristerna som man stöter på i "klassisk" analys av sårbarheter och risker. De hävdar (och jag håller med) att:

  • Att en säkerhetsbrist i sig inte har någon konsekvens förrän någonting händer som gör att bristen påverkar processen. Ett trasigt bilbälte får ingen konsekvens förrän man krockar.

  • Eftersom det finns så många konsekvenser av varje sårbarhet blir det omöjligt att veta vilka konsekvenser som inte kan uppstå eftersom de förhindras av någon helt annan säkerhetsfunktion eller någon begränsning i den fysiska processen. I en bil som bara går att köra i 5 km/h kanske ett trasigt bilbälte inte är ett problem men hur vet du bilens maxfart om du bara tittar på skyddet av föraren?

  • Eftersom det nästan alltid finns massor med tänkbara konsekvenser av en sårbarhet blir sårbarheten också omöjlig att bedöma. Ett stulet lösenord kan användas på extremt många olika sätt, men vilka är värst och vad betyder det för risken av händelsen "Stulet lösenord"? Man tvingas ofta använda något slags påhittat värsta scenario.

  • I många metoder är sannolikhet eller frekvens en viktig faktor för riskbedömningen vilket sällan är en meningsfull bedömningsgrund. Hur bedömer du sannolikheten för att en hacker lyckas hacka just ditt system? Hur ofta det har skett historiskt? Kommer de verkligen ge upp om de misslyckas i de första 20 försöken? Sannolikheter fungerar bra för slumpmässiga händelser men är väldigt mycket sämre för beslutsamma och medvetna mänskliga angripare.

Just alla de där godtyckliga sannolikhetsbedömningarna som görs är nog den största anledningen till att jag genomlidit så många meningslösa workshops för riskanalyser. Ett annat alternativ som fungerar i många viktiga situationer är att använda kvantitativa metoder. Men det är en annan historia som har sitt eget existensberättigande. Vill du läsa mer så har jag skrivit om det i Nyhetsbrev #16.


SPR-metoden bygger på att det redan finns någon form av PHA- eller HAZOP-liknande analys som man återanvänder genom att ta alla felscenarier och skydd från den och utökar dem med bedömningar av deras "hackbarheten" . Om man inte har sådana analyser får man helt enkelt göra det som en del av SPR-arbetet. Enkelt uttryckt kan man säga att en HAZOP-analys är ett systematiskt sätt för en grupp experter att identifiera alla sätt saker kan gå snett oavsett orsak och vilka skydd som finns för att motverka att farliga situationer uppstår. Om man ska summera vad SPR-metoden lägger till på ett extremt komprimerat sätt så blir det:

  1. För varje källa till avvikelser i processen analyserar man om den går att provocera fram genom att hacka en utrustning. Är den inte hackbar så är inte scenariet hackbart. (Här har jag en viktig invändning mot författarnas resonemang, se nedan.)

  2. Om källan är hackbar tittar man på de skydd som finns i processen. Om något av dem inte är hackbart så antas de skyddet motverka avvikelsen och därmed är scenariet inte heller hackbart. (Även här har jag invändningar, se nedan.)

  3. Om både källan och alla skydd är hackbara blir hela scenariet hackbart och då måste man hitta åtgärder. Åtgärderna kan bestå i att införa icke hackbara skydd eller att man höjer säkerhetsnivån i systemet. (Man använder då begreppet SL-T från ISA/IEC 62443, "Security Level Target".)

  4. Repetera för alla system och zoner. Sammanställ resultatet för helheten. Inför åtgärderna som identifierats.

Vad är det då för invändningar jag har? Ja, det är faktiskt flera stycken...

  1. Enligt boken måste en hackbar komponent gå att nå med ett routbart nätverksprotokoll. I min värld så kan man mycket väl manipulera ett system även om det inte går att komma åt det, om det är möjligt att manipulera dess programmering utan att det upptäcks. I min erfarenhet är ofta utvecklingsmiljöer mindre skyddade än de system dit programvaran sedan flyttas. Man kan också vända sig mot att de kräver routbarhet eftersom det i så fall missar situationer där man hoppar mellan system med någon form av direktanslutning emellan dem.

  2. Författarna kräver